How Do MCP and A2A Work Together in Agents?

MCP and A2A are often framed as rivals, but they were designed for different jobs. MCP is the agent-to-tool contract; A2A is the agent-to-agent contract. Confusing them leads to tool servers being asked to do discovery and coordination work they were never built for.

What MCP and A2A Each Solve

MCP and A2A solve two different connection problems in agent systems: MCP is the agent-to-tool layer and A2A is the agent-to-agent layer. MCP, released by Anthropic November 2024, standardizes how one AI agent connects to databases, APIs, files and services (Model Context Protocol). A2A, announced by Google in April 2025 with later contributions from other partners, standardizes how independent agents discover each other, exchange tasks and report status (A2A protocol on GitHub).

The distinction matters because a tool call and a delegation are different operations. When your assistant agent asks an airline's agent for flight availability, no shared database or SDK is required; the two agents negotiate over a protocol. That is A2A's job. When the same assistant needs to read a balance from a core banking system, that is MCP's job. In 2025 Google donated A2A stewardship to the Linux Foundation, placing it under neutral governance alongside other open standards.

	MCP	A2A
Connection type	Agent to tools, data, prompts	Agent to agent
Introduced by	Anthropic, November 2024	Google, April 2025
Typical question	Which tool should I call?	Which agent should handle this task?
Analogy	POST/GET endpoints on a server	Departments exchanging structured referrals
Governance	Open standard	Open source, Linux Foundation since 2025

A concrete framing from the walkthrough: without A2A, an emergency-room doctor phones radiology, explains the case verbally, then repeats everything to surgery. With A2A, every department publishes a standardized capability card, the ER sends a structured referral, and progress updates flow back over the same channel. Same people, same departments, one shared contract.

The airline example shows the delegation chain end to end. Your personal assistant connects to an airline's agent to ask about availability, price and schedule, then to a hotel chain's agent for rooms. If a booking follows, the airline agent itself talks to a payment gateway agent (Stripe, Razorpay and similar services are all shipping agents), which returns a QR code or payment link. Every hop is agent to agent; none of them share a database.

How A2A Works: Agent Cards, Tasks and Executors

A2A uses a client-server shape plus a discovery document. The client agent initiates a request; the remote agent receives it, processes it as a task, and responds with status updates. Before any request happens, each agent publishes an agent card, a JSON metadata file served at a well-known path (.well-known/agent. in the version used in the lab), which works like a robots.txt for agents. Four fields do most of the work: the agent's skills, its capabilities such as streaming or push notifications, the URL where it is hosted, and default input/output modes.

The skills and tags on a card are what make automated delegation possible. A coordinator agent can fetch cards from many agents, read each skill list and tag set, and decide which agent to hand a task to without any hard-coded routing rules.

Tasks carry a lifecycle: submitted, working, input-required, completed, failed or canceled. Lifecycle reporting is what lets a client agent answer 'where is my request?' at any moment instead of waiting blind.

On the server side, the lab implements an AgentExecutor that subclasses the SDK's base executor and supplies two methods: execute, which reads user input from the context and pushes results onto an event queue, and cancel. Because the executor handles the protocol plumbing, including HTTP, JSON-RPC and task lifecycle, the agent logic inside stays framework-agnostic; the same contract works whether the internals come from LangGraph, CrewAI, AutoGen or Google's ADK.

Building a Banking MCP Server With FastMCP

FastMCP, the Python framework used to build MCP servers in this lab, turns any plain Python function into an MCP-compliant tool via a decorator. According to the walkthrough, FastMCP powers more than 70% of MCP servers available today; treat that as a vendor-reported adoption figure rather than an independent count (FastMCP docs).

The lab models HDFC Bank account services with four tools: get customer info, get recent transactions, flag a suspicious transaction, and check loan eligibility. Data lives in simulated dictionaries standing in for SQL tables, with realistic Indian banking fields such as CIBIL scores, UPI transactions and EMIs. The @mcp.tool decorator handles schema generation, validation and JSON-RPC compliance, and the function's docstring becomes the tool description that models read when deciding when to call it.

Server-assigned fields show where real banking logic would live. When a suspicious transaction is flagged, the customer supplies the description and reason, but the alert ID, status, priority and timestamp come back from the server. When a loan check runs for customer 001, Priya Sharma, with a CIBIL score of 810, the eligibility verdict comes back as a structured decline; the reason string in the demo is hard-coded, a shortcut the walkthrough openly flags.

The client side needs no hard-coded knowledge of the tools. It opens an async connection, calls list_tools, and discovers all four automatically. In the notebook, client and server share one machine (Google Colab), so the transport is stdio; in production the same client would point at an HTTPS MCP server URL, the way Zerodha's Kite MCP server or an AWS MCP server exposes a URL. In-memory connection is ideal for testing because there is no networking to configure.

Resources and Prompts: The MCP Primitives Most People Skip

Tools are only one of three MCP primitives, and the other two are the ones most engineers never use. Resources are read-only data loaded into the AI context, analogous to GET endpoints, and prompts are reusable message templates declared with @mcp.prompt. A complete MCP server uses all three, and the walkthrough's health-insurance server demonstrates the full set.

The lab's second server, modeled on a health-insurance scenario, wires the primitives together: read the policy as a resource (sum insured, premium, network of 12,000 cashless hospitals, no-claim-bonus status), read the claim history as a resource, populate the analysis prompt with the claim and policy IDs, then call the submit-claim tool, which generates a claim ID and returns server-assigned status and priority fields. The renewal prompt applies the NCB logic: no claims in the previous financial year earns a 20% no-claim bonus, while any claim forfeits it.

