调用 MCP 工具时返回错误码 -32601 或 -32602 是什么意思？怎么排查？
两个都是 JSON-RPC 标准协议错误：-32601 是 Method not found，方法名写错或 Server 不支持（比如把 tools/call 拼成 tool/call）；-32602 是 Invalid params，方法对但参数不合法（比如 tools/call 缺 name、arguments 类型不对，或调了未暴露的工具名）。排查先看 method 拼写，再对照 tools/list 返回的 inputSchema 逐字段校验参数。
完整回答
先分两层：协议错误走 JSON-RPC error 字段和错误码，工具执行失败不走错误码，走正常结果里的 isError: true——两者处置路径不同，混为一谈会改错地方。再按码定位：-32601 检查 method 字符串是否在 Server 支持的方法列表里；-32602 对照 inputSchema 校验每个字段，未知工具名也归在这一档。同族错误码还有 -32700（请求体不是合法 JSON）和 -32600（请求结构非法，比如缺 id）。本站 POST /api/mcp 的真实行为可以逐条复现：未知 method 返回 -32601；tools/call 缺 name、调用未知工具、或调写工具 save_learning_note（不经 MCP 暴露）都返回 -32602，其中未知工具还在 error.data.exposedTools 里列出可用工具名——error.data 是 Server 给排查留的线索，排障时先读它。收到 -32602 不要盲目重试，参数不合法重试多少次都一样。
加分信息
- 能完整说出 -32700 / -32600 / -32601 / -32602 四个协议错误码的分层
- 指出 error.data 可携带排查线索（如 exposedTools），排障先读 data 再改请求
常见问题
- 把 isError: true 的工具执行失败当成 -32601/-32602 去改协议层代码
- 收到 -32602 不做参数校验就盲目重试
面试官可能追问
- -32602 和 isError: true 都表现为“调用失败”，监控告警应该分开统计吗，为什么？
- 怎么设计 Client，让这类协议错误在开发期而不是线上暴露？
/labs/mcp-tools 可以直接发未知方法名或错误参数，逐帧复现 -32601 与 -32602 的真实响应；POST /api/mcp 的错误响应附中文排查提示，未知工具还会列出 exposedTools。