MCP JSON-RPC decoder

What it does

Paste MCP messages from a log or a capture — one per line, a JSON array, or a Server-Sent Events stream — and read them as a timeline. Each message is a request, a notification, a result or an error; each is explained, and each response is paired with the request it answers. Messages from the client lean left and the server's lean right, and a link jumps from a request to its answer and back.

Try it: a session, errors, and answers that match no request, or the 2026-07-28 revision.

How it reads a message

• A request or a notification is whatever the parser Salyro's own MCP Expose server uses says it is. A message with id: null is a notification there, and here: MCP says a request's id MUST NOT be null.
• A message with result or error and no method is a response. It must carry the id of its request, of the same type — 1 and "1" are different ids — and never both result and error.
• A JSON array is a batch, wherever it sits in the paste: each member is a message. An empty [] is an invalid request. JSON-RPC 2.0 allows batches; of the MCP revisions, only 2025-03-26 did.
• params given as a list (positional parameters) is valid JSON-RPC 2.0 but not valid MCP, which names every parameter; Salyro's MCP Expose server refuses it.
• An event stream and plain JSON can be pasted together, as a curl -v capture shows them: the data: lines are the server's events, and the request beside them is still read and paired.
• Who sent it is read from the method, against the requests and notifications each dated revision's schema assigns to the client and to the server. A response goes the other way from its request. ping goes both ways; mark a line with > for the client or < for the server to say.

Error codes

• JSON-RPC's five: -32700 parse error, -32600 invalid request, -32601 method not found, -32602 invalid params, -32603 internal error.
• MCP's own: -32002 resource not found (2025-11-25 and earlier), -32042 URL elicitation required (2025-11-25), and from 2026-07-28 -32020 header mismatch, -32021 missing required client capability and -32022 unsupported protocol version. From -32000 to -32019 a code is implementation-defined: an SDK's own, with no meaning across implementations.
• A tool that failed is not an error response. MCP reports it as a tools/call result with isError: true, so the model can read it and try again.

Protocol version

The revision is read from initialize — proposed by the client, chosen by the server — or, from 2026-07-28, from each request's _meta and from server/discover. When the server answers with another revision than the one proposed, the decoder says so: the specification lets a server answer with one it supports, and a client that does not support it should disconnect. For comparison, it names the revisions Salyro's MCP Connect proceeds with when it connects out to a server.

Tokens stay hidden

Every message is shown with its credentials masked, recognised the way Salyro's log redactor recognises one, and by names such as api_key or Authorization. A summary names a tool's arguments, never their values.

What it does not know

• What happened on the wire around the messages: HTTP status codes, headers, timing.
• Whether a server's answer is right, only whether it is well-formed.
• Revisions other than the five dated ones it describes: 2024-11-05, 2025-03-26, 2025-06-18, 2025-11-25 and 2026-07-28.

FAQ

Why does a response say it answers no request?

No request with the same id, still waiting for an answer, comes before it in what was pasted — or the request's id has another type.

Does this talk to my server?

No. It reads what you paste, in your browser. A share link carries only which example was open, never your messages.

Sources

Methods, directions, error codes and version negotiation are Reference Data from the MCP specification's schema for each dated revision, read from its repository on GitHub, with the date. JSON-RPC's codes are the table Salyro's MCP Expose server answers with, from Salyro's shared package.