A2A protocol vs MCP solves two different layers

A2A and MCP sit on different boundaries. MCP lets an AI application use tools and read context; A2A lets one independently operated agent hire another agent to complete a task. Treating them as rival protocols usually means the system boundary has not been drawn yet.

That distinction matters because protocol work has a habit of turning into platform work. A founder hears that agents need interoperability, an engineering team builds a universal gateway, and three months later the actual product still needs a safe way to query the CRM. Most teams should implement MCP first, prove that one agent can do useful work with controlled tools, and add A2A only when a real ownership or deployment boundary requires agent delegation.

MCP gives an agent capabilities while A2A gives it peers

The cleanest way to compare the protocols is to ask who controls each side of the connection. An MCP host controls the AI experience and connects to servers that expose capabilities. An A2A client delegates work to a remote agent that controls its own reasoning, tools, state, and execution.

• With MCP, the other side is a server exposing tools, resources, or prompts. With A2A, it is an autonomous or semi-autonomous agent.
• An MCP caller requests a named capability such as search_tickets. An A2A caller requests an outcome through a message or task.
• The MCP host owns planning around a call. The remote A2A agent owns planning for the work it accepts.
• MCP standardizes capability exchange and calls. A2A standardizes task status, messages, follow-up input, cancellation, and artifacts.
• MCP clients discover what a server exposes through protocol methods. A2A clients read an Agent Card while the remote agent keeps its private tools and reasoning opaque.

The field often blurs a tool with an agent because both accept structured input and return structured output. The consequence is ugly. If you wrap a deterministic tax calculator as an agent, you acquire task state, conversational ambiguity, and another security principal without getting better calculations. If you expose a travel planning agent as one synchronous tool call, you hide a long running job, intermediate questions, partial artifacts, and cancellation behind a request that looks like a function.

MCP can still participate in a multi-agent system. A coordinator may connect to several MCP servers, and one of those servers may happen to call an agent internally. That does not make the interaction A2A. The host still sees a capability call and owns the surrounding orchestration. Conversely, an A2A agent may use MCP servers to search files, update records, or run code while it fulfills a delegated task.

This is why the protocols are complementary in architecture even when product vendors compete for the same integration budget. They standardize different contracts. A team can choose one, both, or neither without violating the conceptual model.

MCP solves the tool integration bottleneck

MCP standardizes how an AI host discovers and invokes tools and how it reads resources supplied by a server. It replaces a collection of one-off adapters with a shared data layer and transport contract. The host remains responsible for model calls, permission prompts, context selection, orchestration, and the user experience.

The official MCP architecture is explicit about this division. A host creates a client for each server and keeps servers isolated from the full conversation and from one another. That is more than a diagram choice. It means a payroll server should receive the arguments required for a payroll action, not the user's entire conversation and whatever another server returned.

Consider a support agent that needs ticket history and the ability to issue a credit. Under MCP, a support system can expose get_ticket, search_orders, and issue_credit as separate tools with separate input schemas. The host decides when to call each one and can require a human approval before the mutating call. The server validates the request against the authenticated user and performs the business operation. MCP does not decide whether the agent's plan was sensible.

The current MCP specification uses JSON-RPC messages over transports defined by the protocol. The July 2026 revision made the remote core stateless, moved client identity and capabilities into request metadata, and added routing headers such as Mcp-Method and Mcp-Name. An ordinary call now has a recognizable shape:

POST /mcp HTTP/1.1
MCP-Protocol-Version: 2026-07-28
Mcp-Method: tools/call
Mcp-Name: search_tickets
Authorization: Bearer <token>
Content-Type: application/json

{"jsonrpc":"2.0","id":17,"method":"tools/call","params":{"name":"search_tickets","arguments":{"account_id":"acct_42","status":"open"},"_meta":{"io.modelcontextprotocol/clientInfo":{"name":"support-agent","version":"1.4"}}}}

The useful property is not the syntax. A gateway can route, meter, and deny the call using visible protocol fields, while the tool schema tells the model what it may request. Your application still needs authorization, idempotency, rate limits, audit records, and business validation. A protocol schema does not turn an unsafe refund endpoint into a safe one.

Use MCP when the sentence starts with "the agent needs access to." Files, issue trackers, build systems, databases, browser automation, internal APIs, and specialized calculations fit this boundary. Do not add A2A merely because an LLM initiated the call.

A2A solves delegation across agent boundaries

A2A standardizes how one agent discovers another agent's skills, sends work, follows a task, supplies additional input, receives artifacts, and cancels work. It fits collaborations where the remote side owns how the outcome is produced and may take time, ask questions, or return several deliverables.

