MCP vs A2A: what IT leads need to know now

MCP vs A2A: if you are planning agent projects in 2026, you will run into both acronyms, and the question sounds like an either-or. It is not. The Model Context Protocol (MCP) governs how an AI agent gets to tools and data. The Agent2Agent protocol (A2A) governs how agents hand tasks to each other. Since August 2026, both sit with the same neutral organisation: the Agentic AI Foundation under the umbrella of the Linux Foundation.

For you as an IT lead, that is good news and also a call to action. Two protocols mean two kinds of connections that someone has to approve, secure and monitor. This article explains what each protocol governs, what changed in 2026 and which decisions now sit with you. If MCP is still new to you, read our introduction first: MCP explained simply.

TL;DR

• Two layers, not competitors. MCP connects an agent to tools and data, A2A connects agents to each other. The A2A project itself calls the two protocols "highly complementary".
• A2A published its first stable specification in 2026, and MCP gained a stateless protocol core in specification version 2026-07-28. A2A v1.0 came out in March. Since August, both projects belong to the Agentic AI Foundation.
• Your job is the approvals, not the choice of protocol. Which MCP servers are allowed, which rights an agent has and which actions a human confirms determine benefit and risk.

MCP and A2A in one sentence

MCP is an agent's connection to its tools, A2A is the common language in which agents exchange work with each other. The A2A project site puts it like this: "MCP is for agent-to-tool communication", A2A "is for agent-to-agent communication". They solve different problems and are built to work together.

The A2A project has an image for this that is easy to remember: MCP is the vertical integration layer that connects an agent to internal tools and databases. A2A is the horizontal protocol for collaboration between peer agents.

	MCP	A2A
Connects	Agent with tools, data and services	Agent with other agents
Core building blocks	Tools, Resources, Prompts	Agent Card, Task, Message, Artifact
Version described	Specification 2026-07-28	Version 1.0 (March 2026)
Home	Agentic AI Foundation	Agentic AI Foundation (since August 2026)

What MCP governs: agent to tool and data

According to its specification, MCP is an open protocol for integration between AI applications and external data sources and tools. It defines three roles. The host is the AI application, for example an AI-assisted development environment or a chat interface. The client is the connector inside the host. The MCP server is the service that provides context and capabilities, for example access to your ticketing system or an internal wiki.

An MCP server offers three kinds of building blocks:

• Tools: functions that the AI model can execute, such as "create ticket" or "query record".
• Resources: context and data that users or the model can use.
• Prompts: prepared messages and workflows for users.

One figure from the MCP project shows how widespread this has become: the official Tier 1 SDKs together reach almost half a billion downloads per month. How an agent uses such tools in its working loop is described in How an AI agent really works.

Important for the security assessment: the MCP specification states explicitly that tools represent arbitrary code execution and must be treated with caution. Hosts must obtain explicit user consent before every tool call. Descriptions of tools are considered untrusted unless they come from a trusted server. According to the specification, MCP cannot enforce these principles at protocol level; that is the job of the implementations.

What A2A governs: agent to agent

According to the project site, the A2A protocol is an open standard for communication and collaboration between AI agents, even when they are built on different platforms and frameworks. Google introduced A2A in April 2025 and handed it over to the Linux Foundation. In August 2025, IBM's Agent Communication Protocol merged into A2A.

The basic principle: agents remain opaque to each other. They work together without exposing their internal memory, their tools or their internal logic. For you this means a partner's agent can take over a task without you having to know its systems, and the other way round.

The most important building blocks:

• Agent Card: a JSON document in which an agent describes who it is, what it can do, where it can be reached and which authentication it requires. Other agents read this card and then know whether and how they can assign work to it.
• Task: a unit of work with its own ID and a defined lifecycle. For long-running tasks, the requester polls for status, has intermediate states streamed or is notified by webhook.
• Message and Artifact: Messages are individual conversation steps, Artifacts are the results, such as a document, an image or structured data.

What A2A explicitly is not: it is not a protocol for tool calls, and not one for how an agent talks to its own sub-agents. For that, the A2A project points to the capabilities of the relevant framework or to MCP.

What changed in 2026

A2A published its first stable specification in 2026. MCP gained a stateless protocol core in specification version 2026-07-28. Three events matter.

A2A v1.0: the first stable specification (March 2026)

