BigQuery MCP Server: Read-Only Setup and Byte Caps

Google's BigQuery MCP server lets Claude, Cursor or any MCP client list your datasets and run SQL at bigquery.googleapis.com/mcp, as whoever signs in. By default, one of its tools runs INSERT and DROP, and nothing caps the bytes a query scans. Give the agent its own read-only identity and a byte limit before its first query.

Whether that DROP goes through depends on who signed in: the agent runs as that identity. Connect Claude's custom connector with your own Google account and the agent gets your permissions. If you can drop a table, so can it.

What an agent can do on its first connection

The server is live as soon as the BigQuery API is enabled, and Google says that "for new projects, the BigQuery API is automatically enabled." On October 21, 2026, its tool list, which answers without a sign-in, had nine tools: list_dataset_ids, get_dataset_info, list_table_ids, get_table_info, execute_sql_readonly, execute_sql, get_query_results, get_job and cancel_job. Write-ups from earlier in 2026 count fewer.

Two of them run SQL, and both are on by default:

• execute_sql_readonly "is restricted to only SELECT statements."
• execute_sql "can execute any query that bigquery supports including: SQL Queries (SELECT, INSERT, UPDATE, DELETE, CREATE, etc.)" Google's own examples for it include DROP TABLE and DROP SCHEMA.

execute_sql's own description tells the model to "prefer the execute_sql_readonly tool if possible." That's advice, not a block.

Both SQL tools take a dryRun flag, a job timeout, labels and a project ID. Neither takes a byte limit. A dry run returns how many bytes a query would process, so a careful agent can check first. Nothing forces it to. Google's usage limits are three minutes of processing per query and 3,000 rows per result: time and result size, not bytes. And "there is no limit on the number of calls that can be made to the MCP server."

How BigQuery bills an agent's queries

On-demand queries cost $6.25 per TiB in the US multi-region, after the first free TiB each month. You're charged for the columns a query reads, "even if you set an explicit LIMIT on the results." So an agent that peeks at a wide table with SELECT * and LIMIT 10 pays for every column it touched. Errors and cache hits cost nothing.

BigQuery has a per-query brake. When you set maximum bytes billed, the query's size is estimated first, and if it's over the limit, it "fails without incurring a charge." But it's a job setting, and Google's MCP tools don't expose it, so neither you nor the agent can set it there.

One table-level guard does work with any client. A table created with require_partition_filter refuses unfiltered scans, and the agent gets back "Cannot query over table 'project_id.dataset.table' without a filter that can be used for partition elimination."

Which BigQuery MCP server fits your team

Three servers are worth knowing, and they aren't directly comparable.

	Google's remote server	MCP Toolbox for Databases	ergut/mcp-bigquery-server
Who maintains it	Google, managed	Google, open source (googleapis/mcp-toolbox, v1.14.0 on October 8, 2026)	One community maintainer, last release April 2025
Runs where	Google's endpoint, Streamable HTTP	Your machine, stdio	Your machine, Node.js
Tools	9: metadata, two SQL tools, job tools	9 in the prebuilt set, including forecast, ask_data_insights, analyze_contribution and search_catalog	1: query
Writes by default	Yes, through execute_sql	Yes, all SQL statements allowed	No: SELECT only, checked with BigQuery's own dry run
Byte cap by default	None	None	1,000,000,000 bytes per query
Rows returned	Up to 3,000	50 by default	No limit in the code
Pick it when	You want nothing to host and IAM to control access	You need a custom tool over a parameterized SQL query, or can't enable the remote server (Google's two reasons for local)	You want a quick local read-only trial

For most teams, we'd pick Google's remote server, locked down with the steps below.

Google has one more route that isn't an MCP server. Its Conversational Analytics data agents "can't perform write operations and can't run DML queries," and a big_query_max_billed_bytes setting makes a query fail at no charge if its estimate runs over. That's read-only by design, with a byte cap you can set.

Before the agent's first query: make it read-only and cap the bytes

Google's remote server

1. Create a separate identity for the agent. Google recommends "a separate identity for agents that are using MCP tools so that access to resources can be controlled and monitored." For Claude, that means a separate Google account for the agent. Gemini CLI and Toolbox sign in with Application Default Credentials, so they can run as a service account, and Toolbox can also impersonate one. For agents that should act as each person instead, see our guide to per-user OAuth for MCP.
2. Grant three roles, and no more. MCP Tool User (roles/mcp.toolUser) on the project, BigQuery Job User (roles/bigquery.jobUser) to run jobs, and BigQuery Data Viewer (roles/bigquery.dataViewer) on the datasets the agent should read. Data Viewer can't write, so a DROP fails. Grant on datasets, not single tables. Our own BigQuery docs ask the same of anyone connecting Querio: "Table-level permissions won't expose INFORMATION_SCHEMA."
3. Deny the write tool. Google: "You can restrict access to the execute_sql tool by creating a deny policy that restricts read-write MCP tool use." The policy matches every tool not marked read-only, and cancel_job isn't marked read-only either, so the agent likely loses that one too.
4. Cap the bytes with BigQuery's custom quotas. QueryUsagePerDay caps a whole project (default: 200 TiB a day). QueryUsagePerUserPerDay is one number applied to every user and service account in the project, and Google says "you can't assign a custom quota to an individual user or service account." Both work only on on-demand pricing and reset at midnight Pacific Time. Google's MCP docs add that you're "still subject to the quotas enforced by the APIs called by the MCP server tools," which we read as covering the agent's queries.
5. Give the agent a billing project of its own. This is our recommendation; we haven't run it. Grant the agent Job User only in that project, Data Viewer on the data project's datasets, and set QueryUsagePerDay there. MCP queries "are charged to the project specified in the project_id field," and the agent passes that ID on every call. So the cap holds only if the identity has Job User nowhere else. An agent signed in as someone who can run jobs in the main project can bill there and skip the cap.
6. Audit by label. Every query the server runs carries the job label goog-mcp-server: true, which is how you find the jobs the agent ran.

