MCP connects an AI agent to tools and data; A2A connects AI agents to each other. The Model Context Protocol is the standard way an agent reads your CRM, queries a database or calls an API. Agent2Agent is the standard way an agent hands a task to another agent, even from another vendor, and gets the result back. Since August 2026 both sit under the same neutral governance: the Linux Foundation’s Agentic AI Foundation.
For an SME the practical rule is simple: you almost always need MCP, rarely A2A. The first production agent works on one process with a few tools; collaboration between agents from different vendors comes later, if at all.
MCP vs A2A: the differences in one table
| MCP — Model Context Protocol | A2A — Agent2Agent | |
|---|---|---|
| Connects | Agent → tools, data, prompts | Agent → another agent |
| Question it answers | “What does the agent work with?” | “Who does the agent work with?” |
| Created by | Anthropic (November 2024) | Google (April 2025) |
| Governance | Agentic AI Foundation (Linux Foundation) | Agentic AI Foundation, since 17 August 2026 |
| Stable version | Specification 2026-07-28 | v1.0, March 2026 |
| Unit of exchange | Tools, resources, prompts exposed by a server | Delegated tasks, messages, artifacts |
| Identity | OAuth 2.1 towards the MCP server | Signed agent cards, authentication declared in the card |
| Example | The agent reads an order from the ERP through an MCP server | The purchasing agent asks the supplier’s logistics agent for a delivery date |
The two protocols are complementary: the same agent can use MCP for its own tools and A2A to delegate to an external agent. Axios summed it up when A2A joined the AAIF: MCP handles connections between AI applications and tools and data, A2A handles communication between independent agents (Axios, 17 August 2026).
What changed in MCP with the 2026-07-28 specification
The 2026-07-28 revision is the largest since the protocol launched. For anyone integrating agents in a company, four changes matter:
- Stateless protocol. The
initializehandshake and theMcp-Session-Idheader are gone. Each request carries the protocol version and client capabilities, so any server instance can answer behind a plain load balancer, with no shared sessions. server/discover. Optional for the client, mandatory for the server; it exposes supported versions, capabilities and identity.- Explicit state. If you need state across calls you use server-minted handles passed as tool arguments, not implicit sessions.
- Stricter authorization. Dynamic Client Registration (DCR) is deprecated in favour of Client ID Metadata Documents (CIMD), and issuer validation arrives (RFC 9207). PKCE and resource indicators (RFC 8707) remain required, and token passthrough remains forbidden.
In company terms: MCP servers that are easier to scale and put behind a gateway, and fewer excuses for sloppy token handling. If a vendor offers you an MCP server, ask which version of the specification it supports.
A2A v1.0: what it brings
A2A was created at Google in April 2025, donated to the Linux Foundation with founding organizations including AWS, Cisco, Google, Microsoft, Salesforce, SAP and ServiceNow, and in August 2025 absorbed IBM’s Agent Communication Protocol (AAIF). v1.0, the first stable specification, shipped in March 2026 and added:
- multiple bindings (JSON-RPC, HTTP+JSON, gRPC) with version negotiation;
- multi-tenancy;
- signed agent cards, a public description of the agent (capabilities, endpoint, authentication) that can be verified cryptographically.
The AAIF reports more than 150 organizations backing A2A and support in Google Cloud, Azure AI Foundry and AWS Bedrock AgentCore (AAIF).
When to use MCP, when A2A, when neither
| Situation | What to use |
|---|---|
| One agent that reads documents and writes to a single system | Direct API or one MCP server |
| One agent using 3–5 systems (CRM, ERP, email, archive) | MCP, one server per system with separate permissions |
| You want to switch model or agent platform without redoing integrations | MCP: the integrations stay, the client changes |
| Your agent must delegate to an agent run by a supplier or customer | A2A |
| Several internal agents on the same platform | The platform’s native orchestration; A2A only if you will open up to third parties |
| A fixed “if X then Y” flow | Neither: workflow or RPA |
The protocol does not replace permission design: an MCP server with full access to your ERP is a risk even if it follows the specification. For integrations see connecting an agent to your ERP; for authorization levels see AI agents for companies.
Security: the three risks to manage
Tool poisoning. Malicious instructions hidden in tool descriptions, parameter schemas or responses. The model reads them as trusted context and may call unexpected tools or leak data. The OWASP MCP Security Cheat Sheet treats the entire tool schema as an injection surface, not just the description.
Token passthrough. An MCP server that accepts tokens not issued to it and forwards them to downstream APIs. The specification explicitly forbids it: the server must only accept tokens with its own audience (MCP security best practices).
Confused deputy. The server performs actions with its own, often broad, privileges instead of those of the user who made the request.
Minimum controls to require in any project:
- an allowlist of approved MCP servers, no free installs;
- tool definitions pinned by hash, with an alert if they change;
- credentials per server, narrow scopes, short-lived tokens;
- permissions enforced server-side, not left to the prompt;
- human approval outside the model for actions with side effects (sending, paying, deleting);
- a log of every tool call with user, agent, parameters and outcome.
What to ask a vendor
- Which version of the MCP specification do you support, and with which authorization mechanism?
- Does each MCP server have its own identity and credentials, or do they share a service account?
- How are new tools approved, and how do you detect a changed definition?
- Where are tool-call logs stored, and for how long?
- If you use A2A, how do you verify the external agent’s card, and what is it allowed to request?
- If we change model or platform, which integrations stay and which must be rebuilt?
FAQ
What is AI agent interoperability?
An agent’s ability to use tools and collaborate with other agents through standard protocols. Today: MCP for agent-to-tool, A2A for agent-to-agent.
What is the difference between MCP and A2A?
MCP connects the agent to tools and data; A2A connects it to other agents to delegate tasks. They are complementary.
Does an SME need A2A?
Usually not: it is needed when agents on different platforms or at different companies must collaborate.
What changes with the MCP 2026-07-28 specification?
Stateless protocol, server/discover, state through explicit handles, DCR deprecated in favour of CIMD, and issuer validation.
Is MCP secure?
The protocol is, if used well: the risks are tool poisoning, token passthrough and confused deputy, managed with allowlists, hashes, least privilege and approvals outside the model.
Who governs MCP and A2A?
The Linux Foundation’s Agentic AI Foundation, for both.
Sources
- MCP: 2026-07-28 specification changelog
- MCP: security best practices
- AAIF: A2A joins the Agentic AI Foundation
- A2A Protocol: A new chapter for A2A
- OWASP: MCP Security Cheat Sheet
- Axios: Google-backed A2A protocol gets a new home
Dig deeper in the series
- AI agents for companies: what they are, examples and cost
- Connecting an AI agent to your ERP
- How much an AI agent costs (2026)
- From pilot to production
If you are working out how to connect an agent to your systems without giving it more permissions than it needs, we start from the process and the systems involved. Write to info@zendata.it.
Pietro Ciattaglia, CEO of Zendata AI, Rome