A2A and MCP are not interchangeable: choose the boundary first
When a team adds a second agent, someone usually asks whether the system should use A2A or MCP. That question treats two different contracts as competitors.
The Model Context Protocol (MCP) connects a host to focused capabilities: tools, resources, and prompts. The Agent2Agent Protocol (A2A) lets one independent agent hand work to another without inspecting the remote agent's model, memory, or tools.
A database lookup can take several minutes and still be a tool call. A remote research service can reply quickly and still be an agent if it accepts a goal, controls the work, and returns an artifact. Duration does not define the boundary. Ownership does.
The contracts are different
MCP's stable TypeScript SDK implements the 2026-07-28 specification. A server exposes tools, resources, and prompts; an MCP host connects to it and lets a model use them. The host sits at the center. It chooses servers, supplies context, handles results, and decides where user consent and policy checks belong.
A2A 1.0 describes a client agent talking to a remote agent. The remote agent can remain opaque. It publishes an Agent Card with its identity, endpoint, capabilities, authentication requirements, and skills. Work moves through Tasks, Messages, Parts, and Artifacts. A task tracks the job's lifecycle. An artifact is a result produced during that job.
| Question | MCP | A2A |
|---|---|---|
| What crosses the boundary? | A named tool call, resource request, or prompt | A delegated goal, messages, task state, and artifacts |
| Who owns orchestration? | The MCP host | Each agent owns its side of the collaboration |
| Is the remote implementation visible? | Capability schemas are exposed | Internal model, memory, and tools can remain opaque |
| Typical example | Search an index or query a calendar | Ask a travel agent to build and revise an itinerary |
The protocols can coexist. A planning agent might expose an A2A endpoint while using several MCP servers internally. Its caller sees the remote agent and its task state, not every database, search service, or model behind it.
Long-running does not mean agentic
The MCP 2026-07-28 release made Tasks an official extension for work that continues beyond one request. That helps with slow tool operations. It does not turn every MCP server into an independent peer agent.
Use ownership as the test. When the caller selects an operation, validates its arguments, and remains responsible for the plan, MCP fits even if the operation is slow. When the caller delegates an outcome to a separately operated system that can plan, ask follow-up questions, and produce artifacts, A2A fits.
Calling every function an agent creates its own problem. A thin wrapper adds discovery, task state, messaging, and another security surface without adding useful autonomy. The tool interface still needs a narrow contract, clear inputs, and predictable failure behavior.
A business trip shows where both fit
Suppose an application plans a business trip. It could use MCP tools to search the company travel policy, query a calendar, and retrieve approved hotel limits. The host knows when to call each focused capability and how to combine the results.
The application could also delegate the trip to an external travel-planning agent over A2A. That agent might ask for missing dates through Messages, track the work as a Task, use its own providers, and return an itinerary as an Artifact. The caller does not need its internal tool graph.
The travel agent may call MCP servers for flights, hotels, or document storage. A2A handles the relationship between independent agents. MCP handles the capabilities an agent uses to do its job.
Model access sits on another layer. An OpenAI-compatible endpoint such as the ISH API can power an agent on either side. That choice does not determine whether the system should expose MCP, A2A, both, or neither.
Five questions to settle the design
- Is the caller invoking an operation or delegating an outcome? Named operations favor MCP. Goal delegation favors A2A.
- Who owns the plan? If the host owns it, expose capabilities. If a remote system owns a meaningful part, treat that system as an agent boundary.
- Must the caller understand the implementation? MCP exposes capability schemas. A2A lets the remote agent's internals remain opaque.
- What state must cross the boundary? Tool arguments and results may be enough. Otherwise, task status, follow-up messages, cancellation, and artifacts can justify A2A.
- Who carries the operational risk? Name the owner of authentication, authorization, user consent, retries, timeouts, cancellation, audit records, and incident response.
Start with MCP when one application needs well-defined capabilities. Add A2A when work crosses an independent ownership or deployment boundary and the remote system genuinely controls how the goal is completed. Using both is not evidence of interoperability by itself.
Discovery is not trust
A2A clients can retrieve a public Agent Card from /.well-known/agent-card.json. The discovery guidance notes that sensitive cards may need authentication, static secrets should not be embedded in a card, and cached cards should be refreshed with standard HTTP mechanisms such as ETags.
An Agent Card says how to reach an agent. It does not prove that the agent is safe, reliable, or entitled to receive user data. MCP discovery has the same limit: a server exposing a tool schema is not automatically authorized to act.
If the same capability is reachable through both protocols, put both paths behind one policy layer. Otherwise they can quietly acquire different permissions, retention rules, or approval behavior. Carry a correlation identifier from the A2A task into downstream MCP calls, then record task-level and tool-level events. That makes failures easier to reconstruct with agent traces that explain decisions.
The implementation rule is simple: expose a capability when the caller owns the plan; expose an agent when the remote system accepts responsibility for part of the outcome.
