Invalid Request frames silently dropped with no error response — client hangs waiting for id that never resolves

[SSanju]

When the SDK receives a JSON-RPC message that fails schema validation — specifically a request with a missing jsonrpc field, or a batch array — it silently drops the message with
no response. Any client tracking pending requests by id hangs indefinitely because the server consumed the request but returned nothing.

This affects every server built on @modelcontextprotocol/sdk. Verified on:

• @modelcontextprotocol/server-everything v2.0.0
• @modelcontextprotocol/server-memory v0.6.3

Both use SDK v1.29.0.

SDK version

@modelcontextprotocol/sdk 1.29.0

To Reproduce

Case 1 — request with missing jsonrpc field:

# Start any stdio MCP server, send a valid handshake then the malformed request
printf '%s\n%s\n%s\n' \
  '{"jsonrpc":"2.0","id":1,"method":"initialize","params":{"protocolVersion":"2024-11-05","capabilities":{},"clientInfo":{"name":"test","version":"1"}}}' \
  '{"jsonrpc":"2.0","method":"notifications/initialized"}' \
  '{"id":99,"method":"tools/list","params":{}}' \
| npx -y @modelcontextprotocol/server-everything stdio

Observe: no response for id 99. The server responds to id 1 and then goes silent.

Case 2 — batch request:

printf '%s\n%s\n%s\n' \
  '{"jsonrpc":"2.0","id":1,"method":"initialize","params":{"protocolVersion":"2024-11-05","capabilities":{},"clientInfo":{"name":"test","version":"1"}}}' \
  '{"jsonrpc":"2.0","method":"notifications/initialized"}' \
  '[{"jsonrpc":"2.0","id":100,"method":"tools/list"},{"jsonrpc":"2.0","id":101,"method":"ping"}]' \
| npx -y @modelcontextprotocol/server-everything stdio

Observe: no response for ids 100 or 101.

Expected behavior

Per JSON-RPC 2.0 §5, when a server receives a message with a detectable id but invalid structure, it must return an error response:

Case 1 — id is recoverable from the raw JSON, so:

{"jsonrpc":"2.0","id":99,"error":{"code":-32600,"message":"Invalid Request"}}

Case 2 — id is not recoverable from an array, so use null:

{"jsonrpc":"2.0","id":null,"error":{"code":-32600,"message":"Invalid Request"}}

Either way, the client gets a response and can unblock the pending request.

Actual behavior

Zero bytes returned. The client's pending request for the id sits unresolved until timeout or connection close.

Root cause

In src/server/stdio.ts, processReadBuffer() catches schema validation errors and routes them to onerror — but never sends a response:

// sdk/src/server/stdio.ts
processReadBuffer() {
    while (true) {
        try {
            const message = this._readBuffer.readMessage();
            // readMessage() calls JSONRPCMessageSchema.parse(JSON.parse(line))
            // ↑ throws ZodError for missing jsonrpc field or batch array
            this.onmessage?.(message);
        } catch (error) {
            this.onerror?.(error);  // ← error reported, but no response sent
        }
    }
}

The Zod errors thrown:

• Missing jsonrpc field: Invalid input: expected "2.0" at path jsonrpc
• Batch array: Invalid input: expected object, received array

Both cases discard the id without sending a -32600 response.

How I found this

I ran mcp-scope — a passive JSON-RPC capture tool for MCP — in front of a local server-everything instance and used mcp-scope check --strict
on the capture:

[WARN ] unmatched request id=99 (no response in capture)
[ERROR] unparseable JSON-RPC frame   ← the batch array
FAIL — 1 error(s), 1 warning(s)

The capture shows the request was sent and received (it appears in the c2s direction) but no s2c response frame ever arrived.

Capture file: https://github.com/SSanju/mcp-scope/blob/main/examples/mcp-toolbox/capture-server-everything.jsonl

[koriyoshi2041]

I reproduced the v1.x stdio behavior locally and put a small patch on a fork branch here:
https://github.com/koriyoshi2041/typescript-sdk/tree/fix-v1-invalid-request-response

It preserves the raw parsed stdio frame when schema validation fails, then returns -32600 Invalid Request when the invalid frame has a recoverable string/integer id. The tests I ran:

• pnpm test test/server/stdio.test.ts
• pnpm test test/shared/stdio.test.ts
• pnpm lint

I could not open the upstream PR because PR creation is currently restricted for this repo. I kept batch frames out of scope for that patch because v1.x JSONRPCErrorResponseSchema does not allow id: null, matching the boundary in #2000.

[he-yufeng]

I reproduced the stdio behavior and prepared a tested fix branch here:

https://github.com/he-yufeng/typescript-sdk/tree/fix/stdio-invalid-request-response

The patch keeps non-JSON log lines ignored, but distinguishes JSON frames that parse and fail the JSON-RPC schema. For those malformed frames, the stdio server replies with -32600 Invalid Request when it can recover a string/integer id from the raw frame. Invalid batch frames stay id-less to match the current response schema boundary.

Validation run locally:

pnpm --filter @modelcontextprotocol/core test -- test/shared/stdio.test.ts
pnpm --filter @modelcontextprotocol/server test -- test/server/stdio.test.ts
pnpm --filter @modelcontextprotocol/core typecheck
pnpm --filter @modelcontextprotocol/server typecheck
pnpm --filter @modelcontextprotocol/core lint
pnpm --filter @modelcontextprotocol/server lint
pnpm typecheck:all
pnpm build:all
pnpm lint:all
pnpm prettier --check packages/server/src/server/stdio.ts packages/server/test/server/stdio.test.ts packages/core/src/shared/stdio.ts packages/core/test/shared/stdio.test.ts packages/core/src/exports/public/index.ts
git diff --check origin/main..HEAD

pnpm build:all completed successfully; it still prints the existing ajv/fast-uri type-export warnings.

I tried to open the upstream PR, but this repository currently rejects fork PR creation for my account with CreatePullRequest permission denied. Leaving the branch here so it can be reviewed or pulled if useful.

[tarunag10]

I pushed a refreshed, validated branch for this to tarunag10:codex/stdio-invalid-request-response:

• branch: https://github.com/tarunag10/typescript-sdk/tree/codex/stdio-invalid-request-response
• compare: main...tarunag10:codex/stdio-invalid-request-response

What changed:

• preserve parsed invalid stdio frames so the server transport can recover request ids
• send -32600 Invalid Request for malformed JSON-RPC requests with a recoverable id
• send id: null invalid-request responses for invalid batch frames
• add core/server stdio regressions for both cases

Local validation I ran:

• corepack pnpm --filter @modelcontextprotocol/core test -- test/shared/stdio.test.ts
• corepack pnpm --filter @modelcontextprotocol/server build
• corepack pnpm exec vitest run test/server/stdio.test.ts --config vitest.config.js
• corepack pnpm exec prettier --check ...

I could not open the upstream PR from this fork because GitHub returned CreatePullRequest permission denied for my account on this repository, but the branch is ready to review or pull if useful.

[SSanju]

Thanks to @koriyoshi2041, @he-yufeng, and @tarunag10 for independently arriving at the same fix - preserving the parsed frame before schema validation fails so the id is recoverable, then returning -32600.
So for everyone, PR creation is restricted for external contributors. looks like maintainer just needs to open the PR -the implementation work is already done.