Agent Protocols: MCP and A2A
Same Scenario, Two Protocols
Consider a single task: "Book me a flight to Dubai and add it to my calendar." This scenario runs through both protocols to make the difference concrete. Under MCP: one LLM (Claude) stays in control throughout. It connects to a Flight API MCP server and a Calendar API MCP server as tools it calls directly — simpler architecture, lower latency, one reasoning chain. Under A2A: an Orchestrator agent delegates to two specialized agents — a Flight Agent (its own tools, memory, and model) and a Calendar Agent (same). Each operates autonomously on its subtask; the orchestrator aggregates. The protocol determines the architecture, which determines the trust model and failure modes.
MCP: One LLM, Multiple Tools
MCP standardizes how a single agent reaches out to tools and resources — think of it as the agent peripheral bus. The LLM queries available MCP servers, calls their tools, and synthesizes the results. One LLM stays in control throughout. Key characteristics: simpler architecture, lower latency (fewer round trips), easier to debug (single reasoning chain), single trust boundary to govern. Ideal when tasks are well-defined, tool calls can be orchestrated by one model, and domain specialization is not required. MCP is the right default for most workflows. Note: when agents in an A2A network need to call tools, they use MCP to do so — the two protocols are complementary, not competing.
A2A: Specialized Agents Collaborating
Agent2Agent protocol (Google, 2025, increasingly adopted) standardizes how agents discover and communicate with each other — think of it as the network layer between agents. In the Dubai example, an Orchestrator spawns a Flight Agent and a Calendar Agent, each with specialized tools, memory, and a model tuned for its domain. They run in parallel; the Orchestrator aggregates. Key characteristics: higher coordination overhead, better domain specialization, and independent failure isolation — one agent failing does not cascade to the other. Ideal when subtasks require genuinely different expertise, can run in parallel with independent state, or have different privilege requirements. Together with MCP, A2A creates the substrate for multi-agent enterprise systems.
When to Use Which — and the SE Credibility Move
Decision heuristic: use MCP unless the subtasks are genuinely heterogeneous (different domain expertise required), can run in true parallel, or need different privilege levels. If two or more of those are true, A2A adds real value. If not, A2A adds coordination overhead without benefit. The SE credibility move: cleanly separating agent-to-tool (MCP) from agent-to-agent (A2A) for a customer architect immediately distinguishes you from competitors who conflate them. Discovery question: "Does your current architecture have a coordination layer between agents, or are agent interactions point-to-point?" — the answer reveals their current state and opens the architectural conversation.
Prefer slides, quizzes, and saved progress? Read this lesson in the library — free, no sign-up.