On 12 March 2026, the A2A community released version 1.0, by its own account the first stable, production-ready version. New features include several protocol bindings with version negotiation, multi-tenancy (one endpoint can securely host many agents) and signed Agent Cards, which allow an agent's identity to be verified cryptographically. Technically, A2A relies on well-known standards: JSON over HTTP, gRPC and JSON-RPC.

The release announcement also clears up a misunderstanding. A2A is "complementary to MCP, not a replacement". The announcement says many systems use both in practice: "MCP inside agents, A2A between agents".

MCP specification 2026-07-28: a stateless core

The new MCP specification was released on 28 July 2026. The most important change: the protocol core becomes stateless. The previous connection setup (the initialize handshake) and the Mcp-Session-Id header are gone. Each request carries the protocol version, client identity and capabilities itself. This means every request can land on any server instance behind a simple load balancer, without a shared session store.

Further points that matter for operations:

• Header-based routing: requests over Streamable HTTP must now send the Mcp-Method and Mcp-Name headers. Gateways, rate limiters and web application firewalls can route on them and count requests without parsing the JSON content.
• Stricter authorisation: clients must verify the issuer (iss) per RFC 9207. Dynamic Client Registration is officially marked as deprecated in favour of Client ID Metadata Documents.
• Extensions instead of core: Tasks for long-running operations, MCP Apps and Enterprise Managed Authorization are now formal extensions.
• Predictable deprecations: Roots, Sampling and Logging are marked as deprecated and keep working for at least twelve months. The new deprecation rule generally provides for a window of at least twelve months.
• SDKs: the four Tier 1 SDKs (TypeScript, Python, Go, C#) support the new version, the Rust SDK in beta.

Both under the Agentic AI Foundation (August 2026)

On 17 August 2026, the Agentic AI Foundation (AAIF) announced that A2A is being accepted as a hosted project. The AAIF is based at the Linux Foundation and also hosts MCP, goose, AGENTS.md and agentgateway. The A2A project speaks of more than 150 supporting organisations. It cites built-in A2A support at Google Cloud, AWS Bedrock AgentCore Runtime and Microsoft Azure AI Foundry, as well as use at ServiceNow, Salesforce, Atlassian and SAP. The AAIF itself reported 247 member organisations in August, with Alibaba, Visa and Wells Fargo among the new joiners.

Google Cloud shows how closely the two protocols are moving together in practice. In its developer overview of 20 May 2026, Google describes A2A as the common layer beneath all four ways of building agents on Google Cloud, from the low-code tool to your own code. In the new Managed Agents API, each agent gets its own sandbox with MCP servers; full A2A integration is announced there as "coming soon".

For you this means: according to the AAIF, a protocol under neutral governance no longer depends on the product decisions of a single vendor. How to avoid lock-in at contract level is covered in AI vendor lock-in: the 3 clauses.

What this means for IT leads

The protocol question is quickly answered, the approval question is not. Every MCP server is a new access path to a system, every A2A partner a new requester or contractor for your agents. You should address three issues now.

Approvals: who may trigger what?

An agent with MCP access can carry out real actions. Define which actions an agent may perform on its own and which a human must confirm case by case. Our free AI policy template uses permission levels from 1 to 6: deletion, sending outside the organisation, payments and legally binding declarations (levels 4 to 6) require human confirmation in each individual case. How much autonomy makes sense for which process is explored in the human-in-the-loop guide.

Connectors: which MCP servers are allowed?

Our recommendation: treat MCP servers like software that gets access to your systems. That means an allowlist, an owner for each server and a review before use. In the template, Annex A3 is meant for exactly this, to record connectors and MCP servers, and Annex A1 keeps a register of all agents. For A2A, the same applies one level up: record which external agents your agents may hand tasks to.

If you operate your own MCP servers, plan the migration to 2026-07-28. The MCP team itself says migration will require work, especially for servers that relied on session IDs. If your engineering team builds its own agents, a shared approach helps: our Claude Code course takes you from tooling setup to multi-agent orchestration across 22 lessons and 7 modules.

Security: what the protocols deliver and what they do not

Both protocols bring building blocks, but neither replaces a security architecture. For MCP, consent and control lie with the implementations according to the specification. With version 2026-07-28, gateways get at requests more easily, because method and tool name are in the header. For A2A, the project documentation requires HTTPS for all production connections, relies on established standards such as OAuth 2.0 and OpenID Connect for authentication and calls for the principle of least privilege. Signed Agent Cards help verify the identity of an external agent.

The MCP specification already classes the descriptions of tools as untrusted unless they come from a trusted server. The same principle applies to everything an agent reads: our template treats external content as untrusted by default and states that prompt injection cannot currently be fully ruled out. What such attacks look like and what helps against them is covered in Prompt injection: protecting AI agents.

Decision aid: when to use what

The short rule from the A2A documentation: use MCP to equip a single agent with the tools it needs for its task, such as access to a GitHub repository or a SQL database. Use A2A so that this agent can collaborate securely with other agents across framework boundaries.

Situation	Protocol
An agent should read data from your ticketing system, wiki or ERP, or create something there	MCP
An agent should start a long-running operation via a tool and query its status later	MCP with the Tasks extension
An agent should hand work to an agent on another platform or at a partner	A2A
Agents from different vendors should distribute tasks among themselves	A2A
An agent controls its own sub-agents in the same framework	Framework capabilities or MCP, A2A does not cover this according to the project

Our assessment for the Mittelstand: start with MCP. If your first agent is to access internal systems, MCP offers a standardised interface for that. A2A pays off as soon as agents from different platforms or partners are meant to work together. What the path from the first use case to production looks like is shown in Your first AI agent. If you want to sort out the approvals for your first agents, talk to us for 30 minutes: book a call.

FAQ

What is the difference between A2A and MCP?

MCP governs how an agent accesses tools, data and services. A2A governs how agents find each other, hand over tasks and exchange results. The A2A project describes MCP as the vertical layer and A2A as the horizontal one.

Does A2A replace MCP?

No. The A2A documentation says explicitly that A2A is not a replacement for MCP and that the two are complementary. The release announcement for A2A v1.0 sums it up like this: MCP inside agents, A2A between agents.

Which protocol is better for the Mittelstand?

That depends on the task, not on company size. Our assessment: for your first agent in production, you usually need MCP because it has to connect to your systems. A2A becomes important as soon as agents from different platforms or partners are meant to work together.

How secure are MCP and A2A implementations?

Security depends on implementation, configuration, permissions and operation. The MCP specification requires explicit user consent before tool calls, but cannot enforce this at protocol level. A2A relies on HTTPS, OAuth 2.0, OpenID Connect and least privilege, and since v1.0 also on signed Agent Cards. You still have to settle approvals, allowlists and logging yourself.

What does it mean that MCP is now stateless?

Since specification 2026-07-28, there is no connection setup and no session ID at protocol level. Each request describes itself, so any server instance can answer it, even behind a simple load balancer. If a server still needs state across several calls, the MCP team recommends an explicit handle that the model passes on as an argument.

Does MCP manage agent memory?

No. The specification defines Tools, Resources and Prompts, but no memory concept of its own. Since specification 2026-07-28, there is no protocol session any more. For state across several calls, the MCP team recommends explicit handles. How agents work with memory overall is explained in How an AI agent really works.

Sources

• Model Context Protocol, Specification 2026-07-28: modelcontextprotocol.io/specification/2026-07-28
• Model Context Protocol Blog, "The 2026-07-28 Specification", 28 July 2026: blog.modelcontextprotocol.io/posts/2026-07-28
• A2A Protocol, home page with "How A2A Works with MCP" and "What A2A Is Not": a2a-protocol.org/latest
• A2A Protocol, Key Concepts: a2a-protocol.org/latest/topics/key-concepts
• A2A Protocol, Enterprise Implementation of A2A: a2a-protocol.org/latest/topics/enterprise-ready
• A2A Protocol Blog, "A2A Protocol Ships v1.0", 12 March 2026: a2a-protocol.org/latest/blog/2026/03/12/...
• A2A Protocol Blog, "A New Chapter for A2A: Joining the Agentic AI Foundation", 27 August 2026: a2a-protocol.org/latest/blog/2026/08/27/...
• Agentic AI Foundation, "A2A joins AAIF's open agentic stack", 17 August 2026: aaif.io/blog/a2a-joins-aaif
• Agentic AI Foundation, "Agentic AI Foundation Welcomes 57 New Members", August 2026: aaif.io/news/agentic-ai-foundation-welcomes-57-new-members
• Google Cloud Blog, I/O '26 news for agent developers, 20 May 2026: cloud.google.com/blog/...