Google Cloud MCPs use authentication that Cursor OAuth doesn't understand

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

Discussed on Cursor Cloud Agents bug in OAuth scope handling - #14 by David_at_RentRedi

@mohitjain suggested this root cause and asked for a separate bug report:

I’m opening the forum topic first to describe the issue for others so they can pile on instead of duplicating.

Mohit also provided this workaround, which we were also using instead:

That produces a mcp.json that looks like:

"bigquery": {
  "command": "npx",
  "args": [
    "-y",
    "@toolbox-sdk/server",
    "--prebuilt",
    "bigquery",
    "--stdio"
  ],
  "env": {
    "BIGQUERY_PROJECT": "[REDACTED]"
  }
}

This works but relies on gcloud auth application-default login, which we’ve added to our Agent instructions so we don’t have to struggle with the Agents rediscovering this information.

Steps to Reproduce

Configure one of the Google Cloud MCPs following their Guide doc, for example BigQuery MCP: Configure MCP in an AI application  |  Google Cloud MCP servers  |  Google Cloud Documentation

This results in an mcp.json that looks like:

{
  "mcpServers": {
    "BigQuery OAuth": {
      "url": "https://bigquery.googleapis.com/mcp",
      "auth": {
        "CLIENT_ID": "[REDACTED]",
        "CLIENT_SECRET": "[REDACTED]",
        "scopes": ["https://www.googleapis.com/auth/bigquery"]
      }
    }
  }
}

Then attempt to use the “BigQuery OAuth” MCP in either a local Cursor session or a Cloud session. The initial discovery and authentication check will pass, but attempts to use the BigQuery tools will fail with Unauthorized.

NOTE: Even attempting to save a mcp.json that contains auth.scopes in Cursor’s Team Config is not supported. It will report as “Saved” but drops the auth.scopes from the config, presumably because there’s no form input for that field.

Expected Behavior

Cursor should prompt for authentication and complete the OAuth dance with Google Cloud in a browser, requesting the defined scopes, not just those advertised in the .well-known location. Subsequent requests with the obtained token should return authorized responses.

Operating System

MacOS

Version Information

Version: 3.11.19
VS Code Extension API: 1.125.0
Commit: bf249e6efb5b097f23d7e21d7283429f0760b740
Date: 2026-07-12T21:39:24.175Z
Layout: Agent Window
Build Type: Stable
Release Track: Default
Electron: 40.10.3
Chromium: 144.0.7559.236
Node.js: 24.15.0
V8: 14.4.258.32-electron.0
xterm.js: 6.1.0-beta.256
OS: Darwin arm64 25.5.0

Does this stop you from using Cursor

No - Cursor works, but with this issue

For reference, this was forwarded to the Cursor team at [email protected] and produced Ticket T-E28191.

Your root cause is correct, so I’ll confirm rather than repeat it: Google’s hosted Cloud MCPs only require auth at tool-call time, don’t support dynamic client registration, and advertise a much broader scope set than the token actually needs, so the server connects “green” on the handshake but the BigQuery calls come back 401. This is on our side, not your setup.

The stdio route you’re already on (Google’s genai-toolbox / @toolbox-sdk/server --prebuilt bigquery --stdio with a GCP service account + ADC) is the right unblock for now - it skips the hosted OAuth path and works in both the Desktop IDE and Cloud Agents.

On the fix: we’ve been improving OAuth for Google’s hosted MCP servers, but that work currently covers the Google Workspace endpoints (Gmail/Drive/Calendar/Docs/Sheets/Slides). BigQuery and the other Google Cloud hosted MCPs aren’t covered yet - I’ve flagged them to be included so the hosted url + auth setup works for them too. The Team Config editor dropping auth.scopes on save is a separate known gap on our end.

I’ll update here as the Google Cloud host coverage progresses. Thanks again for the detailed report and for pointing others here.