Hacktoberfest 2026：维护者为十月标记出来的 issue，仍然开放、适合新手。 浏览 Hacktoberfest issue

Malformed params on spec request methods return -32603 Internal error instead of -32602 Invalid params

未关闭 适合新手
  • 哪里不对？
#2,916 3 条评论 0 个 reaction 已指派 0 人 在 GitHub 查看

维护者通常 1 天内回复

@Gauravtiwari31 已经在做这个了。

开始于 2026年10月2日。

  • #2932 来自 @Gauravtiwari31 —— 未关闭

评估

难度
2/5
预计耗时
1-3 小时
新手友好度
78/100
Issue 类型
缺陷
描述清晰度
描述清楚
活跃度
活跃
技术栈
typescript
领域
api, backend-api-design

调研方向

检查 2.1.0 和 2.2.0 版本中 dist/src-*.mjs 文件约第 6842–6845 行处 Protocol.setRequestHandler 的双参数分支。使用 @mcpjam/sdk conformance probe 或等效的 malformed requests，针对 prompts/get 和 logging/setLevel，并配合格式正确的对照请求，验证无效的 wire 参数会返回 -32602 且不会运行 handler，同时确保 tools/call 仍然正确。

由索引模型根据 Issue 内容生成。

描述

v1 v2
Summary

A request whose params fail wire-schema validation is answered with -32603 (Internal error) and the raw validation issues as the message, for every spec method registered through the two-argument setRequestHandler(method, handler). JSON-RPC 2.0 and the MCP spec define this case as -32602 (Invalid params).

tools/call is already correct (Invalid tools/call request: …, -32602), as is the three-argument setRequestHandler(method, { params }, handler) path (Invalid params for <method>), so the inconsistency is only on the generic two-argument path.

Reproduction

Any server on @modelcontextprotocol/server 2.1.0 or 2.2.0 (latest at time of writing) that registers spec handlers with the two-argument form:

POST /mcp  {"jsonrpc":"2.0","id":1,"method":"prompts/get","params":{}}
→ {"error":{"code":-32603,"message":"[ { \"expected\": \"string\", \"code\": \"invalid_type\", ..."}}

POST /mcp  {"jsonrpc":"2.0","id":2,"method":"logging/setLevel","params":{"level":"loud"}}
→ {"error":{"code":-32603,"message":"[ { \"code\": \"invalid_value\", ..."}}

POST /mcp  {"jsonrpc":"2.0","id":3,"method":"tools/call","params":{"name":123}}
→ {"error":{"code":-32602,"message":"Invalid tools/call request: ..."}}   (correct)

Each probe was paired with a well-formed control on the same method (e.g. logging/setLevel with "info"), which succeeds, so the method itself is served.

Cause

In Protocol.setRequestHandler, two-argument branch (dist src-*.mjs, around line 6842 in 2.1.0 and 6845 in 2.2.0):

if (!outcome.ok) {
  if (outcome.reason === "not-in-era") throw new ProtocolError(ProtocolErrorCode.InternalError, `No wire schema for ${method} in the resolved era`);
  throw new Error(outcome.message);   // ← a plain Error, reported as -32603
}
Suggested fix
throw new ProtocolError(ProtocolErrorCode.InvalidParams, `Invalid params for ${method}: ${outcome.message}`);

This matches the tools/call and three-argument paths. The handler never runs for these requests, so a server cannot correct the code itself without re-registering every spec method on the three-argument path (which bypasses the era-aware codec).

Found by an automated conformance probe built on @mcpjam/sdk, with a well-formed control per method.

主要语言
TypeScript
星标
13.5k
派生
2.3k
平均合并
2 天 7 小时
30 天内合并 PR
54

环境准备

  • 没有 Dockerfile 或 Docker Compose 文件
  • 没有 Pull Request 模板
  • 阅读贡献指南

从这里开始

  1. 先读完整个 Issue，再读项目的贡献指南。
  2. 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
  3. Fork 仓库，在一个分支上完成修改。
  4. 提交 Pull Request，并在描述里引用这个 Issue 编号。

modelcontextprotocol/typescript-sdk 的其他 Issue

查看 modelcontextprotocol/typescript-sdk 的全部 Issue

相似的 Issue

更多 TypeScript Issue

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。