[mvanhorn]

What does this PR do?

That call now passes false for the error argument when the method is server/discover and true for every other unknown method, so the probe is logged as level=info with status=ok while other misses stay level=warn and status=error. The JSON-RPC response is still -32601 Method not found. The new test server_handle_discover_probe_logs_info checks those log fields, checks that unknown/method still logs a warning, checks that an initialize request for 2026-07-28 still negotiates 2025-11-25, and checks that resources/list still returns an empty resource list.

Every connect from a current MCP client sends server/discover first. This server answers with JSON-RPC -32601 Method not found, and the daemon records that reply as a warning with status=error, so each successful session leaves one recurring error line even though initialize and the later calls succeed. The method-not-found path in cbm_mcp_server_handle always called cbm_log_mcp_request with the error argument set to true, which is written as level=warn and status=error. server/discover is not implemented, so the modern connect probe takes that path and gets the same log treatment as any other unknown method. The -32601 body is the fallback signal a legacy server is supposed to return so the client continues with initialize.

Fixes #2433

Checklist

• Every commit is signed off (git commit -s) — required, CI rejects
  unsigned commits (DCO, see CONTRIBUTING.md)
• Tests pass locally (make -f Makefile.cbm test)
  Not claimed: ran ./scripts/test.sh locally; it hit its time limit before finishing.
• Lint passes (make -f Makefile.cbm lint-ci)
  Not claimed: make -f Makefile.cbm lint-ci was not run locally either.
• New behavior is covered by a test (reproduce-first for bug fixes)

AI was used for assistance.

[github-actions]

Thanks for opening this — it has been seen, and it is queued.

This note is automated, but it is not a brush-off: it exists so you know where your PR stands instead of having to guess from silence.

Current review status: working through a backlog. 0.9.1-rc.1 is out, so the release freeze that held reviews is over — but it left a large queue of open pull requests behind it, and we are reading through them oldest-first. The background is in discussion #1144.

What that means for this PR, concretely:

• It will not be closed for inactivity. No stale bot touches pull requests here.
• It may still sit a while before a human reads it. That is on us, not on you.
• Older PRs are read first, so a recent one is not being skipped — it is behind a queue.

Things that will genuinely speed it up whenever review does happen:

• Keep it rebased on main — the tree is moving quickly right now, and a conflicting branch cannot be reviewed as the diff you intended.
• Get CI green, or say which failures you believe are pre-existing.
• Keep the change to one claim. Bundled features and refactors get split before they get merged, which costs you a round trip.
• Every commit needs a sign-off (git commit -s) — CI enforces DCO.

If this fixes a bug, a reproduction we can run is worth more than a description of the symptom.

Thanks for contributing, and sorry in advance for the wait.

[DeusData]

Thanks for documenting the server/discover logging change and the unchanged JSON-RPC fallback. I have read the proposal and the incomplete local validation notes; it remains pending review.

[DeusData]

Thank you, Matt! This is exactly the right size of fix for #2433. Keeping the -32601 reply untouched means current MCP clients still fall back to initialize the way the spec describes for servers on the 2025-11-25 revision, while the server/discover probe no longer leaves a warn/error line in every daemon log. Every other unknown method still warns, so real misses stay visible.

The test is a great example of what we like to see: it pins the probe's log fields, proves an unknown method still logs a warning, and guards the initialize fallback and the empty resources/list along the way. We brought the branch up to date with current main and it passed CI there before merging. Much appreciated!