Building AI Agents with Google Cloud Managed MCP Servers and ADK
What is MCP?
MCP (Model Context Protocol) is an open protocol — created by Anthropic — that standardizes how an AI application connects to external tools and data.
Think of it like a USB-C port for AI agents. Before USB-C, every device had its own connector. Before MCP, every integration between an LLM and a system (a database, an API, a file store) was custom glue code that you wrote and maintained yourself.
With MCP, the contract is fixed:
- An MCP Server exposes capabilities —
tools(actions the agent can call),resources(contextual data like schemas), andprompts(predefined inputs). - An MCP Host is your AI application (an ADK agent, Gemini CLI, Claude, VS Code).
- An MCP Client lives inside the host and speaks the protocol to the server.
Your agent doesn’t need to know how BigQuery works. It just needs to speak MCP to a BigQuery MCP server, and it instantly gets a set of well-described tools it can call.
You can directly jump into the demo using below video
Local MCP vs Remote MCP
There are two ways an MCP server can run, and the difference matters a lot for production:
Local MCP is the classic developer experience: you pip install or npm install a server, it runs as a subprocess on your laptop, and the agent talks to it over stdio. Great for prototyping. Painful at scale — you are now responsible for installing, patching, securing, and running that server for every service you want to reach.
Get Vishal Bulbule’s stories in your inbox
Join Medium for free to get updates from this writer.
Remote MCP flips this. The server runs as a managed HTTP endpoint. You just point your agent at a URL and authenticate. No process to babysit.
What Google announced — and why it changes the picture
Google announced official MCP support across Google and Google Cloud services: a fleet of fully-managed, remote MCP servers with enterprise-ready HTTP endpoints (supporting MCP spec version 2025-11-25).
During Cloud Next 2026 MCP service list is Extended
This is the important shift. Previously, to give an agent access to GCP, you’d hunt down community/open-source MCP servers, deploy them, and keep them alive. Now Google runs them for you, behind stable *.googleapis.com/mcp endpoints, with the enterprise plumbing already wired in:
- Google Cloud IAM for access control — the agent only gets what its identity is allowed.
- Audit Logging for observability and compliance.
- Model Armor for defense against agentic threats like indirect prompt injection.
- Cloud API Registry / Apigee API Hub to discover trusted tools.
A large catalog of services is already live (GA) as remote MCP servers, including:
Why this matters for agent builders: the integration layer is no longer your problem. You write the agent logic — the model, the instructions, the routing — and the GCP services show up as governed tools over a URL. That’s the whole picture changing: from “build and run integrations” to “point and authenticate.”
How you build an agent with this
The mental model is three steps:
- Enable the API for the service you want (one gcloud command).
- Connect your agent to that service’s remote MCP endpoint, passing an auth token.
- Let the model route — the LLM picks which MCP tools to call based on your instructions.
Let’s do exactly that.
Part 2 — A working example: an ADK agent with BigQuery + Cloud Run access
We’ll build a Google Cloud expert agent using Google’s Agent Development Kit (ADK) that connects to two official remote MCP servers — BigQuery and Cloud Run — over HTTP.
Step 0 — Enable the APIs
Each MCP server is fronted by its product’s API. Enable the ones you need:
gcloud services enable bigquery.googleapis.com
gcloud services enable run.googleapis.comYou need the Service Usage Admin role (
roles/serviceusage.serviceUsageAdmin) to enable APIs.
Then make sure you’re authenticated locally so your agent can mint tokens via Application Default Credentials:
gcloud auth application-default loginStep 1 — Get credentials for the remote MCP servers
Remote MCP servers are just authenticated HTTP endpoints. We use Application Default Credentials (ADC) to get a short-lived OAuth token and the active project, then pass them as headers.
# tools.py
import google.auth
import google.auth.transport.requests
from google.adk.tools.mcp_tool import McpToolset
from google.adk.tools.mcp_tool.mcp_session_manager import StreamableHTTPConnectionParams
# Official, fully-managed remote MCP endpoints
BIGQUERY_MCP_URL = "https://bigquery.googleapis.com/mcp"
CLOUD_RUN_MCP_URL = "https://run.googleapis.com/mcp"
def _get_gcp_credentials():
# ADC: uses `gcloud auth application-default login` locally,
# or the runtime service account in production.
credentials, project_id = google.auth.default(
scopes=["https://www.googleapis.com/auth/cloud-platform"]
)
auth_request = google.auth.transport.requests.Request()
credentials.refresh(auth_request)
return credentials, project_idThe two headers that matter on every call:
Authorization: Bearer <token>— proves who the agent is.x-goog-user-project: <project_id>— which project to bill/operate against.
This is where IAM does the gatekeeping: the agent can only do what this identity is permitted to do. No extra access layer to build.
Step 2 — Wrap each MCP server as an ADK toolset
ADK’s McpToolset connects to a remote MCP server over streamable HTTP and automatically turns its tools into agent tools.
# tools.py (continued)
def get_bigquery_toolset():
credentials, project_id = _get_gcp_credentials()
return McpToolset(
connection_params=StreamableHTTPConnectionParams(
url=BIGQUERY_MCP_URL,
headers={
"Authorization": f"Bearer {credentials.token}",
"x-goog-user-project": project_id,
},
)
)
def get_cloud_run_toolset():
credentials, project_id = _get_gcp_credentials()
return McpToolset(
connection_params=StreamableHTTPConnectionParams(
url=CLOUD_RUN_MCP_URL,
headers={
"Authorization": f"Bearer {credentials.token}",
"x-goog-user-project": project_id,
},
)
)Notice how little code this is. The entire BigQuery and Cloud Run tool surface — listing datasets, running SQL, exploring schemas, listing services, inspecting revisions, checking traffic splits — comes from pointing at a URL with a token. That’s the payoff of managed remote MCP.
Step 3 — Build the agent and let the model route
Now we assemble an LlmAgent, hand it both toolsets, and write instructions that tell the model when to use which tool. The LLM does the routing at runtime.
# agent.py
import logging
from dotenv import load_dotenv
from google.adk.agents import LlmAgent
from .tools import get_bigquery_toolset, get_cloud_run_toolset
logging.basicConfig(level=logging.INFO)
load_dotenv()
bigquery_toolset = get_bigquery_toolset()
cloud_run_toolset = get_cloud_run_toolset()
root_agent = LlmAgent(
model="gemini-2.5-pro",
name="adk_gcp_mcp_agent",
instruction="""
You are a Google Cloud expert assistant with access to GCP services via MCP.
Tools available:
- BigQuery MCP: query datasets, list tables, run SQL, explore schemas
- Cloud Run MCP: list services, inspect revisions, check traffic splits
Route questions to the right tool:
- Data/SQL questions -> BigQuery
- Serverless workloads -> Cloud Run
Always be precise and show which tool you used to get the answer.
""",
tools=[bigquery_toolset, cloud_run_toolset],
)Step 4 — Run it
With ADK installed, launch the dev UI from the project root:
adk webNow ask it natural-language questions and watch it pick the right MCP server:
- “List the datasets in my project and show the schema of the events table.” → routes to BigQuery MCP.
- “Which Cloud Run services are deployed in project <project id> in region <region>” → routes to Cloud Run MCP.
The agent calls the managed remote MCP server, the server executes against your real GCP resources (governed by IAM), and the model explains the result.
Scaling out
Adding more GCP services is now trivial — it’s the same three-line pattern with a different URL. Want logs and metrics too? Add toolsets pointed at logging.googleapis.com/mcp and monitoring.googleapis.com/mcp, list them in tools=[...], and extend the instruction. No new infrastructure, no servers to run.
Wrapping up
We can build cool Support Agent with Google Remote MCPs check demo here
The headline isn’t “Google supports MCP.” It’s where the work moved:
- Before: you found, deployed, secured, and ran integration servers for every GCP service.
- Now: Google runs managed remote MCP servers behind stable endpoints, with IAM, audit logging, and Model Armor already in place. You write agent logic and point at a URL.
For production agents, that’s the difference between maintaining plumbing and shipping capability. Pick the services you need from the supported products list, enable the APIs, wrap each endpoint as a toolset, and let the model do the routing.