The rule of thumb from the walkthrough: tools are actions (POST-like), resources are reads (GET-like), and prompts are templates. Each primitive has its own decorator (@mcp.tool, @mcp.resource, @mcp.prompt), and mixing them is how a server stops being a bag of endpoints and becomes a usable context source.

Wiring MCP Tools to OpenAI Function Calling

An MCP server becomes an AI assistant once its tool metadata is converted into a function-calling schema. The lab builds schemas from each tool's name, description and input types, then binds them to an OpenAI chat completion request with tool_choice set to auto, so the model decides which tool to invoke (OpenAI function calling guide).

The loop runs in four steps:

1. The model returns a list of tool calls with function names and JSON-formatted arguments.
2. The client executes each call over MCP using call_tool, passing the arguments as JSON-RPC input.
3. Each result is serialized back into the message history with JSON.dumps.
4. The model receives the updated history and produces the final natural-language answer.

Asked for account details and recent transactions, the assistant calls two MCP tools in sequence and formats the results in INR without any hard-coded routing.

The same flow is repeated with a Llama 3.3 70B model served through Groq, showing the integration is provider-independent. The speaker notes this is one reason he skipped LangChain here: direct OpenAI and Groq clients keep the protocol layer visible, though LangChain can be substituted when you want built-in tracing.

The Hospital Multi-Agent System: Three Agents, Zero Hard Coding

The A2A lab builds a hospital network with three specialized agents: a triage agent that classifies patient urgency, a diagnosis agent that produces a ranked differential diagnosis, and a billing agent that handles insurance claims and pre-authorization. Each agent defines its own card with skills, tags, URL, version and default modes, then runs behind an A2A Starlette application launched in a background thread.

Discovery happens through the agent cards: a client fetches the card over httpx, learns the agent's skills and endpoint, then sends a JSON-RPC message/send request. The lab tests three patient cases end to end. Chest pain with sweating routes to emergency cardiology with a possible acute myocardial infarction noted in the reasoning; a mild headache in a 25-year-old routes to routine general medicine; an 8-year-old's high fever routes to pediatrics. Every classification comes from the model, and the handoff logic reads the cards rather than hard-coded rules.

One commenter on the video, Gustavo dev doido, asked how these patterns hold up outside simulated dictionaries. The honest answer from the lab itself: the protocol plumbing is production-shaped, but the data layer is demo data, so real deployments would swap the dictionaries for actual databases and add the security work described below. Note also that the agents' localhost URLs are only reachable from the machine running the server; from your own laptop they resolve, but from outside Colab they do not.

The Combined Enterprise Pattern: MCP for Depth, A2A for Breadth

The final lab combines both protocols in an e-commerce coordinator: MCP goes deep into one agent's tools, A2A spreads work laterally across agents. An MCP server exposes inventory, order-tracking, refund and catalog tools. Specialized agents (order, inventory, returns) use MCP to reach those tools and A2A to coordinate with each other. An LLM-powered coordinator agent routes customer queries: 'where is my order' triggers the order agent, a stock question hits the inventory tool, and a shoe return request activates the returns agent, which initiates the return and schedules pickup.

The integration-count argument makes the case for standardization: without shared protocols, every model must integrate with every tool, an N-times-M problem. With MCP, it becomes N plus M standardized connections.

The speaker's own cost tally for the demo runs (attributed to the walkthrough, not an independent benchmark) compared the MCP plus OpenAI chain at two tool calls and about 600 total tokens against the A2A triage flow at three LLM calls on a cheaper model. The A2A path came out roughly $0.02 cheaper per run on those small token volumes, a saving of about 0.02 dollars that only matters because the triage model itself costs less per call.

Security deserves its own checklist before any of this ships. The lab calls out prompt injection, permission scoping, tool poisoning and consent requirements, which matter most when you write server-level tool code that a model can invoke. A demo with simulated data has none of these controls in place. The lab also sketches reusable patterns worth copying: domain-organized MCP servers (a bank splitting tools across retail banking, loans and fraud detection) and A2A discovery registries that index agents by skill tags.

FAQ

• Do MCP and A2A compete with each other? No. MCP solves the agent-to-tool problem and A2A solves the agent-to-agent problem. In the combined e-commerce lab, agents use MCP to reach tools and A2A to delegate to each other in the same architecture.

• Do agents built with different frameworks interoperate over A2A? Yes, that is the design goal. A2A sits outside the framework, so an agent built with LangGraph, CrewAI, AutoGen or Google's ADK can talk to any other as long as both implement the protocol, which the executor pattern in the lab demonstrates.

• Why does a docstring matter when building MCP tools? FastMCP turns each function's docstring into the tool description. Models read that description to decide which tool to call and when, so vague docstrings produce unreliable tool selection.

• Can I run this lab locally instead of Google Colab? Yes. The notebook patches nested async loops for Colab and Jupyter; in VS Code the asyncio handling differs and the patch may be unnecessary. Local execution also makes the agents' localhost URLs reachable from your own machine, which they are not from outside Colab.

From Watched Video to Written Reference

The core lesson here is that coordination is a protocol problem, not a prompting problem: once triage, diagnosis and billing each publish their capabilities, the handoffs write themselves. This article compresses a 71-minute lab full of protocol details, diagrams and runnable code, the kind of knowledge that usually stays trapped in a video nobody can search or cite. It comes from a channel whose academy reports having helped over 46,000 IT professionals move into AI, data and cloud roles, which is to say the material was built for practitioners, not tourists.

If you have recordings like this one, the knowledge inside them deserves the same treatment: transcribed, structured and published where your team can look it up.

Skala Blog turns a YouTube video into a structured, publishable article: paste the URL, the video is transcribed, and the transcript becomes a written reference your team can actually look up. It is the same move this lab makes, turning ad hoc verbal coordination into a durable, discoverable contract.

Source video