The A2A specification makes this scope unusually plain: A2A is not a sub-agent protocol and does not specify how an agent invokes its tools. It is a contract between agentic applications that can be built with different frameworks and operated by different teams or companies. That qualification matters. Internal worker agents inside one process already share an orchestrator, a runtime, and a deployment. Adding a network interoperability protocol between them often adds ceremony without adding independence.

An Agent Card is the discovery document. It describes the agent, its supported interfaces, capabilities, security schemes, and skills. A public card may live at the well-known agent card path, while authenticated extended cards can reveal capabilities that should not be public. The card advertises what the client can rely on; it should not expose prompts, private tools, credentials, or internal topology.

After discovery, the client sends a message or creates work through one of A2A's standard bindings. A2A 1.0 defines a protocol neutral data model with standard JSON-RPC, gRPC, and HTTP plus JSON bindings. The server can answer with a message or a task. A task has a lifecycle and can accumulate messages, status updates, and artifacts, which makes long work visible without forcing the remote agent to reveal its chain of thought.

Imagine a procurement agent delegating a contract review to a legal operations agent owned by another department. The request describes the desired review and supplies the contract. The legal agent chooses its own document parser, policy store, models, and approval flow. It may ask which jurisdiction applies, then return a redlined document and a risk memo as artifacts. The procurement agent cares about status and outputs, not which internal tools produced them.

A2A earns its cost when that opacity and independent ownership are requirements. It also gives both sides room to upgrade internal frameworks without rewriting the collaboration contract. If the caller already knows the exact function to invoke and expects an immediate result, an MCP tool or a normal API is simpler.

One production flow can use both protocols

The protocols meet naturally when a coordinator delegates an outcome to a specialist agent, and that specialist uses tools to perform the work. A2A governs the outer delegation. MCP governs capability access inside either agent.

Take a release readiness workflow. A coordinator asks a security review agent for an assessment of release candidate 2026.08.3. That is A2A because the security agent owns the review method, may run for minutes, and returns an assessment artifact. Inside its boundary, the security agent calls MCP tools to read dependency reports, query recent incidents, and inspect deployment policy. It may then send an A2A message asking the coordinator for the risk exception owner.

The layering should remain visible in logs and code:

Product workflow
  A2A task: review release 2026.08.3
    Security agent plan
      MCP tools/call: dependency_findings
      MCP resources/read: deployment_policy
      MCP tools/call: incident_search
    A2A input-required: identify exception owner
    A2A artifact: release-risk-assessment.json

Do not build a magical adapter that converts every MCP tool into an A2A agent or every A2A skill into an MCP tool. Automatic wrapping erases semantics. A tool call has a named operation and a bounded response. An agent task may negotiate input, change status, generate several artifacts, and outlive a client connection. The wrapper either discards those behaviors or invents them for tools that never had them.

There are narrower adapters that make sense. A coordinator can expose "delegate contract review" as an MCP tool to its local host while its implementation starts an A2A task. The tool response should return a durable task reference rather than block until review finishes. Likewise, an A2A agent can present one skill backed by a stable set of MCP tools. In both cases, write the boundary conversion as application code and test its failure semantics.

You also need one source of truth for identity. The end user, the calling agent, the A2A server, the MCP host, and the downstream service are distinct principals. Forwarding the same bearer token through the whole chain feels convenient, but it destroys audience checks and audit meaning. Each hop should exchange or mint credentials intended for that resource, and logs should preserve both the initiating user and the acting service where policy allows it.

Adoption favors MCP while A2A has reached a stable base

MCP has broader visible deployment today, while A2A now has a stable specification and serious institutional backing. Those facts do not predict that one protocol will replace the other. They reflect the order in which teams encounter the problems: agents need tools before most companies need cross-vendor agent delegation.

The MCP maintainers released specification revision 2026-07-28 with official SDK support. Their release report says Tier 1 SDKs approach half a billion downloads per month and that both the TypeScript and Python SDKs have crossed one billion total downloads. Download counts include automated builds and indirect use, so I would not equate them with active production systems. The stronger adoption signal is that MCP appears as a supported extension boundary in widely used AI applications and developer tools, backed by an official registry and a formal extension process.

That lead should affect sequencing, not architecture. An MCP server published today can reach several existing hosts without asking each host vendor to adopt a new custom connector. A2A's immediate value is narrower because both endpoints must support compatible task semantics, not merely parse the wire format. A client that expects resumable tasks gains little from a server that returns only immediate messages, even if both products print the A2A logo.

