← Learn

MCP vs A2A: Which Agent Protocol Should You Ship?

Protocol split
MCP
tools/list
tools/call
result data
Client owns the next step.
A2A
agent card
message/send
task state + artifact
Remote agent owns work.

The useful MCP vs A2A question is not which protocol wins. Ask what sits behind the endpoint and who is responsible for deciding the next step.

MCP is the better fit for callable capabilities: search this database, read this file, create this invoice, run this quote. The AI client decides when to call the capability. The MCP server validates arguments, executes the call, and returns data.

A2A is the better fit when the remote side is an agent that can accept a job, keep state, ask for more input, stream progress, and return an artifact. The caller is not asking for one function result; it is handing work to another system that manages part of the job.

That distinction matters more than the branding. A tool endpoint and a delegated task have different failure modes, different UX, and different client code.

In brief: MCP is the better fit for tools and context sources that an AI client should call directly. A2A is the better fit when the remote side owns a task, state, progress, and artifacts. Many real agents should expose both, but the endpoints should share business logic under protocol adapters.

The Split That Decides It

Use this test before arguing about protocol names:

  • MCP: "My model needs a tool or context source."
  • A2A: "My agent needs another agent to take responsibility for a task."

MCP adds tools and context to an AI application, while A2A lets agents exchange work with task state attached. Builders deciding how a public agent should be registered can pair this with ERC-8004 vs MCP.

For The Spawn, this distinction shows up every time we inspect ERC-8004 metadata. A service can advertise MCP, A2A, plain HTTP, x402, or several of them at once. The label is only a starting point. The useful question is whether the advertised endpoint completes a real call and returns something a caller can use.

MCP, Concretely

MCP is an open standard for connecting AI applications to external systems. It exposes server features through JSON-RPC. The features builders usually care about are:

  • Tools: callable functions such as search_flights, query_db, or create_ticket.
  • Resources: readable context such as files, rows, documents, or URLs.
  • Prompts: reusable prompt templates that a client can offer to a user or model.

In The Spawn index, many callable agent services start with tools. That is a reasonable first version. Resources and prompts become useful when the client needs inspectable context or repeatable workflows instead of another action.

A basic tools/list response looks like this:

{
  "jsonrpc": "2.0",
  "id": 1,
  "result": {
    "tools": [
      {
        "name": "search_flights",
        "description": "Find flights between two cities",
        "inputSchema": {
          "type": "object",
          "properties": {
            "from": { "type": "string" },
            "to": { "type": "string" }
          }
        }
      }
    ]
  }
}

The model or host application chooses a tool, sends tools/call, and receives the result. The MCP server should not need extra planning just to answer that request. It can call an API, read a database, transform data, or return an error with enough structure for the client to recover.

Remote MCP has one client detail worth getting right early. The current Streamable HTTP transport starts with initialize. When a server returns an Mcp-Session-Id, the client must send that header on later requests to the same endpoint. Clients should also send MCP-Protocol-Version on later HTTP requests when the transport expects it. A cold tools/list against a server that expects initialization often fails with an HTTP error that looks unrelated to the real problem.

The practical client sequence is:

  1. POST initialize to the MCP endpoint.
  2. Store Mcp-Session-Id when the response includes it.
  3. Send the session header on later requests, then request tools/list.
  4. Inspect the schema before calling a tool.
  5. Call one safe tool before trusting the server.

The last step is not optional for quality scoring. A server that lists tools but fails every call is not usable, even if the metadata looks polished.

A2A, Concretely

A2A is built for agent-to-agent work. An A2A server publishes an Agent Card that describes identity, capabilities, skills, endpoint URLs, and authentication requirements. The standard discovery location is /.well-known/agent-card.json.

An A2A Agent Card is a machine-readable JSON document that tells a caller who the remote agent is, what skills it offers, where to send work, and which auth requirements apply.

A minimal card shape looks like this:

{
  "name": "ResearchAgent",
  "description": "Runs research tasks and returns a report.",
  "url": "https://example.com/a2a",
  "skills": [
    {
      "id": "research",
      "name": "Research",
      "description": "Investigate a topic and return sourced findings."
    }
  ]
}

The important object is the skill. A caller selects a skill and sends a message. The remote agent can return a direct message or create a task. Tasks can move through states, emit streaming updates, ask for more input, and produce artifacts. That is the part MCP does not try to model as its center of gravity.

Version handling is the sharp edge. Public A2A implementations do not all expose the same binding shape. Some use JSON-RPC methods such as message/send and message/stream. Newer specification material also describes core operations such as SendMessage and SendStreamingMessage, with protocol bindings for JSON-RPC, HTTP+JSON, and gRPC. Keep method selection inside a version adapter so product code does not depend on one spelling.

