BigQuery MCP Server: Connect Google BigQuery to AI Agents Safely

by Nic Davidson

August 20, 2026

Quick summary

A BigQuery MCP server lets AI agents like Claude query your Google BigQuery data through a standard protocol instead of ad-hoc integrations. Because BigQuery bills by bytes scanned, an unconstrained agent is not just a security risk but a budget risk: one careless full-table scan on a wide table costs real money. This guide covers what a BigQuery MCP server does, the three ways to set one up, and the cost and security controls that matter before you let an agent anywhere near your analytics data. DreamFactory generates a complete REST API over BigQuery, including full write support, and exposes it as MCP tools with role-based access control, revocable API keys, and per-call audit logging.

What is the Model Context Protocol (MCP)?

MCP is an open protocol, introduced by Anthropic, that standardizes how AI assistants connect to external systems. An MCP server advertises a set of tools, each with a name, a description, and a typed input schema. The AI agent discovers the tools, decides which one fits the task, and calls it. The server executes the call and returns results the model can reason over.

Before MCP, every AI-to-database connection was a custom integration. With MCP, any compliant client (Claude, IDE assistants, agent frameworks) can use any compliant server. The protocol solves connectivity. It deliberately does not solve governance: who the agent is, what it may touch, and what it costs. That part is on you, and with BigQuery the cost dimension is bigger than most teams expect.

Why BigQuery MCP is different

BigQuery is not a typical OLTP database, and the differences change how you should expose it to agents:

You pay per query, by bytes scanned. On-demand pricing bills for every byte a query reads. A human analyst learns to filter on partitions and select specific columns. An AI agent writes whatever SQL gets an answer, and SELECT * over an unpartitioned events table is exactly the kind of SQL a model produces. Cost control is not optional here; it is the core design constraint.
It is serverless. There is no warehouse to size or pause like Snowflake, and no connection pool to exhaust like Postgres. Capacity is not your problem, but that also removes a natural throttle: nothing slows an agent down except the limits you set.
Datasets, not schemas. BigQuery organizes tables into datasets within a project, and access is granted through Cloud IAM at the project, dataset, or table level. Table references look like dataset.table, and your governance model has to follow that shape.
It is an analytics store. The data is often the company's most aggregated, most sensitive view of itself: revenue rollups, customer scoring, usage metrics. The blast radius of overexposure is high even when the agent only reads.

The foundation: auto-generated REST APIs over BigQuery

DreamFactory's approach starts one level below MCP. Point DreamFactory at a BigQuery project with a service account, and it generates a complete REST API over every dataset the account can see: list tables, read schemas, query records with filtering, sorting, pagination, and field selection, and, as of the rebuilt connector in DreamFactory 7.7, create, update, and delete records as well.

That API layer is where governance lives. Every call is authenticated with a DreamFactory API key, authorized against a role that scopes access down to specific tables and HTTP verbs, and logged. The MCP server sits on top of that layer, not beside it, so an agent inherits exactly the same controls as any other API consumer.

What a BigQuery MCP server does

Once enabled, the MCP server advertises BigQuery tools to any connected agent: discover datasets and tables, fetch table schemas, read the data model, and query records. The agent asks in natural language; the tools translate to governed API calls; results come back as structured JSON the model can use.

In practice, a conversation looks like this: a user asks their assistant "which customers are at the highest churn risk this quarter?" The agent finds the customers table, reads its schema, and calls the query tool with a filter and a field list. It never sees a connection string, never holds a service account key, and never gets to run raw SQL against the project.

Common use cases

Conversational analytics. Business users query revenue, churn, and usage data in plain language, without writing SQL or waiting on an analyst.
Agent-driven reporting. Scheduled agents assemble weekly summaries from BigQuery tables and post them to Slack or email.
Operational lookups. Support and sales assistants pull a customer's aggregated history (orders, revenue, risk scores) mid-conversation.
Data quality watchdogs. Agents scan for anomalies, nulls, or drift in key tables and file alerts when something looks wrong.
Writeback workflows. With the 7.7 connector's full write support, agents can also record outcomes: scoring results, enrichment data, or workflow state, written to designated tables under a role that permits exactly that and nothing else.

The three ways to set up a BigQuery MCP server

1. Build a custom MCP server

Write your own server with the MCP SDK and the google-cloud-bigquery client library. You get total control and total responsibility: authentication, per-agent authorization, query limits, audit logging, deployment, and maintenance are all yours to build and keep patched. Reasonable for a platform team with specific requirements; a lot of surface area for everyone else.

2. Google's MCP Toolbox for Databases

Google's open-source MCP Toolbox supports BigQuery and gets you connected quickly with predefined tools. It handles the protocol and the connection well. What it does not give you is an independent governance layer: access is whatever the underlying credentials allow, and cost controls, role scoping per agent, and audit trails beyond BigQuery's own logs are yours to assemble around it.

3. DreamFactory: REST API plus MCP, auto-generated

DreamFactory generates the REST API and the MCP server together, with the governance layer built in: per-agent API keys, role-based access scoped to tables and verbs, rate limiting, and a per-call activity log that records who asked for what and what it returned. It runs where your data lives, including fully on-premises or in your own VPC, which matters when the analytics warehouse is the crown jewels.

