Two open protocols now shape how AI agents are built, and they are often mentioned together and sometimes presented as rivals. They are not. The Model Context Protocol (MCP) is the open standard that connects an AI agent to tools and data, and Agent2Agent (A2A) is the open standard that connects an AI agent to other agents. Most production systems of any size will meet both.
The short version: MCP connects an agent to tools and data. A2A connects an agent to other agents.
What MCP does
MCP is the standard way for an agent to reach the systems it works with: a database, a ticketing system, a document store, an internal API. An MCP server exposes tools and data; an agent, through its client, discovers those tools and calls them.
The MCP versioning page gives the current protocol version as 2026-07-28. That revision moved MCP to a stateless core, as the MCP blog's post on the 2026-07-28 specification explains, and the protocol's security best practices set firm rules. A server must not accept tokens that were not issued for it, so passing a user's token through to another service is forbidden. A proxy server must ask for consent per client. A one-click local installation must show the exact command before it runs. Scopes should start minimal and grow only as needed.
In practice, MCP is where an agent's power over your systems is decided. Every tool an agent can call through MCP is something it can do, so the tool list is a security boundary as much as a feature list.
What A2A does
A2A is the standard way for one agent to find another, learn what it can do, and hand it work, including agents built by other vendors on other frameworks.
The first stable specification, A2A 1.0.0, was released on 12 March 2026. The A2A releases page lists 1.0.1, a bug-fix release published on 28 May 2026, as the latest. The central idea of the A2A specification is the Agent Card: a published description of an agent's skills and how to authenticate with it, discovered at a well-known address on the agent's domain. Agent Cards can be signed. The specification supports API keys, HTTP authentication, OAuth 2.0, OpenID Connect and mutual TLS, and defines three ways to carry calls: JSON-RPC, gRPC and HTTP with JSON.
Google launched A2A in April 2025. The Linux Foundation has hosted it since June 2025, when Google Cloud donated A2A to the Linux Foundation. In August 2026 it joined the Agentic AI Foundation, which also lists MCP among its projects.
Side by side
| MCP | A2A | |
|---|---|---|
| Connects | An agent to tools and data | An agent to other agents |
| The other side is | A server exposing tools | An agent with its own reasoning |
| Discovery | The client lists a server's tools | An Agent Card at a well-known address |
| The main question it answers | What can this agent touch? | Who can this agent delegate to? |
| Main risk to manage | Excessive tool access, poisoned tool definitions | Trusting an agent you cannot verify |
When you need which
MCP alone fits most first agents: one agent, working inside your systems, calling a defined set of tools. The design work is choosing those tools, scoping their credentials, and deciding which calls need a person's approval.
A2A joins when work crosses agent boundaries: a claims agent asking a fraud agent for a check, or your agent calling a supplier's agent. At that point the questions change. How does the calling agent know who it is talking to? What may the other agent do with what it receives? Signed Agent Cards and proper authentication answer the first; your own contracts and monitoring answer the second.
Both together is the common shape of a larger system. Each agent reaches its own tools through MCP and publishes an Agent Card so other agents can call it through A2A. Inside each agent, a framework such as LangGraph or Google's Agent Development Kit holds the steps and the decisions.
How we design for both
- Treat the tool list as policy. An agent should bind only the tools on its allow-list, and stop if a tool's definition changes until someone approves it again.
- Give every agent its own identity. Shared credentials make it impossible to tell which agent did what, across MCP or A2A.
- Keep consequential steps behind approval. Neither protocol decides when a person must approve an action. That is your design decision, and it belongs outside the model.
- Trace across both. A request that passes through three agents and five tools should be one trace. The OpenTelemetry GenAI semantic conventions give agent and tool calls shared names, though they are still in development status.
If you are connecting agents to systems you already run, our MCP engineering work covers server design and security audits, and composable agents describes how single-purpose agents with A2A Agent Cards fit together.
Further reading
- Security best practices, Model Context Protocol: The source of the token, consent and scope rules above, and the page to read before you expose an internal system through MCP.
- A2A specification, A2A project: The full definition of Agent Cards and their signing, the supported authentication schemes and the three ways to carry calls.
- The 2026-07-28 Specification, Model Context Protocol blog: A readable account of why MCP moved to a stateless core and what that retired.
- GenAI semantic conventions, OpenTelemetry: The shared names for agent and tool calls that let one trace follow a request across agents and tools.
- MCP server vs A2A: connect AI assistants to your data, AELSHA™ NEHEMVIX: A working example of both: one set of read-only tools served over MCP and A2A, with access tokens.
Both protocols change with each new revision and release, so check the linked specifications before you build on them.