Google Data Agent Kit and MCP Toolbox vs Data Workers: Build Your Own Data Agents, or Run a Finished Platform

Your data engineers have probably already tried it. Someone installed the Data Agent Kit plugin in Claude Code or VS Code, pointed it at a BigQuery project, and watched it write a dbt model, an Airflow DAG and a Spark job from a sentence. Someone else stood up MCP Toolbox for Databases on Cloud Run with a tools.yaml file and gave an internal agent query access to Cloud SQL, BigQuery and the Snowflake warehouse finance still runs. A third engineer has an ADK prototype that watches failed DAG runs. The demo went well, and now the team is asking a fair question: why buy a platform when Google hands us the parts for free?

That instinct deserves respect. These are good parts, they're open source, and Google ships updates to them almost weekly. The Data Agent Kit plugin reached version 1.0 on September 29, 2026. MCP Toolbox for Databases shipped 13 minor releases between its 1.0 in April and its 1.13 in late September. ADK is on its second major version. If your team wants to build data agents, Google has made that much easier.

Google's Data Agent Kit, MCP Toolbox for Databases and ADK are the parts bin for building your own data agents on Google Cloud. [Data Workers](/product/data-agents-swarm/) is the finished crew: specialist agents, one governed context graph, approvals, receipts and rollback, already built and running across every platform you use. Data Workers is the agentic data platform: the way to run the whole data lifecycle and the path to an autonomous data platform. Google Cloud is where your analytics run, and its kit is a strong way to write code there. Keep it. This page is about what you'd still have to build on top of it, and what that costs to keep running.

This is the build-or-buy page. For one Google agent against the swarm, read BigQuery Data Engineering Agent vs the Data-Agents Swarm. For the wiring on a Google Cloud stack, read Data Workers on Google Cloud.

Key takeaways

• •Parts, or a platform. The Data Agent Kit gives a developer's coding agent 37 skills and Google's managed MCP servers. MCP Toolbox for Databases gives any agent governed query access to 40+ databases. ADK is a framework for writing agents. Data Workers ships 20+ specialist agents that already own the work.
• •The kit acts as the person in the seat. It runs with the signed-in user's Google Cloud credentials, and its safety skill asks for consent in the chat before a destructive command. That's the right design for a developer toolkit.
• •The build list is long. A context graph across platforms, specialist agents, blast-radius scoping, approvals by domain, receipts, rollback and downstream verification. Each one is a product, and each one needs an owner after launch.
• •Every Data Workers change is approved or reversible and leaves a tamper-evident receipt, with autonomy set per domain from L1 observe to L4 autonomous.
• •Use both. Build your own agents with Google's kit. Call Data Workers' agents as tools over MCP, or load them into ADK through our adapter. Nothing migrates.

Six things Data Workers adds on top of Google's kit

1. Agents that own a class of work. The kit makes one developer's session far more capable. Data Workers runs standing specialists: Incident Debugging, Data Change Review, Schema Evolution, Quality Monitoring, Access & Governance, Cost Savings & Data Cleanup, Data Migration and more. Each one owns a standing queue of work.

2. One governed context graph across every platform. The kit's MCP servers reach Google Cloud services, and Toolbox connects to one database per source. Data Context Wizard joins BigQuery schemas and job history, dbt manifests, Airflow DAG state, Snowflake query history and BI metadata. Every fact carries its source, author and the time it was observed.

3. Blast radius before any write. The Data Change Review agent takes the tables a change touches and walks lineage past BigQuery into Airflow, dbt, Snowflake and the dashboards that read them. It posts the blast radius before the change ships.

4. Approvals by domain, with no self-approval. Every proposed change lands in Spellbook Data Catalog, where a named owner approves, steers, sends back or rolls it back. No agent can approve or promote its own work, and that rule is enforced in code.

5. Receipts and rollback for every change. Every change Data Workers executes records who or what made it, why, what it touched, who approved it and how to undo it.

6. Fixes that get verified. The Autonomous Data-Conductor takes a problem through detect, diagnose, fix, review, verify and remember. It reruns after approval and only closes the work once downstream checks pass.

Behind all six is the coding agent your team already uses as the way in, such as Claude Code, Codex or Cursor. That can be the same coding agent that has the Data Agent Kit installed. Every Data Workers agent is an MCP server.

One release, six systems

Here is a night most data teams will recognize. It's an illustration, not a customer case. The team has built a pipeline-repair agent with ADK, using MCP Toolbox for Databases for its Cloud SQL and BigQuery tools.

