Chapter 3

A Protocol Starts With the Message, Not the SDK

An SDK is convenient, but it also hides the protocol. While everything works, the difference is invisible; the moment debugging starts, you need to see what actually goes over the wire: the method, params, id, version metadata, HTTP headers, and the response. Both protocols use the same envelope - JSON-RPC 2.0 - and it's precisely this similarity that makes them easy to confuse. So it's worth looking at the raw messages of both, once.

Here is how MCP addresses a specific capability - it calls a tool by name with arguments and the modern metadata of the 2026-07-28 revision.

JSON
{
  "jsonrpc": "2.0",
  "id": "req-42",
  "method": "tools/call",
  "params": {
    "name": "review_release",
    "arguments": {
      "service": "web-portal",
      "version": "2.4.0"
    },
    "_meta": {
      "io.modelcontextprotocol/protocolVersion": "2026-07-28",
      "io.modelcontextprotocol/clientInfo": {
        "name": "release-host",
        "version": "1.0.0"
      },
      "io.modelcontextprotocol/clientCapabilities": {}
    }
  }
}

And here is how A2A hands a goal to an executor - it sends a Message with a role and parts, naming neither a function nor its arguments.

JSON
{
  "jsonrpc": "2.0",
  "id": "req-43",
  "method": "SendMessage",
  "params": {
    "message": {
      "messageId": "msg-1",
      "role": "ROLE_USER",
      "parts": [
        {
          "text": "Check the release web-portal@2.4.0"
        }
      ]
    },
    "configuration": {
      "acceptedOutputModes": [
        "text/markdown",
        "application/json"
      ]
    }
  }
}

They do share a lot: request-response correlation by id, structured errors, transport over HTTP, and the option of streaming. But the difference is fundamental, and it lies not in the envelope but in the semantics of the method. An MCP method addresses a capability - "call this tool with these arguments". An A2A operation changes or reads the state of an agent task - "here is a goal, run its lifecycle". The same JSON-RPC describes two different worlds.

JSON-RPC doesn't make protocols interchangeable. The same shell doesn't mean the same methods, capability negotiation, errors, or lifecycle. You can't send tools/call to an A2A agent or SendMessage to an MCP server.

Learning to read these messages pays off immediately: almost any integration problem - the wrong protocol, lost metadata, a bad response format - is visible at the wire level before it shows up in application logs. Next we'll trace how such messages compose into one end-to-end request across both boundaries.

Links