Answer -32602 Invalid params for schema-invalid spec-method requests

[earfman]

Closes #2284.

Motivation and Context

When a spec-defined method (e.g. logging/setLevel) received params that fail the method's wire schema, the server answered -32603 Internal error. Per JSON-RPC 2.0, invalid method parameters are the caller's error and should be -32602 Invalid params. The old surface told callers the server broke when in fact their request was malformed.

Before the function-only WireCodec contract, the Zod parse threw out of the handler and the funnel mapped it to -32603. Custom handlers registered with a params schema already answered -32602; this change makes spec methods match that surface.

Root cause is a single throw in the spec-method dispatch closure in protocol.ts — it re-threw the schema failure as a bare Error (funnelled to -32603) instead of a ProtocolError(InvalidParams).

How Has This Been Tested?

• New regression test packages/server/test/server/specMethodInvalidParams.test.ts: a Server with the logging capability + a logging/setLevel handler; after the initialize handshake, sending logging/setLevel { level: 'not-a-level' } now yields error.code === -32602 and a message containing Invalid params for logging/setLevel.
• The dispatch-rejection corpus fixture invalid-spec-params.json is updated to pin -32602.
• The e2e requirements manifest had a knownFailures block for logging:set-level:invalid-level encoding the old -32603 behavior; with the fix those e2e scenarios pass, so the stale knownFailures entry is removed (otherwise the "expected to fail" scenarios error out).
• pnpm lint:all and pnpm test:all pass locally.

Breaking Changes

Wire-visible: peers that matched on -32603 for schema-invalid spec-method params will now observe -32602. This is intentional and brings spec methods in line with the custom-handler path. A changeset (patch to core-internal, client, core, server) is included.

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)

Checklist

• I have read the MCP Documentation
• My code follows the repository's style guidelines
• New and existing tests pass locally with my changes
• I have added tests that prove my fix is effective
• I have added a changeset (pnpm changeset)

[changeset-bot]

🦋 Changeset detected

Latest commit: a1899fd

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 6 packages

Name	Type
@modelcontextprotocol/core-internal	Patch
@modelcontextprotocol/client	Patch
@modelcontextprotocol/core	Patch
@modelcontextprotocol/server	Patch
@modelcontextprotocol/server-legacy	Patch
@modelcontextprotocol/codemod	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[pkg-pr-new]

Open in StackBlitz

@modelcontextprotocol/client

npm i https://pkg.pr.new/@modelcontextprotocol/client@2492

@modelcontextprotocol/codemod

npm i https://pkg.pr.new/@modelcontextprotocol/codemod@2492

@modelcontextprotocol/core

npm i https://pkg.pr.new/@modelcontextprotocol/core@2492

@modelcontextprotocol/server

npm i https://pkg.pr.new/@modelcontextprotocol/server@2492

@modelcontextprotocol/server-legacy

npm i https://pkg.pr.new/@modelcontextprotocol/server-legacy@2492

@modelcontextprotocol/express

npm i https://pkg.pr.new/@modelcontextprotocol/express@2492

@modelcontextprotocol/fastify

npm i https://pkg.pr.new/@modelcontextprotocol/fastify@2492

@modelcontextprotocol/hono

npm i https://pkg.pr.new/@modelcontextprotocol/hono@2492

@modelcontextprotocol/node

npm i https://pkg.pr.new/@modelcontextprotocol/node@2492

commit: a1899fd