MCP vs A2A in 2026: 5 tests for whether you need agent-to-agent protocol

Summary. The two protocols solve different problems and most teams need only one. The Model Context Protocol connects an agent to tools and data; the Agent2Agent Protocol connects agents to each other across organisational boundaries. Both are now Linux Foundation projects, and both shipped major releases in 2026. MCP published the 2026-07-28 specification on 28 July 2026, retiring the initialize/initialized handshake and the Mcp-Session-Id header to make the protocol stateless. Its four Tier 1 SDKs see close to half a billion downloads a month, and the TypeScript and Python SDKs have each crossed 1 billion total downloads. A2A reached its 1.0 stable specification and, as of 9 April 2026, more than 150 supporting organisations, up from more than 50 a year earlier, with 22,000 GitHub stars and five production-ready SDK languages. Austin Parker, Director of AI Strategy at honeycomb.io, reported that "nearly 20% of all monthly interactive queries are now made by agents". The decision between them is not a technology preference. It is a question about how many organisations, teams and trust boundaries your agents have to cross.

Most architecture diagrams get this wrong in the same way: they draw A2A as a more advanced version of MCP. It is not. If you added A2A to a single-agent system, you would have added a coordination protocol with nothing to coordinate.

What each protocol actually does

MCP defines how an agent connects to internal tools and data sources. A tool call, a prompt template, a resource read. One agent, many tools, a vertical relationship.

A2A defines how agents discover, communicate and transact with each other across different frameworks, vendors and platforms. Many agents, one task, a horizontal relationship. The Linux Foundation states the split plainly: A2A "defines how agents communicate and coordinate with each other across organizational boundaries, while MCP defines how agents connect to internal tools and data sources".

The important consequence sits in the word boundaries. A2A's design assumption is that the agent on the other end was built by someone else, on a different stack, possibly at a different company, and that you cannot see inside it. Agents built on LangGraph or CrewAI can delegate sub-tasks and coordinate workflows through A2A without sharing internal memory. That isolation is the whole point, and it is also the cost: everything the other agent knows has to travel as a message.

Test 1: do you have more than one agent that you did not build?

This is the test that settles it for most teams.

If every agent in your system is yours, deployed by you, and can be upgraded by you in the same release, you do not need A2A. You need a function call, a queue, or at most an internal RPC. A2A's value comes from version negotiation, capability discovery and cryptographic identity between parties who cannot coordinate their release trains.

A2A 1.0 introduced Signed Agent Cards precisely for this. An Agent Card may be digitally signed using JSON Web Signature, with the card content canonicalized using the JSON Canonicalization Scheme, so a client can verify that a card has not been tampered with and originates from the claimed provider. That machinery is valuable when the counterparty is a vendor's agent or a partner's agent. It is overhead when the counterparty is a Python class in the same repository.

Luca Muscariello, Distinguished Engineer at Cisco, described A2A's role as follows: "A2A has emerged as the syntactic layer that makes agent-to-agent communication reliable and interoperable."

The syntactic layer between whom? Answer that first.

Test 2: is your bottleneck tool access or coordination?

Instrument before you architect. Two failure signatures point in opposite directions.

If your traces show the agent making many tool calls, re-fetching the same tool catalogue, hitting authorization errors, or timing out on long-running tool work, your problem is at the MCP layer, and the 2026-07-28 revision is aimed directly at it:

• List responses from tools/list, prompts/list, resources/list and resources/read now carry ttlMs and cacheScope, with a deterministic ordering, so clients can cache tool catalogues and keep upstream prompt caches stable across reconnects.

• Long-running work moved into the io.modelcontextprotocol/tasks extension, with a poll-based tasks/get and a new tasks/update.

• Authorization was hardened: authorization servers should return the iss parameter per RFC 9207 and clients must validate it before redeeming a code, which closes an authorization-server mix-up hole.

If instead your traces show one agent waiting on another agent's result, retrying against a partner system, or failing because two agents disagree about a task's state, that is a coordination problem, and no amount of MCP tuning fixes it.

Teams that have not instrumented at all should start with agent evals in CI/CD rather than a protocol decision. You cannot pick a protocol to fix a failure you have not characterised.

Test 3: can your infrastructure carry the session?

This test used to favour A2A by accident, because MCP's stateful core was operationally painful. That changed on 28 July 2026.

