MCP JSON-RPC Parse Error (-32700): How to Fix It (Claude Desktop, Cursor, Claude Code)

A JSON-RPC parse error in MCP means one side received text that was not valid JSON. With local stdio servers, the usual cause is the server printing something other than protocol messages to stdout, such as a banner, a debug line or a progress bar. The fastest fix is to send every log line to stderr instead, then restart the client. If the error appears before any server starts, the broken JSON is in your config file.

Checked against: the JSON-RPC 2.0 specification, the MCP 2026-07-28 stdio transport, the MCP build-a-server tutorial and the source of the @modelcontextprotocol/sdk 1.32.2 npm package on 2 November 2026. eSEOspace did not reproduce the error in each client.

What this error means

There are two kinds of "parse error," and the fix differs.

Protocol parse errors. The JSON-RPC 2.0 spec defines -32700 as "Invalid JSON was received by the server." When a receiver cannot read the request at all, the spec says the response id "MUST be Null." In MCP, either side can hit this. On stdio, the transport spec says messages are "delimited by newlines" and that the server may write logs to stderr but "MUST NOT" write non-MCP text to stdout.

The 1.32.2 TypeScript SDK shows what happens next. Its stdio reader splits the stream on newlines and runs JSON.parse on each line. A line like Server started! fails that parse. In that version the client reports the error and moves to the next line. Other clients may drop the connection instead. You might see "Unexpected token" in a log, -32700, or a closed connection.

Config parse errors. If your claude_desktop_config.json, mcp.json or .mcp.json is not valid JSON, the client cannot read any servers. This is not a JSON-RPC error. It usually shows as no servers at all.

Quick fix

1. Check your config file first. Run python3 -m json.tool claude_desktop_config.json (or the path to your mcp.json). It prints the file if valid, or the line and column of the problem.
2. Run the server by hand and watch stdout. Anything printed before you send a request is a problem. Banners, "Listening on..." lines and warnings all count.
3. Move logs to stderr. In Python, use the logging module. In Node, use console.error(). The build tutorial gives the same advice for Java, Kotlin, C# and Ruby.
4. Silence noisy dependencies. Some libraries and package managers print to stdout. Turn off their progress output or redirect it.
5. Never pretty-print messages. If you write your own transport, one message must be one line.
6. Restart the client fully.

Fix by client / OS

Claude Desktop

Open mcp-server-SERVERNAME.log in ~/Library/Logs/Claude (macOS), %APPDATA%\Claude\logs (Windows) or ~/.config/Claude/logs (Linux), per the MCP debugging guide. Lines your server wrote to stderr appear there. Then check mcp.log around the same time for parse errors. Text that shows up in an error but not in the stderr log most likely came from stdout.

Cursor

Open the Output panel and choose MCP Logs, as Cursor's MCP docs describe. Look for parse or "Unexpected token" errors around server start.

Claude Code

Run claude mcp get <name>. The Claude Code MCP docs say a failed server shows its error on an Issue: line. Fix the server, then select Reconnect in /mcp.

VS Code

Use MCP: List Servers, pick the server and choose Show Output, as the VS Code MCP page describes.

Windows line endings

The 1.32.2 SDK strips a trailing carriage return before parsing, so \r\n line endings are fine for that client. A message split across two lines is not.

Where to find the logs

Use the MCP Inspector to watch the raw JSON-RPC exchange. Its monitoring sidebar shows each message, which makes a non-JSON line easy to spot.

If it still fails

• The server sends valid JSON but the client rejects it. That is -32600 (Invalid Request) or -32602 (Invalid params), not a parse error. See invalid params -32602.
• Very large messages fail. The 1.32.2 SDK closes the transport when one unfinished line passes 10 MB. Return less data per call.
• The connection closes right after the bad line. See MCP error -32000: Connection closed.
• You need the full rules. Read MCP JSON-RPC messages and the stdio transport reference.

Decode the code you see with the MCP error code lookup. Stray stdout is the most common cause, so read stdout logging breaks the server next. If you ship servers to customers, our MCP development team can review them for protocol hygiene.

Frequently asked questions