Ir al contenido

Analisis: Video Oficial Google — ADK + A2A + MCP

Analisis: Video Oficial Google — ADK + A2A + MCP

Sección titulada «Analisis: Video Oficial Google — ADK + A2A + MCP»

Fuente: Video oficial Google Cloud (canal Google Cloud Tech o similar) Duracion: ~15 minutos Fecha analisis: 2026-04-05


Intro — Que vamos a construir (0:00 - 2:00)

Sección titulada «Intro — Que vamos a construir (0:00 - 2:00)»

ADK, A2A, MCP. If you’re trying to build an agent, you’ve probably come across these acronyms. So, let’s cut through the noise. In the next 15 minutes, we are going to do three things: Create an MCP tool and deploy it as a server. Create an agent with ADK. And expose the agent via A2A and test it.

If you follow every step in this video, you will understand these concepts and have a working AI agent by the end of this tutorial.

First, we’ll take a look at MCP or model context protocol. You can think of this as a reverse proxy or an API server for API servers. It’s a standard way to connect your AI model to the specific resources, prompts, and tools it needs to get a job done.

Next, we’ll use Agent Development Kit or ADK. This is our framework for actually building and deploying the agent. It’s designed to make creating complex agents feel straightforward, like software development.

And finally, we’ll use the agent-to-agent protocol or A2A. Once our agent is built, A2A provides a common language that allows it to communicate and collaborate with other agents, no matter who built them, where they are hosted, or what framework or programming language they use.

By the end of this tutorial, you’ll have hands-on experience setting up a local MCP server and deploying it to the cloud. You’ll build your own agent using ADK and then use the A2A protocol to test it. To follow along, you’ll need a browser and a Google Cloud project with billing enabled. Ready? Let’s get started.

Setup — Google Cloud Environment (2:00 - 4:15)

Sección titulada «Setup — Google Cloud Environment (2:00 - 4:15)»

The first thing we need to do is set up our Google Cloud environment. If you don’t have one already, go ahead and create a new Google Cloud project and make sure that billing is enabled.

We’ll be doing all of our work today inside Cloud Shell. To open it, just click the activate Cloud Shell icon in the console. Once it’s open, you’ll see you can easily toggle between the terminal, where we’ll run our commands, and the editor where we’ll browse our code. We will be using both throughout this tutorial.

Now, in the terminal, let’s make sure you’re authenticated correctly by running our first command. Now this part is important. We need to set up our project ID so that all the resources we create are associated with our project. Find your project ID from the console and run these commands, replacing your project ID with your actual ID. We’ll export it as an environment variable first, which makes the next command a bit cleaner.

With our project set, we need to enable the specific APIs that our agent will rely on. This includes APIs for Cloud Run, Cloud Build, Artifact Registry, and Vertex AI. This single command will enable all of them for us. Note that this step can take a few minutes to complete. And one last check, this project requires Python 3.10 or newer. This should be the default in your Cloud Shell environment, but you can quickly verify by running the command python3 --version.

Descargar codigo y configurar entorno (3:45 - 5:00)

Sección titulada «Descargar codigo y configurar entorno (3:45 - 5:00)»

Okay, our project and APIs are all set. Now, working in that same Cloud Shell terminal, we’ll need to download the project source code. It’s important to continue in the same session so we still have access to the project ID variable we configured in the last step.

First, let’s clone the project’s repository from GitHub. And once that’s downloaded, we’ll change into the new project directory.

This project uses a tool called UV to manage its Python dependencies. We’ll install it by running the curl command shown here. Just a quick heads up, if you get a UV not-found error in the next steps, you may need to open a new terminal tab for the UV installation to be recognized. Don’t forget to CD back into the currency agent directory if you do.

Now we need to configure our application’s environment variables. This next command creates an .env file and populates it using the project ID variable from the previous step. Let’s quickly check the contents of the file to make sure it was created correctly. You should see three variables printed out with your project ID filled in.

With the code downloaded and our environment configured, we can now set up the MCP server. Now, it’s time to build our first major component of our system, the MCP server. This server’s job is to expose tools that our agent can use. In our case, we need a tool that can fetch currency exchange rates. We’ll use a Python package called FastMCP to build the server.

FastMCP is a Python framework that provides a fast and intuitive way to build servers and clients for MCP by using simple decorators and Python functions.

