How to use Claude with BigQuery
How to connect Claude to BigQuery with MCP. What actually happens when you try Google's OAuth setup, the errors you'll hit, and a simpler way to get your team querying.
I tried connecting BigQuery to Claude today. It took longer than I expected, and not because of anything technical on our end. Here's what actually happened, and a simpler way to do it.
Attempt 1: Claude's native BigQuery connector
Claude has a native BigQuery connector now. I clicked install. It asked me for an OAuth Client ID and Secret.

To get those, you need to go to Google Cloud Console and:
- Set up a Google Auth Platform (consent screen)
- Pick internal vs external audience
- Configure app name, support email, scopes
- Create an OAuth Client ID (Web application type)
- Add the right redirect URI (but which one?)
- Copy the Client ID and Secret back into Claude
I did all of that, but I hadn't added a redirect URI because I didn't know which one Claude needed. Hit this:

redirect_uri_mismatch.
After some digging, the redirect URI Claude uses is https://claude.ai/api/mcp/auth_callback. I added it to the OAuth client in Google Cloud Console, waited a few minutes for Google to propagate the change, and it finally connected.
Claude can now list datasets, run queries, and return results. It works. But then you hit the next problem.
Side note: I also tried the custom MCP route
While waiting for the redirect URI to propagate, I tried a different route. Google's official MCP docs suggest connecting to their managed MCP server at https://bigquery.googleapis.com/mcp. I added it as a custom MCP server in Claude.

“Automatic client registration isn't supported by bigquery.” You still need the OAuth credentials from above.
Even once connected, Claude doesn't know what your data means
The connection gives Claude access to your tables and columns, but no context about what they mean. If your table is called analytics_events_v3 or a column is called sts, Claude guesses. Two people ask “what's our revenue?” and get two different numbers.
You can fix this by manually editing schema descriptions in BigQuery. Go to each table, click edit schema, and add a description for every column.

BigQuery's schema editor. You'd need to do this for every column, in every table, for the LLM to understand your data.
Now repeat that for every table. And keep it up to date when columns change. And hope everyone on your team has the same BigQuery permissions and OAuth setup on their machine.
Now imagine rolling this out to your team
Say you get it working for yourself. Now your ops lead wants access. Your marketing manager wants to check campaign numbers. Your CEO wants a revenue update.
Each person needs to go through the same OAuth setup on their machine. Each person gets the same raw access to every table. And you have no idea what anyone is asking or what queries Claude is running on your behalf.
Someone asks “what's our revenue?” and gets a wrong number because Claude interpreted it differently than you would. You wouldn't even know it happened. BigQuery logs the query jobs, but there's no team-level view tying the natural-language question to the generated SQL to the person who asked it. That's fine for personal exploration. It's a problem when the CEO makes a decision based on a number Claude made up.
- Everyone needs their own OAuth setup
- Access control lives in Google Cloud IAM, not a centralized analytics workspace your business users can manage
- No shared metric definitions
- No team-level view connecting questions, SQL, users, and results in one place
- Results capped at 3,000 rows with a 3-minute timeout [1]
The simpler way: BigQuery + Contextflo
We use Google's service account APIs directly. No OAuth flows, no consent screens, no redirect URIs. Here's the setup:
- Create a read-only service account in Google Cloud with BigQuery Data Viewer and BigQuery Job User roles. Takes about 2 minutes.
- Paste the JSON key into Contextflo and select your project.
- Pick your datasets and tables. Contextflo auto-generates descriptions for every table and column. Refine anything that's off.
- Invite your team. They install the Contextflo MCP server in Claude and start querying. One setup, shared by everyone.
For a detailed walkthrough with screenshots, see our BigQuery setup guide. If you need to restrict access using views, check our guide on BigQuery views.
Because Contextflo adds a context layer, Claude actually knows what your tables and columns mean without you manually editing BigQuery schema descriptions. It also comes with per-user access controls, so you can scope which tables each person can query, and an audit trail of every question and query.
Which approach to use
Google's MCP server works well for a data engineer doing quick exploration on a schema they already know. It's free and doesn't require additional tooling once you get past the OAuth setup.
Contextflo is for teams where multiple people need to ask questions and get consistent answers. If your ops lead or marketing manager needs data from BigQuery without debugging Google Cloud OAuth, this is the path.
One honest tradeoff: Contextflo is a paid tool and adds a dependency. If you're a solo data engineer who's comfortable with the direct MCP setup, you probably don't need it.
Sources
- Google BigQuery MCP docs (accessed June 20, 2026)
- Claude native BigQuery connector (accessed June 19, 2026)
- Google Cloud blog: Using the BigQuery MCP server (accessed June 19, 2026)
Related reading
- BigQuery setup guide: step-by-step with screenshots
- Restricting BigQuery access with views: limit what your team can query
- You connected your warehouse to Claude, now what?: what every team needs beyond the MCP connection