MCP vs A2A: How AI Agents Use Tools

Most explanations of MCP vs A2A treat the protocols as rivals. They are not. MCP, the Model Context Protocol, is the agent-to-tool layer; A2A, the Agent2Agent protocol, is the agent-to-agent layer. The interesting design work sits in both: routing headers, explicit state handles and a human approval before money moves.

MCP vs A2A: what each protocol actually connects

MCP vs A2A is a division of scope, not a competition: MCP, the Model Context Protocol, is an open standard that connects an AI application to tools and data, while A2A, the Agent2Agent protocol, is an open standard that lets independent agents discover each other and hand off tasks. Both were contributed to the Linux Foundation.

The distinction matters because the two layers fail differently. A broken tool connection shows up as a wrong argument or a timeout. A broken agent handoff shows up as a task stuck in a state nobody polls.

Layer	Protocol	Connects	Typical failure
Tools and data	MCP	Host app to servers	Vague tool descriptions, wrong tool chosen
Peer agents	A2A	Agent to agent	Stalled task, unclear state
Inside the agent	Agent loop	Model to its own next step	Endless looping, runaway cost

Neither protocol makes a model smarter. Anthropic introduced MCP in late 2024 as a way to replace bespoke per-tool integrations with one wire format. Google created A2A and donated it to the Linux Foundation in June 2025. A chatbot wrapped in an agent loop, MCP servers and an A2A client is often the same underlying model as the plain chatbot it replaced.

What separates a chatbot from an AI agent

An AI agent is a model plus tools, a loop and memory, working toward a stated goal; the model alone only predicts text. That definition is the whole difference. A bare model asked for next Friday's cheapest Chicago flight can only guess, because its knowledge is frozen at training time and it cannot reach a booking API.

The loop runs in three beats: think about the next step, act by calling a tool, observe the result, then repeat. It ends when the goal is met or when the agent hits a decision it should not make alone.

A step cap belongs in every design. Without a maximum number of steps, a time limit or a budget, an agent that keeps receiving confusing tool results can loop indefinitely, and each lap costs tokens.

TripPilot, the travel assistant used as the running example, shows the loop in four laps. It searches flights and finds options near $200, searches hotels and finds one around $200 a night, totals the trip under budget, then places a 24-hour hold. The fifth lap would be payment, and the agent stops and asks before spending.

How tool calling works when the model only emits text

Tool calling works because the model never executes anything: it writes a structured request naming a tool and its arguments, and the application decides whether to make the call. The app then returns the result to the model as more text. Function calling is the same mechanism under an older name.

That middle layer is where permissions, logging and refusals live. The model proposes and your code decides, which keeps a human-authored policy between the language model and any real system.

A tool definition has three parts: a name such as search_flights, a plain-language description, and an input schema declaring which arguments are required. The model reads all three when choosing a tool and filling in arguments.

Treat the description as part of the prompt. Two tools with vague or overlapping descriptions produce wrong selections. Clear names, distinct descriptions and tight schemas are among the cheapest reliability improvements available, and they cost nothing at runtime.

MCP hosts, clients and servers, explained without the confusion

An MCP host is the AI application a person uses, and inside it run one or more MCP clients, each a connector bound to a single server that offers capabilities. The client is software inside the app, not the end user, which is the naming trap that trips up most newcomers.

MCP servers expose three kinds of capability. Tools are actions the model can choose, such as searching flights. Resources are data the app reads into context, such as a cancellation policy. Prompts are reusable templates a user picks from a menu. Tools do, resources inform, prompts guide.

Servers run locally or remotely. Local servers start as background programs and talk over standard input and output (stdio), which suits reading files in a project. Remote servers speak the Streamable HTTP transport, which suits a shared service used by many people. Local servers run with your machine permissions, so installing one carries the same risk as installing any application.

A single call has a fixed shape. The client asks tools/list and receives the tool catalog with descriptions and schemas. The model selects one. The client sends tools/call with a name and arguments such as Dallas to Chicago on November 20. The server calls the airline API and returns three flights from $212. The client drops that into the model's context and the loop continues.

