MCP & A2A In Depth
MCP Primitives: Tools, Resources, Prompts
The Model Context Protocol is now the established standard for connecting models to external capabilities — the question in interviews and design reviews is no longer "what is MCP" but whether you understand it at the protocol level. MCP is JSON-RPC between a client (embedded in the model host) and servers that expose three primitives with deliberately different control models. Tools are model-controlled: executable functions the model chooses to invoke during its loop. Resources are application-controlled: addressable data — files, schemas, documents — that the host decides to place into context. Prompts are user-controlled: parameterised templates a person explicitly invokes, like slash commands. Collapsing everything into tools is the most common integration mistake; the primitive you choose determines who decides when content enters the context window.
- Tools: model-invoked actions with JSON Schema inputs — the agent's hands
- Resources: host-selected context data addressed by URI — not something the model fetches on a whim
- Prompts: user-invoked templates — explicit human intent, not model discretion
- One protocol, three control models: model, application, and user each own a primitive
Server Lifecycle, Transports, and Auth
An MCP session begins with an initialization handshake: client and server exchange protocol versions and declare capabilities, and nothing else is valid until that completes. After the handshake the client typically lists tools, resources, and prompts, then the operational phase begins — calls flow, and servers can push notifications when their tool or resource lists change, which clients must handle since real servers evolve mid-session. Two transports dominate: stdio for local servers launched as child processes — the trust model is your own machine — and streamable HTTP for remote servers, which is where real authentication begins. Remote MCP standardises on OAuth 2.1, with the server acting as a resource server and dynamic client registration smoothing first connections. Treat every remote server as an internet-facing API: tokens, scopes, and audit logs, not an implementation detail.
- Lifecycle: initialize and capability exchange, then discovery, operation, shutdown
- List-changed notifications matter — production clients cannot assume a static tool list
- stdio for local child processes; streamable HTTP for remote, multi-client servers
- Remote auth is OAuth 2.1 — scope server tokens as tightly as any third-party API credential
A2A: Agent-to-Agent, Now Under Neutral Governance
Where MCP connects one agent to its tools and data, A2A addresses the peer problem: how independently built agents — different vendors, different frameworks, different companies — discover and delegate to each other. Google launched it and then donated it to the Linux Foundation, moving governance to neutral ground with a broad roster of industry backers; vendor-neutral stewardship was a precondition for competitors adopting a shared protocol. Technically, an agent publishes an Agent Card — a JSON document describing its identity, capabilities, and endpoint — and peers interact through a task lifecycle over HTTP: submitted, working, input-required, completed or failed, with streaming updates and support for long-running work. A deliberate design choice: agents exchange tasks and results, not internals — an A2A peer stays opaque, its reasoning and tools hidden behind the interface.
- Agent Card: machine-readable capability advertisement enabling discovery
- Tasks are the unit of work, with an explicit lifecycle and streaming progress
- Opacity by design: peers see results, never each other's prompts or internals
- Linux Foundation governance signals long-term neutrality; adoption still trails MCP's by a wide margin
Composition — and What Standards Don't Solve
The protocols compose cleanly because they answer different questions: an agent uses MCP vertically to reach its own tools and data, and A2A horizontally to delegate to peer agents — one agent's public A2A face can front an internal machinery of MCP servers. But be precise about what standardisation buys. It solves plumbing: discovery, transport, schemas, auth handshakes — the undifferentiated glue that once made every integration bespoke. It does not solve judgement: whether the model calls the right tool, whether a tool description is honest, whether a peer agent is competent or safe to trust, or how errors compound across a delegation chain. Interoperability also cuts both ways — a standard port for capabilities is a standard port for attacks, which is where the next lesson picks up. Protocols move the hard problems up the stack; they do not remove them.
- MCP is vertical (agent to capabilities); A2A is horizontal (agent to agent) — complementary, not rivals
- Standardisation commoditises integration plumbing, and only the plumbing
- Tool choice, description honesty, peer trust, and error propagation remain your problems
- Every standard interface is also a standard attack surface — design with that symmetry in mind
- Protocol depth stops here — Agent Engineering covers what a good tool looks like: descriptions, schemas, and returns a model can recover from
Prefer slides, quizzes, and saved progress? Read this lesson in the library — free, no sign-up.