Start here: the basics
MCP vs A2A: what is the difference?
MCP gives an agent tools to call, and A2A gives it other agents to talk to.
MCP (Model Context Protocol) connects one agent to the tools and data it needs: a database, a calendar, a ticketing system. A2A (Agent2Agent) connects that agent to a different, independent agent, one it does not control and whose internals it never sees. Both are open specifications, and a system can use both.
What each protocol is for
MCP's specification describes a host (the AI application), a client inside it, and a server that exposes tools, resources and prompts. A client calls tools/list to learn what a server offers, then tools/call to run one. The server does the work and returns a result. Nothing in that exchange assumes the thing on the other end is itself an agent. It usually is not: it is a wrapper around an API, a file system, or a database.
A2A's home page states the split directly: "MCP is for agent-to-tool communication: it standardizes how an agent connects to its tools, APIs, and resources to get information... A2A is for agent-to-agent communication: as a universal, decentralized standard, A2A lets independent agents, including those using MCP, discover each other, delegate tasks, and share results."
A2A's own introduction explains why it does not just reuse MCP's tool model for this: "To expose agents to each other, developers often wrap them as tools, much like the Model Context Protocol (MCP) exposes tools. But this is inefficient: agents are built to negotiate directly, and wrapping them as tools limits what they can do. A2A exposes agents as they are, with no wrapping." A tool call is a single function with a fixed input and output. An agent might need several turns, ask a clarifying question, or take minutes to finish, and A2A's data model is built around that instead of flattening it into one call.
Discovery: Agent Cards vs tools/list
An MCP client discovers what a server offers by connecting to it and sending tools/list. The response is a list of tools, each with a name, a description, and an inputSchema. There is no step before the connection: you point the client at a server and ask.
A2A puts discovery before the connection. A server publishes an Agent Card, a JSON document, typically at /.well-known/agent-card.json, that a client fetches first. The A2A specification defines it as "a JSON metadata document published by an A2A Server, describing its identity, capabilities, skills, service endpoint, and authentication requirements." The client reads the card to decide whether this agent fits the task and how to reach it, before any message is sent. A2A also supports an "Extended Agent Card" for callers who authenticate, with more detail than the public one.
This mirrors the difference in what is being described. tools/list describes functions: a model matches a sentence in a prompt to a tool description and fills in arguments. An Agent Card describes an agent's skills and how to reach it. The work of understanding a request happens inside the remote agent.
Tasks and turns
MCP's tool calls are typically one request, one response. The 2026-07-28 revision added a way for a tool to come back mid-call asking for more input (an InputRequiredResult) before finishing, but a tool call still ends with a result for that one call.
A2A is built around a Task, which the specification calls "the fundamental unit of work managed by A2A, identified by a unique ID. Tasks are stateful and progress through a defined lifecycle." A Send Message request can return a Task instead of a direct answer, and the agent keeps working on it after the response comes back. The client checks progress by polling, by opening a streaming connection with Server-Sent Events, or by registering a webhook for push notifications. A task moves through states and ends in one of four terminal ones: completed, failed, canceled or rejected. Output comes back as Artifact objects, kept separate from the Message objects used for status and clarification. A contextId groups several related tasks into one ongoing conversation.
MCP has no concept of a conversation lasting across tool calls, so a server that needs to remember state between calls has to invent a handle for it. A2A has that built in, because inter-agent work is often long enough to need it: an itinerary that takes several minutes to assemble, or a negotiation that spans multiple messages.
Authentication and authorization
MCP leaves authorization optional and transport-dependent. Its specification says: "Authorization is OPTIONAL for MCP implementations... Implementations using an HTTP-based transport SHOULD conform to this specification. Implementations using an STDIO transport SHOULD NOT follow this specification, and instead retrieve credentials from the environment." Where it does apply, an MCP server acts as an OAuth 2.1 resource server, publishing Protected Resource Metadata so a client can find the right authorization server. A local server, launched as a subprocess over stdio, usually skips all of this and gets its API key from a config file instead.
A2A delegates authentication to the HTTP layer the same way, but it is not optional in the same sense: every server advertises how to authenticate as part of discovery. The specification's enterprise guidance says: "Authentication requirements are advertised by the A2A server in its Agent Card... The A2A Client obtains the necessary credentials, such as OAuth 2.0 tokens or API keys, through processes external to the A2A protocol itself... Credentials must be transmitted in standard HTTP headers." A failed or missing credential gets a 401 with a WWW-Authenticate header; a valid credential without the right permission gets a 403. Authorization past that point, deciding which caller may invoke which skill, is left to the server's own policy, the same way MCP leaves tool-level permissions to whoever runs the server or sits in front of it.
Where they overlap, and when to use both
Both protocols run over HTTP (A2A requires it for production; MCP also supports local stdio), both use JSON-RPC-style messages, and both treat authorization as something handled at the transport layer rather than inside the protocol payload. Both also leave the hard access-control questions, who may call what, to whatever runs the server.
A single agent that needs to query a database or open a support ticket needs MCP. A system made of several independently built agents, each maybe using MCP internally, needs A2A to let them find each other and hand off work without one agent having to understand the others' internals. A2A's own documentation is explicit that it is "not a sub-agent or tool-call protocol": it does not describe how an agent calls its own tools, only how it talks to agents it does not control.
In practice this means an orchestrating agent can use A2A to delegate "book a flight" to a travel agent built by another team, and that travel agent can use MCP underneath to call the airline's actual booking API. The orchestrator never sees the airline API, and the travel agent never has to understand A2A's task lifecycle to call a database. Each protocol does one layer, and a system that only needs one of them should only adopt one: adding A2A to connect a single agent to its own tools adds a task lifecycle and discovery step that nothing in that setup needs.
Where Statio fits
Statio is a gateway for MCP: it decides, per tool, which agent may call it, injects the upstream credential at call time instead of handing it to the agent, and scans tool arguments and responses for threats. That covers the agent-to-tool side of a system. It does not sit between two A2A agents, because A2A does not expose tools to grant or deny. It exposes skills behind an Agent Card, which is a different kind of boundary.