Agent Protocols Explained
How agents talk to tools and to each other, message by message.
An interactive guide to MCP and A2A, animated by an engine that sends the same messages as the official SDKs.
2025-11-25: 3,790 bytes of JSON and 2,478 bytes of HTTP framing in 17 messages.
2026-07-28: 5,262 bytes of JSON and 1,708 bytes of HTTP framing in 12 messages.
JSON-RPC HTTP framing
How this is checkedThe engine sends the same 160 messages as the official MCP Python SDK (mcp 2.3.0) over 18 recorded sessions, and the same 56 as the official A2A SDK (a2a-sdk 1.2.2), compared as JSON. How it is tested →
What you'll learn
An agent reaches its tools through a protocol. The Model Context Protocol (MCP) is the common one: a host's MCP client sends JSON-RPC messages to an MCP server, over a pipe or over HTTP. Its current revision, 2026-07-28, dropped the handshake that every earlier revision began with: the same short session now takes 12 messages instead of 17.
Each chapter is built around an animation of real protocol messages. They come from Agent_Loop_Sim's protocol state machines, and in CI the official MCP Python SDK (mcp 2.3.0) plays the same 18 sessions: the simulator must send the same messages (see the recordings). Agents talk to other agents too: chapter 8 follows a task between two agents over A2A 1.0, checked the same way against the official A2A SDK (a2a-sdk 1.2.2). Then authorisation, gateways and the attacks on all of it. Nothing here calls a live model or opens a real connection.
01
Why a protocol
N agents and M tools need N·M adapters point to point, or N+M implementations of one protocol; then one tool call followed from the model to the server and back.
02
JSON-RPC and the life cycle
Every message of a session, both protocol eras: the handshake and its version negotiation, the stateless 2026-07-28 revision, progress, errors, pagination and cancellation.
03
Tools, resources and prompts
The three things a server offers, told apart by who decides to use them: the model, the application or the user. The same document reaches the model all three ways.
04
Transports
stdio pipes against Streamable HTTP: bytes of framing and time per message, and an SSE stream that breaks mid-call, resumed in one revision and sent again in the next.
05
Server to client: sampling and elicitation
When a server needs the user or a model, the direction reverses: a request from the server (2025-11-25) or an input_required result and a retry (2026-07-28), with the human gates in the host.
06
Authorisation
The OAuth 2.1 flow an HTTP MCP server requires, step by step: discovery, registration, PKCE as SHA-256, the token's audience; and nine ways to break it, each failing at its own check.
07
Gateways and composition
One gateway in front of many servers: tool names that collide, a prefix that keeps them apart, an allow-list that cuts the tool list's token cost, and a call routed to the right server or the wrong one.
08
Agent to agent (A2A)
An agent delegating to another over A2A 1.0: the agent card, a task's life cycle across two agents, streaming, input and auth required, cancellation; and where A2A and MCP overlap and differ.
09
Protocol security, in brief
Three attacks at the protocol level, tool poisoning, a confused deputy and a hijacked state handle, each shown at the step where it happens, then again with the defence that stops it.
Part of a family of sixteen companion sites in four tracks, all in the site menu above: Foundations (Decoder, Training), Hardware (Kernels, Systolic, Accelerators, Racks), Inference (Serving, Architectures, Numerics, Trade-offs) and Agents (Harnesses, Protocols, Context, Orchestration, Evals, Security). It is the second of the six agent sites. How this one was built, and how to check it: about.