• •Tuesday 23:40. An app release changes orders.amount in Cloud SQL from integer cents to a numeric dollar value.
• •02:05 Wednesday. The nightly Managed Airflow DAG fails while loading stg_orders into BigQuery: the new type doesn't fit the staging column.
• •02:20. The home-built agent reads the error, widens the column with an execute_sql call through Toolbox and reruns the DAG. The run goes green. The agent did exactly what it was built to do.
• •03:00. The dbt model fct_revenue still divides amount by 100. Revenue is now one hundredth of the true figure. Its not-null and uniqueness tests pass.
• •03:00. The nightly export lands the wrong revenue in the finance team's Snowflake warehouse.
• •08:30. The Tableau revenue tile goes to the CFO.

Nothing in Google's kit failed here. The agent fixed what it could see. The cost of the night came from four systems it had no reason to know about, and from the gap between "the run is green" and "the number is right". Closing that gap is the build list.

What Google's agent kits cover, as of October 2026

Google now presents its data portfolio as the Agentic Data Cloud. These are the developer building blocks within it, from Google's documentation, release notes and GitHub repositories.

One correction to a common belief: the kit is not Dataform-only. Google's April announcement said it picks frameworks such as dbt, Spark or Airflow, and the plugin now ships a dbt-bigquery skill that builds and changes dbt projects targeting BigQuery. The docs pages themselves still describe Airflow, Spark and notebooks.

Every row is a capability a developer uses inside Google Cloud, with their own credentials. None of them describes a standing owner for a class of work across the estate.

One platform, not one more tool

Writing pipeline code is one job on a data team's list. The same team keeps the catalog honest, answers questions, runs quality checks, closes incidents, runs schema changes and migrations, handles access, protects sensitive data, cuts spend and keeps models fed with good data. Each point tool covers one or two of those, and each one adds another console, another contract and another handoff. A home-built agent adds one more: a codebase your team now owns.

Data Workers covers the whole data lifecycle with one context graph, one approval flow and one audit trail. We score the same ten stages on every comparison page, so you can compare tools across pages. Google's kit leads on its two home stages, Pipelines & Ingestion and Analytics & Insights, which is exactly what it was built for.

Google's kit vs Data Workers on the outcomes you buy

The ten-stage view shows breadth. This view scores eight outcomes a data leader pays for when the question is build or buy. Google's kit leads on two, both on its own ground: code written in the IDE, and building blocks for agents you write yourself. Data Workers leads on the six that make up the operating layer every production agent needs.

These are directional scores of scope, not benchmarks. We've shown the reasoning so you can check every line against the Google docs and repositories linked below.

The build list: what "we'll build it ourselves" includes

Your team can build this. Strong data platform teams have the skills, and Google's parts remove a lot of the plumbing. Here is what the incident above says you'd be signing up for, beyond the first demo.

1. A context graph across platforms. Lineage and metadata joined across BigQuery, Knowledge Catalog, dbt, Airflow, Snowflake and BI, kept fresh as each system changes, with provenance on every fact. Toolbox gives you queries per database. The join, the freshness and the provenance are yours.

2. Specialist agents. One agent that does everything ends up doing nothing well. Incidents, change review, schema evolution, quality, access, cost and migrations each need their own prompts, tools, evaluations and failure modes. Each is a codebase.

3. Blast-radius scoping. Before any write, compute what it touches across systems and refuse writes outside the scope. That needs the context graph plus rules for every platform's objects.

4. Approvals. A queue, named approvers per domain, steering and send-back, escalation when nobody answers, and a hard rule that no agent approves its own work. ADK's tool confirmation is a building block for this; the workflow around it is yours.

5. Receipts. A record of every change that an auditor can read: who or what made it, why, what it touched, who approved it, how to undo it, and evidence it hasn't been edited since.

6. Rollback. An undo path for each kind of change on each platform, tested before you need it.

7. Verification. After a fix, check the numbers downstream as well as the run status, and keep the work open until they're right.

Then there's the part no build plan budgets for: keeping it running. Models change behavior between versions. The MCP spec moves. Toolbox released a new minor version roughly every one to two weeks this summer. ADK went from 1.0 to 2.0 in a year, and in 2026 it published two critical security advisories, both fixed upstream, one of them about forged tool confirmations. Somebody on your team owns every upgrade, every regression and every new platform the business adopts. That's the honest comparison: your engineers' time on the operating layer, every quarter, against a platform where that layer is already the product.

