After a developer adds print-style debug output to a stdio MCP server, the host starts reporting parse errors and drops the connection. What is the fix?
Select an answer to reveal the explanation.
Short Explanation
On stdio, stdout is the phone line between you and the host, and it only speaks JSON-RPC. Shout debug text down that line and the host hears gibberish and hangs up. You've got a second line for chatter, stderr, so use it.
Full Explanation
The stdio transport carries newline-delimited JSON-RPC messages on the server's stdout, and the specification says the server MUST NOT write anything to stdout that is not a valid MCP message. The client reads stdout one line at a time and expects each line to parse as a request, notification or response, so a stray debug line produces exactly the parse failures described. The same specification says the server MAY write UTF-8 strings to stderr for any logging purpose, including informational, debug and error messages, and the debugging guide warns that local servers should not log to stdout because it interferes with protocol operation. Dressing debug text up as a notification still violates the rule unless it is a genuine, valid MCP message, and inventing methods only creates new errors. Switching to Streamable HTTP is unnecessary; stdio supports diagnostics perfectly well through stderr. Deferring output to a single line at shutdown still writes non-MCP text to stdout and simply moves the failure to the end of the process. Exam caveat: messages on stdout must also not contain embedded newlines, so serializers must emit each message as one line. Operational check: capture the server's stdout during a session and confirm every line parses as JSON-RPC, while debug text appears only in the stderr capture.