Two Protocols, Two Different Jobs
If you are planning an AI agent project, you will soon hear about MCP and A2A. They are often presented as rivals, but they solve different problems, and many larger systems will use both.
The short version:
• Model Context Protocol (MCP) connects an agent to tools and data.
• Agent2Agent (A2A) connects an agent to other agents.
The Linux Foundation describes A2A as complementary to MCP: A2A covers how agents coordinate across organizational boundaries, while MCP covers how agents connect to tools and data.
Think of a new employee. MCP is their access to the CRM, the document library, and the ticketing system. A2A is how they ask a colleague in another department to handle part of a job.
What MCP Does
Without a standard, every combination of agent and system needs its own integration. MCP replaces that with one common way for a system to tell an agent what it offers, and for the agent to use it.
An MCP server wraps a system such as a database, a CRM, or an internal API, and offers its tools and data to agents. Any compatible client can then use that server, so the same integration can work with different agents and models.
Use MCP when:
• An agent needs to read from or act on your business systems
• You want integrations you can reuse across agents and vendors
• You want one consistent place to control access to tools
What Changed in MCP This Year
The current MCP specification is the 2026-07-28 revision, and it is a significant update:
• Stateless by design. The initialize handshake and protocol-level sessions are gone. Each request carries what the server needs, which makes MCP easier to run behind ordinary load balancers.
• Server discovery. A new server/discover method lets a client ask what versions and capabilities a server supports.
• Long-running work. Tasks moved into an official extension, so clients can check on long operations and send input while they run.
• A clear deprecation policy. Roots, Sampling, and Logging are deprecated. Deprecated features generally stay in the specification for at least twelve months before they can be removed.
If you built MCP servers on an earlier revision, plan time to review them against this release.
What A2A Does
As companies deploy more agents, those agents increasingly come from different vendors and frameworks. A support agent from one platform may need a logistics agent from another to resolve an order. A2A gives them a common way to find each other, communicate, and work together, without either one exposing its internal workings.
Google introduced A2A in 2025 and donated it to the Linux Foundation that June. By April 2026, the Linux Foundation reported more than 150 supporting organizations. It also reported integration in Azure AI Foundry, Copilot Studio, and Amazon Bedrock AgentCore Runtime.
Version 1.0 added features aimed at enterprise use, including Signed Agent Cards, which let an agent verify another agent's identity cryptographically, along with multi-tenancy support and modernized security flows.
Use A2A when:
• Agents from different teams, vendors, or companies need to delegate work
• You can't, or don't want to, merge everything into one framework
• Agents need to work together across organizational boundaries
How to Decide
One agent using your internal systems
Start with MCP. You probably don't need A2A yet.
Several agents built by one team on one framework
Use your framework's own orchestration to coordinate them, and MCP for their tools. A2A adds little if every agent already lives in the same system.
Agents crossing teams, vendors, or companies
Use MCP for each agent's tools and A2A between the agents.
Most businesses should start with the first case. Add A2A when you have a real need for agents to work across boundaries, not because it is on a checklist.
Practical Advice for Either Protocol
Keep tool lists short
More tools aren't always better. Too many can overload an agent's context and increase errors, so give each agent only what it needs and describe each tool clearly.
Treat connections as a security boundary
Open standards make it easy to connect things, including things that shouldn't be connected. Vet third-party MCP servers before you use them, use narrowly scoped permissions, and require human approval for high-impact actions. Our guide to the OWASP Top 10 for Agentic Applications covers these risks in more detail.
Don't let a protocol become your architecture
Protocols connect the parts of a system, but they won't decide what your agent should do, how to test it, or when a person should step in. Those decisions matter more to whether a project succeeds.
Expect change
Both protocols are moving quickly. Check the current versions when you build, keep integrations in one place, and track deprecations so that upgrades don't catch you out.
Where to Start
List the systems your first agent actually needs, and decide which of them should be read-only. That short list is your first set of MCP servers. If you would like help designing it, or connecting agents across teams and vendors, get in touch through our contact form.