[blackwell-systems]

The stdio transport feeds os.Stdin into a single streaming json.Decoder. A
syntactically malformed frame makes Decode return a *json.SyntaxError, and the
read goroutine returned on that error, so one bad frame terminated the whole
session. A streaming decoder also cannot resynchronize on its own: a syntax
error poisons its buffered stream state.

Per JSON-RPC 2.0, a parse error should be answered with a -32700 response and
the session should continue. That is what mark3labs/mcp-go does (it reads
newline-delimited frames and unmarshals each independently), and it is the same
recoverable-decode direction taken for empty-method requests in #1000.

The stdio read loop now:

• replies with a -32700 parse-error response (id: null) for a malformed frame,
• resynchronizes to the next newline-delimited frame and keeps reading,
• terminates only on a genuine EOF or I/O error, as before.

An EOF immediately after a malformed frame (with or without a trailing newline)
still ends the session cleanly. Only *json.SyntaxError is recovered; the
existing "invalid trailing data" handling is unchanged.

Tests cover a malformed frame followed by a valid request (the request is still
delivered and a -32700 is written), consecutive malformed frames, and malformed
frames at end-of-stream. Verified with -race.

Surfaced by an MCP conformance study run against a downstream server
(blackwell-systems/agent-lsp#14). The behavior is a property of this transport,
shared by every server built on the SDK's stdio transport.

Fixes #1209

[jmrplens]

My server keeps stdio sessions alive with a line filter in front of the SDK's transport, and its end-to-end cases might help here: not JSON, a truncated frame, valid JSON that is not a message ({"hello":"world"}, an array), a boolean, object or array id, a response whose error is not an object, and a few more.

Each case checks that the next call is still answered. The refusals carry -32700 for a line that is not JSON, -32600 for JSON that is not a valid message, and -32601 and -32602 for an unknown method and an unknown tool, while a blank line gets no answer. A refusal echoes a request's id when it is a string or a number the SDK can read back, and otherwise leaves the member out rather than sending null, which no MCP schema allows. A response's id is left out too, since it names one of the server's own requests.

I can port them to a test against this branch if that helps.

[Ahmad-Faraj]

I ran the census that #1209 mentions. Here is the census data for this transport, since it shows the behaviour across the ecosystem rather than in one server.

The census found 11 registry servers written in Go that complete a handshake over stdio. Each one got a syntactically malformed frame after the handshake, and then a valid request. The result split by library with no exceptions:

Library (from go.mod)	Servers	Survived the malformed frame
modelcontextprotocol/go-sdk (v1.1.0 to v1.8.0)	5	0
mark3labs/mcp-go	6	6

The five on this SDK are goreleaser/mcp, stackql, blackwell-systems/agent-lsp, x7even/cloudcostsmcp and w31r4/codex-mcp-go. Two of them, GoReleaser and StackQL, have since added their own workarounds downstream. Each server that keeps using this transport would need to do the same, so a fix here would reach all of them at once.

Across all 3,685 servers that responded in the census (every SDK and language), 0.5% failed this check, against 5 of 5 on this SDK. The method and data are in the preprint: https://doi.org/10.5281/zenodo.22996025.

On scope, I agree with @serverplumber and @jmrplens. Valid JSON that is not a JSON-RPC message (42, {}, []) should get a -32600 and not end the session. Each bad frame should get exactly one error. Their case lists would make a good regression test for this PR.