`server/discover` returns `-32601 Method not found`, so every modern MCP SDK connect logs an error

Version

codebase-memory-mcp 0.11.0

Platform

macOS (Apple Silicon)

Install channel

GitHub release archive / install.sh

Binary variant

ui

What happened, and what did you expect?

The current official MCP SDK client uses server/discover as its default connect probe (see @modelcontextprotocol/client, connect mode auto: it sends server/discover, and falls back to the 2025-era initialize handshake only if the probe fails). Against CBM 0.11.0 that probe is answered with -32601 Method not found on every connection, and the daemon records it as an error.

From ~/.cache/codebase-memory-mcp/logs/cbm-daemon.log:

level=warn msg=mcp.request protocol=jsonrpc method=server/discover status=error duration_ms=0

45 occurrences in the log; server/discover is the only method that ever reports status=error (every initialize, tools/list, prompts/list etc. is status=ok).

Impact:

• Every modern-SDK connect produces a spurious error/warn line in the daemon log.
• No modern (2026-07-28) revision is ever advertised, so clients cannot use the modern revision even when they ask for it — the server silently negotiates down to 2025-11-25.

Expected: implement server/discover (returning supportedVersions, capabilities, instructions, plus cache hints) as required for protocol revision 2026-07-28; or, if the modern revision is intentionally unsupported, don't log the expected fallback probe as an error.

This is not the same as #1813: there the server exited / never answered in the test container. Here the server answers promptly with a well-formed JSON-RPC error while tools/list works normally.

Reproduction

1. Start the MCP server on stdio: codebase-memory-mcp
2. initialize, claiming the modern revision (the server negotiates down to 2025-11-25):

{"jsonrpc":"2.0","id":1,"method":"initialize","params":{"protocolVersion":"2026-07-28","capabilities":{},"clientInfo":{"name":"probe","version":"1"}}}

Result:

{"jsonrpc":"2.0","id":1,"result":{"protocolVersion":"2025-11-25","serverInfo":{"name":"codebase-memory-mcp","version":"0.11.0"},"capabilities":{"tools":{"listChanged":false},"prompts":{"listChanged":false}},"instructions":"..."}}

1. server/discover:

{"jsonrpc":"2.0","id":2,"method":"server/discover","params":{}}

Result:

{"jsonrpc":"2.0","id":2,"error":{"code":-32601,"message":"Method not found"}}

Expected: a DiscoverResult (supportedVersions + capabilities), since the official client uses this as its connect probe.

1. Sanity check — the same session's tools/list succeeds, so the transport/handshake is fine:

{"jsonrpc":"2.0","id":3,"method":"tools/list","params":{}}

→ returns the 15 tools.

The same -32601 is returned when initialize is sent at 2025-06-18 or 2025-11-25; the client always probes server/discover first.

Logs

level=info  msg=mcp.request protocol=jsonrpc method=initialize    status=ok duration_ms=0
level=info  msg=mcp.request protocol=jsonrpc method=tools/list    status=ok duration_ms=0
level=info  msg=mcp.request protocol=jsonrpc method=prompts/list  status=ok duration_ms=0
level=warn  msg=mcp.request protocol=jsonrpc method=server/discover status=error duration_ms=0

Only server/discover errors; cbm-daemon.log contains zero level=error/panic/fatal lines, i.e. this is the sole recurring error surface.

Confirmations

• I searched existing issues and this is not a duplicate (closest is #1813, which is the test-container exit, not this).
• My reproduction uses shareable code (a dummy snippet or a public OSS repository), not proprietary code.