Let’s take a look at the code which you can find in the mcp_server/server.py file using the Cloud Shell editor.

The key part of this file is the get_exchange_rate function. The @mcp.tool decorator above it is what registers this function as a tool that our server will expose. The function itself calls an external API to get the exchange rate.

Now let’s run this server in our Cloud Shell terminal. This will start it on port 8080.

With the server running, we need to test it. It’s important to do this in a new Cloud Shell tab so you don’t have to stop the server. In the new tab, make sure you are in the currency agent directory and run the test script. The test script just connects to our localhost client and makes a tool call. You should see a success message in the output showing the current exchange rate from US dollars to euros.

This confirms our MCP server is up and running. Perfect. Go ahead and stop the server by pressing Ctrl+C in the first terminal tab.

In the next step, we’ll deploy this server to the cloud. Our MCP server works, but it’s only running in our interactive Cloud Shell session, which is temporary. To make it a permanent and reliable tool for our agent, we actually need to deploy it as a standalone service.

We’ll use Cloud Run for this, which provides benefits like automatic scaling and built-in security. First, let’s navigate into the server’s directory.

Now, we’ll deploy it with a single gcloud command. Pay attention to the --no-allow-unauthenticated flag. This is critical for security as it ensures that only authorized accounts can access our server.

Once that finishes, our server will be live. But because we made it secure, we need a way to authenticate our test calls. We’ll use the Cloud Run proxy to create a secure authenticated tunnel from our Cloud Shell environment to our live service. You may be prompted to install the proxy if you haven’t done it already.

Now leave this proxy running. To test it, we need to open a new Cloud Shell terminal. In the new tab, navigate back to the project’s root directory. Now run the same test script we ran earlier. This time it’ll be routed through the proxy to our Cloud Run server. You should see the same success message as before.

To prove it really worked, we can even check the logs of our deployed service right from the command line. And there you have it, a live secure MCP server running on Cloud Run.

Now we’re ready to build an agent that can use it. For this, we’ll use the Agent Development Kit or ADK.

Using the Cloud Shell editor, let’s look at the agent’s code in the currency_agent/agent.py file.

You’ll see two key parts. First, a system instruction that tells the agent its purpose and its rules. In this case, to only answer questions about currency.

Second, you’ll see the MCPToolset. This is the critical piece that connects our agent to the MCP server we’ve deployed in the last step, giving it access to the get_exchange_rate tool.

The ADK comes with a simple web interface for testing. Let’s start it up. Remember to leave your Cloud Run proxy from the last step running in its own tab. In a new terminal tab, run the adk web command. This starts a new server on port 8000.

To access it, go to the web preview button in your Cloud Shell toolbar. You may need to change the port to 8000 before launching the preview tab.

In the web page that opens, make sure the currency agent is selected in the top left dropdown. Now ask a question like “what is 250 Canadian dollars to USD?”

It works. The ADK agent correctly used the tool from our deployed MCP server to answer the question.

Now let’s see how to make this agent available to other agents. Our agent can now talk to us. But the real power of AI agents comes when they can talk to each other. For that we’ll use the agent-to-agent protocol or A2A.

A2A is an open protocol that standardizes how agents collaborate across frameworks and vendors. It is built on standards like HTTP, SSE, and JSON RPC while ensuring enterprise-grade security. Designed to be modality agnostic, A2A enables agents to work together across text, audio, video, and other unstructured formats.

A2A allows agents to discover each other’s capabilities and collaborate on tasks. They do this by using something called an agent card, which is like a digital business card. The card advertises the agent’s skills. In our case, we might define a skill for our get_exchange_rate tool. Then package that skill into an agent card which includes the agent’s name, description, and other details.

Now that we understand the concepts, let’s put it all together and build our A2A server. ADK provides a utility function called to_a2a (or similar) that does most of the heavy lifting for us. This function takes our existing agent and converts it into an A2A-compatible application that can be served through Uvicorn.

Under the hood, it even generates an agent card for us. You can see this inside currency_agent/agent.py.

With just two lines of code, we’ve exposed the currency agent as an A2A server. Now, let’s launch our A2A server. Make sure that your other processes, the Cloud Run proxy and the ADK web server, are still running in their own tabs.

