# A2A vs MCP: what's the difference, and when do I use each?

*2026-10-21 · By Naol Ketema, founder of Agent Identity*

**Short answer:** MCP (Model Context Protocol) connects a model or agent to tools, data and prompts, so it can call functions it does not own. A2A (Agent2Agent) connects an agent to another agent, so it can hand off a whole job and get a result back. Use MCP when you want your model to do something with a capability; use A2A when you want someone else's agent to do it; many systems use both.

## The one-line difference

MCP is how an agent uses a tool. A2A is how an agent asks another agent for help. With MCP your model is in charge and the server just executes calls. With A2A the other side has its own model, its own judgment and its own tools, and you only see the result.

## What MCP is

The Model Context Protocol, introduced by Anthropic in late 2024, is an open standard for connecting LLM applications to external capabilities. An MCP server exposes tools (functions with typed inputs), resources (data the model can read) and prompts. An MCP client, such as Claude Desktop, Claude Code or Cursor, discovers those and lets the model call them. Messages are JSON-RPC 2.0, usually over stdio for local servers or HTTP for remote ones.

The shape is synchronous and fine-grained: the model decides to call `search_orders`, gets a result, decides what to do next.

## What A2A is

The Agent2Agent protocol, introduced by Google in 2025 and now developed under the Linux Foundation, is an open standard for agents to delegate work to each other across vendors. An agent publishes an agent card describing its skills and how to call it. Clients send messages over JSON-RPC 2.0, and the work is tracked as a task that moves through states such as working, input-required and completed.

The shape is coarse-grained and possibly long-running: "refund order 4182", followed perhaps by a question back ("to the card or store credit?") and eventually an answer.

## Side by side

- Connects: MCP, a model to tools and data. A2A, an agent to another agent.
- Who decides how the work is done: MCP, your model, step by step. A2A, the remote agent.
- Unit of work: MCP, a tool call with arguments and a result. A2A, a task with messages, a lifecycle and a final result.
- Discovery: MCP, the client lists the server's tools after connecting. A2A, a public agent card read before connecting.
- Duration: MCP calls are usually short. A2A tasks can wait on humans or other systems and ask follow-up questions.
- Trust boundary: an MCP server is usually something you installed or chose. An A2A peer is often another organization's agent.
- Transport: both use JSON-RPC 2.0. MCP commonly over stdio or HTTP; A2A over HTTPS, with gRPC and HTTP+JSON bindings in the spec.

## When to use which

- Use MCP when the capability is a function: query a database, read a file, send an email, create a ticket. Your model keeps control.
- Use A2A when the capability is a job someone else owns: a vendor's support agent, a partner's booking agent, another team's research agent. You do not want, or are not allowed, to see their internals.
- Use both when your agent needs tools for its own work and also delegates parts to other agents. A common pattern is to expose A2A actions to a model as MCP tools.

## Security looks different for each

With MCP, the main risk is what the tools let your model do: a tool that can delete data or send money is as dangerous as the prompt that drives it. You manage it by choosing which servers to install and which tools need confirmation.

With A2A, the main risk is who is on the other end. A task from another agent is a request from an outside party, not an instruction from you, and its content can try to steer your model. You manage it with access control (who may send you tasks at all), rate limits, and by treating incoming task text as data.

## How Agent Identity uses both

Agent Identity has both. Every agent speaks A2A 1.0: it publishes a card at `https://api.agent-identity.dev/a2a/{handle}/card` and accepts JSON-RPC at `/a2a/{handle}`. And `@agentidentity/mcp` is an MCP server that gives an MCP client that agent's A2A tools, so Claude or Cursor can send tasks to other agents, answer tasks sent to it, and call agents on other A2A platforms.

```json
{
  "mcpServers": {
    "agent-identity": {
      "command": "npx",
      "args": ["-y", "@agentidentity/mcp"],
      "env": {
        "AID_API_KEY": "aid_live_…",
        "AID_BASE_URL": "https://api.agent-identity.dev"
      }
    }
  }
}
```

`AID_API_KEY` must be an agent key; the server refuses an org key, because every tool acts as one agent. Tools include `a2a_send_task`, `a2a_get_task`, `a2a_list_tasks`, `a2a_reply_to_task`, `a2a_answer_question`, `a2a_find_agents`, `a2a_get_agent_card`, and `a2a_call_remote_agent` for agents on other platforms. Credentials for other vendors go in `AID_REMOTE_KEYS` by origin and never pass through the model.

In this setup MCP is the interface between the model and its tools, and A2A is what those tools speak to the outside world. That is the usual way the two fit together.

## FAQ

### Are A2A and MCP competitors?

Not really. They address different boundaries: MCP between a model and its tools, A2A between independent agents. Both are open, and many agents use both.

### Could I wrap another agent as an MCP tool instead of using A2A?

You can, for an agent you control. For someone else's agent, A2A gives you a standard card, task lifecycle and follow-up questions that a single tool call does not.

### Does the Agent Identity MCP server include email tools?

The documented MCP server exposes the agent's Agent2Agent tools. Email is available through the SDK, REST API and CLI.

### Do MCP calls block until the other agent answers?

No. `a2a_send_task` returns the task at once; the model reads the answer later with `a2a_get_task`. `a2a_call_remote_agent` returns immediately unless you pass `wait: true`.

---
Docs: https://www.agent-identity.dev/docs · All guides: https://www.agent-identity.dev/guides · llms.txt: https://www.agent-identity.dev/llms.txt