The A2A protocol vs MCP choice is simple to state: use MCP for tools and A2A for other agents. A2A defines an Agent Card at a well-known URL, OAuth-style authentication, a task with an ID and lifecycle, and JSON-RPC 2.0 messages. That combination lets a travel planner delegate flight and hotel work without rebuilding those agents.
Part 2 of a series, after MCP vs A2A: Agent Protocol Layers Explained.
A2A protocol vs MCP: tools or teammates?
The A2A protocol vs MCP distinction is a matter of relationship: MCP connects an agent to tools and data, while A2A connects an agent to other agents that may belong to a different organization. The Agent2Agent (A2A) protocol sets out how one agent discovers another, authenticates with it, sends a task and receives results.
The Model Context Protocol (MCP) is an open standard that exposes tools, resources and prompts to a model or agent. In the video's travel example, an MCP tool could search flights, but the planner's developer would still write that tool, manage its prompts and operate the search flow. With A2A, the airline's own agent occupies that slot instead.
That split is worth keeping straight when the two protocols appear in one stack. A planner can call MCP tools for its own local work and use A2A for work owned by a partner. The protocols answer different design questions, so a system can sit on both. As the video puts it: MCP is for tools, A2A is for agents, and most systems end up using both.
| Question | MCP | A2A |
|---|---|---|
| What it connects | Agent to tools, resources, prompts | Agent to another agent |
| Who owns the far side | You, the developer | A partner or vendor |
| What you write | The tool code and its prompts | A client that reads a card and sends tasks |
| Message format | Tool-call protocol of the host agent | JSON-RPC 2.0 over HTTP |
| Discovery | Configured into the host | Agent Card at a well-known URL |
| Failure mode | Your tool breaks | A remote service changes or goes down |
The trade-off is operational. A partner agent can change its internal prompts, models or tooling without breaking the planner, because the planner relies on the card's skills, interfaces and security scheme. The planner buys that freedom by depending on a live remote service it does not control.
What is an Agent Card and where does it live?
An Agent Card is a JSON document, normally published at a well-known URL, that tells a client agent what the remote agent is called, what it can do, how to reach it and how to authenticate. The A2A specification treats this discovery document as the starting point for every interaction.
Clients look for it at /.well-known/agent-card.json under the agent's domain. That default path matters because it lets a client find the card without any private integration work. If an agent publishes its card under a bespoke path, the default does not work.
The card is not a catalogue entry for humans. It is machine-readable configuration that a client can fetch, parse and act on. The description and skill descriptions are the fields a client uses to judge whether the remote agent matches a subtask before any commitment. In the video, the description is singled out as the field that decides relevance: the client reads it to work out whether this agent is the one needed for a given task, before it looks at anything else.
The transcript describes a card containing organization and URL, a version, supported interfaces, capabilities, input and output modes, a security scheme and skills. Those field names follow the published A2A specification; the values in the video were illustrative sample data for fictional partners.
A fetched card is a snapshot. The client cached it and used it; the article does not claim whether or when the card was refreshed.
What is inside an A2A Agent Card?
An A2A Agent Card is grouped into a few practical blocks: identity, interface, capabilities, content formats, security and skills. The transcript walked through a sample airline-partner card containing all six, and the order below follows that walkthrough.
Identity fields name the agent, describe it in prose, identify the organization and give a URL and version. The description carries the most weight, according to the video, because the client reads it to decide whether the agent is relevant at all.
Interface and capability fields say how to talk to the agent and which optional features it offers. In the sample, the interface declared JSON-RPC binding with protocol version 1.0, and capabilities listed streaming and push notifications. A separate table below compares those features at a glance.
Content and security fields set accepted media types and the authentication method. The sample used text, plain text and application JSON as input modes and application JSON as output, with an OAuth security scheme under which a short-lived token is issued and used for HTTP header authentication. The video notes the security exchange is a one-time setup step: the client arranges credentials during discovery and then reuses that arrangement for later task calls.
Skills are the core of the matching logic. Each skill carries an ID, a name, a description, tags and examples. The client compares the subtask against skill descriptions because a list of skill names alone does not say enough about fit.
| Card block | What it declares | Why a client uses it |
|---|---|---|
| Identity | Name, description, organization, URL, version | Judge relevance before committing |
| Interface | Binding protocol, protocol version, target URL | Find the endpoint and the message format |
| Capabilities | Streaming, push notifications | Choose streaming or basic request-response |
| Content | Default input and output modes | Format the request correctly |
| Security | Declared scheme and credential location | Authenticate before the first task |
| Skills | Skill ID, name, description, tags, examples | Match skills to subtasks |
One travel request, five steps
The video reduces A2A handling of one travel request to five steps: discover, authenticate, send a task, stream updates, and collect the result. A planner agent receives the request, splits it into subtasks and runs each subtask against a remote agent. The steps below keep that order.
The worked example is a five-day trip. The planner decides the itinerary, and the flight search and hotel booking become subtasks that other parties' agents handle.
Step 1: Discover
The planner breaks the request into pieces and asks which agents can handle each one. Discovery means fetching an Agent Card and comparing its description and skills against the subtask. Fictional partners SkyLink and Oasis Stays are the example targets, and their cards are what the client reads. In the video the cards are described as saved at a known location, and discovery is the client searching those cards and picking the relevant one.
Step 2: Authenticate
The client uses the security scheme named on the card. In the transcript's sample that is OAuth with a short-lived token sent in an HTTP header; the protocol's framing is ordinary web security, not a bespoke login system. The client still needs credentials arranged in advance.
Step 3: Send the task
The planner sends a structured request over JSON-RPC 2.0 to the card's declared interface. Questions surface here, such as a seat preference or cabin class. The transcript depicts these as ordinary request inputs, and the planner answers from its itinerary or budget before the remote agent returns flight or hotel details. The airline agent replies with the matching flights, their prices and the rest of the requested detail, and the hotel partner runs the same exchange.
Step 4: Stream updates
If the card lists streaming as a capability, the remote agent can return interim progress while the task runs. The video did not demonstrate a stream, so the exact event sequence remains to be shown. The card is where the client confirms that streaming is a viable option.
Step 5: Get the result
The final response arrives as a task result tied to the task identity the client sent. The transcript describes one task ID with a lifecycle, which is how a long-running booking stays identifiable. There is also a provisioned push-notifications path for long jobs, though the video did not exercise one end to end.
What the planner does and does not need to know
A planner agent only needs the remote agent's declared capabilities, skills, communication endpoint and input/output formats to delegate work. Everything else, such as the remote agent's prompts, model choice and internal API calls, stays private to its owner. The transcript repeated that boundary as the point of the design.
On the planner side, that means a small set of concrete operations:
- Fetch and cache the remote Agent Card.
- Match task requirements against the card's skill descriptions.
- Authenticate with the declared security scheme before making task calls.
- Send and receive task messages in JSON-RPC 2.0.
Read those as checks against the card, not against the remote agent's internals. If the card says the agent skill is flight search, the planner can send flight-search work and expect flight results; it cannot inspect how those results were produced.
The remote side keeps its own logic behind the interface. The boundary only holds if the published skills and interfaces describe reality, so a client that matches against stale skills may send work the remote agent cannot finish.
The transcript does not claim the planner reads any other part of the remote implementation. A remote agent remains a black box behind its card and its messages.
Where gateways such as LiteLLM fit
A gateway is an optional middle layer that sits between the client agent and one or more remote agents and handles routing or credentials on their behalf. The video shows gateways sitting in the middle of the request path and mentions LiteLLM in this role, saying the next part of the series would show it live. The transcript itself does not demonstrate a working gateway setup.
LiteLLM documents a workflow for using A2A agents through its proxy, including listing agent cards through the proxy. A planner then reaches partner agents through one endpoint instead of many, and credential placement moves into the gateway configuration.
That is a deployment choice, not a requirement of A2A. The protocol defines the card, the task and the message format; it does not mandate a gateway. For a reader deciding architecture, gateways are most useful when many remote agents must be addressed by policy.
Common mistakes when reading Agent Cards
Reading an Agent Card is the easy part. Matching subtasks to the right card and doing it safely are the parts that produce mistakes, and the transcript's caveats point at a handful of recurring ones.
- Trusting the name field for relevance. The description and skill descriptions carry the matching signal, and a short name will not say enough.
- Treating the card as complete. The card is what the remote agent chose to publish, not an audit of what it can do.
- Skipping the security scheme. The scheme determines the token and the header, and the client should arrange credentials before the first task.
- Assuming streaming exists. The capability is declared, and the client should check that declaration before expecting interim updates.
- Collapsing A2A and MCP into one stack. A planner may use both, but each protocol answers a different question about tools and agents.
The video is an overview and explicitly waits for a code walkthrough. A booking process also carries commercial and regulatory weight, which is a topic for the deployment, not the protocol. The author, listed in the video metadata under the channel VisionNLP, says it was published on 23 October 2026; speakers of technical content such as Gustavo dev doido are not part of this transcript.
The safe habit is to read a card as a claim: fetch it, check the skills you need, authenticate, and verify the first result before widening the integration.
FAQ
- What is the main difference between A2A and MCP? MCP connects an agent to tools, resources and prompts, while A2A connects an agent to other agents that may belong to another organization. A2A adds discovery through Agent Cards, task identity and JSON-RPC 2.0 messaging. Most real systems use both.
- Where is an A2A Agent Card usually published? The A2A specification places the card at the well-known path
/.well-known/agent-card.jsonunder an agent's domain. The client fetches that URL to discover the agent's skills, interface and security scheme.
- What does a sample A2A Agent Card contain? The transcript's sample card contained identity and organization fields, a version, a JSON-RPC 2.0 interface at protocol version 1.0, streaming and push-notification capabilities, text and JSON content modes, an OAuth security scheme, and a set of skills with IDs, descriptions, tags and examples.
- What was the five-step A2A flow in the travel example? The planner discovered the relevant agents, authenticated with them, sent a task over JSON-RPC 2.0, received streamed updates if the capability was declared, and collected the result. The video was an introduction; its Python implementation was promised for a later episode.
- Do I have to drop MCP to use A2A? No. The video's four takeaways put it plainly: MCP is for tools, A2A is for agents, and most systems use both. A planner can search flights through an MCP tool and book them through a partner's A2A agent.
From a travel demo to a written explainer
The travel example works because each agent owns a narrow piece and publishes just enough for another agent to use it. A2A hides the prompts and tooling behind a card and a message contract, and that gap between a published interface and the machinery underneath is often the most useful part of a technical explanation.
If you already record explanations like this, the same gap exists between your video and a reader who is searching for the written version. Skalablog turns a YouTube video into a draft article from its transcript, so the explanation can live in a format people can read, quote and link.
Paste a YouTube URL into Skala Blog, review the transcription, and shape the article you want to publish.
Fork this article
Start a new branch from the same video, shaped your way. You keep the credit; the original keeps the attribution.
A fork in another language is filed as a translation of this article, so the two pages point at each other. You can unlink it later from the editor.
0/240
You are creating
- Format
- For
- Language
- Source
- Your angle
You will be asked to sign in before it is generated.
Buy credits