A practitioner’s tour of Google Cloud’s Data Agent Kit: how MCP servers and agent skills work together, real prompts from start to finish, and the guardrails to set up before you let it loose
It’s 9:07 on a Monday. A message lands from your operations lead: “Average delivery time went from 2.1 days to 3.4 days over the last two weeks of August. Nothing is on fire. What happened?”
You already know how this goes. Shipment facts sit in BigQuery. Warehouse inventory lives in a Cloud SQL for MySQL instance owned by the app team. Carrier routing rules are JSON files someone drops into a Cloud Storage bucket. None of these systems has ever heard of the others. Each individual query is easy. The investigation is not. By lunch you have eleven tabs open, two SQL dialects in your head, and a growing suspicion that the answer was in the tab you just closed.
Google Cloud’s Data Agent Kit is aimed squarely at that afternoon. Instead of generating SQL for you to paste into a console, it lets the coding agent you already use run the queries across those systems, read the results, and keep digging, while you approve the tools it uses and review what it did.
This post covers what the kit is, how it’s wired together, how to install it, four worked examples, and the security setup I’d treat as non-negotiable.
Status check: Data Agent Kit is in Preview under Google’s Pre-GA terms, and the open-source plugin is still pre-1.0 (v0.6.1 at the time of writing). Expect things to move.
Data Agent Kit in one breath
Google announced Data Agent Kit at Cloud Next ’26 in April as one piece of its “Agentic Data Cloud”, next to Knowledge Catalog and the cross-cloud lakehouse. It’s a bundle of MCP servers and agent skills that brings Google Cloud data work into your editor or terminal, so you stop bouncing between the console, the gcloud CLI, and your IDE.
It ships in two forms:
- An IDE extension for VS Code and compatible editors such as Antigravity IDE and Cursor. It adds a panel that gives you a unified view of your data assets and workloads, alongside agent chat. It comes preinstalled in Cloud Workstations and is integrated into Cloud Code.
- A plugin for coding agents, including Antigravity CLI, Claude Code, Codex CLI and Gemini CLI. Same capabilities, driven purely by natural language instead of a UI.
The plugin lives on GitHub as the Data Agent Kit Starter Pack under the Apache 2.0 license, and Google describes the kit as freely available.
The mental model: hands, know-how, and a director
Everything in the kit comes down to two mechanisms, plus you.
MCP servers are the hands. The Model Context Protocol is an open standard for connecting agents to tools and data. An MCP server exposes tools like “run a read-only query” or “list datasets”, and the agent calls them and gets structured results back. No copy-pasting between windows.
Skills are the know-how. Skills are markdown files that teach the agent how to work with a particular part of your stack: dbt conventions, BigQuery SQL notebooks, Spark jobs, orchestration pipeline syntax and so on. They’re plain files, so you can read and edit them.
You are the director. Before the agent runs any MCP tool, your IDE or CLI asks for permission. You can allow a tool once, which is great when you want to audit every call, or always, which keeps the flow moving. Every tool call and every raw SQL statement shows up in the execution trail.
Remote versus local MCP servers
You can connect to MCP servers in two ways. Remote servers run on Google’s infrastructure behind managed HTTP endpoints. Enabling a product’s API also enables its remote MCP server, and you get fine-grained authorization, centralized audit logging and optional Model Armor screening for free. Local servers run on your machine through MCP Toolbox and talk to the agent over standard input and output.
The remote endpoints are refreshingly predictable:
BigQuery https://bigquery.googleapis.com/mcp
Cloud SQL https://sqladmin.googleapis.com/mcp
Spanner https://spanner.googleapis.com/mcp
Knowledge Catalog https://dataplex.googleapis.com/mcp
AlloyDB https://alloydb.REGION.rep.googleapis.com/mcp
Managed Spark https://dataproc-REGION.googleapis.com/mcp
A local BigQuery toolbox, by contrast, is just an npx command the agent launches for you:
npx -y @toolbox-sdk/server@>=1.1.0 --prebuilt bigquery --stdio
One quietly important detail from the docs: Google’s servers track MCP specification version 2026–07–28, which turns MCP into a stateless protocol. Each request carries everything it needs in HTTP headers, with no session handshake. That’s exactly what you want from a load-balanced, globally hosted endpoint.
What it can reach
For analytics and governance, the kit covers BigQuery, Dataflow, Managed Service for Apache Spark, Managed Service for Apache Airflow and Knowledge Catalog. On the database side it supports AlloyDB, Cloud SQL for MySQL, Cloud SQL for PostgreSQL and Spanner. For storage, it works with Cloud Storage.
Setting it up
You’ll need Node.js and npm, the gcloud CLI with Application Default Credentials configured, and one supported coding agent. These are the plugin steps; the IDE extension has its own guided install in the docs.
Step 1: Authenticate with Google Cloud
gcloud auth login
gcloud auth application-default login
Step 2: Install the plugin for your agent
Antigravity CLI:
agy plugin install https://github.com/gemini-cli-extensions/data-agent-kit-starter-pack
Gemini CLI (v0.6.0 or later):
gemini extensions install https://github.com/gemini-cli-extensions/data-agent-kit-starter-pack --ref 0.6.1
Claude Code (run claude first, then):
/plugin install data-agent-kit-starter-pack@claude-plugins-official
Codex:
codex plugin marketplace add https://github.com/gemini-cli-extensions/data-agent-kit-starter-pack
codex plugin add dak@data-agent-kit-starter-pack-marketplace
Step 3: Configure the MCP toolboxes
Skills work the moment the plugin is installed. The MCP toolboxes don’t. They need values like your project ID and region in the agent’s config file before they’ll start. For Claude Code, for example, that file sits under ~/.claude/plugins/cache/claude-plugins-official/data-agent-kit-starter-pack/0.6.1/.claude-mcp.json. The README lists the path for each agent. Restart the agent after editing.
Step 4: Verify
Run /mcp to see which servers are connected, then ask the agent "What skills are available?" If a server shows a "Connection closed" error, it's almost always a missing project or region value in that config file.
Step 5: Get the right IAM roles
Ask your admin for the MCP Tool User role (roles/mcp.toolUser) on the project, plus the normal product roles for whatever data you'll touch. One gotcha that will bite MySQL and Postgres folks: the kit only connects to Cloud SQL and AlloyDB instances with IAM database authentication enabled. Built-in database users and the Auth Proxy aren't supported.
Example 1: A root cause hunt across three systems
Back to our delivery-time mystery. The setup: shipments in BigQuery, inventory in Cloud SQL for MySQL, routing rules as JSON in Cloud Storage. The prompts below are real-shaped; table names, numbers and outputs are illustrative.
Prompt 1: confirm the baseline
Using BigQuery, calculate average delivery days per week for the last eight weeks from analytics.shipments, split by warehouse.
The agent loads its BigQuery skill, inspects the table schema, and then pauses to ask permission to use the read-only query tool. Once you approve, it runs something like this:
SELECT
DATE_TRUNC(DATE(shipped_at), WEEK(MONDAY)) AS week,
warehouse_id,
COUNT(*) AS shipments,
ROUND(AVG(TIMESTAMP_DIFF(delivered_at, shipped_at, HOUR)) / 24, 2) AS avg_delivery_days
FROM `analytics.shipments`
WHERE shipped_at >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 56 DAY)
AND delivered_at IS NOT NULL
GROUP BY week, warehouse_id
ORDER BY week, warehouse_id;
And summarizes the result:
week warehouse shipments avg_delivery_days
2026-08-03 WH-SOUTH-1 8,412 1.9
2026-08-03 WH-CENTRAL 1,106 4.8
2026-08-17 WH-SOUTH-1 4,970 2.0
2026-08-17 WH-CENTRAL 4,688 4.9
Here’s the interesting bit: no warehouse got slower. Volume shifted from the fast warehouse to the slow one, which dragged the blended average up. It’s the same shape as Google’s own demo, where a drop in average order value turned out to be a change in order mix rather than a real decline.
Prompt 2: cross into the operational database
Why did WH-CENTRAL suddenly ship so many southern orders? Check inventory in our Cloud SQL for MySQL database for the top SKUs it shipped since August 17.
Same chat thread, different system. The agent switches to the Cloud SQL tools, finds the inventory table, and carries the SKU list it just got from BigQuery straight into a MySQL query:
SELECT sku, warehouse_id, qty_on_hand, updated_at
FROM inventory
WHERE sku IN ('SKU-4471', 'SKU-4472', 'SKU-5190')
AND warehouse_id IN ('WH-SOUTH-1', 'WH-CENTRAL')
ORDER BY sku, warehouse_id;
Result: all three SKUs have been at zero in WH-SOUTH-1 since August 15. Notice that the “join” between BigQuery and MySQL happened in the conversation, not in a federated query. For an investigation, that’s exactly what you want.
Prompt 3: read the config that made the decision
Find the rule that decides where southern orders go when the nearest warehouse is out of stock. The rules are JSON files in gs://acme-ops-config/routing/.
The agent lists the bucket, opens the latest file and points at the relevant block:
{
"rule_id": "fallback-south",
"applies_to_zones": ["S1", "S2"],
"on_stockout": {
"fallback_warehouse": "WH-CENTRAL",
"carrier_tier": "ground"
},
"updated_at": "2026-08-14T18:02:11Z"
}
The chain is complete. A stockout triggered a fallback rule, the fallback rule used a ground carrier, and a ground carrier from a distant warehouse added almost three days per order. Revenue looked fine the whole time, which is why nobody noticed until the delivery metric moved.
Prompt 4: tell the humans
Write a five-line summary for the ops lead with the key numbers and one recommendation.
Average delivery time rose from 2.1 to 3.4 days because order volume shifted, not because any warehouse slowed down. Three top SKUs stocked out at WH-SOUTH-1 on Aug 15. The fallback routing rule sent those orders to WH-CENTRAL on ground shipping, which averages 4.9 days. WH-CENTRAL’s share of southern orders rose from 12% to 49%. Recommendation: restock the three SKUs and change the fallback carrier tier to express for zones S1 and S2.
Three systems, one thread, no tab gymnastics. You still read every query before trusting the conclusion, but reading a query against an unfamiliar schema is far faster than writing it.
Example 2: Turn the investigation into a dbt model that fixes itself
A one-off answer is nice. A model you can rerun next month is better.
Create a dbt project using dbt-bigquery with a model called delivery_performance that joins shipments to the latest status from analytics.shipment_events. Add unique and not_null tests on shipment_id, then run dbt build.
The agent creates a Python virtual environment, installs dbt-bigquery, scaffolds the project, and writes the tests:
version: 2
models:
- name: delivery_performance
columns:
- name: shipment_id
tests:
- unique
- not_null
Then dbt build fails. The first draft joined shipments directly to shipment_events, and every shipment has many events: created, picked, shipped, out for delivery. One shipment became five rows, and the uniqueness test caught it.
The agent reads its own terminal output, recognizes a fan-out join, and rewrites the model to keep only the latest event per shipment:
WITH latest_event AS (
SELECT shipment_id, status, event_ts
FROM {{ source('analytics', 'shipment_events') }}
QUALIFY ROW_NUMBER() OVER (
PARTITION BY shipment_id ORDER BY event_ts DESC
) = 1
)
SELECT
s.shipment_id,
s.warehouse_id,
s.shipped_at,
s.delivered_at,
le.status AS latest_status,
TIMESTAMP_DIFF(s.delivered_at, s.shipped_at, HOUR) / 24 AS delivery_days
FROM {{ source('analytics', 'shipments') }} AS s
LEFT JOIN latest_event AS le USING (shipment_id)
The rerun passes. Google’s walkthrough hit the same class of bug, where joining customers to their pet profiles multiplied orders for multi-pet households. The lesson is the same in both cases: the test caught the bug, not the agent’s intuition. Agents write code fast. Ask for data quality tests in the same prompt, every time.
Example 3: Schedule it with Orchestration Pipelines
The kit also bundles a Data Engineering tab and a skill called gcp-pipeline-orchestration for authoring, deploying and troubleshooting Airflow pipelines on Managed Service for Apache Airflow. Rather than Python DAG boilerplate, you describe pipelines in a declarative YAML format.
Create an orchestration pipeline that refreshes the delivery_performance dbt project every morning, then runs a BigQuery query that writes any warehouse averaging more than three delivery days into ops.delivery_alerts.
An abridged version of what comes back looks like this. Schedule and trigger settings are omitted here; the skill fills those in against the current schema, so check the Orchestration Pipelines docs for exact fields.
modelVersion: "1.0"
pipelineId: "delivery-health-daily"
runner: airflow
owner: "data-eng"
defaults:
projectId: "your-project-id"
location: "us-central1"
actions:
- pipeline:
name: "refresh_dbt_models"
framework:
dbt:
airflowWorker:
projectDirectoryPath: "delivery_health/dbt_project"
- sql:
name: "flag_slow_warehouses"
dependsOn:
- "refresh_dbt_models"
engine:
bigquery:
location: "US"
destinationTable: "your-project-id.ops.delivery_alerts"
query:
path: "delivery_health/flag_slow_warehouses.sql"
For deployment, the agent generates a GitHub Actions workflow, so a commit packages and ships the pipeline bundle to your Airflow environment. Day two is where it gets pleasant: run status shows up inside the IDE, and when a run fails, a Troubleshoot button hands the failure to the Data Engineering Agent. Google says it can tell an infrastructure problem, like a quota limit or a Spark out-of-memory error, apart from a code bug, then propose an inline fix.
Example 4: Prompts worth stealing
Swap in your own names and these make good first sessions:
- “Profile analytics.shipments: null rates per column, cardinality, and any values that look like outliers.”
- “Compare row counts and the latest updated_at between the orders table in Cloud SQL and its BigQuery replica for the last seven days, and flag any day that doesn’t match.”
- “Create a BigQuery SQL notebook that loads deduplicated orders from gs://my-bucket/raw/orders/ into a date-partitioned table.”
- “Create a Spark notebook that reads raw clickstream files from Cloud Storage and writes hourly partitions to a BigLake Iceberg table.”
- “Train a BigQuery ML boosted tree model on delivery_performance to predict late deliveries and show the evaluation metrics.”
- “Build a view of weekly delivery performance, then generate a LookML model and a Streamlit dashboard prototype on top of it.”
The part you shouldn’t skip: guardrails
A coding agent on your laptop runs with your privileges, types faster than you, and has the skepticism of a golden retriever. Google’s own documentation is unusually direct about the main risk: indirect prompt injection. An attacker plants instruction-like text somewhere your agent will read it, such as a BigQuery row, a Cloud Storage object or an email, and waits for the agent to treat that data as a command.
[Image 3: upload the PNG here. Caption: Treat every row your agent reads like an email from a stranger.]
Here’s the setup I’d put in place before the first real session, drawn from Google’s recommendations:
- Use service account impersonation, not your user credentials. Google recommends it for both the gcloud CLI and ADC when connecting to MCP servers. Give that service account the narrowest roles that still get the job done.
- Write IAM policies around the tools themselves. Allow and deny policies for MCP can key off the principal, the service or tool name, the OAuth client ID, and whether a tool is read-only. “Read-only tools only, for this identity” is a very reasonable default.
- Add a Principal Access Boundary so the agent’s identity can only reach projects in your own organization, even if a poisoned instruction points it elsewhere.
- Run agents somewhere constrained. Google’s canonical example is Cloud Workstations with internet access and root disabled, protected by VPC Service Controls. If you already run an egress proxy, the Organization Restriction Header is another way to fence agents inside your tenant.
- Turn on Model Armor for MCP traffic. A project-level floor setting screens tool calls and responses to Google’s managed MCP servers.
gcloud model-armor floorsettings update \
--full-uri='projects/PROJECT_ID/locations/global/floorSetting' \
--enable-floor-setting-enforcement=TRUE \
--add-integrated-services=GOOGLE_MCP_SERVER \
--google-mcp-server-enforcement-type=INSPECT_AND_BLOCK \
--enable-google-mcp-server-cloud-logging \
--malicious-uri-filter-settings-enforcement=ENABLED
Two caveats on Model Armor. With logging on, it records full payloads, so sensitive data can end up in your logs. And it’s only available in certain regions, so calling an MCP server in an unsupported jurisdiction can change routing and affect data residency. Google also advises enabling the prompt injection and jailbreak filter only when your MCP traffic actually carries natural language.
Two habits of my own on top of that: keep “always allow” for read-only tools and approve anything that writes one call at a time, and cap BigQuery spend with maximum bytes billed on the identity or project the agent uses. An enthusiastic agent can scan a lot of terabytes while it’s “just checking”.
Limitations and honest caveats
- It’s Preview software. Pre-GA terms apply, support may be limited, and the plugin warns of possible breaking changes before v1.0.
- IAM database authentication is mandatory for Cloud SQL and AlloyDB connections.
- Automated orchestration deployment only works with GitHub Actions for now. GitLab, Cloud Build and Azure DevOps shops will need to wire deployment themselves.
- Output varies. Google notes that responses depend on model version, workspace context and token depth. Short follow-up prompts to fill a missing parameter are normal, not a failure.
- Cross-system reasoning happens in the agent’s context. Carrying a few SKUs from BigQuery into MySQL is perfect. Carrying ten million rows is a job for a real pipeline, not a chat.
- Reviewing SQL is still your job. The kit removes the typing, not the accountability.
Who should try it this week
If you spend your days stitching answers together across a warehouse, an operational database and a bucket of config files, this is built for you. Analytics engineers who live in dbt will like the build, fail, fix loop. Consultants and anyone onboarding onto an unfamiliar data estate may get the biggest win of all, because understanding a strange schema quickly is exactly where an agent that can explore and query saves the most time.
Data Agent Kit doesn’t make hard questions easier. It makes the tab-hopping disappear, which leaves you with the part that was always the real job: deciding what to ask next, and whether to believe the answer.
Resources
- Agentic analytics with the Data Agent Kit (Google Cloud Blog)
- From weeks to minutes: the new agentic era of data pipelines (Google Cloud Blog)
- Data Agent Kit overview (documentation)
- Use MCP servers with Data Agent Kit (documentation)
- Mitigate indirect prompt injection risks (documentation)
- Data Agent Kit Starter Pack (GitHub)
- Codelab: Analytics with Data Agent Kit and Antigravity IDE
Examples in this post use illustrative table names, data and outputs. Product details reflect Google Cloud documentation as of September 2026; check the docs for the latest.
Data Agent Kit: What It Does, How It Works, and How to Use It Safely. was originally published in Google Cloud – Community on Medium, where people are continuing the conversation by highlighting and responding to this story.
Source Credit: https://medium.com/google-cloud/data-agent-kit-what-it-does-how-it-works-and-how-to-use-it-safely-b8656e9b948c?source=rss—-e52cf94d98af—4
About the Author
