Deploy & Connect to the Ecosystem

Where we are in the series

1. Your first agent — a single agent with one tool. (done)
2. Tools, state & memory — the agent remembers. (done)
3. Multi-agent systems — coordinator + specialists. (done)
4. Evaluation, callbacks & safety — measurable and safe. (done)
5. Deploy & connect (this lab) — get it out of your laptop and into the open ecosystem.

This finale takes the safe, evaluated Acme support agent from Lab 4 and does the last mile: connect it to other systems and ship it.

What you'll build

You'll make the agent a full participant in a real, multi-system environment:

• Consume an MCP server — give an agent tools from an external MCP server (McpToolset), instead of hand-writing every tool. This is the client side of the Model Context Protocol.
• Expose your agent over A2A — wrap it with to_a2a so it publishes an Agent Card and serves the Agent-to-Agent protocol; now other agents can discover and delegate to it.
• Run it as a service — serve the agent over HTTP locally with the ADK API server, and containerize it.
• Deploy to the cloud — ship it with adk deploy (Cloud Run or the managed Agent Engine), with a production checklist.

By the end, your ADK agent is both an A2A server (others call it) and an MCP client (it calls tools) — closing the loop with the open-protocol labs earlier in your broader series.

Why this matters (the 5-minute business case)

Read this section before handing the lab to your team.

An agent that only runs on a developer's laptop creates zero business value. The gap between "it works in adk web" and "it's serving customers, reliably, connected to our systems" is where most AI initiatives quietly die. This lab is about crossing that gap in two dimensions at once: deployment (making the agent a real, scalable service) and interoperability (connecting it to the tools and agents around it via open standards). ADK is explicitly built for both — it's "build, evaluate, and deploy," and it speaks MCP and A2A so you're not locked into one vendor's walled garden.

Three reasons this is a leadership-level concern:

1. Open standards prevent lock-in and multiply reuse. Because the agent consumes MCP servers, it can use any tool the organization (or a vendor) exposes through that standard — build the integration once, reuse it across every MCP-speaking agent. Because it's exposed over A2A, any other compliant agent or platform can call it. You're plugging into an ecosystem, not re-integrating point-to-point for every new combination. That interoperability is a direct hedge against betting the company on a single platform.
2. Deployment is where reliability, security, and cost become real. Moving from a laptop to a managed service forces the questions that matter: where do secrets live, how does session state persist across instances, how does it scale, what does it cost per request, how is it monitored. ADK's deploy targets (Cloud Run for a standard container, Agent Engine for a managed agent runtime) handle the mechanics so your team can focus on those operational decisions rather than plumbing.
3. Composability is how agent systems actually grow. The end state isn't one mega-agent; it's many specialized agents and tools, owned by different teams and vendors, collaborating over shared protocols. An ADK agent that both offers itself via A2A and consumes capabilities via MCP is a reusable building block in that larger system — the same modularity that let microservices scale across an organization, now for AI.

The honest caveats, because pragmatic adoption means naming them:

• Deployment surfaces everything you deferred. The in-memory session/memory services from earlier labs are fine for dev and wrong for production — restart the service and state is gone; run two instances and they don't share it. Production needs a real backing store (e.g. a database-backed session service) and real secrets management for your API key. Shipping is the moment to fix what was a convenient stub.
• Every connection is a trust and security boundary. Consuming an MCP server means trusting its tools (and its operator) with whatever you let the model call; exposing your agent over A2A means deciding who may invoke it and with what authentication. The discovery-and-verify discipline from the ARD/A2A labs isn't optional once you're networked — auth, allowlists, and least privilege are part of deployment, not afterthoughts.
• Cost and latency compound in the open. An agent that calls remote MCP tools and delegates to remote A2A peers makes network hops on top of model calls. That's powerful, but each hop adds latency, failure modes, and spend. Design for timeouts, retries, and graceful degradation, and watch the per-request cost — distributed agent systems are still distributed systems.

A useful framing for a non-technical stakeholder: "We're taking the agent from a prototype to a deployed service, and connecting it to our other tools and agents using open standards — so it can use shared capabilities and be used by other systems, without locking us into one vendor. Going to production also means we handle the real concerns: secure secrets, persistent memory, scaling, and monitoring."

Concepts you'll use (2-minute primer)

• Consuming MCP — McpToolset(connection_params=StreamableHTTPConnectionParams(url=...)) added to an agent's tools. ADK fetches the MCP server's tools at runtime and exposes them to the model. (StdioConnectionParams for local servers; tool_filter=[...] to allowlist.)
• Exposing A2A — to_a2a(agent, host, port) returns a Starlette ASGI app that publishes an Agent Card at /.well-known/agent-card.json and serves the A2A protocol. Run it with uvicorn.
• Serving locally — adk api_server <dir> runs an HTTP API over your agents; adk web <dir> is the dev UI.
• Deploying — adk deploy cloud_run ... builds a container and deploys to Cloud Run; adk deploy agent_engine ... targets the managed runtime. The included Dockerfile is the manual container path for any host.
• Production services — swap in-memory session/memory for persistent backends; manage the API key as a secret; configure scaling and observability.

