Return -32601 for unknown MCP methods instead of an empty response

[psp65]

What behavior changes?

A request with an unknown JSON-RPC method that carries an id now receives a proper error response:

{"jsonrpc":"2.0","error":{"code":-32601,"message":"Method not found: nonexistent/method"},"id":4}

Previously both dispatch switches in McpService returned null for unknown methods, so the request got no response at all (over HTTP transports that surfaces as a 200 with an empty body). Notifications — known or unknown, identified by the absence of an id — are still silently dropped, and all known methods are unchanged.

Why is this change needed?

JSON-RPC 2.0 requires that every request carrying an id receive a response. Beyond spec correctness, this is groundwork for MCP protocol revision 2026-07-28 (#1337, PR 1 of the ladder proposed there): the Python SDK ≥ 2.0.0 probes servers with server/discover and falls back to the legacy initialize handshake when the probe fails. Today that fallback only works because the client synthesizes a parse error from the empty body — with this change it triggers off a clean, deterministic -32601, which is one of the documented legacy-server signals. The description of #1304 records this same empty-response symptom for initialize with an unrecognized version.

How was this validated?

• New unit tests in McpServerTest: unknown method with an integer id and with a string id (the id is echoed with its original type — it is modeled as a Document), unknown and known notifications produce no output, ping/tools/list unaffected. Module test and check (spotless, spotbugs, integration suite) green.
• End-to-end against our internal MCP gateway (which embeds this engine) with Python SDK mcp==1.28.1 (full legacy flow unchanged) and mcp==2.0.0 (mode=auto still connects, now falling back via the clean error; verified on the wire).

What should reviewers focus on?

• The methodNotFound(JsonRpcRequest) helper in McpService and its two call sites (both dispatch paths).
• One pre-existing quirk left untouched: validate() requires an id on any method not prefixed notifications/, so an id-less request with an unknown non-notification method is rejected as a validation error rather than treated as a notification per strict JSON-RPC. Flagged in MCP server: support protocol revision 2026-07-28 (stateless / modern era) #1337.

Additional Links

• MCP server: support protocol revision 2026-07-28 (stateless / modern era) #1337 (MCP 2026-07-28 support proposal; this is step 1)
• Add MCP protocol version 2025-11-25 #1304 (prior fix that documents the empty-response symptom)

---

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.