MCP Messages Explained: JSON-RPC Methods, Results, and Errors

MCP messages use JSON-RPC 2.0. That gives clients and servers a standard shape for requests, results, errors, and notifications while MCP defines the methods and data structures that carry protocol capabilities. Reading these message shapes is one of the fastest ways to debug an MCP connection.

Requests have methods and IDs

A request includes the JSON-RPC version, an ID, a method name, and optional parameters. The ID lets the client match a response to the operation that created it. Methods such as initialize, tools/list, and tools/call describe MCP operations, while the parameters carry the structured input for that method.

{
  "jsonrpc": "2.0",
  "id": 7,
  "method": "tools/call",
  "params": {
    "name": "search",
    "arguments": { "query": "MCP" }
  }
}

Results return successful work

A result uses the same request ID and includes a result object. For a tool call, the result can contain content items and an isError signal. The server may have handled the protocol request correctly while the underlying action still failed, so clients should inspect the result semantics.

Errors identify request handling failures

An error response includes a code, message, and optional data. It can indicate an invalid request, an unknown method, invalid parameters, or a server-side failure. The message is useful for diagnosis, but production telemetry should avoid copying secrets or unbounded user input into logs.

Notifications do not expect a result

Notifications omit the ID because the sender does not expect a response. MCP uses them for events such as initialized and catalog-change notifications. A client should not wait for a response to a notification, and a server should not manufacture one.

How to debug a captured exchange

• Confirm the message is valid JSON-RPC and uses jsonrpc 2.0.
• Match every response ID to the request that created it.
• Separate a protocol error from a valid tool result with isError set.
• Check method names, argument shapes, and negotiated capabilities.
• Redact tokens and sensitive arguments before storing or sharing an exchange.

TrackMCP's server-boundary view is designed to preserve useful event semantics without requiring raw message payloads. That makes it possible to investigate tool usage, duration, errors, and sessions while keeping capture bounded and privacy-aware.