MCP also moved to neutral governance. Anthropic donated it to the Agentic AI Foundation under the Linux Foundation in December 2025, with Anthropic, Block, and OpenAI as cofounders and support from several large infrastructure vendors. Governance does not guarantee compatibility, but it reduces the risk that one model vendor can casually redefine the protocol around its own product.

A2A reached version 1.0 after its original Google release and donation to the Linux Foundation. The project calls 1.0 its first stable production release, defines three standard bindings, and hosts SDKs for Python, Go, JavaScript, Java, .NET, and Rust. Its technical steering committee includes representatives from eight large technology companies. The Linux Foundation reported support from more than 100 companies when it launched the project in 2025.

Treat those company lists as ecosystem intent, not proof of interoperable production traffic. A logo can mean engineering contribution, a prototype, planned support, or a marketing agreement. For procurement, ask for the supported protocol version, binding, authentication profile, conformance results, error behavior, and an interoperation test against a second implementation. "Supports A2A" is not an acceptance criterion.

Registry size needs the same skepticism. A long server catalog shows supply, but it does not tell you whether entries are maintained, secure, or useful in your environment. Evaluate the few integrations on a live workflow: inspect ownership, release history, requested privileges, failure handling, and whether schemas stay small enough for the model to choose correctly. Adoption lowers search cost; it does not replace due diligence.

Version movement is part of the adoption story. MCP's 2026 revision retired the initialization handshake and protocol sessions, while A2A 1.0 followed several pre-1.0 versions and changed its normative model. Pin versions at both ends, record negotiated versions, and budget for migration. Early standards lower integration costs across products, but they do not remove maintenance.

For a new build, target the newest stable version that every required endpoint genuinely supports, then isolate protocol code behind a small internal interface. Do not expose SDK objects throughout business logic. When the next revision changes transport state or task fields, you want one adapter and a contract suite to change, not dozens of workflow handlers.

Implement the first boundary your product actually has

Most startups should implement MCP first because one useful, well governed agent beats a network of agents that cannot safely act. The exception is a product whose first requirement is already remote delegation, such as an agent marketplace, a cross-company workflow, or a platform that must accept tasks from third-party agents.

Use this decision sequence before assigning protocol work:

1. Write the business operation in one sentence. "Search our account records" points to a capability. "Investigate this account and return a risk report" may point to an agent task.
2. Mark ownership. If your team controls caller and callee and the callee is a deterministic service, use MCP or a normal API. If another team controls the callee's planning and release cycle, evaluate A2A.
3. Mark time and interaction. A quick bounded response fits a tool. Work that pauses for input, streams status, produces artifacts, or needs cancellation fits A2A better.
4. Prove one vertical path. Use one read operation and one carefully approved write for MCP, or one A2A skill with a complete task lifecycle. Do not start with a generic protocol platform.
5. Add the second protocol only when a measured workflow crosses its boundary. Preserve the original boundary instead of rewriting everything into the new abstraction.

For an MCP first rollout, choose a low risk resource and a business relevant tool. Define tight input and output schemas, connect a real identity, log authorization decisions, and test prompt injection through tool results. Then add a mutating tool with an explicit approval and idempotency token. That sequence teaches the team more than publishing twenty read-only wrappers.

For an A2A first rollout, avoid a generic "assistant" skill. Choose an outcome with a named artifact and a clear terminal state, such as a policy compliance report. Publish the smallest useful Agent Card, require authentication for sensitive skill details, implement cancellation and input required behavior, and test with a client maintained outside the server repository.

Can you defer both? Yes. If a single application calls two stable internal APIs, direct typed clients may be cheaper and easier to operate. Adopt a protocol when interoperability or host portability repays its extra versioning, discovery, and security surface. Protocol compliance is not a product milestone unless a user can complete work because of it.

Estimate the operational cost before approval. Count endpoints, credentials, protocol versions, retry paths, dashboards, and teams that must respond when work stalls. A2A often creates a new service boundary; MCP can create many capability endpoints behind one host. The implementation estimate should include those recurring costs, not only the happy path demo.

Security belongs to every hop, not to the protocol label

Neither MCP nor A2A makes an agent safe. Both specifications provide places to express capabilities and authorization, but your implementation decides whether a caller may read a record, start a task, approve a payment, or retrieve an artifact.

MCP's security guidance explicitly forbids token passthrough. An MCP server must reject tokens that were not issued for it, because forwarding an upstream token can bypass audience restrictions, blur client identity, and turn the server into an exfiltration proxy. The guidance also calls out confused deputy attacks, server side request forgery, broad scopes, and local servers running with the client's privileges.