The integration argument is simple arithmetic. Four apps and five tools written as custom glue produce twenty integrations, each with its own bugs and its own maintenance when a tool API changes. One MCP server per tool removes the multiplication, which is why the protocol is compared to USB-C.

What changed in the July 2026 MCP specification

The MCP specification dated 2026-07-28 made the protocol core stateless, retiring the initialize handshake and the session ID header so any request can reach any server instance behind a plain load balancer. Earlier revisions, through November 2025, opened every connection with a capability handshake and, over HTTP, a session identifier.

The old model worked like a phone call and broke under scale. If a session lived on server A and the next request landed on server B, server B had no record of the caller. Teams answered with sticky sessions, which uneven load and awkward deploys follow, or a shared session store, which is another piece of infrastructure to run and secure.

Statelessness does not mean the application forgets the trip. A tool such as create_itinerary returns an explicit handle like trip 42, and the model passes that handle back as an argument on later calls while the state sits in your database. The model can see the handle and thread it between calls, which the MCP project argues is clearer than hidden connection state.

Four further changes matter for anyone migrating:

1. HTTP requests must carry the method and tool name in the Mcp-Method and Mcp-Name headers, so gateways, rate limiters and firewalls can route or block without parsing the body.
2. List responses can carry a time to live and cache scope, so clients stop re-downloading the same tool catalog and the model's prompt stays stable.
3. Multi Round-Trip Requests replace server-initiated prompts over a held-open connection: the server answers that input is required, the app collects it, and the client re-sends the original call with the answer attached.
4. The Tasks extension, experimental in late 2025, became an official extension for long-running work that a client starts and checks later.

The same revision deprecated older features including roots, sampling and logging, and the legacy HTTP plus SSE transport. Those remain supported for at least twelve months, but new projects should not adopt them. Authorization was hardened as well, moving away from dynamic client registration toward client metadata documents as one element of that work; builders should read the migration notes before assuming their existing auth flow carries over unchanged.

Governance shifted too. MCP was introduced by Anthropic late in 2024 and contributed to the Linux Foundation's Agentic AI Foundation in December 2025. The official tier-one SDKs are TypeScript, Python, Go and C#. Neutral stewardship is what lets competitors build on one standard, and it is a plausible reason adoption followed.

A2A agent cards, tasks and how A2A differs from MCP

A2A lets one agent hand work to another company's agent using a published agent card and a task lifecycle, and its separation from MCP is the point. A hotel chain running its own booking agent on its own framework can work with your planner agent without either side exposing internal prompts, memory or tools.

Discovery starts with the agent card, a JSON business card published at a well-known address. It lists the agent's name and description, its skills such as booking a room or changing a reservation, the address to reach it, and the authentication it requires, for example OAuth.

Work then follows a defined path:

• Messages carry the conversation, composed of parts that can be text, files or structured data.
• Tasks track the work and move through submitted, working, then completed, failed, canceled or rejected.
• Artifacts carry the result, such as a booking confirmation.
• Two special states pause the work: input-required when an answer is needed, auth-required when credentials are needed.

A2A offers three ways to learn that a task finished. Polling checks status periodically, which is simple but slower and slightly wasteful. Streaming pushes updates live, which suits progress bars. Push notifications call a webhook when something changes, which suits long server-to-server work such as a group booking that takes hours. The protocol runs over JSON-RPC, gRPC or plain HTTP with JSON.

Splitting one overloaded agent into specialists is the usual reason to reach for this layer, and the tradeoff is real. More agents means more model calls, more cost and more places for failures to surface. Start with a single agent and split only when context pressure and error rates justify it.

Memory, context engineering and what breaks in production

Agents fail most often on context management and security rather than reasoning: tool results pile up until important details are buried, cost rises and quality drops. Context engineering, the practice of choosing exactly what the model sees on each step, is the response.

