MCP vs A2A is a layer question, not a contest. MCP (Model Context Protocol) connects an agent to tools, data and prompts. A2A (Agent2Agent) connects an agent to other agents, which can belong to another team or company. The A2A documentation says it plainly, "MCP is vertical" and "A2A is horizontal".
If you have one agent calling your own API, you need neither protocol yet. Pick MCP when more than one AI client must reach the same tools. Pick A2A when two or more independently deployed agents must hand work to each other and writing a custom integration per pair has become the real cost.
As of November 12, 2026, MCP's current revision is 2026-07-28 and A2A's current line is v1.0.x. Both are hosted by the Agentic AI Foundation. This post gives you a feature table where every entry is sourced, and a decision matrix by team situation.
See what a working MCP server looks like
Oakgen runs a remote MCP server for image, video, speech, music and sound generation. Read the tool list and connect a client.
The short version
| Question | MCP | A2A |
|---|---|---|
| What does it connect? | An AI application to tools, data and prompts | Independent agents, as peers |
| Who is on the other end? | A server that exposes capabilities | Another agent that reasons and keeps its own state |
| Discovery | server/discover RPC, plus whatever your client is configured with | Agent Card at /.well-known/agent-card.json, registries or direct configuration |
| Long-running work | Optional Tasks extension | Task is a core object with a defined lifecycle |
| Current version | 2026-07-28 | 1.0.1 on GitHub (the docs page still says 1.0.0) |
| Start here if | Several clients need the same tools | Several agents need to delegate across a boundary |
Who this is for
You are an engineer or technical lead who keeps seeing "MCP and A2A" in the same sentence and must decide what to build this quarter. You may also lead a creative team that uses AI assistants. If you are wiring one assistant to a few services, read the matrix and the "you may need neither" section, and skip the A2A detail.
How we checked this
On November 12, 2026 we opened the MCP specification pages, the MCP changelog and SEP-2663, the A2A specification, its v1.0 notes and roadmap, the A2A GitHub releases, and the Linux Foundation and Agentic AI Foundation announcements. Every spec detail below comes from those pages. Every third-party number names its publisher and date on the same line.
We did not build an A2A agent or benchmark either protocol. Adoption figures are the publishers' own claims and are labelled that way.
Disclosure. Oakgen is our product and it exposes an MCP server. We found no A2A support in our code. We mention Oakgen only to show how a creative team would apply the choice.
The layers, in one picture
Picture an agent in the middle. Below it sit things that are not agents. Beside it sit other agents.
Below, MCP. The MCP architecture page describes a host that creates one client per server. Servers expose resources, tools and prompts, and should not be able to read the whole conversation or see into other servers. The protocol is JSON-RPC 2.0, and since the 2026-07-28 revision it is stateless. The changelog removes the initialize handshake and the Mcp-Session-Id header, so every request carries its own protocol version and client capabilities.
Beside, A2A. The A2A specification describes a client agent and a remote agent that collaborate without access to each other's internal state, memory or tools. It calls this opaque execution. The unit of work is a Task, which the server creates and tracks. Discovery runs through an Agent Card.
The A2A v1.0 announcement puts it as "MCP inside agents, A2A between agents". That is the A2A project's own framing, and it fits the MCP side's design.
What A2A adds, in four objects
You can read the whole A2A model in four objects.
Agent Card. A JSON document every A2A server must make available. Required fields in the v1.0 specification are name, description, supportedInterfaces, version, capabilities, defaultInputModes, defaultOutputModes and skills. Security schemes and signatures are optional. Here is an illustrative card for a made-up ad review agent, not a real service.
{
"name": "Ad Review Agent",
"description": "Checks ad drafts against a brand guide and returns pass or fail notes.",
"version": "1.0.0",
"supportedInterfaces": [
{ "url": "https://agents.example.com/review", "protocolBinding": "JSONRPC", "protocolVersion": "1.0" }
],
"capabilities": { "streaming": true, "pushNotifications": false },
"defaultInputModes": ["text/plain", "image/png"],
"defaultOutputModes": ["application/json"],
"skills": [
{ "id": "brand-check", "name": "Brand guide check", "description": "Flags off-brand copy and visuals.", "tags": ["review", "brand"] }
]
}
A client finds it at /.well-known/agent-card.json, in a registry or through direct configuration. The A2A discovery page is candid that the specification does not prescribe a standard API for curated registries.
Task. A Task has a server-generated id, an optional contextId that groups related work, a status, optional artifacts and optional history. Clients cannot choose the task ID for a new task.
{
"id": "task-7f3a",
"contextId": "ctx-91c2",
"status": { "state": "TASK_STATE_WORKING", "timestamp": "2026-11-12T10:15:00.000Z" }
}
Task states. The v1.0 specification defines eight states plus an unspecified placeholder. Submitted and working are in progress. Input required and auth required are interrupted states, where the agent waits for the client. Completed, failed, canceled and rejected are terminal.
Message, Part and Artifact. A Message is one turn with a role. A Part carries text, a file or structured data. An Artifact is a task output built from Parts.
Three details matter in practice. Clients get updates by polling GetTask, streaming or webhooks. Clients must send an A2A-Version header with every request. A card can carry a JSON Web Signature over an RFC 8785 canonical form, which the A2A v1.0 notes list as an enterprise feature.
The grey zone where they overlap
The boundary is clean for simple cases and blurry for long-running work.
MCP now has its own answer to long jobs. SEP-2663 moves tasks out of the core spec into an official extension, io.modelcontextprotocol/tasks, with tasks/get, tasks/update and tasks/cancel. The server decides per request whether to return a task handle. The SEP says tasks are expected to be supported in future protocol versions and may be promoted into the core once the extension stabilizes. The MCP blog's November 11, 2026 release-cycle post notes that Luca Chang, who co-authored the original Tasks proposal, co-leads the Tasks and Events Working Group and joins as a release manager.
A2A moves toward MCP territory too. Its roadmap, last updated September 15, 2026, lists elicitation and multi-turn workflows, a concept MCP already covers with multi round-trip requests.
So the dividing line is not features. It is who sits at the other end. If it is a capability you control and can describe with a schema, MCP fits. If it is an autonomous system with its own owner, release cycle and identity, A2A is built for that. The A2A docs say a server can expose well-defined, stateless skills as MCP-compatible resources, but that is not where A2A earns its keep.
History and the IBM ACP merger
- March to June 2025. IBM Research launches ACP for its BeeAI platform (IBM's account). Google launches A2A in April, and the Linux Foundation launches the A2A project on June 23, 2025.
- August 25, 2025. IBM Research announces that ACP is merging into A2A, that active ACP development is winding down, and that IBM joins the A2A Technical Steering Committee. The A2A docs list IBM ACP as incorporated.
- December 9, 2025. The Linux Foundation announces the Agentic AI Foundation with MCP, goose and AGENTS.md.
- March 12, 2026. A2A v1.0.0 is released on GitHub. v1.0.1 follows on May 28, 2026.
- April 9, 2026. The Linux Foundation says A2A has more than 150 supporting organizations, up from more than 50. That is the foundation's claim.
- August 17, 2026. AAIF announces that A2A is joining as a hosted project. A2A's own post of August 27 says it was accepted as a Growth Stage project.
- October 22, 2026. The Linux Foundation reports AAIF membership of 305 organizations and ten hosted projects.
The merger means agent-to-agent has one open standard, not two. If you built on ACP, plan the migration. If not, ignore ACP.
What governance does not settle
Neutral governance answers who decides. It does not answer whether your deployment is safe.
A Cloud Security Alliance research note dated October 29, 2026 says AAIF's project list carries no maturity or security-readiness labels and that it could not find a foundation-wide security baseline.
InfoWorld's November 11, 2026 analysis by Isaac Sacolick is an opinion piece built on vendor quotes. Its useful point is that both protocols define how agents present credentials, not who may act. C1.ai's CISO Kevin Paige says neither says "who is authorized to place the call". The A2A spec fits that reading. When an agent needs authorization mid-task, it moves to TASK_STATE_AUTH_REQUIRED and hands the problem to the client.
For the MCP side of this risk, see our MCP security checklist for creative teams. For who governs what, see our explainer on the Agentic AI Foundation.
Side-by-side feature table, verified entries only
Every row below comes from a page we opened on November 12, 2026. Where the source is a vendor or foundation claim, the cell says so. If we could not verify an entry, it is not in the table.
| Feature | MCP | A2A |
|---|---|---|
| Current version | 2026-07-28, listed as Current (MCP versioning page) | 1.0.0 released Mar 12 2026, 1.0.1 released May 28 2026 (A2A GitHub releases) |
| Release cadence | Two a year, last Tuesday of March and September, next target 2027-03-30 (MCP blog, Nov 11 2026) | We found no published release calendar. The roadmap lists v1.1 work (A2A roadmap, Sep 15 2026) |
| Wire format | JSON-RPC 2.0 messages (MCP spec) | Three bindings, JSON-RPC, gRPC and HTTP+JSON, over a Protocol Buffers data model (A2A spec) |
| State model | Stateless, no handshake and no session header (MCP changelog) | Stateful Task with contextId, task ID generated by the server (A2A spec) |
| Discovery | Mandatory server/discover RPC advertising versions, capabilities and identity (MCP changelog) | Agent Card at a well-known URI, registries or direct configuration, no standard registry API (A2A docs) |
| Long-running work | Optional Tasks extension with polling (SEP-2663) | Task in the core spec, polling, streaming and webhooks (A2A spec) |
| Input mid-task | Multi round-trip requests with an InputRequiredResult (MCP changelog) | TASK_STATE_INPUT_REQUIRED and TASK_STATE_AUTH_REQUIRED (A2A spec) |
| Identity and auth | OAuth-based, 2026-07-28 adds iss validation per RFC 9207 (MCP changelog) | Security schemes in the card (API key, HTTP, OAuth 2.0, OpenID Connect, mutual TLS), optional signed cards (A2A spec) |
| What the other side can see | Servers do not see the whole conversation or other servers (MCP architecture) | Agents collaborate without sharing internal state, memory or tools (A2A spec) |
| Governance | Agentic AI Foundation since Dec 9 2025 (Linux Foundation) | Linux Foundation Jun 23 2025, AAIF hosted since Aug 17 2026 (AAIF) |
| Scale claim | More than 10,000 published servers, Linux Foundation, Dec 9 2025, a foundation claim | More than 150 supporting organizations, Linux Foundation, Apr 9 2026, a foundation claim |
Two cautions. The scale claims count different things, servers against organizations, so do not compare them. And the A2A docs page and GitHub disagree on whether the latest release is 1.0.0 or 1.0.1, which the spec says does not affect compatibility.
Test the agent-to-tool layer with real tools
Connect Claude, Codex or Cursor to Oakgen MCP and let an agent search models, quote a price and start a generation.
Decision matrix by team situation
This is the asset to bookmark. Find the row that looks like your team, then read across. The right column is what would change the answer.
| Your situation | MCP | A2A | What to do first | What would change the answer |
|---|---|---|---|---|
| Solo builder, one agent, one or two APIs | Not yet | No | Plain function calling | A second client needs your tools |
| Product team that wants Claude, ChatGPT or Cursor to use your service | Yes | No | Ship an MCP server with a small, well-described tool set | You also need your service to act as an agent that asks questions back |
| Several agents in one codebase and one framework | Optional, for shared tools | No | Use your framework's in-process handoff | An agent moves to a separate deployment owned by another team |
| Agents owned by different teams, different frameworks, same company | Yes, for each agent's tools | Candidate | Count the integrations. If it is two or three, a plain HTTP contract can be cheaper | Five or more pairs, or teams that cannot coordinate releases |
| Agent handoff across companies, such as supplier or partner agents | Yes, for each side's tools | Strong candidate | Agree identity and authorization first, then the Agent Card | A partner cannot support A2A, so you fall back to an API |
| You sell an agent that other platforms should be able to call | Optional | Strong candidate | Publish a signed Agent Card and test with an A2A client | Your buyers only use one platform with its own agent API |
| Regulated enterprise with security review | Yes, behind a gateway | Later | Identity, logging and an allowlist before more protocols | An approved gateway that handles both protocols |
| Creative team using generation tools from an assistant | Yes | No | Connect one MCP server, keep a human approval step | Another company's agent must deliver work into your pipeline |
Read the matrix as a sequence, not a menu. Most teams move from no protocol, to MCP, and only later to A2A. Thresholds such as "five or more pairs" are my rule of thumb, not a published figure.
You may need neither yet
Anthropic's guidance on building agents, first published in December 2024 and modified in October 2026 (the page now notes that much of its tooling advice has changed), says it directly. "When building applications with LLMs, we recommend finding the simplest solution possible, and only increasing complexity when needed. This might mean not building agentic systems at all." A protocol is complexity too.
Run this check before adding either one.
- Do you have more than one independently deployed agent? If not, A2A has nothing to connect.
- Do those agents have different owners who cannot ship together? If one team owns them all, an internal call is simpler.
- Will more than one client use your tools? If only your own app calls them, a typed API is enough.
- Can you name the integration that hurts today? Protocols pay off when you write the same glue repeatedly.
- Do you have identity and logging for agents? The protocols do not provide them, so fix that first.
If you answered no to the first three, stay with direct calls. Yes to question 3 only means build MCP. Yes to questions 1 and 2 means evaluate A2A.
How a creative team would apply this
Take an agency that uses an AI assistant to plan a campaign, then generate images and short video. That is one agent using several tools. It is an MCP case. The assistant needs to find a model, check a price, start a job and read the result.
Oakgen's MCP server, which is our product, exposes tools for that sequence. Our guide to image generation MCP servers and the MCP, API and web app comparison walk through it. Nothing here needs A2A.
A2A would become relevant only if a different company's agent had to deliver work into yours, for example a partner studio's review agent returning approvals on a schedule you do not control. Even then, keep a human approval step in the loop, as we describe in what a creative AI agent should automate.
Common mistakes
- Treating the two as competitors. Both the A2A and MCP communities describe them as complementary layers. Choose by what sits on the other end.
- Adopting A2A for agents in one codebase. A framework's in-process handoff is simpler. See our agent orchestration patterns explainer.
- Calling an agent an MCP tool when it asks follow-up questions. Stateless request and response fits a dialogue poorly. Use a task-based pattern.
- Assuming foundation hosting equals security. CSA's October 29, 2026 note says it does not.
- Mixing up versions. A2A v1.0 broke compatibility with v0.3, and MCP 2026-07-28 removed the handshake. Pin the version you test against.
- Skipping identity. Neither protocol decides who may do what.
What I would do
Build MCP first, and only if a second client needs your tools. Keep the server small, with well-described tools and a human approval gate for anything that spends money or publishes. Pin to spec 2026-07-28 and plan for the next release on March 30, 2027. Our spec explainer covers what changed.
Evaluate A2A when you can name two agents with different owners and a handoff that needs custom code. Start with one pair. Publish an Agent Card, test with an A2A client, and treat identity and authorization as a separate project.
Revisit this in six months. A2A's roadmap lists v1.1 and bidirectional streaming, and MCP's next revision lands in March 2027, so check the dates before you decide.
Plan a campaign in Agent Chat, then generate the assets
One agent, several tools, a human approving each step. Brief Oakgen Agent Chat and review the plan before you spend credits.
For the question that comes before protocol choice, see our guide to when to split an agent. For production creative workflows, see agentic creative pipelines.
Browse the models an agent can call
See which image, video and audio models an agent can call through Oakgen.
Frequently asked questions
What is the difference between MCP and A2A?
MCP (Model Context Protocol) standardizes how an AI application connects to tools, data and prompts. A2A (Agent2Agent) standardizes how independent agents discover each other, delegate tasks and exchange results. The A2A documentation describes MCP as the way an agent uses a capability and A2A as the way agents partner on work. Both use open specifications and both are now hosted by the Agentic AI Foundation, a Linux Foundation body.
Do I need both MCP and A2A?
Most teams do not need both. If one agent calls tools, you may need only MCP, or even just plain function calling. You need A2A when two or more independently deployed agents, usually owned by different teams or companies, must hand work to each other and a custom integration per pair has become the cost. The A2A v1.0 announcement says many systems will use both, MCP inside agents and A2A between agents, but that describes the end state of larger systems, not a starting point.
Did IBM's ACP merge into A2A?
Yes. IBM Research announced on August 25, 2025 that its Agent Communication Protocol was merging into A2A under the Linux Foundation, that the ACP team would wind down active development and contribute to A2A, and that an IBM Research director would join the A2A Technical Steering Committee. The A2A documentation lists IBM ACP as incorporated into A2A. If you have ACP agents, IBM's BeeAI project published an ACP to A2A migration guide.
Who governs MCP and A2A?
Both sit under the Agentic AI Foundation (AAIF), a Linux Foundation body. AAIF was announced on December 9, 2025 with MCP, goose and AGENTS.md. A2A was launched as a Linux Foundation project on June 23, 2025 and joined AAIF on August 17, 2026. Governance settles who decides the specification. It does not settle security. A Cloud Security Alliance research note dated October 29, 2026 found no foundation-wide security baseline across AAIF's ten projects.
Is A2A v1.0 stable?
A2A calls v1.0 its first stable, production-ready specification. GitHub shows v1.0.0 released on March 12, 2026 and v1.0.1, a bug-fix release, on May 28, 2026. The specification page on a2a-protocol.org still lists 1.0.0 as the latest released version, so the two disagree on the patch number. Per the spec, patch versions do not affect protocol compatibility. v1.0 broke compatibility with v0.3, for example by changing enum values to SCREAMING_SNAKE_CASE, so check which version your counterpart speaks.
What is an A2A Agent Card?
An Agent Card is a JSON document that an A2A server must publish. It describes the agent's name, description, version, supported interfaces (URL, protocol binding and protocol version), capabilities, default input and output modes, skills and, optionally, security schemes and signatures. The well-known location is /.well-known/agent-card.json. Cards can be signed with JSON Web Signatures over an RFC 8785 canonical form, which lets a client verify who published the card.
Can I expose an agent as an MCP tool instead of using A2A?
Yes, for simple cases. The A2A documentation says an A2A server can expose well-defined, stateless skills as MCP-compatible resources, and notes that A2A's strength is stateful, collaborative exchanges that go beyond a tool call. If your 'agent' is really a function with structured inputs and a single result, an MCP tool is simpler. If it asks follow-up questions, runs for hours or needs its own identity, a task-based protocol such as A2A, or MCP's Tasks extension, fits better.
Does Oakgen support A2A?
We found no A2A support in Oakgen's code as of November 12, 2026, so do not assume it. Oakgen is our product. It exposes a remote MCP server with tools to find models, check exact prices, upload reference files, start generations, follow progress, list past generations, check your account and cancel jobs. Connection details are on the Oakgen MCP page.
Sources
- Model Context Protocol, Versioning (current revision 2026-07-28) (read 2026-11-12)
- Model Context Protocol, Key Changes in 2026-07-28 (changelog) (read 2026-11-12)
- Model Context Protocol, Architecture, spec 2026-07-28 (read 2026-11-12)
- Model Context Protocol, SEP-2663 Tasks Extension, status Final (read 2026-11-12)
- MCP Blog, A More Predictable Release Cycle for MCP, Nov 11 2026 (read 2026-11-12)
- A2A Protocol, Specification, Agent Card, Task and bindings (read 2026-11-12)
- A2A Protocol, What's New in v1.0 (read 2026-11-12)
- A2A Protocol, Announcing Version 1.0 (read 2026-11-12)
- A2A Protocol, A2A and MCP detailed comparison (read 2026-11-12)
- A2A Protocol, Agent Discovery (read 2026-11-12)
- A2A Protocol, Roadmap, last updated Sep 15 2026 (read 2026-11-12)
- A2A Protocol, A New Chapter for A2A, Aug 27 2026 (read 2026-11-12)
- GitHub, a2aproject/A2A releases, v1.0.0 and v1.0.1 (read 2026-11-12)
- Agentic AI Foundation, A2A joins AAIF's open agentic stack, Aug 17 2026 (read 2026-11-12)
- Agentic AI Foundation, Projects (read 2026-11-12)
- Linux Foundation, Formation of the Agentic AI Foundation, Dec 9 2025 (read 2026-11-12)
- Linux Foundation, Agentic AI Foundation Surpasses 300 Members, Oct 22 2026 (read 2026-11-12)
- Linux Foundation, Agentic AI Foundation Announces Four New Projects, Oct 22 2026 (read 2026-11-12)
- Linux Foundation, Launch of the Agent2Agent Protocol Project, Jun 23 2025 (read 2026-11-12)
- Linux Foundation, A2A Protocol Surpasses 150 Organizations, Apr 9 2026 (read 2026-11-12)
- IBM Research via BeeAI, ACP Joins Forces with A2A Under the Linux Foundation, Aug 25 2025 (read 2026-11-12)
- Cloud Security Alliance AI Safety Initiative, One Foundation, Ten Projects, Oct 29 2026 (read 2026-11-12)
- InfoWorld, MCP and A2A alone won't scale AI agents, Nov 11 2026 (read 2026-11-12)
- Anthropic, Building effective agents, Dec 2024, page updated Oct 2026 (read 2026-11-12)

