--- title: How does Agent2Agent differ from MCP? url: https://deepthinkingai.org/agent2agent-vs-mcp/ published: 2026-10-02 author: Shekhar Singh topic: Agents & Protocols tags: a2a, mcp, agents, interoperability, protocols site: DeepThinking AI --- # How does Agent2Agent differ from MCP? **Summary:** Agent2Agent and MCP solve different boundaries. A2A standardises how one agent discovers another, opens a task and receives updates or artifacts back. MCP standardises how an agent runtime discovers and uses tools, resources and prompts. Use MCP inside an agent. Use A2A when the other side owns its own planner, state and operators. ## Key takeaways - The A2A specification defines Agent Cards, task lifecycle objects and message methods for peer agent collaboration. - The MCP specification defines JSON-RPC requests for tools, resources and prompts inside one host-controlled integration surface. - A2A discovery starts from an Agent Card, commonly at `/.well-known/agent-card.json`, before any task is opened. - An A2A task is a stateful remote work unit, while an MCP tool call is a capability invocation within the caller's runtime. - Teams should default to MCP for internal tool wiring and add A2A only when the remote side is a separately owned agent service. Agent2Agent is one of the more current protocol conversations in AI engineering, and much of the commentary frames it as a successor to MCP. The current specifications do not support that reading. The A2A docs describe a peer protocol for independent agents. The MCP spec describes a host-mediated integration layer for tools, resources and prompts. My view is simple. Default to MCP until the thing on the other side is a real agent service with its own task state, auth rules and operators. Wrapping every internal workflow in A2A adds discovery and lifecycle machinery you probably do not need. ## What does Agent2Agent standardise that MCP does not? Agent2Agent standardises the boundary between one agent and another agent. The current A2A docs describe independent, often opaque agents that discover each other, negotiate interaction modes, exchange messages, and collaborate on a shared task. The protocol definition then turns that into concrete methods such as `SendMessage`, `SendStreamingMessage`, `GetTask`, `CancelTask` and task push notification configuration. Those methods assume the remote side owns a task lifecyle and may need more than one turn to finish the work. MCP standardises a different surface. The [MCP specification](https://modelcontextprotocol.io/specification/2026-07-28) defines JSON-RPC communication between a host, its MCP clients and MCP servers, with server features exposed as [tools, resources and prompts](/how-model-context-protocol-works/). That surface is a capability boundary between a host and the things it can use. A tool may be powerful, but the caller still owns the plan. That distinction is the durable finding here: A2A delegates work to another agent service, while MCP extends the current agent's own reach. ## How does Agent2Agent discovery work before a task starts? A2A begins with discovery. The specification says A2A servers must make an Agent Card available, and the common path is `https://{server_domain}/.well-known/agent-card.json`. That card tells the caller what the remote agent claims to be, which protocol bindings it supports, which skills it exposes, and which authentication schemes it expects. The same document may also advertise optional capabilities such as streaming, push notifications and an authenticated extended card. That is a heavier first contact than MCP because the remote side is a service you may not control. The A2A docs also allow curated registries and direct configuration, which matters in enterprise settings where a public well-known URI is the wrong trust model. The practical consequence is that caching belongs in the client from day one. The spec recommends `Cache-Control` and `ETag`, and clients should revalidate rather than fetch the whole card on every run. If you skip that work, protocol discovery becomes needless latency on every delegation. ## How does an Agent2Agent task differ from an MCP tool call? The sharpest difference is state. In the A2A proto, a `Task` is the core unit of action, with lifecycle states such as `SUBMITTED`, `WORKING`, `COMPLETED`, `FAILED`, `INPUT_REQUIRED` and `AUTH_REQUIRED`. A caller can block on `SendMessage`, stream progress with `SendStreamingMessage`, poll with `GetTask`, or register push notifications. That is the contract you need when remote work may span multiple steps, approvals or partial artifacts. An MCP tool call is much smaller. Modern MCP uses self-contained JSON-RPC requests where the client negotiates version and capabilities per request, then invokes one tool, reads one resource, or loads one prompt. The host keeps control of orchestration, consent and retry policy. Even when the server is complex, the unit exposed to the model is still a capability call inside the current runtime. That is why [cloud agent deployment](/cloud-agents-manual-deployment/) and A2A fit naturally together: a delegated agent behaves more like a remote worker than like a local function. **An A2A delegation with internal MCP work behind it** ```mermaid sequenceDiagram participant AgentA as Agent A participant AgentB as Agent B AgentA->>AgentB: GET /.well-known/agent-card.json AgentA->>AgentB: SendMessage AgentB-->>AgentA: status_update or message AgentB->>AgentA: artifact or completed task ``` - GET /.well-known/agent-card.json: Agent A learns skills, auth and bindings. - SendMessage: opens or continues a stateful task - status_update or message: may stream while Agent B uses MCP internally - artifact or completed task: final result of the delegated work A2A standardises the peer exchange. The remote agent is still free to use MCP, direct APIs or other private logic behind its own boundary. ## When should a team use Agent2Agent instead of MCP? Use MCP first when the other side is still your own integration problem. If you control the runtime, the approval flow, the credentials and the orchestration, an MCP tool or resource keeps the contract smaller and keeps policy in one place. This is still true when the capability is complicated. Complexity alone does not make something a peer agent. It may only mean you need a better tool description or a stricter execution boundary. Use A2A when the other side is genuinely another agent service. Signs include a separate operator, a published skill catalog, its own task queue, remote auth requirements, or a need to return progress and artifacts over time. My opinion is that teams should be conservative here. If an internal service could be described honestly as "an API my agent calls", forcing it through A2A is usually theatre. If the better sentence is "an agent I delegate work to", A2A is probably the right contract, much like choosing between [ADK and LangGraph](/google-adk-vs-langgraph/) depends on who owns the runtime burden. ## How do Agent2Agent and MCP fit in one production system? The clean production pattern is layered. An entry agent receives the user goal and decides whether another specialist agent should own a slice of work. If so, it discovers that agent through the Agent Card, opens or continues an A2A task, and tracks the task until it gets a completion state or an interruption that needs human input. Inside the remote agent, the implementation can stay private: it may call MCP tools, attach MCP resources, use direct APIs, or mix all three. That is why the A2A docs call the remote side opaque. The caller needs a stable peer contract and a clean result surface. The right architecture is therefore A2A outside, MCP inside. Teams that blur the layers end up either publishing too much of their internal topology or hiding a remote workflow behind a tool call that cannot represent progress cleanly. The protocol stack is only simpler once the ownership boundary is made explicit. **Where A2A stops and MCP starts** 1. Client agent Owns the user goal and delegation policy. 2. A2A task and Agent Card Discovers peers and tracks delegated work. --- protocol boundary --- 3. MCP client inside remote agent Chooses tools, resources and prompts. 4. MCP servers and external APIs Hold the data and side effects. The useful split is ownership. A2A crosses from one agent service to another. MCP stays inside an agent runtime and describes how that runtime reaches capabilities. ## Choose between Agent2Agent and MCP without protocol cargo culting Start from the ownership boundary, because the wrong protocol choice usually comes from pretending a tool is an agent or an agent is a tool. 1. **Identify who owns the logic on the other side**: If the remote side has its own planner, memory, operators or SLA, treat it as an agent boundary candidate. If it is a capability inside your runtime, keep it in the tool layer. 2. **Model local capabilities as MCP first**: Tools, resources and prompts are the smaller contract. They keep routing, consent and policy in the calling host rather than creating an unnecessary remote task protocol. 3. **Add Agent2Agent only for delegated work**: Use A2A when you need skill discovery, multi-turn task progress, remote authentication rules or artifact exchange with a separately owned agent service. 4. **Publish an Agent Card that says exactly what is supported**: Declare the binding, protocol version, skills and optional features such as streaming or push notifications. If details are sensitive, move them to an authenticated extended Agent Card. 5. **Decide the task completion path before integration**: Pick between blocking `SendMessage`, `SendStreamingMessage`, polling with `GetTask`, or webhook push notifications. The choice affects client complexity more than the choice of SDK. 6. **Log task ids separately from tool calls**: Keep A2A task ids, context ids and remote agent identity distinct from internal MCP tool traces. Without that split, a delegated failure looks like a local tool fault. ## Frequently asked questions ### Is Agent2Agent a replacement for MCP? No. The current A2A documentation says the two are complementary. A2A covers agent-to-agent communication. MCP covers agent-to-tool communication. A remote A2A agent may still use MCP internally to reach its own tools and data. ### Do I need an Agent Card for every internal service? Usually no. An Agent Card makes sense when the service is being presented as an autonomous agent with declared skills, auth requirements and protocol bindings. A plain internal API or tool adapter is usually a better fit for MCP or direct application code. ### When should I use SendStreamingMessage instead of polling GetTask? Use streaming when the caller benefits from partial progress, intermediate messages or artifact chunks. Use blocking or polling when the task is short, the network path is simple, or your client only needs the final state. ### Can one system expose both Agent2Agent and MCP? Yes. That is often the clean design. The system can expose an A2A surface to peer agents while its own runtime uses MCP to reach tools, resources and prompts behind that boundary. ### Does Agent2Agent require public discovery? No. The spec allows well-known discovery, curated registries and direct configuration. Public `/.well-known/agent-card.json` is only one discovery path. Private deployments can rely on registries or direct configuration instead. ## Sources - [A2A Protocol Specification](https://a2a-protocol.org/latest/specification/). A2A Protocol - [a2a.proto normative protocol definition](https://a2a-protocol.org/latest/spec/a2a.proto). A2A Protocol - [A2A and MCP](https://a2a-protocol.org/latest/topics/a2a-and-mcp/). A2A Protocol - [Model Context Protocol Specification (revision 2026-07-28)](https://modelcontextprotocol.io/specification/2026-07-28). Model Context Protocol, 2026-07-28 --- Canonical HTML: https://deepthinkingai.org/agent2agent-vs-mcp/