Repository navigation
A known method whose params do not deserialize is answered with -32601 Method not found #1347
Description
Describe the bug
When a request names a standard method but its params do not fit that method's type, the server answers -32601 with the method name as the message. The client is told the server has no tools/call, when the problem is in its own arguments.
To Reproduce (main at 808124b, also 3.5.1; stdio, after a 2025-11-25 handshake, server built with #[tool_router] / #[prompt_router])
| request | response |
|---|---|
tools/call, no params |
-32601 tools/call |
tools/call, params: {} |
-32601 tools/call |
tools/call, params: {"name": 7, "arguments": {}} |
-32601 tools/call |
tools/call, params: {"name": "ok", "arguments": "x"} |
-32601 tools/call |
prompts/get, params: {"name": 7} |
-32601 prompts/get |
resources/read, params: {"uri": 7} |
-32601 resources/read |
fixture/unknown (control) |
-32601 fixture/unknown |
On 2026-07-28 the rows that carry params behave the same; the row without params is correctly answered with -32602 for the missing _meta.
Why
ClientRequest is #[serde(untagged)]. When the typed variant for the method fails, the message falls through to CustomRequest, and the default on_custom_request returns METHOD_NOT_FOUND. Same shape as #1345, one level down.
Expected behavior
-32602 Invalid params when the method is one the SDK defines and its params do not deserialize. The tools page lists "Malformed requests (requests that fail to satisfy CallToolRequest schema)" under protocol errors, and the Go, Python and TypeScript 2.x SDKs answer these requests with -32602.
Related, smaller
A request whose params is not an object ("params": []) is answered with {"jsonrpc":"2.0","error":{"code":-32600,"message":"Invalid request"}}. The response has no id member, although the request's id was readable, so the sender cannot match it. I can split this into its own issue if you prefer.
I can send a PR for the first part.
AI disclosure: investigated and drafted with Claude Code; I reviewed it.
Activity
SIDDARTHAREDDY8 commentedon Oct 16, 2026
Confirmed by reading current
main; the fallthrough the report describes is exactly what the code does, in two places:ClientRequestis generated by thets_union!macro incrates/rmcp/src/model.rs(invocation at ~L4784) as a#[serde(untagged)]enum, withCustomRequestas the last variant. Since untagged deserialization tries variants in order andCustomRequestaccepts any method string with arbitrary params, a request whose method matches a typed variant but whose params fail to deserialize lands inCustomRequest— the original deserialization error is discarded, so dispatch can no longer tell it apart from a genuinely unknown method.crates/rmcp/src/handler/server.rs(~L223) routesClientRequest::CustomRequesttoon_custom_request, and the defaultServerHandler::on_custom_requestimplementation (~L552) returnsMcpError::new(ErrorCode::METHOD_NOT_FOUND, method, None)— which is why the error message in every reported row is exactly the method name.One consequence for a fix: by the time
on_custom_requestruns, the only signal left is the method string onCustomRequest, so distinguishing "known method, invalid params" (-32602) from "unknown method" (-32601) has to compare that string against the SDK's known method names there, or the check has to happen earlier, before the untagged fallthrough swallows the typed-variant error.talhayme commentedon Oct 16, 2026
Thanks for confirming, and for tracing where the error gets lost. I'll send a fix along those lines once my open PR (#1344) lands, since the repo allows one at a time.
AI disclosure: drafted with Claude Code; I reviewed it.