Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

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

Open Beginner friendly
  • Is something wrong?
#2,916 3 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

@Gauravtiwari31 is already working on this.

Since Oct 2, 2026.

  • #2932 by @Gauravtiwari31 — open

Assessment

Difficulty
2/5
Estimated time
1-3 hours
Newbie friendliness
78/100
Issue type
Bug
Clarity
Clearly specified
Activity status
Active
Tech stack
typescript
Domain
api, backend-api-design

Research direction

Inspect the two-argument branch of Protocol.setRequestHandler in the dist/src-*.mjs files around lines 6842–6845 for versions 2.1.0 and 2.2.0. Use the @mcpjam/sdk conformance probe or equivalent malformed requests for prompts/get and logging/setLevel, with well-formed controls, and verify invalid wire parameters return -32602 without running the handler while tools/call remains correct.

Written by the indexing model from the issue text.

Description

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.

Dominant language
TypeScript
Stars
13.5k
Forks
2.3k
Avg merge
2d 4h
Merged PRs (30d)
45

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from modelcontextprotocol/typescript-sdk

All issues in modelcontextprotocol/typescript-sdk

Similar issues

More TypeScript issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.