For remote MCP servers, validate issuer, audience, expiry, scopes, and the intended resource. Bind client credentials to the authorization server that issued them. Put write tools behind narrow scopes and application checks, not merely model confirmation. For local servers, restrict filesystem and network access and prefer a transport that does not expose a listening port when only one local client needs access.

A2A has a different exposure. Agent Cards advertise endpoints and skills, tasks may contain sensitive history, and artifacts can outlive the request that created them. Public cards should reveal only public capabilities. Put sensitive skills in authenticated extended cards, check authorization on every task operation, and scope task lookup to the caller. An unguessable task ID does not grant access.

At the combined boundary, make delegation explicit in policy. A user who may ask a coordinator to summarize invoices has not automatically authorized a remote finance agent to export them. Record the delegation chain, apply the least privilege credential at each hop, and set retention rules for messages and artifacts. Cancellation should stop downstream work where possible rather than merely changing the coordinator's local status.

Human approval needs a concrete object. Show the operation, target, important arguments, acting identity, and expected side effect. "Allow agent?" trains people to approve noise. If an A2A agent requests input that will trigger an MCP write, the component holding the user session should collect approval and bind it to that exact request.

Interoperability requires failure tests, not matching diagrams

A protocol implementation is credible when two independently built systems survive unhappy paths together. A successful hello and one tool call prove little. The expensive bugs live in version skew, authentication renewal, duplicate delivery, partial artifacts, cancellation races, and errors that one SDK silently normalizes.

For MCP, keep a small contract suite that lists capabilities, calls one read tool, rejects invalid arguments, denies an insufficient scope, handles a tool error, and verifies behavior against the protocol versions you claim. Include a malicious tool result that tries to redirect the model or request another credential. The host should treat returned content as untrusted data, not as instructions with higher authority.

For A2A, run one task through each state transition your product supports. Disconnect and resume while the task runs. Submit duplicate requests with the same application idempotency reference. Cancel before work starts and while an artifact is being produced. Ask for a task under another tenant's identity and verify a denial rather than an empty success that leaks timing or existence.

A compact acceptance record can be more useful than a thick architecture document:

{
  "implementation": "release-review-agent",
  "a2a_version": "1.0",
  "binding": "HTTP+JSON",
  "client": "independent-test-client/2.1",
  "cases": {
    "auth_wrong_audience": "denied",
    "task_resume": "passed",
    "cancel_during_work": "passed",
    "cross_tenant_task_get": "denied",
    "artifact_checksum": "passed"
  }
}

Store the real request and response shapes for failed cases with credentials removed. That gives maintainers something reproducible when an SDK upgrade changes behavior. It also exposes fake interoperability early: two services built on the same SDK can share the same bug and still pass each other's tests.

Conformance tools help, but application semantics remain yours. A protocol test cannot know that a canceled purchasing task must release a reservation, or that a tool retry must not issue a second credit. Put those invariants beside the wire tests.

The architecture should reduce team boundaries, not multiply them

Protocol choice affects organization design because every independently operated agent becomes a service with an owner, release policy, on-call path, and security principal. A2A is justified when that independence already exists or creates clear business value. It is a costly way to draw boxes around one small engineering team.

MCP usually centralizes orchestration in the host and pushes narrow capabilities toward teams that own systems of record. That can work well if tool owners publish stable schemas and retain authorization responsibility. It fails when an "AI platform team" becomes the approval queue for every tool change or when tool servers simply mirror huge internal APIs that models cannot use reliably.

A2A distributes planning across agent owners. That supports cross-company services and specialist domains, but it also distributes incident diagnosis. When a coordinator reports "task failed," someone must determine whether discovery, authentication, delegation, the remote plan, an MCP dependency, or artifact delivery caused it. Agree on correlation identifiers and escalation ownership before the first production incident.

This is also why I push back on building a universal agent mesh first. The idea is popular because infrastructure feels measurable and politically neutral. Yet without proven workflows, the team cannot know which task states, approval points, service objectives, or audit fields matter. A thin vertical implementation exposes those requirements quickly.

In a Team & AI Audit at oleg.is, I map protocol work to the engineering hours and handoffs it removes, then cut integrations that create more operational surface than product output. The same test works without hiring anyone: name the user outcome, the current bottleneck, the owner on each side, and the failure you need a standard to contain.

Implement MCP first when your agent lacks controlled access to useful systems. Implement A2A first when independent agents already need to delegate work across an ownership boundary. Implement both when one agent delegates an outcome and either side needs standard tool access. If none of those sentences describes a live workflow, keep the architecture boring until one does.