Invalid method names return error code -32602 instead of -32601

快速结论：这个报错发生在向MCP Python SDK服务器发送未知方法名（如 invalid/method 或 tools/register）时。服务器错误地返回了 -32602（无效请求参数）而非规范的 -32601（方法未找到）。优先排查 session.py 中Pydantic验证是否在方法未找到处理器之前拦截了请求。

问题场景

用户在运行MCP Python SDK服务器（v1.2.0及更高版本）时，通过JSON-RPC请求发送一个未经注册的方法名（例如 invalid/method 或 tools/register），服务器返回了错误的错误码。该问题在SSE传输协议上也被确认。

报错原文

# 发送请求：
{"jsonrpc":"2.0","method":"invalid/method","id":1,"params":{}}

# 实际返回（错误）：
{"jsonrpc":"2.0","id":1,"error":{"code":-32602,"message":"Invalid request parameters","data":""}}

# 期望返回（正确）：
{"jsonrpc":"2.0","id":1,"error":{"code":-32601,"message":"Method not found"}}

原因分析

问题原因在于请求验证流程中的顺序冲突。在 mcp/shared/session.py 中（约第360-375行），于Pydantic模型验证阶段提前捕获了未知方法名，并返回了 -32602（无效请求参数）。这导致代码无法进入 mcp/server/lowlevel/server.py（约第716-718行）中正确的“方法未找到”处理器（该处理器应返回 -32601）。可能原因：SDK的请求验证层在方法查找之前先执行了参数验证，而未知方法名未通过Pydantic模型的参数格式检查，从而被错误地归类为参数无效。

环境排查

Python版本：确认Python版本（如在Issue中报告的3.12或其他版本）
MCP Python SDK版本：确认版本号（Issue中影响v1.2.0至v1.26.0）
传输协议：确认使用的是stdio流还是SSE传输（SSE下问题也被确认）
操作系统：确认平台（在macOS上报告）

解决步骤

复现问题：运行MCP服务器后，通过以下命令发送未知方法名：
echo '{"jsonrpc":"2.0","method":"invalid/method","id":1,"params":{}}' | your-mcp-server
或使用SSE传输按Issue中的示例代码发送 tools/register 请求。
检查返回码：确认返回的错误码是 -32602 而非 -32601。
定位问题代码：检查 mcp/shared/session.py 中约第360-375行的Pydantic验证逻辑，验证它是否在方法未找到处理器之前返回错误。
修复方向（可优先尝试）：在Pydantic验证前添加方法名检查，确保未知方法名能正确传递到 _handle_request 的 else 分支（该分支返回正确的 -32601）。具体实现可参考：在 session.py 的请求处理入口处，先判断方法名是否在已注册方法列表中，如果不是则直接返回 -32601，避免进入Pydantic验证。
更新SDK版本：检查是否有官方补丁版本发布，确保使用最新版本的MCP Python SDK。

验证方法

再次发送与复现步骤相同的未知方法名JSON-RPC请求，确认服务器返回的是 {"error": {"code": -32601, "message": "Method not found"}} 而非 -32602。如果使用SSE传输，可运行Issue中的完整测试脚本，检查工具注入攻击测试中的安全检测结果是否不再出现假阴性。