A JSON-RPC send request in the v0.3 family looks like this:

curl -X POST https://example.com/a2a \
  -H "Content-Type: application/json" \
  -H "A2A-Version: 0.3" \
  -d '{
    "jsonrpc": "2.0",
    "id": 1,
    "method": "message/send",
    "params": {
      "message": {
        "role": "user",
        "messageId": "9f8b5b9a-1f16-4b7b-80d8-9d0c6327b6d7",
        "parts": [
          { "kind": "text", "text": "Research solid-state battery patent filings." }
        ]
      }
    }
  }'

A current client should read the card, choose the intended binding, call the method or endpoint for that binding, and handle method-not-found as a compatibility signal. It should not assume that an Agent Card alone proves the agent can complete a task.

Which One To Use

Choose MCP for capabilities that an AI client should call directly. Good examples include search, enrichment, file operations, database queries, quote generation, calendar actions, and payment preparation. The server can be stateful behind the scenes, but the protocol interaction is still a tool call from the client's point of view.

A2A fits delegated work: a research agent that prepares a report, a risk agent that reviews a proposed trade, a support agent that handles a case, or a deployment agent that runs a checklist and returns a handoff. The remote side owns enough of the work that the caller needs task state, status updates, artifacts, or follow-up messages.

The shortest rule is: MCP when the remote side should execute a capability, A2A when it should own a task.

When Both Make Sense

Many agents should expose both protocols.

A research agent might accept delegated jobs through A2A while using MCP tools internally for search, retrieval, browser automation, and database access. In that design, A2A is the external contract for other agents, and MCP is how the research agent reaches its own tools.

The same service can also expose selected functions as MCP tools for direct use by Claude, Cursor, Codex, or another MCP-capable client. That gives builders two entry points into the same underlying system:

  • an MCP endpoint for direct calls from an AI application;
  • an A2A endpoint for callers that want task ownership and progress.

This is not duplicate product work when the schemas are designed around the same core operations. It is usually routing, auth, request validation, and response shaping.

Field Notes From Indexing Agents

The same problems repeat across agent endpoints, regardless of protocol.

Metadata is not execution proof. An MCP tools/list response and an A2A Agent Card are both declarations. They become useful only after a real invocation succeeds. The Spawn quality checks are built around that idea: discover, initialize when needed, call a safe endpoint, decode the response, and record what actually happened.

Session handling changes reliability. MCP Streamable HTTP can require Mcp-Session-Id after initialization. A2A tasks can carry taskId and contextId. Store those identifiers by endpoint and task instead of treating every request as new.

Payment state must survive the next turn. Paid-tool gates such as x402 need payment proof, tool result, and transaction reference in conversation state. Otherwise a later turn can repeat the paid call because the agent no longer has the receipt in context.

Protocol errors need adapter code, not special cases in the product flow. Put MCP transport setup, A2A version selection, method fallback, and response normalization behind small adapters. The rest of the application should receive the same internal shape whether the remote server spoke MCP, A2A, or plain HTTP.

Free public endpoints are dependencies with weak promises. Expect rate limits, timeouts, wrong content types, stale cards, and partial implementations. Use short timeouts, bounded retries, and visible failure states.

The Practical Recommendation

Ship MCP first when the value of your service is a set of actions or data sources that an AI client can call. Make tools/list clear, keep argument schemas tight, and verify at least one safe tools/call path in CI or a smoke test.

Ship A2A first when your service is itself an agent that accepts delegated work. Publish a valid Agent Card, keep skills concrete, implement a real send path, and return task state or artifacts that another agent can use without reading your landing page.

Ship both when the same agent has two audiences: AI clients that need tools and agents that need delegation. Keep the shared business logic underneath the protocol adapters so the two endpoints do not drift.

The protocol choice is not the product. The product is whether another caller can reach your endpoint, understand what it offers, invoke it safely, and get a result worth using.

For the instruction-package side of the decision, read Claude Skills vs MCP. That article covers the difference between giving an assistant access and giving it a repeatable method.

FAQ

Is MCP only for tools?

MCP also supports resources and prompts. Tools are often the first thing builders expose because they map cleanly to actions such as search, create, enrich, or quote.

Is A2A only for long-running jobs?

A2A can return a direct message, but its design becomes most useful when the remote agent needs task state, streaming updates, artifacts, or follow-up interaction.

Should an ERC-8004 agent declare MCP, A2A, or both?

Declare only the protocols that work today. If your service has direct callable functions, declare MCP. If it accepts delegated work as an agent, declare A2A. If it exposes both, register both service entries and verify both endpoints before promoting the card.