Open a new Cloud Shell terminal and run the following command. You’ll see output indicating that the server has started on port 10,000.

Our currency agent is now officially running as an A2A-compliant server ready to be called by other clients or agents.

Now let’s test the A2A server. The file currency_agent/test_client.py uses the A2A Python SDK’s A2AClient class to connect to the agent and run through some tests.

You’ll see output confirming the client connected successfully, sent a request, and received a response. For example, asking “how much is 100 USD in Canadian dollars?” will return the conversion using live exchange rate data.

A successful run means that other programs and agents can now communicate with our currency agent over A2A.

But if you want to access this A2A agent from another agent, then define a remote A2A agent (sub-agent) and point it to the public agent card.

Nice. You’ve successfully built a complete end-to-end agentic system. Before we wrap up, it’s very important to clean up the resources we created to avoid any future charges to your Google Cloud account. The simplest way to do this is to delete the entire project.

Congratulations. In this video, we covered how to create and deploy an MCP server on Cloud Run to provide tools for an agent. We then built that agent using ADK and finally exposed it to other agents to use within the A2A protocol. Thanks so much for following along and we can’t wait to see what you build with these powerful tools for creating AI agents.


[External API: Frankfurter]
^
| HTTP GET (exchange rates)
|
[MCP Server (FastMCP)] ← Cloud Run service, port 8080
- server.py
- @mcp.tool: get_exchange_rate()
- --no-allow-unauthenticated
^
| MCP protocol (via SSE/streamable HTTP)
| (through Cloud Run proxy for auth)
|
[ADK Agent] ← currency_agent/agent.py
- model: Gemini (via Vertex AI)
- system_instruction: "solo currency"
- tools: MCPToolset(url=MCP_SERVER_URL)
^
| A2A protocol (HTTP + SSE + JSON-RPC)
| Port 10,000
|
[A2A Server wrapper] ← agent.py (to_a2a utility)
- Uvicorn serving the A2A app
- Auto-generates agent card
- agent card advertises skills
^
| A2A protocol
|
[A2A Test Client] ← test_client.py
- Uses A2A Python SDK's A2AClient class
- Sends tasks, receives responses
[Other agents]
- Can define a "remote A2A agent (sub-agent)"
- Point to public agent card URL
ComponenteArchivoPuertoDeploy
MCP Servermcp_server/server.py8080Cloud Run
ADK Agentcurrency_agent/agent.py8000 (adk web)Local (Cloud Shell)
A2A Servercurrency_agent/agent.py (to_a2a)10,000Local (Cloud Shell)
Test Clientcurrency_agent/test_client.pyN/ALocal

  • Built with FastMCP (Python package)
  • Expone UN solo tool: get_exchange_rate
  • Backed by: API externa (Frankfurter API) — NO Firestore, NO GCS, NO SQLite, NO in-memory
  • El MCP server es simplemente un wrapper que llama a una API REST de exchange rates
from fastmcp import FastMCP
mcp = FastMCP("currency-server")
@mcp.tool
def get_exchange_rate(currency_from: str, currency_to: str) -> dict:
"""Get the exchange rate between two currencies."""
# Calls external Frankfurter API
# Returns exchange rate data
...
# Navigate to mcp_server directory
cd mcp_server
# Deploy with gcloud — NOTE: --no-allow-unauthenticated
gcloud run deploy mcp-server \
--source . \
--no-allow-unauthenticated \
--project $PROJECT_ID
# Create authenticated tunnel
gcloud run services proxy mcp-server --project $PROJECT_ID
# In another tab, run test script
uv run test_mcp_server.py

Dos partes clave:

1. System Instruction:

  • Dice al agente que SOLO responda preguntas sobre currency
  • Define su proposito y reglas

2. MCPToolset:

  • Conecta el agente al MCP server desplegado en Cloud Run
  • Le da acceso al tool get_exchange_rate
from google.adk import Agent
from google.adk.tools.mcp import MCPToolset
# System instruction
SYSTEM_INSTRUCTION = """You are a currency conversion agent.
Only answer questions about currency exchange rates."""
# Agent definition with MCPToolset connecting to deployed MCP server
agent = Agent(
model="gemini-...",
system_instruction=SYSTEM_INSTRUCTION,
tools=[MCPToolset(url="http://localhost:8080")] # URL points to MCP server (via proxy)
)
# Start ADK web interface
adk web
# Opens on port 8000
# Select "currency_agent" in dropdown
# Ask: "What is 250 Canadian dollars to USD?"

