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.
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.
BigQuery is not a typical OLTP database, and the differences change how you should expose it to agents:
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.dataset.table, and your governance model has to follow that shape.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.
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.
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.
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.
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.
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.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.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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.