How to connect Cursor to BigQuery

You can give Cursor access to BigQuery in two ways. Use Google's managed remote MCP server if it is just you, or connect BigQuery to Contextflo once if your teammates will ask data questions from their editors too. Both end in a few lines of mcp.json.

Option 1: Google's BigQuery MCP server in Cursor

Google hosts a remote MCP server at https://bigquery.googleapis.com/mcp. It signs in with OAuth and IAM. Its tools are list_dataset_ids, get_dataset_info, list_table_ids, get_table_info, execute_sql_readonly and execute_sql. Results are capped at 3,000 rows and queries time out after 3 minutes.

Two things to know before you start:

• execute_sql can write. Use an identity that only has BigQuery Data Viewer and BigQuery Job User.
• The server does not support automatic client registration. Create an OAuth client ID in Google Cloud Console, then enter the client ID and secret.

Add the server to ~/.cursor/mcp.json (global) or .cursor/mcp.json (one project):

{
  "mcpServers": {
    "bigquery": {
      "url": "https://bigquery.googleapis.com/mcp"
    }
  }
}

Cursor runs the OAuth flow itself when the server asks for it. Toggle the server on or off from Cursor's MCP settings.

If you would rather run a local server, community stdio options exist. One is pvoo/bigquery-mcp, which only allows SELECT and WITH:

{
  "mcpServers": {
    "bigquery": {
      "command": "uvx",
      "args": ["bigquery-mcp", "--project", "YOUR_PROJECT", "--location", "US"]
    }
  }
}

Option 2: Contextflo

Contextflo connects to BigQuery once, then every person signs in from Cursor with their own account.

In Google Cloud, create a service account and give it:

• BigQuery Data Viewer (grant it at the dataset level if you can)
• BigQuery Job User

Download a JSON key for it. In Contextflo, go to Data Sources, then Add data source, and fill in:

Pick the tables to expose and invite your team. Then point Cursor at Contextflo:

{
  "mcpServers": {
    "contextflo": {
      "url": "https://mcp.contextflo.com/mcp"
    }
  }
}

Cursor opens the sign-in flow. Contextflo runs SELECT only. Keep the read-only service account anyway.

You also get table and column descriptions generated for you, shared definitions your team saves as corrections, per-person table access, an audit trail of prompts and the SQL that ran, and a weekly digest. In BigQuery's own job history, every query shows up under the service account, so Google alone cannot tell you who asked.

Which one to use

Just you, a handful of tables, and a repo open in Cursor? Option 1 is fine. When your team asks too, use Contextflo: shared context, per-person table access, and an audit trail of prompts and the SQL that ran.

Using Claude instead? See Claude with BigQuery.

You do the modeling, we do the rest. Connect BigQuery free.

FAQ

Is the BigQuery MCP server read-only in Cursor? Not by default. Google's server has execute_sql_readonly and execute_sql, and execute_sql can write. Use an identity with only BigQuery Data Viewer and BigQuery Job User so a write attempt fails. Contextflo runs SELECT only and you should still give its service account the same two roles.

Why does Google's BigQuery MCP server need an OAuth client ID? It does not support automatic client registration. You create an OAuth client ID in Google Cloud Console and enter the client ID and secret yourself. Contextflo supports automatic client registration, so Cursor only needs the URL.

Where does the BigQuery MCP config live in Cursor? In ~/.cursor/mcp.json for every project, or .cursor/mcp.json inside one repo. Both use the same mcpServers shape.

Which BigQuery location should I use in Contextflo? The one your dataset lives in. The Location field has to match the dataset region.