MCP Toolbox for Databases

Toolbox allows writes and caps nothing unless you say so. Two environment variables fix both: BIGQUERY_READONLY=true allows only SELECT, and with BIGQUERY_MAXIMUM_BYTES_BILLED set, "queries that exceed this limit fail before executing and cost nothing." Toolbox's own docs also say its execute_sql tool "shouldn't be used for production agents."

For Claude Code, put this in .mcp.json in the project root. This is the config from Google's MCP Toolbox page plus the two variables from Toolbox's own docs (v1.14.0), with their 10 GiB example as the cap. We read it in the code; we didn't run it.

{
  "mcpServers": {
    "bigquery": {
      "command": "./PATH/TO/toolbox",
      "args": ["--prebuilt","bigquery","--stdio"],
      "env": {
        "BIGQUERY_PROJECT": "PROJECT_ID",
        "BIGQUERY_READONLY": "true",
        "BIGQUERY_MAXIMUM_BYTES_BILLED": "10737418240"
      }
    }
  }
}

ergut/mcp-bigquery-server

ergut's server ships read-only and capped. It asks BigQuery for a dry run, rejects anything that isn't a SELECT, and passes a 1,000,000,000-byte cap to every real query. That's a decimal 1 GB, not 1 GiB. Change it with --maximum-bytes-billed. Give it the same narrow identity anyway: SELECT-only says nothing about which tables it can read.

Connect Claude, Cursor or Gemini CLI to the remote server

Google's client setup page uses OAuth for both Claude and Cursor. Google says "custom redirect URIs aren't supported," so use the exact ones below. For the general pattern across warehouses, see our step-by-step guide to connecting Claude over MCP.

Claude. In the Google Cloud console, go to Google Auth Platform > Clients > Create client, and pick Web application. Add https://claude.ai as an authorized JavaScript origin and https://claude.ai/api/mcp/auth_callback as the redirect URI. Copy the secret; Google shows it only once. In Claude, add a custom connector for https://bigquery.googleapis.com/mcp and enter the client ID and secret under Advanced settings. Sign in with the agent's Google account, not yours. Google lists the same client type and redirect URI for Claude Desktop and Claude Code.

Cursor. Create the same kind of client with Cursor's redirect URI: https://www.cursor.com/agents/mcp/oauth/callback for web and Cursor agents, or http://localhost:8787/callback for the desktop app. Then configure the server in Cursor with static OAuth.

Gemini CLI. Merge this from Google's January 7, 2026 launch post into ~/.gemini/settings.json:

{
  "mcpServers": {
    "bigquery": {
      "httpUrl": "https://bigquery.googleapis.com/mcp",
      "authProviderType": "google_credentials",
      "oauth": {
        "scopes": [
          "https://www.googleapis.com/auth/bigquery"
        ]
      }
    }
  }
}

Google's newer client setup page configures Gemini CLI as an extension with Application Default Credentials instead. Either way, it signs in as whatever identity those credentials hold.

To test any of them, ask "What datasets are in my_project?" with your project ID. A list back means the connection works. A list that includes datasets the agent shouldn't see means your grants are too wide.

If your warehouse is Databricks instead, we covered its hosted MCP servers separately, and ClickHouse has its own MCP server setup with per-user limits. For MySQL, we tested what two MCP servers let an agent do.

Where the agent's metric definitions live

A read-only, capped agent still writes its own SQL. Ask it for revenue and it decides which orders count, which timestamp to use and what "last month" means. Two tools can pick two definitions and return two numbers, both over a perfectly safe connection.

Google sells a layer for this. Conversational Analytics data agents answer from verified queries, "deterministic SQL that executes when it matches a user prompt," plus glossary terms and instructions. Looker announced a managed MCP server in preview in April 2026. With either, your definitions live in Google Cloud or in Looker.

We built Querio for teams that want them in a git repo they own. Querio connects to BigQuery, and our docs ask for "a dedicated read-only account whenever possible." Your metrics, joins and business rules are written once and reviewed like code, and Querio, Slack, Claude, the CLI and any agent over MCP read the same definitions. Enver, co-founder of Growdash, says: "We prompt through the MCP every week and diff the answers against golden answers. It's faster, cheaper, and I can actually do evals compared to the BigQuery MCP." Our MCP server is on every plan, Free included.

FAQ

What is MCP for Google?

MCP is the open protocol AI agents use to call tools. Google runs managed remote MCP servers for its own products, and BigQuery's is one of them. The supported products list shows the rest.

Is the BigQuery MCP server generally available?

We haven't seen Google announce general availability. It launched in preview in January 2026, and as of October 21, 2026 its docs have dropped the preview label.

Does the BigQuery MCP server cost extra?

Google's pricing page lists no separate charge for it. You pay for the queries it runs, billed to the project the agent names in each call.