Why doesn't Google just do this itself?

Because Google built these for a different job, and built them well for that job.

The Data Agent Kit is a free developer toolkit. Its pitch is to meet practitioners "where they already build", in VS Code and coding agents, and it acts with the developer's own Application Default Credentials. Its safety model fits that design: a skill that stops and asks the person in the chat before a destructive command, and documentation on locking the environment down with VPC Service Controls and Model Armor. MCP Toolbox for Databases is a well-built door to your databases. ADK is a framework. Each one gives the developer more power and leaves the operating decisions to the team, which is the right call for parts that every kind of developer uses.

Owning work across production systems is a different product category. It needs standing, scoped identities instead of a person's session, blast radius computed across systems Google doesn't run, approvals that vary by domain, rollback paths and a receipt an auditor can read. And it means taking responsibility for changes inside a dbt project on Snowflake, a self-managed Airflow deployment or a Tableau workbook. A general toolkit shouldn't impose one approval model on every developer, and Google has good reasons not to take liability for systems outside its cloud. That's the product Data Workers is.

Where Google's kit stops

Each limit below comes from Google's own documentation or repositories. None of them is a flaw. They follow from building developer parts.

It runs as the person in the seat. The plugin's prerequisites are gcloud auth login and application-default login. Whatever the agent does, it does with that user's access, inside that user's session.

Its world is Google Cloud. The kit's services and managed MCP servers are Google Cloud services. Its dbt skill targets BigQuery. Toolbox can query Snowflake or Trino, one source at a time, with no lineage between them.

Consent lives in the chat. The data-loss-prevention skill asks the user before irreversible commands. There's no shared queue, no named approver per domain and no record outside the conversation and Cloud Audit Logs.

Deployment isn't verification. The pipelines guide deploys on merge through GitHub Actions. Checking that the numbers downstream are right after the run is left to you.

The back office sits outside it. Access requests, cost cleanup, cross-system schema changes, migrations off Google Cloud and audit evidence are not what a developer toolkit is for. Data Workers runs every one of them.

Where the two overlap

"Both" means your engineers keep Google's kit for building, and Data Workers owns what happens once a change leaves the session.

What it costs

Google's parts are free to download. The Data Agent Kit README calls the plugin free, and MCP Toolbox for Databases and ADK are Apache 2.0. You pay for the Google Cloud services they call, for the models your agents use, for wherever you host Toolbox and your ADK agents (Cloud Run, GKE or Agent Runtime), and for the engineers who build and maintain the seven items on the build list.

Data Workers is a flat platform fee. The Apache 2.0 core is free. A pilot is $7,500 one-time. Scale starts at $1,000 a month and Enterprise at $3,000 a month (billed annually). Seats are unlimited, there's no usage meter, and there's no markup on model spend because you bring your own model. See pricing.

The comparison that matters is engineer time. The kit makes the first agent cheap. The operating layer under it is what costs money every quarter, and that's where Data Workers puts its engineering.

The case for your CFO

The outcome. The data your business reads stays correct across BigQuery, dbt, Snowflake and the dashboards, and the recurring back-office work (incidents, reviews, access tickets, cost cleanup) runs without senior engineers driving it. Your engineers spend their time on agents and pipelines that are specific to your business, and the approval queues and audit trails come with the platform.

The risk story. Every Data Workers agent starts observe-only (L1). At propose (L2), every change is a draft a person approves. At act reversibly (L3), agents run only changes they can undo, in the domains you've moved up. Autonomous (L4) is a per-domain choice, never a default. Every write is scoped before it runs, no agent approves its own work, and every receipt records what changed, why, who approved it and how to undo it. Zero migration: your data stays in BigQuery and everywhere else it lives today.

Why now. Google's kits make it cheap to put agents in front of production data. The more agents your engineers build, the more you need one place that scopes, approves, records and verifies what they do.

The first win. Cross-system blast radius on every pull request that touches a BigQuery table read outside Google Cloud, in observe mode, from the first week.

What stays the same. BigQuery stays where your analytics run. The Data Agent Kit, Toolbox and any ADK agents you've built stay in your engineers' hands. IAM and Knowledge Catalog stay authoritative.

The pilot path. Start with a pilot on one domain, usually change review for tables that leave Google Cloud. See pricing; the pilot is credited in full against the first year.

The sentence to repeat upstairs: "Google gives our engineers good parts to build agents on BigQuery; Data Workers is the finished platform that runs our data lifecycle across every system, with an approval and a receipt for each change, so our engineers only build what's unique to us."

