[Server] Return invalid-params for unknown tool in tools/call

[latent-9]

Summary

CallToolHandler returns -32601 (Method not found) when a tools/call request names a tool that is not registered. The tool name is a parameter of a method that does exist, so the correct JSON-RPC error for this case is -32602 (Invalid params).

Details

tools/call is a valid, supported method. When its name argument does not resolve to a registered tool, the method was found but a parameter was invalid. -32601 is reserved for an unknown method (an unsupported JSON-RPC method name), which is not what happened here.

The same handler already treats bad tool input as invalid params: when the arguments fail schema validation it returns Error::forInvalidParams(...) (-32602). An unknown tool name belongs to the same class of error and should use the same code.

The reference TypeScript schema classifies an unknown tool name under InvalidParamsError, and the other SDKs have converged on -32602 for the unknown-name case (for example modelcontextprotocol/ruby-sdk#517 for prompts/get).

Impact

A client that receives -32601 for tools/call can reasonably conclude that the server does not implement tools/call at all and stop issuing tool calls, when in fact only the specific tool name was wrong. -32602 correctly signals that the request was understood but a parameter was invalid, so the client can recover by choosing a valid tool.

Scope

This is limited to the tool-not-found path and is independent of #337 and #359 (resource and prompt not-found moving from -32002 to -32602). No protocol-version gate is needed: -32602 is a standard JSON-RPC code valid in every MCP revision, and -32601 was never the specified value for an unknown tool name.

Changes

• CallToolHandler: return Error::forInvalidParams(...) instead of Error::METHOD_NOT_FOUND when a tool is not found.
• Update the corresponding unit test to assert Error::INVALID_PARAMS.