19 min

Agent Protocols: MCP vs A2A

Where each protocol fits, what agent cards and tasks standardize, and how to secure cross-boundary calls.

Lesson 6 of 9

0 done

In plain English

MCP connects an agent to tools. A2A connects an agent to other agents, even from other companies. If two parts live in one program, just call a function. Use a protocol only when parts are separate services, and always check who may call what.

A2A: A standard way for agents to talk to other agents.
Agent card: A short public description of what an agent can do.
Authentication: Proving who is calling.

Picture it

Which protocol?

If both parts live in one program, just call a function. Always check who may call what.

MCP

Connects an agent to tools
Like a plug for apps and data

A2A

Connects an agent to other agents
Even agents from other companies

So far the agents we have orchestrated lived in one codebase and talked through function calls. As agent systems spread across teams, vendors and companies, they need a standard way to find each other, describe what they can do and swap work. Two protocols have appeared. Knowing which one solves which problem will save you from over-building.

MCP and A2A: up and down, or side to side

MCP (Model Context Protocol) connects an agent to tools and data, such as databases, file systems and software services. Think vertical: agent to ability. You met it in the engineer path.
A2A (Agent2Agent protocol) was introduced by Google and is now an open project. It connects agents to other agents, even agents built with other frameworks by other vendors. Think horizontal: agent to agent.

They work together. They do not compete. A remote travel agent might offer itself through A2A, so other agents can hand trips to it. Inside, it might use MCP to reach flight and hotel services. A handy rule: if you would call it like a function and it answers quickly, it is a tool (MCP). If you would hand it over like a task to a colleague who may think for a while, ask questions and report back, it is an agent (A2A).

What A2A standardizes

Discovery: an agent card, which is a JSON document at a well-known web address. It describes the agent's name, address, skills, supported formats and how to log in.
Tasks: a unit of handed-over work with a life cycle, with states such as submitted, working, input-required, completed, failed and canceled. So long and slow work is a first-class case.
Messages and results: structured parts, such as text, files and data, that are swapped during the task, and the results it produces.
Streaming and push: progress updates over a streaming connection, and webhooks for tasks that outlive a connection.

agent-card.json (simplified)

{
  "name": "Contract Review Agent",
  "description": "Reviews vendor contracts and flags non-standard clauses.",
  "url": "https://agents.example.com/contract-review",
  "version": "1.2.0",
  "capabilities": { "streaming": true, "pushNotifications": true },
  "authentication": { "schemes": ["oauth2"] },
  "skills": [
    {
      "id": "flag-risky-clauses",
      "name": "Flag risky clauses",
      "description": "Given a PDF contract, returns a ranked list of clauses that deviate from our standard terms.",
      "inputModes": ["application/pdf"],
      "outputModes": ["application/json"]
    }
  ]
}

→The details are still changing. Treat the field names above as examples, and read the current A2A specification before you build. The ideas are the stable part: the agent card, the task life cycle and the results.

When a protocol is too much

Do not put a network protocol between two agents that live in the same process. Hand-offs inside a process, shared state and plain function calls are faster, simpler, easier to trace and easier to secure. Reach for A2A-style connections when agents belong to different teams or vendors, run as separate services, use different frameworks, or must be findable and deployable on their own. A useful middle path: design your internal agent boundaries as if they were remote. Give them clear input and output schemas and clear task states. Then you can turn one into a service later without a rewrite.

The agent-as-tool pattern

Many frameworks let you wrap a whole agent as a tool that another agent can call. This gives the caller a clean, narrow interface, from an input schema to an output schema. It hides the sub-agent's own prompts and tool use. It is the simplest way to build a hierarchy, and it fits well with MCP: offer the sub-agent through an MCP server, and any MCP-ready client can use it. The cost is that the caller sees only the final answer. So you need good tracing to see what happened inside.

Trust, logins and blast radius

Authenticate every remote agent, and give permission skill by skill. Can call flag-risky-clauses is not the same as can call anything.
Use short-lived, narrowly scoped credentials. Pass the end user's identity through, which is called delegation. Do not let agents share one master key.
Treat every remote agent's output as untrusted input. It can carry prompt injection, just like a web page.
Set timeouts, budgets and rate limits on calls that cross a boundary. A slow or hostile remote agent should not be able to stall yours.
Log every call between agents, with the caller, the callee, the task ID and the outcome, for audits.

Key takeaways

✓MCP connects an agent to tools and data. A2A connects agent to agent. They complement each other.
✓A2A standardizes discovery (agent cards), long-running tasks, messages and results, and streaming and push.
✓Do not add a network protocol inside one process. But design your boundaries so that turning one into a service is cheap.
✓Calls across a boundary need logins, scoped credentials, budgets and care with untrusted output.

Hands-on exercise

Write an agent card for your own agent

Choose one agent, real or imagined, from your work. Write an agent card for it with two or three skills.
For each skill, define the input and output schemas and the task states it can be in.
List who may call each skill, and what credentials they would need.
Decide: should this be a function in the same process, an MCP tool or a remote A2A agent? Justify it in two sentences.

Check yourself

Q1A flight search that answers in under a second: is it an MCP tool or an A2A agent?show answer

An MCP tool. It is a fast, function-like ability. A2A suits handed-over tasks that may be long, interactive and agent-driven.

Q2Why should two agents in the same process not talk over a network protocol?show answer

It adds delay, ways to fail and security risk for no benefit. Calls in the process and shared state are simpler and easier to trace.

Q3What should you do with output from a remote agent before acting on it?show answer

Treat it as untrusted input. Check it against a schema, clean it, and never let it act as instructions to your own agent.

← Shared State, Memory & Durable Execution Failure Modes & Reliability →