The fastest first win: add Data Workers to the coding agent that already has the kit

Start where your engineers already work. Add Data Workers as an MCP server in the same coding agent that has the Data Agent Kit installed, and connect it to BigQuery, the Git repositories, the dbt project and Airflow, all in observe mode, with the kit's Knowledge Catalog server beside it. For Claude Code it looks like this (example; your install and credentials will differ):

# Example: Google's kit and Data Workers side by side in Claude Code
claude plugin marketplace add https://github.com/GoogleCloudPlatform/data-agent-kit-plugin
claude plugin install dak@dak-marketplace
# Data Workers agents from a clone of the open-source repo (see /opensource-docs/client-setup/)
claude mcp add --scope user dw-catalog -- "$(pwd)/start-agent.sh" dw-context-catalog
claude mcp add --scope user dw-incidents -- "$(pwd)/start-agent.sh" dw-incidents

Now when an engineer asks the coding agent to change a dbt model with the kit's dbt skill, the same agent can call Data Workers' blast_radius_analysis before opening the pull request. It gets back which Airflow DAGs, Snowflake tables and dashboards read the changed columns. Nothing is written yet.

When your reviewers have agreed with those reports for a few weeks, move the domain up to propose: the agents open the paired fix and the rerun plan for approval in Spellbook.

What each Data Workers product does

Data-Agents Swarm. 20+ specialist agents that own classes of work: Pipeline Building, Orchestration, Data Change Review, Schema Evolution, Incident Debugging, Quality Monitoring, Access & Governance, Security, Identity, Cost Savings & Data Cleanup, Data Migration, Streaming, MLOps and more. Each is an MCP server. On BigQuery, the governance agents list privileges and propose time-boxed grants, the cost agent reads spend from the Jobs API, and the orchestration tools trigger Managed Airflow DAG runs after approval.

[Autonomous Data-Conductor](/product/autonomous-data-conductor/). The orchestrator that owns an outcome rather than a step. It runs detect, diagnose, fix, review, verify and remember across the estate, routes work to the right agents and scopes the blast radius before anything changes. It also answers as a peer agent over A2A.

Data Context Wizard. One governed graph across BigQuery, Snowflake, dbt, Airflow and BI, with 50+ connectors. BigQuery connects as a full control plane, including permissions and policy. Knowledge Catalog entries reach it through your coding agent over MCP.

[Spellbook Data Catalog](/product/spellbook-data-catalog/). The control plane for agent work, in preview. Every proposed change lands in one inbox to approve, steer, send back or roll back, and an authority guard in code stops any agent approving its own work.

Autonomy guardrails and security

Google's kit manages risk by keeping a person in the session and asking before destructive commands. Data Workers manages risk for work nobody is watching live, with graded, reversible control.

• •New deployments start observe-only. You raise autonomy one domain at a time, as the receipts earn trust.
• •Autonomy is set per domain, from L1 observe through L2 propose and L3 act reversibly to L4 autonomous. Change review can propose fixes while access grants stay at observe.
• •Every write is scoped before it runs, with blast radius computed across platforms.
• •Every change is approved or reversible and leaves a tamper-evident receipt: what changed, why, who approved it and how to undo it.
• •No agent can approve or promote its own work. This is enforced in code.
• •Least privilege. Data Workers acts with the grants you give it, through each platform's own permission system, including BigQuery IAM.
• •Read-only by default for your own agents. Our ADK adapter exposes read tools unless you opt in to write tools.
• •Zero migration. Data Workers stores metadata and scrubbed facts about your data, not copies of your tables.

"Toolbox has read-only mode and ADK has tool confirmation. Isn't that enough?"

They're useful controls, and we'd turn both on. Toolbox's read-only mode (added in 1.10) keeps an agent from writing through that server. ADK's tool confirmation pauses an agent until a person says yes. Google's managed MCP servers let IAM policies condition on whether a tool is read-only.

Each of those is a gate on one call. None of them knows that widening a BigQuery column at 02:20 changes revenue in Snowflake at 03:00. A gate can stop a write; it can't tell the approver what the write will break, route it to the person who owns finance data, undo it next week or prove to an auditor what happened. MCP gives an agent one more tool. Data Workers gives your team the operating model around the tools: an owner for each class of work, blast radius across systems, a named approver per domain, a rollback path and a shared record. Every Data Workers agent is itself an MCP server, so your ADK agent can call the Change Review agent before it asks a person to confirm.

