Logging to stdout Breaks My MCP Server: How to Fix It (Python, TypeScript, Java, C#)

A stdio MCP server uses stdout as its protocol channel, so anything else printed there, such as print("Server started") or console.log(), corrupts the JSON-RPC stream. Clients then show parse errors, ignore messages or drop the connection. The fastest fix is to send all logging to stderr: use Python's logging module or print(..., file=sys.stderr), and console.error() in Node. Then restart the client.

Checked against: the MCP 2026-07-28 stdio transport, the MCP build-a-server tutorial, the MCP debugging guide and the source of the @modelcontextprotocol/sdk 1.32.2 npm package on 2 November 2026. Python defaults were checked by running Python 3.9 locally. eSEOspace did not test servers in each client.

What this error means

With the stdio transport, the client starts your server and reads its stdout one line at a time. Each line must be one JSON-RPC message. The stdio spec says messages are "delimited by newlines" and must not contain embedded newlines.

When your code prints "Connecting to database..." to stdout, the client reads it as a message and fails to parse it. In the TypeScript SDK 1.32.2 client, each line goes through JSON.parse. A non-JSON line raises an error, which that client reports and then skips. Other clients may close the connection. Either way, the server looks broken even though its tools are fine.

stderr is the safe channel. The spec says the client "MAY capture, forward, or ignore" stderr and "SHOULD NOT assume stderr output indicates error conditions." The MCP debugging guide says messages logged to stderr "will be captured by the host application automatically."

Quick fix

1. Search your code for print(, console.log(, System.out.println, Console.WriteLine, puts and println.
2. Replace them with stderr logging (examples below).
3. Check dependencies. Libraries, progress bars and package managers sometimes print to stdout. Turn their output off or point it at stderr.
4. Run the server by hand and send nothing. If any text appears on stdout before a request, something still prints there. In a shell, your-server-command 2>/dev/null hides stderr so only stdout shows.
5. Restart the client and read the server log.

Python

The build tutorial recommends "the standard library logging module, which writes to stderr":

import logging
import sys

logging.basicConfig(level=logging.INFO)  # default stream is stderr
logger = logging.getLogger(__name__)

# Bad on stdio: goes to stdout
# print("Processing request")

# Good: logging writes to stderr by default
logger.info("Processing request")

# Also fine: print explicitly to stderr
print("Processing request", file=sys.stderr)

Python's own print docstring says it prints "to sys.stdout by default," which is why a stray print() breaks the stream.

TypeScript and Node

The tutorial says: "Never use console.log()" on a stdio server, and use console.error() or a logger that writes to stderr or files.

// Bad on stdio
// console.log("Server started");

// Good: stderr is safe
console.error("Server started");

Java, Kotlin, C# and Ruby

The tutorial gives the same rule for each: avoid System.out.println() in Java, println() in Kotlin, Console.WriteLine() in C# and puts or print in Ruby on stdio servers. Configure your logging framework so it never writes to stdout.

Fix by client / OS

Claude Desktop

The local server guide says files named mcp-server-SERVERNAME.log "contain the stderr output from the named server." Once your logs go to stderr, they show up there. Folders: ~/Library/Logs/Claude (macOS), %APPDATA%\Claude\logs (Windows), ~/.config/Claude/logs (Linux).

Cursor

Open the Output panel and pick MCP Logs, per Cursor's MCP docs.

Claude Code

Check /mcp and claude mcp get <name> for the error. Server stderr is not the protocol channel, so moving logs there does not affect Claude Code's connection.

HTTP servers

For Streamable HTTP, the debugging guide says "stderr is not captured by the client." Use your own log aggregation or OpenTelemetry. stdout logging is fine there.

Where to find the logs

If it still fails

• You see -32700 or "Unexpected token." See JSON-RPC parse error.
• The server disconnects. See Connection closed.
• You used protocol logging. The debugging guide says notifications/message logging is deprecated as of protocol version 2026-07-28. See MCP logging status.
• You want better logs. The logging and monitoring lesson covers what to record, and the stdio transport reference covers the framing rules.

Paste any error code into the MCP error code lookup. If you want a second pair of eyes on a server before you ship it, our MCP development team does reviews.

Frequently asked questions