MCP retired the initialize/initialized exchange and the Mcp-Session-Id header from Streamable HTTP. Each request now travels on its own, carrying its protocol version, client identity and client capabilities in _meta. A client that wants a server's capabilities up front can call the new server/discover RPC, but it is not required. The practical effect: any request can land on any server instance behind a plain round-robin load balancer, with no shared session store.

            POST /mcp HTTP/1.1
MCP-Protocol-Version: 2026-07-28
Mcp-Method: tools/call
Mcp-Name: search

{"jsonrpc":"2.0","id":1,"method":"tools/call",
 "params":{"name":"search","arguments":{"q":"otters"},
 "_meta":{"io.modelcontextprotocol/clientInfo":{"name":"my-app","version":"1.0"}}}}
          

Streamable HTTP requests must now include Mcp-Method and Mcp-Name headers, so a gateway, rate limiter or web application firewall can route and meter on headers instead of parsing JSON bodies. That is the change that turns an MCP server into an ordinary HTTP workload.

Server-initiated requests did not survive intact. elicitation/create, sampling/createMessage and roots/list previously required a held-open bidirectional stream. They are replaced by Multi Round-Trip Requests: the server returns resultType: "input_required" with the requests it needs answered, and the client retries the original call with answers attached in inputResponses.

            {
  "resultType": "input_required",
  "inputRequests": [
    { "name": "confirm_delete", "schema": { "type": "boolean" } }
  ]
}
          

Swami Sivasubramanian, VP of Agentic AI at AWS, framed the operational payoff: "With the new MCP specification and its stateless protocol core available in Amazon Bedrock AgentCore, developers can deploy MCP servers on standard, scalable infrastructure without managing sessions or persistent connections."

If your only reason for reaching past MCP was that stateful servers would not scale behind your load balancer, that reason expired on 28 July 2026. Retest before you add a second protocol.

Test 4: are you crossing a commercial boundary, not just a technical one?

A2A extended beyond communication into economic coordination with the Agent Payments Protocol, which more than 60 organisations across payments and financial services already support. That is the signal to watch. When agents transact rather than merely exchange data, you need identity, non-repudiation and an audit trail that survives a dispute between two companies.

Sub-tests that mean yes:

• Money or a contractual commitment moves as a result of the agent exchange.

• The counterparty is a customer, supplier or vendor rather than an internal team.

• Someone will eventually need to prove what was agreed, by whom, and when.

• The two sides ship on independent release schedules and cannot coordinate a breaking change.

If none of those are true, you are building distributed systems inside one trust boundary, and ordinary service-to-service patterns will serve you better than an interoperability protocol.

Test 5: what does your cloud platform already give you?

Both protocols now ship inside major platforms, which changes the build-versus-adopt calculation.

Microsoft integrated A2A into Azure AI Foundry and Copilot Studio. AWS added support through Amazon Bedrock AgentCore Runtime, and contributed the Tasks extension to MCP. Cloudflare's Agents SDK supported the 2026-07-28 MCP spec from day zero, letting developers run MCP servers directly in Workers. Google Cloud publicly backed the release, with Engineering Fellow Anna Berenberg calling it "a massive leap forward in enterprise AI scalability".

What the 2026-07-28 migration actually costs

The MCP release is a breaking one, and the maintainers said so. Teams should budget for four specific items rather than a generic upgrade ticket.

Session identifiers. Anything that depended on Mcp-Session-Id has to be reworked. The maintainers' guidance is that dropping the protocol-level session does not force your application to be stateless: mint an explicit handle from a tool and have the model pass it back as an argument. Their stated reason is that this works better than session state hidden in the transport, because the model can see the handle and thread it between tools.

Server-initiated requests. Any elicitation or sampling flow built on a held-open stream needs the MRTR retry pattern instead.

Deprecations. Roots, Sampling and Logging are deprecated, and the legacy HTTP+SSE transport is officially deprecated with a year-long offramp. All keep working for at least twelve months under a new formal deprecation policy with a twelve-month minimum window. New implementations should not adopt them.

Registration. Dynamic Client Registration is formally deprecated in favour of Client ID Metadata Documents. DCR still works for backward compatibility and will be removed in a future spec version. Client credentials are now bound to the issuer that minted them, with no reuse across authorization servers.

One reported result gives a sense of the direction of travel. Enrico Toniato, CTO at Manufact, said the new SDK v2 that powers the mcp-use framework "helped us cut the package size by around 83% while making it 25% faster, thanks to the new client-server split". Treat that as one team's number on one framework, not a benchmark you can assume.