Cost-control patterns for BigQuery MCP

Cap bytes billed. Set maximum_bytes_billed on the query layer so any query that would scan more than your ceiling fails instead of billing you. This is the single most important BigQuery-specific control.
Partition and cluster the tables agents touch. Partitioned tables turn "scan everything" into "scan today," often a thousandfold cost difference for time-scoped questions. If agents will query it, partition it.
Limit fields and rows in tool definitions. Tools that require a field list and enforce row limits keep responses small twice over: fewer bytes scanned in BigQuery, and fewer tokens burned in the model's context window.
Rate-limit per agent. A runaway agent loop is a cost incident. Per-key rate limits on the API layer contain it regardless of what the model decides to do.
Prefer curated tables over raw events. Point agents at aggregated marts, not the raw event firehose. The answers are better and the scans are smaller.

Security controls every production BigQuery MCP server needs

A dedicated, least-privilege service account. The account DreamFactory uses should see only the datasets agents need. Grant dataset-level IAM roles, not project-wide ones.
Role-based access above IAM. Cloud IAM bounds what the platform can reach; DreamFactory roles narrow what each key can reach, down to a single table and verb. A read-only reporting key physically cannot write, whatever the service account could do.
Authorized views and policy tags for sensitive columns. BigQuery's authorized views and column-level policy tags keep PII and payroll-grade fields out of reach at the warehouse level, a second fence behind the API layer.
Revocable, identifiable credentials. Every agent holds its own API key. Revoking one key ends one agent's access without touching anything else, and without rotating the service account.
Audit on both layers. BigQuery's INFORMATION_SCHEMA.JOBS shows every query the platform ran; DreamFactory's per-call log shows which key asked for it, when, and with what outcome. Together they answer "what did the agent do?" precisely.

Common pitfalls when exposing BigQuery to AI agents

Handing the agent raw SQL access. Text-to-SQL against a per-bytes-scanned warehouse with no caps is how you convert a hallucination into an invoice.
One shared credential for every agent. When all agents share a key, you can neither attribute cost nor revoke one consumer. Per-agent keys are the unit of control.
Skipping the schema step. Agents write better queries when a tool serves them the data model first. Guessing column names produces failed calls and wasted scans.
Exposing every dataset by default. Scope the service account and the roles to the datasets agents actually need. "Everything the project can see" is rarely that.
Forgetting the response is context. A 10,000-row result does not make the model smarter; it evicts the instructions you gave it. Enforce limits server-side.

How DreamFactory fits in

DreamFactory 7.7 ships a rebuilt BigQuery connector: full schema discovery, filtered and paginated reads, and complete write support (create, update, delete) through the same _table API every other DreamFactory database connector uses. The MCP server exposes it to agents with the platform's standard governance: role-scoped keys, rate limits, request tracing, and audit logging on every call. Setup is a service account JSON and a project id; the API and the MCP tools generate from there. It deploys on-premises, in your VPC, or anywhere Docker runs.

Frequently asked questions

What is a BigQuery MCP server?

A server that exposes Google BigQuery data as standardized MCP tools, so AI agents like Claude can discover schemas and query data through governed, structured calls instead of raw SQL access.

Why not just give the agent BigQuery credentials?

Because BigQuery bills by bytes scanned and credentials are all-or-nothing. An agent with raw credentials can scan anything the account sees and cost whatever its SQL happens to cost. An API layer inserts roles, limits, and logging between the agent and the warehouse.

How do I stop an AI agent from running expensive BigQuery queries?

Cap maximum_bytes_billed, partition the tables agents query, enforce field selection and row limits in tool definitions, and rate-limit each agent's key. Each control works independently; together they bound the worst case.

Does DreamFactory support writing to BigQuery, not just reading?

Yes. The rebuilt connector in DreamFactory 7.7 supports create, update, and delete through the standard _table API, governed by the same role and verb scoping as reads. A role can allow reads on every table and writes on exactly one.

How does authentication work between the agent and BigQuery?

The agent authenticates to DreamFactory with its own API key (or an OAuth session). DreamFactory authenticates to BigQuery with a dedicated service account. The agent never holds Google credentials.

Can I expose only some datasets to agents?

Yes, twice over: grant the service account dataset-level IAM on only the datasets you intend to expose, then use DreamFactory roles to narrow each key further, down to specific tables and verbs.

How do I audit what an agent did in BigQuery?

Combine BigQuery's INFORMATION_SCHEMA.JOBS (every query, bytes scanned, cost) with DreamFactory's per-call activity log (which key, which endpoint, which outcome). The two views join cleanly because every agent call flows through the API layer.

Does this work with Claude Desktop and other MCP clients?

Yes. DreamFactory's MCP server implements the standard protocol with OAuth-based client registration, so any compliant MCP client can connect and discover the tools its role permits.

What about BigQuery's own AI features like Gemini in BigQuery?

They are complementary. Gemini in BigQuery helps humans write SQL inside Google's console. An MCP server puts governed BigQuery access inside your agents and assistants, wherever they run, under your access model.

Is DreamFactory's BigQuery support open source?

The MCP server is open source, and the platform's core API generation is the foundation of the free tier. The rebuilt BigQuery connector ships with DreamFactory 7.7.

Healthcare

Financial Services

Government

Manufacturing