Keep your OpenAPI spec as the source of truth, give each agent a small set of task-shaped tools, and add MCP the day a second agent client needs those same tools. Adopt A2A only when another team's agent, with its own reasoning and its own state, has to accept work from yours. A2A is the loser for most platform teams this quarter: its spec is stable, but the vendor guides checked for this article still show older protocol names, and a tool call does not need a task lifecycle. MCP and A2A do different jobs, so most large estates will eventually run both.
The comparison below uses one workload so every row is like for like: an internal order system with 200 REST operations and a current OpenAPI 3 spec, four agents owned by two teams, and access delegated from the signed-in user. Platform support and prices were checked on vendor pages on November 4, 2026.
| OpenAPI + function calling | MCP | A2A | |
|---|---|---|---|
| What it connects | One agent to your API, through code you own | Any MCP client to tools and resources | One agent to another agent |
| Current version | 3.2.1, September 10, 2026 | 2026-07-28 | 1.0.0 |
| Who runs the call | Your application | The MCP server | The remote agent |
| Auth | Describes schemes; enforcement is yours | OAuth 2.1 profile for HTTP, optional overall | Schemes declared in the Agent Card; policy is yours |
| At our workload | Curate about 12 tools from the 200 operations | One narrow server shared by four agents | Only if the second team's agent reasons on its own |
| Do not pick it when | Clients you do not control must discover the tools | One app calls a dozen operations you own | Nothing you run speaks it, or the far side is a tool |
| Verdict | Default start | Default second step | Loser for now; wait for a real agent boundary |
What Does Each Standard Actually Specify?
OpenAPI describes an HTTP API, MCP defines how an AI client discovers and calls tools, and A2A defines how one agent hands a stateful task to another. They sit at different layers, which is why the "which one wins" framing misleads buyers.
OpenAPI is a description format published under the OpenAPI Initiative and copyrighted to the Linux Foundation. It has no runtime of its own. Function calling supplies the agent half: per OpenAI's guide, the model returns a call with JSON arguments and your code executes it. Claude works the same way, where you write the schema and your application runs each call. Neither vendor needs your spec at run time, so the spec does its work at build time, as the input to the tools you generate.
MCP, the Model Context Protocol, is a JSON-RPC protocol for exposing tools, resources and prompts to AI clients. The July 2026 revision removed the initialize handshake and protocol-level sessions, added a mandatory server/discover call, moved tasks to an official extension, and deprecated Roots, Sampling and Logging. Anthropic donated MCP to the Agentic AI Foundation, a Linux Foundation fund, in December 2025.
A2A, the Agent2Agent protocol, defines an Agent Card (a JSON document listing an agent's identity, skills, endpoint and auth requirements), a Task with a lifecycle, Messages and Artifacts. It has JSON-RPC, gRPC and HTTP+JSON bindings. Google called the March 2026 v1.0 release its first stable version. In August A2A moved into the same foundation as MCP, so governance no longer separates the two. That foundation's post counts over 150 backing organizations and says A2A is running in production across supply chain, financial services and mobile platforms, but it gives no traffic or deployment figures, so ask for references.
The A2A project's own line is the clearest test available: agents partner on tasks over A2A and use capabilities over MCP. If the thing on the far side has structured inputs, returns a result and keeps no plan of its own, it is a tool.
Which Platforms Support MCP, A2A and OpenAPI Today?
MCP has the broadest client support of the three, OpenAPI import is uneven, and A2A support is concentrated in the cloud agent platforms. "Supports" also hides real limits, so read the second column before you commit.
| Platform | MCP | A2A | OpenAPI route |
|---|---|---|---|
| Claude API | Beta connector: tool calls only, public HTTP only, no direct stdio | Not mentioned on the connector page | You write input_schema per tool |
| OpenAI Responses | Remote Streamable HTTP or HTTP/SSE, plus Secure MCP Tunnel | Not mentioned on that page | JSON Schema functions |
| Gemini API | Remote, Streamable HTTP only, no SSE | Not mentioned on that page | Declarations use a subset of OpenAPI schema |
| Copilot Studio | Tools and resources; prompts not listed as supported | Connects to external A2A agents | REST tools in preview; v3 specs are translated to v2 |
| Bedrock AgentCore | Runtime hosts MCP servers | Runtime hosts A2A servers with SigV4 or OAuth 2.0 | Gateway turns OpenAPI, Smithy and Lambda into MCP tools |
| Vertex AI with ADK | MCP tools across five SDK languages, via McpToolset |
ADK marks A2A "Experimental"; Agent Platform Runtime lists an Agent2Agent guide | OpenAPIToolset makes one tool per operation from v3.x |
The version gap is the finding buyers should act on. A2A 1.0 renamed message/send to SendMessage, removed TextPart and moved url into supportedInterfaces[], with aliases during the transition. Yet AWS's current A2A guide pins a2a-sdk[all]~=0.3.26 and sends message/send, and Microsoft's page shows the same method and tells you to look for the card at /.well-known/agent.json, while AWS serves it at /.well-known/agent-card.json. None of that proves either platform cannot speak 1.0. It does mean a vendor's A2A checkbox tells you nothing about which version it speaks, and you should test the pair you plan to run.
MCP has its own version of this problem. AWS's MCP guide pins the Python SDK below version 2, its sample client calls session.initialize(), and the runtime adds an Mcp-Session-Id header. Those are the handshake and session the current revision removed. AWS's protocol contract does describe 2026-07-28 behaviour, so the guide may only lag the platform. The spec documents backward compatibility with handshake-based versions, but only for implementations that support both eras: a legacy client fails against a modern-only server, and a modern-only client fails against a legacy server. You need to know which revision your clients negotiate before you upgrade.
Who Handles Authentication and Authorization in Each?
MCP is the only one of the three that prescribes an authorization flow, A2A declares schemes and leaves policy to the server, and OpenAPI only describes what your API already enforces. None of them decides what an agent may do on a user's behalf.
MCP's authorization spec is marked optional. HTTP implementations that support it should follow an OAuth 2.1 profile in which the server is a resource server, publishes RFC 9728 metadata, and must reject tokens not issued for it. Clients must send an RFC 8707 resource parameter, and servers must not pass a client's token through to an upstream API. Stdio servers skip all of this and read credentials from the environment, which is why a laptop full of local servers is a credential problem. Dynamic Client Registration is now deprecated in favour of Client ID Metadata Documents, so check that your identity provider supports them before you assume the flow works.
A2A declares five scheme types in the Agent Card: API key, HTTP auth, OAuth 2.0, OpenID Connect and mutual TLS. Clients get credentials out of band and send them in headers on every request. Cards can be signed with JWS over a canonicalised document. A task can pause in TASK_STATE_AUTH_REQUIRED, but the spec says the protocol does not define what the resulting authorization covers. Signing tells you who published a card. Whether that publisher should get your data is still your policy.
OpenAPI's Security Scheme Object lists apiKey, http, mutualTLS, oauth2 and openIdConnect. It documents requirements, and your API or gateway enforces them. The advantage is that you probably have this already, including the audit trail. The weakness is function calling: the agent's token handling is code you wrote, so nothing stops a shortcut through a shared service account.
Whichever you choose, adopt the rule from IBM's six-agent platform: "Carry the user's identity through every hop — propagate or exchange, never substitute a service account." Our agent identity comparison covers the products that issue those identities.
How Bad Is the MCP Security Record?
MCP has a long public record of real vulnerabilities, and A2A's shorter record may only reflect less exposure, so read neither as a safety ranking. The MCP failures fall into four groups, and each needs a different control.
Model-level attacks come first. Invariant Labs showed tool poisoning in April 2025: instructions hidden in a tool description told the model to read ~/.ssh/id_rsa and send it through a parameter. The same post described rug pulls (a description changing after approval) and shadowing (one server's description changing how the agent uses another server's tool). A later Invariant demonstration used a malicious public GitHub issue to pull private repository data into a public pull request, and the authors said the fault was not in GitHub's server code.
Client and SDK bugs come second. CVE-2025-6514 in mcp-remote scored CVSS 9.6, affected versions 0.0.5 to 0.1.15, and let an untrusted server trigger OS command execution on the client. CVE-2026-25536 in the official TypeScript SDK (CVSS 7.1, fixed in 1.26.0) could route one client's responses to another when transports were reused. Server bugs and supply chain make up the rest: Asana's hosted server exposed data across about 1,000 customers through a logic flaw, and a fake postmark-mcp package added a BCC backdoor in version 1.0.16.
A search on November 4 for A2A found threat models, few incident reports and 22 CVEs listed against the project's own SDKs, most rated Medium. An arXiv threat analysis singles out Agent Card management, task integrity and authentication. Treat another agent's task output as untrusted input, because it is model-generated text arriving from outside your trust boundary, and a compromised remote agent can inject instructions through it just as a poisoned tool description can.
Function calling against your own OpenAPI spec removes the third-party server from the picture, which is its real security advantage. It does not remove prompt injection. If an API returns text a stranger wrote, the model still reads it. Our MCP governance guide covers client allowlists, version pinning and gateways, and the Prefab UI sandbox flaw shows the record is still growing.
When Is an Existing REST API the Cheapest Answer?
A well-specified REST API is the cheapest answer when one application you own calls a small number of operations. The steelman for MCP everywhere is reuse: write once, and every client gets it. That payoff needs a second client, and until you have one the server is another service to deploy, patch and authenticate.
Do not convert the whole spec on either route, because the expensive mistake is the 1:1 mapping. Cloudflare measured 1.17 million tokens to describe over 2,500 endpoints as native tools (its own page summary says over 2 million). At the body figure, about 470 tokens per endpoint, our 200 operations would cost roughly 94,000 input tokens before the first user message. That is our arithmetic on Cloudflare's API, and your schemas will differ. OpenAI's guide suggests fewer than 20 functions at the start of a turn. Stainless, which generates MCP servers from specs, reports that users generally want up to a dozen or so tools at a time, and that Cursor supported up to 40 tools per server when it wrote the post in May 2025.
Tool shape matters on either route. Anthropic calls tools that merely wrap API endpoints a common error and suggests one schedule_event tool over separate list and create calls. A benchmark on UNICEF data put numbers on it: in the original three-way run, a generic MCP server scored 0.074, no tools scored 0.147, and a purpose-built server scored 0.990, as we covered in September. The results sit in the winning server's own repository, which now marks that scoring as superseded and lists 0.891 to 0.909 for later builds of the purpose-built server, with no rerun of the generic arm under the new scoring. Read the gap as directional.
If you do have 2,500 endpoints, the answer changes. Cloudflare's Code Mode lets the model search the spec with code, at about 1,000 tokens, and Anthropic reported 150,000 tokens falling to 2,000 with a similar pattern. Both are vendor numbers, and both need a sandbox you must run safely.
Managed translation is cheap enough to ignore on the meter. AgentCore Gateway lists $0.005 per 1,000 API calls, $0.025 per 1,000 search calls and $0.02 per 100 tools indexed per month (checked November 4, 2026). A million tool calls comes to $5. Your real costs are model tokens and engineers.
The exception is a platform that decides for you. Copilot Studio's REST tools are preview and not meant for production, and OpenAI's custom GPT actions do not transfer to plugins before the December 11 retirement. If your agents live inside someone else's product, use that product's supported route.
Who Should Not Adopt Each Standard?
Each standard has a buyer it will hurt, and for A2A that buyer is most platform teams right now.
A2A is the wrong choice if your agents share a process, a framework and an owner; sub-agents in LangGraph or ADK do that job with less ceremony. The same goes if nothing you run speaks it, if the far side is really a tool, or if you cannot propagate user identity across a hop. Teams without an eval harness should wait too. IBM's team got what A2A promises, with five of six agents built by separate teams, and then could not get the fleet to adopt a better reasoning pattern it had already shipped.
MCP is overhead if one application calls a dozen operations you own. Local stdio servers on developer machines are a bad bet unless you can enforce an allowlist with pinned versions, and a generated server that exposes every operation fails for the token reasons above.
Function calling alone stops working when clients you do not control need the capability, such as ChatGPT, Copilot Studio or a partner's agent. Each would need a separate integration, and that is the point at which MCP pays for itself. It also fails when four teams are about to write four versions of the same tool wrappers.
Where Do MCP, A2A and OpenAPI Work Together?
The stable pattern is a three-layer stack: OpenAPI at the API, MCP at the tool boundary, and A2A at the agent boundary. IBM's rule is the short version: "Use A2A for every agent boundary, MCP for every tool boundary." Our agentic stack guide places these layers among the others you will buy.
Vendors are building to this shape. AgentCore Gateway converts OpenAPI into MCP tools and also passes A2A traffic through one endpoint. If you already run Kong, its AI gateway applies per-consumer tool policy, as our governance guide describes. Microsoft's own guidance maps APIs to connectors, tools to MCP servers and external reasoning agents to A2A, and says you can combine them in one agent.
In our workload, that means generating about 12 task-shaped tools from the spec, serving them from one MCP server to the four agents, and adding A2A only if the second team's agent starts holding multi-turn tasks that your agents need to delegate.
Which Criteria Predict Regret?
Four questions predict regret better than any feature list, and their answers change the recommendation.
First, how many clients will call this in 12 months? With one, use function calling. With two or more, especially ones you do not control, use MCP.
Second, does the far side reason or execute? If it executes, it is a tool, whatever its vendor calls it. If it plans, keeps state across turns and is owned by someone else, A2A earns its overhead.
Third, can you carry user identity through every hop today? If you cannot, fix that first, because adding a protocol to a shared-service-account design moves the same problem somewhere harder to audit.
Fourth, can you prove the agent got better? Run your eval set against 12 curated tools and against the full generated set, and let the scores settle the tool design.
What to Do This Quarter
This Week:
- List every agent in production or pilot, its owner, and what it calls. Mark each callee as "tool" or "agent" using the test above.
- Check whether your critical API has a current OpenAPI spec. If it does not, write that before anything else, because every route here starts from it.
- Search your developer fleet for
mcp-remotebelow 0.1.16 and@modelcontextprotocol/sdkbelow 1.26.0.
This Month:
- Pick the 10 to 15 workflows your agents run and design tools around them, then measure token overhead against the full list.
- Have your identity lead confirm support for RFC 8707
resourceand Client ID Metadata Documents before anyone builds an MCP authorization flow. - Move any custom GPT with an action onto a supported route before December 11.
Before Q1 Close:
- Stand up one shared MCP server if the agent inventory shows two or more clients needing the same tools.
- If you have a real agent boundary, run an A2A pilot between the exact two platforms you would ship, and record the protocol version each one negotiates.
The Bottom Line
This is the same decision API teams made during the move from SOAP to REST, when the practical question was which service to change next. Your OpenAPI spec carries forward under all three options, so you lose little by waiting on MCP and A2A. Write the spec, build the dozen tools, and record the date a second client asks for them.
Continue Reading
- MCP Server Governance: Enforce at the Client, Not the Registry
- IBM Wired 6 Agents With A2A. Then Couldn't Upgrade Them.
- UNICEF Tested a Generic MCP Server. It Lost to No Tools.
- Okta vs Entra Agent ID vs SailPoint: Two Issue, One Governs
- The 2026 Agentic AI Stack: 8 Layers, 3 You Can Skip
- Rebuild Your Custom GPT Actions Before OpenAI Retires Them
