Enterprise AI teams keep running into the same architecture question: should this integration be an API, an MCP server, or an A2A connection? The honest answer is that it depends on who, or what, is on the other end of the wire.
| Dimension | REST API | GraphQL | MCP | A2A |
|---|---|---|---|---|
| Primary consumer | Developer, deterministic client | Developer, deterministic client | AI agent | AI agent, talking to another agent |
| Direction | Client to server | Client to server | Agent to tool or data | Agent to agent |
| Transport | HTTP | HTTP | stdio, Streamable HTTP | HTTP, JSON-RPC 2.0 |
| Discovery | OpenAPI or Swagger, optional | Introspection query | MCP Registry, tools/list | Agent Card |
| Auth model | OAuth, API key, mTLS | Same as REST | OAuth 2.1 / OIDC, per the 2026-07-28 RC | Signed Agent Cards, v1.0 |
| Session semantics | Stateless | Stateless | Stateful, session context | Stateful, task lifecycle |
| Governance model | Whatever you build | Whatever you build | Registry and allowlist patterns emerging | Signed cards, task delegation |
| Maturity, July 2026 | Decades | About 10 years | Stable 2025-11-25; RC 2026-07-28 | v1.0 stable, April 2026 |
| Backers | Universal | Universal | Anthropic and the Linux Foundation's Agentic AI Foundation | Google and the Linux Foundation |
| When to use | Your existing developer surface, deterministic apps | Complex nested reads, developer flexibility | Any AI agent calling tools or data | Multi-agent orchestration, agent handoffs |
Read that table as a map, not a bake-off. This is not four standards competing for the same job. It is four layers of the same enterprise architecture, and every serious agent deployment in 2026 uses more than one of them at once.
APIs: the system integration layer
APIs remain the foundation of enterprise software. REST, GraphQL, gRPC, webhooks, and event streams expose system capabilities to applications through known interfaces. An application knows which endpoint to call, what payload to send, and what response to expect. That determinism is the whole point, and it is not going away because agents entered the picture.
Agents still depend on this layer. Whether an AI agent talks to a CRM, an ERP, a payments system, or a data warehouse, an API is usually doing the underlying work, even when an MCP server sits in front of it. What APIs do not do natively is explain to a model when a capability should be used, how it relates to other tools, or what business meaning sits behind the data. A REST endpoint returns a payload; it does not tell an agent that the payload represents net revenue after returns, or that a second endpoint must be called first to resolve a customer ID. That gap is exactly what the next layer addresses.
It is worth naming the frameworks that sit on top of these protocols, since they are often mistaken for competitors rather than consumers. LangChain and LangGraph ship MCP client support directly. OpenAI's own function calling and Tools API predate the Apps SDK and now sit alongside it. Microsoft's AutoGen and Semantic Kernel are MCP-aware, and CrewAI and LlamaIndex both support MCP as clients. None of these are protocols in their own right; they are orchestration layers that consume MCP and, increasingly, A2A underneath.
MCP: the agent-to-tool layer
The Model Context Protocol gives AI applications a standard way to discover and call external tools, data sources, and workflows. An MCP tool can wrap a database query, a search call, a calculation, or a business operation, and any MCP client can call it the same way. As covered in enterprise MCP adoption, this standardization is why MCP moved from developer convenience to infrastructure so quickly: instead of every client building custom connectors for every tool, one protocol layer sits between agents and capabilities.
An a16z framing worth keeping in mind: MCP is roughly "API++", exposed directly to agents, and the mapping from an existing API to an agent tool is rarely one-to-one. A tool like draft_email_and_send() bundles several underlying API calls into one agent-shaped action. MCP does not replace the API estate; it packages it differently for a different consumer.
Current production transport is Streamable HTTP, a single HTTP endpoint with optional SSE streaming and session management, which replaced the deprecated HTTP+SSE transport described in Cloudflare's MCP transport writeup. The current stable spec revision is 2025-11-25; the 2026-07-28 release candidate adds a stateless protocol core and hardens OAuth 2.0/OIDC further. Per Anthropic's December 2025 ecosystem update, more than 10,000 active public MCP servers and 97 million-plus monthly SDK downloads run on it, and the official MCP Registry gives clients a central place to discover them. MCP is now governed by the Linux Foundation's Agentic AI Foundation, donated in December 2025.
You do not need to rewrite your REST estate to adopt MCP. Gateway tooling such as AWS Bedrock AgentCore Gateway auto-converts OpenAPI specifications into MCP tool definitions. OpenAPI becomes the source spec the gateway translates from, not a legacy format to retire.
A2A: the agent-to-agent collaboration layer
Agent2Agent (A2A) solves a different problem: what happens when one agent needs help from another agent. Google announced A2A on April 9, 2025 with more than 50 launch partners, including Atlassian, Box, Cohere, Intuit, LangChain, MongoDB, PayPal, Salesforce, SAP, ServiceNow, and Workday. Instead of one agent calling a tool directly, A2A lets an agent discover another agent's capabilities through a signed Agent Card, send it a task, and track that task through a defined lifecycle.
A2A was donated to the Linux Foundation in mid-2025, and IBM's own Agent Communication Protocol (ACP) was folded into it during that consolidation rather than surviving as a separate standard. Version 0.3 shipped July 31, 2025, and v1.0 went stable on April 9, 2026, the protocol's first anniversary. That release added signed Agent Cards and the Agent Payments Protocol (AP2) for agent-initiated payment flows.
Some commentary in September 2025 argued A2A's momentum had stalled behind MCP's. The April 2026 numbers tell a different story: 150-plus production organizations, 22,000-plus GitHub stars, and SDKs in five languages (Python, JavaScript, Java, Go, and .NET), with native support landing in Azure AI Foundry, Amazon Bedrock AgentCore, and Google Cloud. Both narratives are worth holding at once: A2A had a real early wobble, and it recovered. A comparative survey of agent interoperability protocols and DeepLearning.AI's A2A course are worth reading if you want the task-lifecycle details underneath the Agent Card model; independent engineering analysis of A2A's wire behavior is also useful if you are implementing against it directly rather than through a framework.
This matters because enterprise AI will not be one giant agent. It will be sales agents, finance agents, analytics agents, operations agents, and compliance agents, each specialized, each needing a way to hand off work without every system being tightly coupled to every other. That is the shift from copilots to autonomous, AI-native operations, and A2A is the coordination fabric for it.
Picture a planning agent that receives a quarterly forecast request. Under REST alone, that agent would need hardcoded knowledge of every downstream system: which analytics service to call, in what order, with which credentials. Under A2A, the planning agent instead discovers an analytics agent through its Agent Card, sends it a scoped task, and receives status updates as the task progresses, without ever needing to know how the analytics agent gets its own answers. That last part is MCP's job, running underneath, invisible to the planning agent entirely.
Standards are converging, not fragmenting
The clearest evidence that this ecosystem is consolidating, not splintering, is the OpenAI Apps SDK, launched at DevDay on October 6, 2025 and built on MCP. The community MCP-UI project converged with OpenAI's approach through SEP-1865 into the official MCP Apps specification, ratified as a dated spec on 2026-01-26. ChatGPT supports that open standard plus optional window.openai extensions; Claude, Goose, and VS Code speak the open standard only. That is one standard with one vendor's optional extensions, not a fork.
Analyst signals point the same direction. Gartner's 2025 Software Engineering Survey projects that 75% of API-gateway vendors and 50% of iPaaS vendors will ship MCP features by the end of 2026, which is the clearest sign yet that MCP is becoming table stakes for the integration market, not a niche AI feature.
Where enterprise teams go wrong
- Using raw APIs directly with agents forces a model to reason over low-level endpoints without enough context to choose correctly.
- Using MCP as a thin wrapper over everything exposes too many tools without governance or semantic clarity. More tools does not mean more capability; it often means worse tool selection.
- Reaching for A2A too early adds multi-agent complexity before the underlying tool and data layer is mature enough to support it.
- Ignoring identity across layers makes it unclear who, or what, is actually authorized to do what, once a request has crossed three protocol boundaries. That is the whole subject of how to govern AI agents that query enterprise data.
- Skipping observability makes it impossible to reconstruct why an agent called a tool, delegated a task, or returned a particular result.
A three-question decision framework
Enterprise teams should start with the use case, not the protocol brand. Three questions settle almost every case:
- Is a human developer writing the client? Use REST or GraphQL, the same as you always have.
- Is an AI agent calling a tool, database, or SaaS system? Use MCP. If the underlying capability is already exposed as REST, wrap it in an MCP tool rather than rebuilding it; that is exactly what the AWS AgentCore Gateway pattern is for.
- Are multiple AI agents coordinating, delegating, or handing off tasks? Use A2A on top of MCP. A2A is the coordination layer; MCP remains the capability layer each coordinated agent uses underneath.
Every serious enterprise agent architecture in 2026 uses REST, MCP, and A2A together. The question was never which protocol wins. It is how they compose, and if you are weighing that composition against vendors, the semantic layer buyer's guide covers the evaluation criteria that outlast any single protocol version.
The data access problem none of these protocols solve
APIs can expose data. MCP can make data tools agent-accessible. A2A can let one agent request analysis from another. None of that guarantees the answer is semantically correct, authorized, or auditable. An agent can call the right tool and still use the wrong metric. It can query the right database and still apply the wrong join. It can delegate to the right agent and still pass along data the requesting user was never permitted to see. As explored in how to build an MCP semantic layer server, these are not protocol failures. They are governance and semantics failures, and no version bump to any of the four rows in that comparison table fixes them.
This is also why data catalogs cannot execute AI agents on their own: discovering that a table or an API exists is not the same problem as knowing which join is valid, which definition of revenue is current, and who is allowed to see the result.
Fix the Context, Not the Model. Wrapping an API in an MCP tool or coordinating agents over A2A increases connectivity. It does not, by itself, increase trust. A governed semantic layer that resolves meaning and proves the query before execution is what turns connectivity into a reliable answer.
The role of a governed semantic layer in this stack
A semantic layer defines business meaning once, metrics, entities, relationships, and access rules, and makes that definition reusable across every agent, tool, dashboard, and API that touches it. In an API-plus-MCP-plus-A2A architecture, the semantic layer becomes the control plane for business data specifically. MCP can expose semantic tools. A2A can delegate to a specialized analytics agent. APIs execute against the underlying systems. The semantic layer is what keeps the business meaning identical no matter which layer the request arrived through, the same compile-time discipline covered in fine-grained data access control, governance as code, and a semantic control plane.
Colrows sits behind agent interfaces, including MCP, as that governed layer: it exposes both an MCP server and a REST API surface over the same underlying tools, so agent traffic and conventional traffic compile through one typed semantic graph and return the same answer. That is the practical proof that these layers compose rather than compete: MCP is the transport, the semantic layer is the logic, and an enterprise needs both.
Frequently asked questions
Is A2A a competitor to MCP?
No. MCP is agent-to-tool: it connects one agent to the tools, data, and resources it needs. A2A is agent-to-agent: it connects one agent to another agent. They compose, they do not compete.
Can MCP and A2A work together?
Yes. A2A coordinates which agent handles a task and how work is delegated. Each agent it coordinates typically uses MCP underneath to reach its own tools and data.
Does MCP replace REST APIs?
No. MCP usually wraps existing REST APIs so agents can consume them safely, with tool metadata and session semantics. Gateways like AWS AgentCore Gateway auto-convert OpenAPI specs into MCP tools without an API rewrite.
What is the OpenAI Apps SDK built on?
MCP. The community MCP-UI project converged with OpenAI's approach through SEP-1865 into the official MCP Apps spec, ratified as a dated specification on 2026-01-26.
What happened to IBM's Agent Communication Protocol (ACP)?
It was merged into A2A during the Linux Foundation consolidation, alongside A2A's own donation and Agent Card and task-delegation model.
How do I convert an existing OpenAPI spec into MCP tools?
Gateway tooling such as AWS Bedrock AgentCore Gateway auto-generates MCP tool definitions from an OpenAPI spec. You wrap the API; you do not rewrite it.
Which protocol should an enterprise bet on?
All three, at different layers: REST or GraphQL for deterministic developer clients, MCP for agents calling tools and data, and A2A for agents coordinating with other agents.
Is Streamable HTTP the same as the old HTTP+SSE transport?
No. Streamable HTTP is MCP's current production transport, a single HTTP endpoint with optional SSE streaming and session management. It replaces the deprecated HTTP+SSE transport.