Two kinds of memory need separate treatment. Short-term memory covers this trip. Long-term memory covers durable preferences, such as always wanting an aisle seat, and should be visible to the user and deletable. Summarizing old steps and exposing only the tools needed right now keeps each prompt small.

Security requires treating the agent as an insider with credentials.

• Prompt injection: text the agent reads, such as a hotel review instructing it to email passport details, can be mistaken for instructions because the model does not reliably separate data from commands.
• Untrusted tool metadata: the MCP specification warns that tool descriptions and annotations should be treated as untrusted unless they come from a trusted server.
• Over-broad permissions: one large access token for every action means one leak exposes everything.
• Shadow servers: unapproved MCP servers appear without review. In Salt Security's 2026 State of AI Agents report, 54% of respondents confirmed or suspected an unauthorized, shadow or misconfigured MCP server in the previous year, and about 17.5% said they could automatically stop a misbehaving agent in production.

Practical controls follow from that list: give each agent its own identity rather than the user's account, grant least privilege, require human approval for costly or irreversible actions, log every tool call so the sequence can be reconstructed, and keep a kill switch. The Microsoft security framing quoted in the video, surrounding non-deterministic intelligence with deterministic controls, is the right summary. Local execution and allowlists support a restricted deployment; they do not by themselves prove compliance with any regulatory regime.

Putting the pieces together: a reference agent stack

A complete agent system puts a planner agent with memory and deliberate context in front of specialist agents, MCP servers for tools and an A2A connection to outside companies, with one security layer around all of it. Nothing in that stack is exotic; the ordering is the design.

TripPilot's assembled shape looks like this:

Component	Role	Protocol
Planner agent	Breaks the trip into parts	none (internal loop)
Flight and budget agents	Specialist reasoning	internal handoff
Flight, calendar, payment servers	Tool access	MCP
Gateway	Routing and rate limits	MCP headers
Hotel chain agent	External booking	A2A

Payments sit behind an approval gate, the gateway uses the new Mcp-Method and Mcp-Name headers to send booking calls to a stricter tier, and stateless servers scale behind a plain load balancer. Identities, least privilege, logs and a kill switch wrap the whole arrangement.

Four myths are worth retiring before an interview. MCP is not an agent framework; frameworks build agents and MCP plugs them into tools. A2A does not replace MCP; real systems use both. A well-designed agent should ask before risky or irreversible actions. And a stateless protocol does not stop an agent from remembering, as long as explicit handles carry the state.

FAQ

• What is the difference between MCP and A2A? MCP connects an AI application to tools and data through hosts, clients and servers. A2A connects one agent to another agent using agent cards and tasks. They address different layers and are designed to be used together.

• Is MCP stateless now? The MCP specification revision dated 2026-07-28 made the protocol core stateless, removing the initialize handshake and the session ID header. Applications keep their own state in explicit handles rather than in the connection.

• Does A2A replace MCP? No. A2A handles agent-to-agent task handoff, while MCP handles agent-to-tool and agent-to-data access. A production system such as a travel assistant typically needs both.

• How do you secure an AI agent? Give each agent its own identity and least-privilege credentials, require human approval for spending or deleting, log every tool call, restrict which MCP servers are allowed, and keep a way to stop the agent automatically. Detectable prompt injection in tool output should be treated as an expected input, not an edge case.

• What is an agent card in A2A? An agent card is a JSON document published at a well-known address that describes an agent's name, skills, endpoint and authentication requirements. It lets other agents discover what the agent can do without exposing its internal prompts or tools.

If you are learning this material from videos as well as documentation, tools such as Gustavo dev doido's channel walk through adjacent AI engineering topics and are worth comparing against the specs above.

Turn a recorded walkthrough into a readable article

Explaining MCP vs A2A out loud is one skill; leaving behind a written explanation that someone can reread line by line is another. The diagrams and trip-booking thread that make a video clear rarely survive as text without work.

If your explanation already exists on YouTube, Skala Blog takes a video URL, transcribes it and generates an article draft from that transcript. The decisions about accuracy and structure stay with you.

Source video