You can build an agent. You can give it tools. You can even build a team of agents that work together. But what happens when your agent needs to use a tool built by someone else? Or when your agent needs to collaborate with an agent built by a different team, at a different company, using a different framework?
Without standards, you end up writing custom integration code for every combination. That does not scale.
This lesson covers two open protocols that solve this problem: the Model Context Protocol (MCP) for connecting agents to tools and data, and the Agent-to-Agent Protocol (A2A) for enabling agents to collaborate across organizations and vendors. Together, they form the communication layer of the modern agent ecosystem.
Imagine you have 5 agent frameworks and 10 tools. Without a standard protocol, each framework needs a custom connector for each tool. That is 5 x 10 = 50 custom integrations.
Now add 5 more tools. You need 25 more integrations. Add another framework and you need 15 more. The cost grows multiplicatively.
Without a standard protocol:
Agent A ---custom---> Tool 1
Agent A ---custom---> Tool 2
Agent A ---custom---> Tool 3
Agent B ---custom---> Tool 1
Agent B ---custom---> Tool 2
Agent B ---custom---> Tool 3
...
(N agents x M tools = N*M integrations)
With a standard protocol:
Agent A ---\ /--> Tool 1
Agent B -----> [Protocol] ---+--> Tool 2
Agent C ---/ \--> Tool 3
(N + M integrations)
This is the same problem that USB solved for hardware. Before USB, every device had a proprietary connector. Printers needed parallel ports. Keyboards needed PS/2. Cameras needed serial cables. USB gave everyone a common interface, and the ecosystem exploded.
Protocols do the same thing for agents.
Agents need to communicate in two fundamentally different ways:
Agent to Tool: “Call this function with these parameters and give me the result.” This is structured, specific, and synchronous. MCP handles this.
Agent to Agent: “I need help with this goal. Figure out how to accomplish it and let me know when you are done.” This is open-ended, goal-oriented, and potentially asynchronous. A2A handles this.
Understanding this distinction is key to understanding why we need two protocols, not one.
MCP is an open standard for connecting language models and agents to external tools and data sources. Originally created by Anthropic and now widely adopted across the industry, MCP provides a universal interface between AI applications and the services they need to access.
Think of MCP as a universal adapter for AI tools. Just as a USB port lets you plug any USB device into any computer, MCP lets any agent use any MCP-compatible tool without custom integration code.
MCP uses a three-part architecture:
+------------------+
| Host | (Your AI application - IDE, chatbot, agent)
| +------------+ |
| | Client | | (MCP client - manages connections to servers)
| +-----+------+ |
+---------|---------+
|
MCP Protocol
(JSON-RPC)
|
+---------|---------+
| Server | (MCP server - wraps a tool or data source)
| +------------+ |
| | Tool/Data | | (The actual capability - database, API, file system)
| +------------+ |
+-------------------+
Host: The application the user interacts with. This could be an IDE like VS Code, a chat interface, or your agent application. The host contains one or more MCP clients.
Client: The MCP client lives inside the host and manages connections to MCP servers. It handles protocol negotiation, message routing, and connection lifecycle. A single client can connect to multiple servers.
Server: An MCP server wraps a specific tool or data source and exposes it through the MCP protocol. There are servers for databases, file systems, APIs, SaaS products, and more. Anyone can build an MCP server.
MCP defines three core primitives that servers can expose:
| Primitive | What It Is | Direction | Example |
|---|---|---|---|
| Tools | Functions the model can call | Model invokes, server executes | search_database(query), send_email(to, body) |
| Resources | Data the model can read | Model requests, server provides | File contents, database records, API responses |
| Prompts | Template interactions | Server provides, user selects | “Summarize this document”, “Debug this error” |
Tools are the most commonly used primitive. They work just like the function tools we covered in Lesson 3, but with a standardized interface that works across any MCP-compatible agent.
Resources provide context to the model without requiring a function call. Think of them as read-only data sources the model can reference.
Prompts are pre-built interaction templates that a server can offer. They help users discover what the server can do.
Without MCP, connecting an agent to a new data source looks like this:
With MCP, it looks like this:
The MCP server handles authentication, request formatting, error handling, and schema definition. Your agent just needs to speak MCP.
Write once, use everywhere. A tool built as an MCP server works with any MCP-compatible agent - ADK, Claude, Cursor, or any other host.
Dynamic tool discovery. Agents can discover what tools are available at runtime instead of having everything hardcoded. Connect to a new MCP server and your agent automatically gains new capabilities.
Ecosystem leverage. There are hundreds of community-built MCP servers for popular services. Need to connect to GitHub? Slack? A PostgreSQL database? There is probably an MCP server for it already.
Separation of concerns. Tool builders focus on their tool. Agent builders focus on their agent. The protocol handles the interface between them.
ADK has built-in support for MCP. You can connect to any MCP server and use its tools as if they were native ADK tools.
from google.adk.agents import Agent
from google.adk.tools.mcp_tool import MCPToolset, SseServerParams
# Connect to an MCP server
mcp_tools = MCPToolset(
connection_params=SseServerParams(
url="http://localhost:3000/mcp",
)
)
agent = Agent(
name="mcp_agent",
model="gemini-2.0-flash",
instruction="You are a helpful assistant with access to external tools.",
tools=[mcp_tools],
)
The agent discovers the available tools from the MCP server at runtime. If the server exposes a search_database tool and a create_ticket tool, your agent can use both without any additional code.
Learn more: MCP Tools in ADK
MCP is powerful, but it comes with trade-offs you should understand:
Tool shadowing. If two MCP servers expose tools with similar names or descriptions, the model might get confused about which one to call. Be deliberate about which servers you connect and check for naming conflicts.
Context window bloat. Every connected MCP server adds tool definitions to the context window. Connect too many servers and you eat into the space available for actual conversation. Each tool definition typically consumes 100-500 tokens.
No native scope limiting. MCP does not have built-in fine-grained permission controls. If your agent connects to a database MCP server, it can potentially access any data that server exposes. You need to handle authorization at the server level or through guardrails.
Trust and supply chain. Community-built MCP servers are third-party code that your agent executes. Treat them with the same caution you would treat any open-source dependency. Review the code, check the maintainer, and run in sandboxed environments.
Latency. Every MCP tool call involves network communication with the MCP server. For time-sensitive applications, factor in this overhead.
| Consideration | Risk | Mitigation |
|---|---|---|
| Tool shadowing | Model calls wrong tool | Audit tool names, limit connected servers |
| Context bloat | Reduced reasoning quality | Connect only needed servers |
| No scope limits | Overly broad data access | Server-side auth, guardrails |
| Supply chain | Malicious or buggy servers | Code review, sandboxing |
| Latency | Slow tool responses | Local servers, caching |
A2A is an open protocol developed by Google for enabling agents to discover, communicate with, and delegate tasks to other agents - even agents built by different teams using different frameworks at different organizations.
While MCP handles the “agent talks to tool” problem, A2A handles the “agent talks to agent” problem.
Think about how professionals collaborate in the real world. When you need legal advice, you do not become a lawyer. You find a qualified lawyer, explain what you need, and they handle it.
How do you find that lawyer?
A2A works the same way for agents:
An Agent Card is like a business card for an agent. It is a standardized JSON document that describes what the agent can do, how to communicate with it, and what authentication it requires.
{
"name": "Travel Booking Agent",
"description": "Books flights and hotels based on travel requirements",
"url": "https://travel-agent.example.com/a2a",
"capabilities": {
"streaming": true,
"pushNotifications": true
},
"skills": [
{
"id": "book_flight",
"name": "Book Flight",
"description": "Search and book flights between cities"
},
{
"id": "book_hotel",
"name": "Book Hotel",
"description": "Find and reserve hotel rooms"
}
],
"authentication": {
"schemes": ["oauth2"]
}
}
Agent Cards are hosted at a well-known URL (typically /.well-known/agent.json), making discovery straightforward. Your agent can check a known endpoint to see what another agent offers.
A task is the fundamental unit of work in A2A. When one agent wants another agent to do something, it creates a task:
Artifacts are the outputs of a task. They can be text, files, structured data, or any other content the working agent produces.
A2A supports real-time communication through Server-Sent Events (SSE). This lets agents stream progress updates rather than waiting for the entire task to complete. This is especially important for long-running tasks where the calling agent (or a human) wants to see intermediate progress.
You might wonder: why not just call another agent’s API directly? You could, but you would face the same N x M problem we discussed earlier. A2A gives you:
This is one of the most important distinctions to understand:
| Aspect | MCP | A2A |
|---|---|---|
| What talks | Agent to tool | Agent to agent |
| Communication style | “Do this specific thing” | “Achieve this goal” |
| Complexity of request | Single function call | Open-ended task |
| Intelligence on other side | Tool (no reasoning) | Agent (has reasoning) |
| Example | “Query this database” | “Research this topic and write a report” |
| Analogy | Using a calculator | Hiring a consultant |
MCP is for tools. You know exactly what function you want to call and what parameters to pass. The tool executes and returns a result. There is no reasoning on the other side.
A2A is for agents. You describe a goal and let the other agent figure out how to accomplish it. The other agent has its own reasoning, its own tools, and its own approach.
A practical example: Suppose you are building a travel planning agent.
Learn more: A2A in ADK and A2A Protocol Spec
MCP and A2A are not competing standards. They operate at different layers and complement each other.
+---------------------------------------------+
| Your Agent |
| |
| "I need to book a trip to Tokyo" |
| |
| +-------------------+ +----------------+ |
| | MCP Client | | A2A Client | |
| | (talks to tools) | | (talks to | |
| | | | other agents) | |
| +--------+----------+ +-------+--------+ |
+-----------|-----------------------|----------+
| |
+-------v--------+ +-------v--------+
| MCP Servers | | Remote Agents |
| | | |
| - Flight API | | - Hotel Agent |
| - Weather API | | - Budget Agent |
| - Calendar | | - Review Agent |
+--+---------+----+ +---+--------+---+
| | | |
v v v v
[Flight [Weather [Hotel [Budget
Data] Data] Booking] Analysis]
Think of it as layers:
Tool layer (MCP): Your agent connects to specific data sources and APIs through MCP servers. This gives it access to raw capabilities - search databases, call APIs, read files.
Agent layer (A2A): Your agent collaborates with other agents that have their own tools, reasoning, and expertise. This gives it access to higher-level capabilities - tasks that require judgment, planning, and multi-step execution.
Orchestration layer (your agent): Your agent decides when to use a tool directly (MCP) and when to delegate to another agent (A2A) based on the task at hand.
A user asks your travel agent: “Plan a 3-day trip to Tokyo next month within a $3000 budget.”
Your agent might:
Notice the pattern: MCP for specific data retrieval, A2A for tasks requiring another agent’s expertise and judgment.
You know how different countries have different electrical outlets? If you travel from the US to the UK, your laptop charger will not fit. You need an adapter.
MCP is that adapter for AI agents. Every tool used to have its own proprietary plug (custom API integration). MCP gives everyone a universal outlet. Plug any tool into MCP, and any agent can use it.
The tool itself does not get smarter. A power adapter does not make your laptop faster. But it makes your laptop usable in places it could not work before. Same with MCP - it makes tools accessible to agents that could not reach them before.
Now imagine you are working on a big project at a company. You handle the engineering, but you need marketing materials. You do not learn marketing yourself. You call your coworker in the marketing department.
You say: “We are launching the new API next Tuesday. Can you put together a launch blog post and social media plan?”
Your coworker says: “Sure, I will draft something and send you updates as I go.”
A2A is that phone call. One agent (you) calls another agent (marketing) with a goal. The other agent uses their own skills and tools to accomplish it. They send updates along the way. And they deliver the finished work when it is done.
You did not need to know what tools marketing uses. You did not need to understand their process. You just needed to describe what you wanted and trust them to figure it out.
Going back to the coworker analogy:
You need both. Some things you do yourself with your tools. Other things you ask a specialist to handle.
Both protocols benefit from a layered security approach:
MCP has seen rapid adoption since its introduction. The ecosystem includes:
A2A is newer and the ecosystem is still developing:
Both protocols are actively evolving. Expect to see:
Protocols solve the N x M integration problem. Without standards, every agent-tool and agent-agent combination needs custom code. MCP and A2A replace that with universal interfaces.
MCP connects agents to tools. It is a universal adapter that lets any agent use any MCP-compatible tool. Think USB for AI.
A2A connects agents to agents. It enables agents to discover, communicate with, and delegate tasks to other agents across organizations and frameworks.
MCP and A2A complement each other. MCP operates at the tool layer (specific function calls). A2A operates at the agent layer (goal-oriented tasks). Use both together for maximum flexibility.
Security requires attention at both layers. Verify identities, minimize data sharing, validate results, and log everything.
You have covered the fundamentals and the building blocks. In the final lesson, we will step back and look at the big picture - where to go from here, what resources to explore, and how to continue growing as an agent builder.