Prerequisites

Get the starter repo. adk-lab-05/ carries acme_support/ (the Lab 4 agent) and adds mcp_agent/, a2a_app.py, and a Dockerfile.

Setup (3 minutes)

cd adk-lab-05
python3 -m venv .venv && source .venv/bin/activate
pip install -r requirements.txt
pip install "google-adk[a2a]"                  # for the A2A exercise
cp acme_support/.env.example acme_support/.env # set GOOGLE_API_KEY=...
cp mcp_agent/.env.example mcp_agent/.env

python test_guardrails.py                       # 7/7 — the Lab 4 guards still hold

Exercise 1 — Consume an MCP server (12 min)

Goal: Give an agent tools from an external MCP server instead of writing them in Python.

Open mcp_agent/agent.py. The whole integration is one toolset:

from google.adk.tools.mcp_tool import McpToolset, StreamableHTTPConnectionParams

mcp_tools = McpToolset(
    connection_params=StreamableHTTPConnectionParams(url="http://localhost:8000/mcp"),
    # tool_filter=["get_order", "search_orders"],   # optional allowlist
)

root_agent = Agent(name="mcp_orders_agent", model="gemini-2.5-flash",
                   instruction="Answer order questions using the connected MCP tools.",
                   tools=[mcp_tools])

McpToolset is added to tools like any tool — but at runtime ADK connects to the MCP server, lists its tools, and exposes them to the model. You wrote no per-tool code.

Try it end-to-end with the MCP server you built earlier in the broader series:

# In one terminal — start an MCP server over HTTP (from the MCP protocol lab):
python server.py --http            # serves http://localhost:8000/mcp

# In another — run this agent:
adk web .                          # pick "mcp_agent", ask an order question

The agent answers using tools it discovered from the server. Use tool_filter to allowlist exactly which of the server's tools the agent may call.

Business callout: this is "integrate once, reuse everywhere" in action. Any capability your organization (or a partner) exposes as an MCP server becomes instantly usable by your ADK agents — no bespoke client per integration. The catch is trust: an MCP server's tools run on the model's behalf, so consume servers you trust and allowlist what the agent can call.

Checkpoint: Your agent can use external tools over MCP. Now let other agents use yours.

Exercise 2 — Expose your agent over A2A (12 min)

Goal: Publish the Acme support agent as an A2A service that other agents can discover and call.

Open a2a_app.py — two lines of real code:

from google.adk.a2a.utils.agent_to_a2a import to_a2a
from acme_support.agent import root_agent

app = to_a2a(root_agent, host="localhost", port=8001)

to_a2a wraps the agent in a Starlette app that publishes an Agent Card and serves the A2A protocol. Run it (needs pip install "google-adk[a2a]"):

uvicorn a2a_app:app --host localhost --port 8001

Then fetch the card:

curl http://localhost:8001/.well-known/agent-card.json

You'll see a card built automatically from the agent — its name, description, and skills. Any A2A client can now discover this agent and send it work — including the orchestrator from the A2A protocol lab, which discovers a peer's card and delegates over message/send. Your ADK agent has become a drop-in A2A peer.

Business callout: exposing the agent over a standard means other teams' systems can use it without touching its code or even knowing it's built on ADK. The Agent Card is the contract; the protocol is the integration. That's how an organization builds a network of reusable agents instead of a pile of disconnected ones — and it's why "speaks A2A" is worth requiring of any agent you build or buy.

Checkpoint: Your agent is callable by other agents over A2A. Now make it a real service.

Exercise 3 — Run it as a service (10 min)

Goal: Serve the agent over HTTP and package it as a container.

For local serving, ADK gives you an HTTP API over your agents:

adk api_server --host 0.0.0.0 --port 8080 .

That exposes a REST API your apps (or a UI) can call — the same agents you've been running in adk web, now over HTTP.

To ship it anywhere, containerize. The included Dockerfile:

FROM python:3.11-slim
WORKDIR /app
COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt
COPY . .
ENV PORT=8080
CMD ["sh", "-c", "adk api_server --host 0.0.0.0 --port ${PORT} ."]

Build and run it:

docker build -t acme-support .
docker run -p 8080:8080 --env-file acme_support/.env acme-support

Note --env-file: the API key comes in as an environment variable, not baked into the image. That's the first production reflex — secrets are configuration, never code.

Business callout: turning the agent into a standard HTTP container is what lets it live in your existing infrastructure — load balancers, autoscalers, CI/CD, monitoring. The agent stops being a special snowflake and becomes a service you operate like any other. (adk deploy, next, can build this container for you — the Dockerfile just makes the moving parts visible.)

Checkpoint: The agent runs as an HTTP service and packages as a container. Now deploy it.

