Nilesh Vishwakarma

Posted on Oct 4

MCP vs A2A: How AI Agents Connect to Tools — and to Each Other

#ai #mcp #architecture #agents

The short version: MCP connects an AI app to tools and data. A2A connects one AI agent to another AI agent. They solve different problems, and many systems use both.

Why agents need more than a language model

A chatbot only has to produce text. An agent has to get things done.

To do that, it may need to search a knowledge base, read a file, query a database, create a ticket, or hand part of the job to another agent. A language model cannot do any of that by itself. Something has to connect it to the outside world.

We already have APIs for connecting software, and they are not going away. The trouble is that every API is different. If each AI app writes its own custom integration for GitHub, for the database, and for the ticketing system, the work gets repeated again and again.

MCP and A2A are two open standards that reduce that repeated work. Each one covers a different connection:

MCP  →  AI app    ↔  tools, data, and context
A2A  →  AI agent  ↔  another AI agent

What is MCP?

The Model Context Protocol (MCP) is an open standard that connects AI applications to the systems where data and tools live.

A helpful way to picture it is a USB port. Before USB, every device needed its own cable and its own driver. MCP gives tools one standard plug, so a tool built once can work with any AI app that speaks MCP.

How MCP works. Conceptual diagram; implementations can vary.

There are three parts to know:

Host: the app the user works in, such as an IDE, a desktop AI app, or your own agent.
Client: the piece inside the host that speaks MCP. One host can connect to many servers.
Server: the piece that offers capabilities to the AI app.

An MCP server can offer three kinds of things:

Tools are actions the model can run, such as search_issues or create_ticket.
Resources are content the app can read, such as a file, a document, or a database record.
Prompts are reusable templates, such as "Review this pull request for security problems."

A quick example

A user asks: "Summarize our release status and create an issue for any blocking database problem."

The app reads the project roadmap through an MCP resource.
The model spots a blocking problem.
The app calls the create_issue tool.
The MCP server talks to the real project-management API.
The result goes back to the user.

Notice step 4. The MCP server still calls a normal API behind the scenes. MCP does not replace APIs. It sits in front of them and presents them in a form that AI apps can discover and use.

What is A2A?

Now picture a company with several specialist agents: a support agent, a billing agent, and a travel agent.

A customer writes: "Refund my ticket and find me a replacement flight."

The support agent knows the customer and the refund policy. The travel agent owns rebooking. So the support agent needs to hand over part of the job.

That is different from calling a tool. The other agent does its own reasoning, has its own tools, may ask a question back, and may need minutes or hours to finish.

The Agent2Agent (A2A) Protocol is an open standard for exactly this. If MCP is a USB port, A2A is closer to how colleagues work together: you find out who does what, hand over a job, check on progress, and get the finished work back.

Google started A2A in 2025 and donated it to the Linux Foundation. Version 1.0, the first stable release, shipped in March 2026. Since August 2026 it has been hosted by the Agentic AI Foundation, the Linux Foundation body that also hosts MCP.

How A2A works. Conceptual diagram; implementations can vary.

A2A has four building blocks:

Agent Card: a small JSON file where an agent describes itself, including its name, skills, address, and security requirements. Think of it as a business card that other agents can read.
Message: one turn of conversation between agents. It can carry text, files, or structured data.
Task: a unit of work with its own ID and status. It can be working, waiting for input, completed, or failed, so the client can follow long jobs.
Artifact: the finished output of a task, such as a report, an image, or structured data.

One point matters here. The remote agent keeps its inner workings private. Other agents see what it can do, not how it does it.

MCP vs A2A at a glance

MCP and A2A solve different interoperability problems.

	MCP	A2A
Connects	AI app ↔ tools and data	Agent ↔ agent
Main building blocks	Tools, resources, prompts	Agent Card, messages, tasks, artifacts
Other side is	An MCP server	An independent agent
Typical request	"Search GitHub issues"	"Ask the security agent to investigate this incident"
Long-running work	Possible	Built in through tasks
Replaces REST APIs?	No	No

Neither one is "better." They describe different relationships.

Using both together

Most real systems with more than one agent end up using both.

A user asks a support agent: "Find out why our customer's deployment failed, check whether it affects their SLA, and draft a reply."

A2A handles agent-to-agent collaboration. MCP handles access to tools and context.

The support agent uses MCP to read logs, tickets, and customer data.
It sees that the incident may affect the customer's contract.
It hands that question to a contract agent through A2A.
The contract agent uses its own MCP server to look up the contract.
The contract agent returns its findings as an artifact.
The support agent combines everything and drafts the reply.

The support agent never needs to learn the contract system's API. The contract agent never has to expose its internal tools. Each side has one clear job.

Which one do you need?

Your AI app needs tools or data. Use MCP.
Your agent needs help from another independent agent. Use A2A.
Your agents work together and also need tools. Use both.
You have one simple integration that already works. Use neither. A plain REST API or function call is fine.

That last point is easy to forget. If your app calls a single weather API, adding a protocol only adds complexity. Use MCP or A2A when they save you integration work, not because they are new.

A simple test: ask what sits on the other side. If it mainly offers tools or data, MCP fits. If it is an independent agent that accepts work, A2A fits.

Two things a protocol will not fix

Security. A standard way to call delete_file does not make it safe to call. You still need authentication, permissions, input validation, audit logs, and human approval for risky actions. The MCP team says plainly that tool annotations are hints and not enforcement. A tool that describes itself as read-only may not be.

Quality. MCP standardizes how a tool is called. It cannot promise the tool works correctly. A2A standardizes how agents talk. It cannot promise the other agent is right. An agent that speaks your protocol is not automatically an agent you should trust.

One 2026 change worth knowing

If you read older MCP tutorials, watch out for one thing. The MCP specification released on July 28, 2026 made the protocol stateless.

Older versions began every connection with an initialize handshake and tracked it with a session ID. Both are gone. Every request now carries everything it needs, so any server instance behind a load balancer can answer it.

Your application can still keep state. It just no longer lives inside the protocol session. Many articles from 2025 describe the old behavior, so check which version your SDK supports.

Wrapping up

MCP is how an AI app reaches tools, data, and prompts.
A2A is how one agent hands work to another agent.
They complement each other, and both sit on top of the APIs you already have.
Sometimes the right answer is neither.

Pick the protocol that matches the relationship between your components, not the one getting the most attention this month.

This article reflects the MCP 2026-07-28 specification and A2A 1.0, as of October 2026. Both projects are still evolving, so check the version your tools support.

DEV Community