ADK provee una utilidad to_a2a que convierte el agente existente en un servidor A2A compatible:

from google.adk.a2a import to_a2a
# This converts the ADK agent into an A2A-compatible ASGI app
# Served through Uvicorn
app = to_a2a(agent)
# Under the hood, it auto-generates an agent card
# The agent card advertises the agent's skills

El agent card es como una “tarjeta de presentacion digital” que anuncia:

  • Nombre del agente
  • Descripcion
  • Skills (ej: get_exchange_rate)
  • Endpoint URL
# Start A2A server on port 10,000
uvicorn currency_agent.agent:app --port 10000
from a2a.client import A2AClient
# Connect to A2A server
client = A2AClient(url="http://localhost:10000")
# Send task
response = client.send_task("How much is 100 USD in Canadian dollars?")
print(response)

1. MCP = TOOLS (que puede hacer)
- FastMCP server expone get_exchange_rate
- Deployed on Cloud Run (seguro, escalable)
- Cualquier agente MCP-compatible puede conectarse
2. ADK = AGENT (el cerebro)
- Define el agente con system instruction + model
- MCPToolset conecta al MCP server
- El agente RAZONA y decide cuando usar el tool
3. A2A = INTEROPERABILIDAD (como se comunican agentes)
- to_a2a() wraps the ADK agent
- Genera agent card automaticamente
- Otros agentes descubren capabilities via agent card
- Se comunican via HTTP + SSE + JSON-RPC
MCP = "Como un agente accede a tools/datos"
ADK = "Como construyes el agente"
A2A = "Como agentes hablan entre si"

Son COMPLEMENTARIOS, no competidores:

  • MCP es para tool access (agente -> herramientas)
  • A2A es para agent-to-agent communication (agente -> agente)
  • ADK es el framework que los une
# In another agent's code:
# Define a remote A2A sub-agent pointing to the agent card
remote_agent = RemoteA2AAgent(
agent_card_url="http://currency-agent:10000/.well-known/agent.json"
)
# Use as sub-agent in your multi-agent system
orchestrator = Agent(
sub_agents=[remote_agent]
)

TecnologiaUso
FastMCPBuild MCP server (Python)
google-adk (ADK)Build agent + MCPToolset + to_a2a()
a2a-sdkA2A Python SDK (client class)
UvicornASGI server para servir A2A app
UVPython package manager
Cloud RunDeploy MCP server
Cloud BuildBuild container para Cloud Run
Artifact RegistryStore container images
Vertex AILLM backend (Gemini)
Frankfurter APIExternal API for exchange rates
Cloud ShellDevelopment environment
Cloud Run ProxyAuthenticated tunnel for testing

  1. MCP server en Cloud Run con --no-allow-unauthenticated — seguridad first
  2. FastMCP como framework para MCP servers (no build from scratch)
  3. MCPToolset de ADK para conectar agent a MCP server
  4. to_a2a() de ADK para exponer agente como A2A server (2 lineas de codigo)
  5. Agent card auto-generada — no necesitas definirla manualmente
  6. UV como package manager (no pip)
  7. Cloud Run proxy para testing de servicios autenticados
  8. Port convention: MCP=8080, ADK Web=8000, A2A=10000
AspectoVideo GoogleNuestro sistema
Num agentes1 (currency)7 agentes ADK
MCP server1 (exchange rates)No usamos MCP servers (tools inline)
Deploy A2ASolo local (Cloud Shell)Cloud Run para cada agente
Agent cardAuto-generadaDefinida manualmente
OrquestadorNo hayorchestrator_a2a.py
Testtest_client.py localcurl / orchestrator

El video de Google es basico: 1 MCP server, 1 agente, testing local. Nuestro video es produccion real: 7 agentes en Cloud Run, orquestador, CI/CD con Agent Teams. Podemos referenciar este video como “el tutorial oficial” y mostrar que nosotros vamos MUCHO mas alla.

La funcion to_a2a() de ADK es nueva e importante — simplifica drasticamente exponer agentes via A2A. Verificar si nuestro codigo ya la usa o si seguimos con el patron manual de A2A server.