Connect Claude to BigQuery: the connector, the errors, a team path

I tried connecting BigQuery to Claude. It took longer than it should have, and none of the difficulty was in our product. Here is exactly what happened, the errors in order, and what I would do differently.

Attempt 1: Claude's native BigQuery connector

Claude has a native BigQuery connector. I clicked install. It asked for an OAuth Client ID and Secret.

Getting those means a detour into the Google Cloud Console:

• Set up a Google Auth Platform consent screen
• Choose internal or external audience
• Configure app name, support email, scopes
• Create an OAuth Client ID of type "Web application"
• Add the right redirect URI — but which one?
• Copy the ID and Secret back into Claude

I did all of that except the redirect URI, because nothing told me what Claude expected. So:

redirect_uri_mismatch.

After some digging: the redirect URI Claude uses is https://claude.ai/api/mcp/auth_callback. Add that to the OAuth client, wait a few minutes for Google to propagate it, and it connects.

If you are here from a search engine having hit this exact error, that URI is the answer, and you can stop reading.

Claude can now list datasets, run queries and return results. Which is where the next problem starts.

A detour: the managed MCP endpoint

While waiting for the redirect URI to propagate I tried the other route. Google's MCP docs point at a managed server at https://bigquery.googleapis.com/mcp, so 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 the previous section. There is no shortcut around the consent screen.

Connected is not the same as useful

The connection gives Claude your tables and columns. It does not give it any idea what they mean.

If a table is called analytics_events_v3 and a column is sts, Claude guesses. Usually plausibly, which is the problem — a wrong guess returns a number rather than an error. Two people ask "what's our revenue?" and get two different answers, and neither of them knows.

The documented fix is to add descriptions in BigQuery itself: open each table, edit the schema, describe every column.

Now do that for every column, in every table, and keep it current as columns change. It is real and it works. It is also the kind of task that gets done for four tables and then abandoned.

Then try to roll it out

Say you get it working for yourself. Your ops lead wants access. Your marketing manager wants campaign numbers. Your CEO wants a revenue update.

Each of them goes through the same OAuth setup on their own machine. Each of them gets the same raw access to every table the credential can reach. And nobody has any view of what is being asked or what SQL is running.

That last one is the one that actually costs you something. Someone asks about revenue, Claude interprets it differently than you would, and a decision gets made on the answer. BigQuery does log the query jobs, so the SQL exists somewhere — but nothing ties the natural-language question to the generated SQL to the person who asked it. Reconstructing that after the fact means correlating job history against a chat transcript you cannot see.

Concretely, what you are missing:

• Everyone needs their own OAuth setup
• Access control lives in Google Cloud IAM, not somewhere a business user can manage
• No shared metric definitions
• No team-level view connecting question, SQL, person and result
• Results capped at 3,000 rows with a 3-minute timeout, per Google's MCP docs (accessed June 2026)

That last cap surprises people. It is fine for exploration and awkward the first time somebody asks for a full export.

The simpler path for a team

Contextflo uses Google's service account APIs directly. No OAuth flow, no consent screen, no redirect URI:

1. Create a read-only service account with BigQuery Data Viewer and BigQuery Job User. About two minutes.
2. Paste the JSON key into Contextflo and select your project.
3. Pick your datasets and tables, and Contextflo generates descriptions for each table and column. Correct anything that is wrong — this is the step that determines whether the answers hold up, and it is worth an hour from someone who knows the data.
4. Invite your team. They connect Claude to Contextflo. One setup, shared.

Step-by-step with screenshots is in the BigQuery setup guide. If you need to expose views rather than tables, see restricting BigQuery access with authorized views.

The difference is not the connection, which either tool makes work. It is that the context, the per-user table scoping and the audit trail exist in one place rather than being five separate things you were going to get to.

Which one to use

Google's connector is the right call for a data engineer doing quick exploration on a schema they already know. It is free, and once past the OAuth setup it needs nothing else. If that is you, use it.

Contextflo is for when several people need to ask questions and get consistent answers, particularly if some of them are never going to debug a Google Cloud consent screen.

One honest tradeoff: we are a paid tool and a dependency. If you are a solo data engineer comfortable with the direct setup, you do not need us, and the row cap is the only thing likely to change your mind.