Exercise 4 — Deploy to the cloud (and the production checklist) (12 min)

Goal: Deploy with one command — and know what to harden before real traffic.

ADK can build and deploy for you. Two targets:

# Cloud Run — a standard, autoscaling container service:
adk deploy cloud_run --project YOUR_PROJECT --region us-central1 acme_support

# Agent Engine — Google's managed agent runtime (handles sessions, scaling):
adk deploy agent_engine --project YOUR_PROJECT --region us-central1 acme_support

adk deploy cloud_run containerizes the agent (you don't even need the Dockerfile) and ships it; agent_engine targets a managed runtime purpose-built for agents. Either way, the command is the easy part. The production checklist is the real work:

• Persist state and memory. The in-memory services from Labs 2–4 lose everything on restart and aren't shared across instances. For production, use a database-backed session service (ADK provides DatabaseSessionService) and a real memory backend. This is the most common "it worked in dev" trap.
• Manage the API key as a secret. Use your platform's secret manager (e.g. Secret Manager on Google Cloud), injected as an environment variable — never committed, never in the image.
• Lock down the front door. Decide who can call the deployed service (and the A2A endpoint): authentication, allowlists, rate limits. An open agent endpoint is an open tool-execution endpoint.
• Keep the safety net on. The guardrails and evals from Lab 4 ship with the agent — they're code, so they deploy too. Run the eval suite in CI before each deploy (the deploy-gate idea from Lab 4 / the standalone Evals lab).
• Observe it. Wire the event trace / logging callbacks (Lab 4) to your logging and monitoring so you can debug and audit production behavior.
• Watch cost and latency. Especially once it calls remote MCP tools and A2A peers — set timeouts, handle failures gracefully, and track per-request spend.

Business callout: adk deploy removes the excuse that "productionizing the AI is a huge project." The deployment mechanics are now a command; the durable work is the operational discipline — persistence, secrets, access control, monitoring, and cost. Budget for that, not for reinventing deployment plumbing.

Checkpoint: You can deploy the agent and you know the checklist that separates a demo from a service.

Wrap-up

You shipped the agent and connected it to the ecosystem. You can now:

• Consume external tools via an MCP server (McpToolset)
• Expose your agent over A2A (to_a2a) for other agents to discover and call
• Serve it over HTTP (adk api_server) and containerize it
• Deploy with adk deploy (Cloud Run / Agent Engine) — and apply the production checklist (persistence, secrets, auth, evals-in-CI, observability, cost)

The one idea to carry forward: a production agent is an interoperable service, not a script. ADK lets it both use the ecosystem (MCP client) and be used by it (A2A server), and deploy with a single command — but the value comes from doing the operational work deployment exposes: durable state, managed secrets, access control, continuous evaluation, and monitoring.

Series wrap-up — what you built across 5 labs

You took one agent from "hello world" to a deployed, interoperable system:

1. First agent — model + instruction + tool, run by a Runner.
2. State & memory — context within a session and across sessions.
3. Multi-agent — a coordinator routing to specialists, plus deterministic Workflows.
4. Eval, callbacks & safety — measurable quality and deterministic guardrails.
5. Deploy & connect — shipped as a service, consuming MCP and exposed over A2A.

And it connects outward to the open-protocol labs: the MCP server it consumes, the A2A orchestrator that can call it, plus ARD (discovery/trust), OKF (documenting the agent's knowledge), and the Interactions API and Evals labs. Invoke → discover → know → integrate → evaluate → collaborate → deploy.

Stretch challenges

1. Full circle. Run the MCP lab's server.py --http and the A2A lab's orchestrator, point mcp_agent at the server, expose acme_support via a2a_app, and have the orchestrator delegate to your ADK agent — a live multi-system loop.
2. Persistent sessions. Swap InMemorySessionService for DatabaseSessionService (SQLite to start) and confirm state survives a restart.
3. Authenticated A2A. Put a bearer token in front of the A2A endpoint and have the client present it — least-privilege for agent-to-agent calls.
4. Deploy for real. If you have a GCP project, run adk deploy cloud_run and hit the deployed Agent Card from the public URL.

Troubleshooting

References

Technical details follow the ADK 2.0 Python API:

• ADK docs — MCP tools, A2A, deployment
• ADK Python (`McpToolset`, `to_a2a`, `adk deploy`)
• This series' MCP and A2A protocol labs — the server this consumes and the orchestrator that can call it
• Get a Gemini API key

A note on accuracy for your readers: code targets ADK 2.0 (google.adk.tools.mcp_tool.McpToolset + StreamableHTTPConnectionParams; google.adk.a2a.utils.agent_to_a2a.to_a2a; adk api_server / adk deploy cloud_run / agent_engine). The carried guardrail logic is unit-tested here; the MCP/A2A/deploy wiring is syntax-verified against the 2.0 source. Deployment commands, extras, and the A2A/MCP integration surface evolve quickly — pin your google-adk version and re-verify against the live docs before publishing.