How it fits together

Getting started takes no migration. Connect Data Workers to BigQuery, your Git repositories, the dbt project, Managed Airflow and your BI tool. Knowledge Catalog, Dataform and your BI tool connect over their APIs or MCP servers today. The Context Wizard builds the graph, every agent starts observe-only, and the first thing you see is the cross-system blast radius of the changes your engineers, and their agents, are already making.

When Google's kit alone is enough

Google's kit alone can be enough if your goal is developer productivity on Google Cloud: engineers writing dbt, Dataform, Airflow and Spark code faster, with a person reviewing and running every change, and an estate that lives mostly in Google Cloud. It's also enough for a narrow internal agent with a clear owner and low blast radius, such as a read-only assistant that answers questions from Cloud SQL through Toolbox.

Most teams reach a point past that. When agents start to act on production data, when a BigQuery table feeds Snowflake, dbt or a BI tool outside Google Cloud, or when your senior engineers are spending their quarters building approval queues and audit trails instead of data products, the parts were never the expensive part. The operating layer is.

Use both: build with the kit, call Data Workers over MCP

The best setup we see uses both. Your engineers keep the Data Agent Kit in their IDE and coding agent. Your platform team builds the agents that are specific to your business with ADK and MCP Toolbox for Databases. And every one of those agents calls Data Workers' agents as tools over MCP, or loads them through our ADK adapter, for blast radius, review, fixes, approvals and receipts. Google Cloud stays where your analytics run. Data Workers runs the data lifecycle around it, across every platform you use.

FAQ

What is MCP Toolbox for Databases? It's Google's open-source MCP server for databases, Apache 2.0, in the googleapis/mcp-toolbox repository (formerly genai-toolbox). You define tools in a tools.yaml file or use prebuilt ones, and it handles authentication, connection pooling and telemetry. It supports 40+ sources, including BigQuery, Cloud SQL, AlloyDB, Spanner, Postgres, Oracle and Snowflake. Version 1.0 shipped on April 10, 2026; 1.13.1 shipped on September 25, 2026.

What is the Google Cloud Data Agent Kit? A free set of skills, MCP connections, an IDE extension and a plugin that bring Google Cloud data services into VS Code, Claude Code, Codex CLI, Gemini CLI and Antigravity. Google announced it in preview on April 22, 2026, and the plugin reached version 1.0 on September 29, 2026.

Does the Data Agent Kit support dbt? Yes, for BigQuery. The plugin ships a dbt-bigquery skill that creates and changes dbt projects targeting BigQuery, alongside a Dataform skill. It doesn't describe dbt on Snowflake or Databricks. Data Workers works on dbt projects across warehouses.

Can we build what Data Workers does with ADK and Toolbox? Yes, with enough engineering time. The build list is a context graph across platforms, specialist agents, blast-radius scoping, approvals, receipts, rollback and downstream verification, plus keeping all of it current as models, MCP and the frameworks change. Most teams would rather spend that time on agents specific to their business.

Can our ADK agents call Data Workers? Yes. Every Data Workers agent is an MCP server, and ADK supports MCP tools. We also ship an ADK adapter that turns Data Workers tools into ADK function declarations, read-only by default. The Conductor and Search agents also answer as peers over A2A.

Will we be locked in? No. The Data Workers core is Apache 2.0, it connects over MCP, and nothing migrates: your data stays in BigQuery and everywhere else it lives.

How much does Data Workers cost? A free Apache 2.0 core, a $7,500 one-time pilot, Scale from $1,000 a month and Enterprise from $3,000 a month (billed annually), with unlimited seats and no usage meter. See pricing.

Sources

Sources for Google Cloud capabilities and statuses, checked October 2, 2026: the Data Agent Kit overview, pipelines guide, MCP servers page, prompt injection guidance and plugin install guide (all updated September 30, 2026); the Data Agent Kit plugin repository (README, skills and changelog, 1.0.0 on September 29, 2026); What's new in the Agentic Data Cloud (April 22, 2026); the MCP Toolbox for Databases repository, its releases (1.13.1 on September 25, 2026) and documentation site; the ADK documentation and adk-python releases (2.11.0 on October 2, 2026); the GitHub security advisory GHSA-8qg5-x5vm-75jx (July 29, 2026); and supported MCP products (updated October 2, 2026). Product names and statuses change quickly; if we've got something wrong, tell us and we'll fix it.