Layering
MCP, A2A and AMAP sit at different layers
AMAP is not an alternative to MCP or A2A. Each connects different things, and each is good at different things. This is a layering summary, not a verdict. Check the details against each protocol's own documentation before relying on them.
| Connects | Good at | Where send authority lives | What the other side needs | |
|---|---|---|---|---|
| MCP | A model to tools and context | Giving agents capabilities through a common tool interface | With the tool server, and whatever credentials it holds | Not a cross-organisation protocol |
| A2A | Agent services to each other | Task lifecycles, progress reporting, streaming and conversation between agent services | Within each service and its agreed authentication | A reachable, compatible agent service and an agreed authentication arrangement |
| AMAP | An agent's connector to its email runtime | Keeping email authority outside the agent | In the trusted runtime only | An email address |
MCP
MCP connects a model to tools and context. Where authority lives depends on the tool server and the credentials it holds: MCP itself does not decide that.
AMAP can sit behind MCP. In the Claude Code connector, for example, the agent sees ordinary MCP tools: a read-only inbox, and a submit tool that writes a gated request. AMAP is the specification behind those tools, which is why they carry no send capability. The two are complementary.
A2A
A2A connects agent services directly. It has real strengths:
- explicit task lifecycles;
- progress reporting;
- streaming;
- conversational interaction between agent services.
It does not require the same vendor, cloud or directory on both sides, and managed platforms can supply much of the plumbing. Credential isolation, policy enforcement and human approval can be built around A2A as well as around email.
Either way, cross-organisation automation still needs agreement on:
- business authorisation;
- data governance;
- failure handling;
- revocation.
AMAP
AMAP defines the boundary between an agent's connector and its trusted email runtime. It adds nothing to the wire between organisations: the other side sees ordinary email. So an organisation can deploy an agent under AMAP without its counterparties changing anything, whether each counterparty is a person with an inbox or an agent of its own.
Hypothesis For relationships that already run on email, AMAP may reduce the coordination needed to automate safely, not only the code. This is a hypothesis to test, not a finding. Services that are intentionally integrated may well be better served by direct agent-to-agent protocols.
For how AMAP relates to IETF work, such as DKIM, DMARC and WIMSE, see AMAP at the IETF.
See also: How it works · For implementers · Glossary.