The architecture that most enterprises actually end up with

The stack that works in practice is a two-layer one, and both layers are optional.

At the bottom, MCP servers wrap the systems of record: the CRM, the ticketing system, the data warehouse, the internal APIs. Each agent talks to those over MCP. This layer is where the vast majority of enterprise agent value has been delivered so far, and it is where the MCP server development and integration work sits.

Above it, A2A appears only where agents genuinely have to reach across a boundary: a supplier's fulfilment agent, a vendor's support agent, a partner bank's reconciliation agent. Vertical adoption reported by the Linux Foundation spans supply chain, financial services, insurance and IT operations, where organisations coordinate autonomous systems across tools, vendors and environments.

Three things sit in neither protocol and still have to be built:

1. Identity for the agent itself. Neither protocol tells you how a non-human identity gets provisioned, rotated or revoked in your directory. That is a separate programme, covered in our analysis of AI agent identity governance.

1. Guardrails against untrusted input. A2A carries messages between agents you do not control, which is an injection surface. The controls in AI agent prompt injection guardrails apply to inbound agent messages exactly as they apply to inbound user text.

1. Governance and approval paths. Which agent may commit what, on whose behalf, with what audit trail. Our enterprise AI agent governance layers breakdown covers the layers that neither specification defines.

A protocol standardises the wire, not the decision to trust what comes over it.

Teams comparing orchestration choices at the same time should note that the framework question is separate again. Whether you build on LangGraph, CrewAI or a vendor SDK is largely independent of these protocols now that both interoperate, which is the point our production agent framework comparison makes at more length.

India-specific considerations

For Indian engineering organisations, the practical constraint is usually the counterparty, not the protocol.

Indian services and GCC teams building agent systems for overseas enterprises will increasingly be handed an A2A requirement by the client's platform team, because Azure AI Foundry, Copilot Studio and Amazon Bedrock AgentCore already carry it. That is an integration requirement to price, not an architecture choice to make. The engineering work is Agent Card publication, signature verification and capability negotiation, and it is bounded.

Indian domestic deployments are a different picture. Most agent work landing with Indian banks, insurers and manufacturers today is single-organisation: one company's agents reaching one company's systems. That is MCP territory, and the 2026-07-28 stateless core removes the operational objection that used to push those teams toward custom RPC. Running MCP servers behind an ordinary load balancer, with no sticky sessions and no shared session store, is a meaningful cost reduction for teams running on modest infrastructure.

One caution specific to India. Where an agent exchange carries personal data, the Digital Personal Data Protection Act 2023 applies to that processing regardless of which protocol moves the bytes. A2A's cross-boundary design makes data flowing to a third party's agent easy to arrange and easy to under-document. Map the flow before you enable it, and treat an outbound agent call as a disclosure, not an internal function call.

FAQ

How eCorpIT can help

eCorpIT is a Gurugram-based product engineering organisation, CMMI Level 5 and ISO 27001:2022 certified, with senior engineering teams building production agent systems for Indian and global clients. We can instrument your existing agent traces to establish whether the bottleneck is tool access or coordination, scope the 2026-07-28 MCP migration against the specific session and elicitation patterns in your codebase, and build the Agent Card publication and signature-verification path if a client platform hands you an A2A requirement. Talk to us at /contact-us/.

References

1. The 2026-07-28 specification — Model Context Protocol Blog, 28 July 2026.

1. MCP 2026-07-28 changelog — Model Context Protocol.

1. MCP 2026-07-28 specification — Model Context Protocol.

1. Beta SDKs for the 2026-07-28 MCP spec release candidate — Model Context Protocol Blog.

1. The 2026 MCP roadmap — Model Context Protocol Blog.

1. A2A protocol surpasses 150 organizations — The Linux Foundation, 9 April 2026.

1. Announcing A2A version 1.0 — A2A Protocol.

1. What's new in A2A v1.0 — A2A Protocol.

1. Agent2Agent protocol specification — A2A Protocol.

1. A2A protocol home — A2A Protocol project.

1. A2A on GitHub — a2aproject/A2A.

1. Agent Payments Protocol — AP2 project.

1. A2A agent delegation in CrewAI — CrewAI documentation.

1. MCP TypeScript SDK — Model Context Protocol.

Last updated: 7 August 2026.