[BUG] claude.ai custom connector fails to request server-declared scopes for Google Workspace People API — all tool calls return permission denied

[tommohide-kumekawa]

Summary

When adding Google's official People API MCP server (https://people.googleapis.com/mcp/v1) as a custom connector in claude.ai, the OAuth flow completes successfully (the connector shows Connected and tools are visible in the tool list), but every tool call fails with The caller does not have permission because the access token issued by claude.ai's OAuth flow is missing the scopes the MCP server declared as required.

This is functionally the same class of bug as #42 (offline_token not being added as a scope during oauth), but for the People API scopes (userinfo.profile, contacts.readonly, directory.readonly).

Environment

• Client: claude.ai web (custom connector UI)
• MCP server: https://people.googleapis.com/mcp/v1 (Google official, docs)
• Upstream OAuth IdP: Google (via customer-owned OAuth client in Google Cloud)
• Google Workspace customer with Domain-wide Delegation enabled; all required APIs enabled; OAuth consent screen lists userinfo.profile, userinfo.email, contacts.readonly, directory.readonly; end-user granted all requested scopes on the consent screen.

Reproduction

1. Create an OAuth 2.0 Web Application client in Google Cloud, add https://claude.ai/api/mcp/auth_callback to authorized redirect URIs.
2. In claude.ai → Settings → Connectors → Add custom connector, set URL https://people.googleapis.com/mcp/v1 and paste the OAuth client ID / secret.
3. Click Connect → redirected to Google consent screen → approve.
4. Connector status becomes Connected.
5. Invoke any People API tool (get_user_profile, search_contacts, search_directory_people).

Expected

Tool call succeeds (or at minimum fails with a Google API error unrelated to missing OAuth scopes).

Actual

All three tools return:

The caller does not have permission

Root cause (as far as we could diagnose)

• The People API MCP server correctly advertises the three required scopes (userinfo.profile, contacts.readonly, directory.readonly) via authorization server metadata.
• The Google Cloud OAuth client is configured with these scopes on the consent screen.
• The end-user grants all scopes at the consent screen.
• However, claude.ai's OAuth authorization request to Google does not include these scopes in the scope parameter, so the resulting access token has only the default minimum scopes and cannot call the People API methods.

The same user / same GCP project / same OAuth client works correctly with Gmail, Drive, Calendar, and Chat custom connectors — so the issue appears specific to how claude.ai maps the server-declared required scopes to the scope parameter sent to the upstream IdP for the People MCP endpoint.

Note: claude.ai's custom connector UI does not expose a "scopes" input field, so there is no user-side workaround.

Related

• offline_token not being added as a scope during oauth #42 — same class of bug (hardcoded scopes in authorize request). Marked `fix-in-progress` but this case suggests the fix did not cover server-declared scopes for all Google Workspace MCP endpoints.

Impact

Google's official People API MCP server is effectively unusable from claude.ai custom connectors, blocking use cases that rely on organization directory / contact lookups (e.g. personal assistant agents that resolve attendees, participants, email recipients by name).

[riekusr]

Confirming this from a custom remote MCP operator with end-to-end evidence

We run a remote MCP server (@rekog/mcp-nest@1.9.8, NestJS, OAuth 2.1 + DCR + 365-day refresh token JWTs) for our claude.ai web/mobile users. We see exactly the symptom this issue describes — "Connection has expired" UI every 1–3 days — and we've now collected evidence on all three sides (server, browser, peer servers) that points squarely at the proxy refresh path.

Server-side evidence (11 days, single deploy, no restarts)

Endpoint	Hits	Status
POST /mcp	263	174× 200, 89× 202, 0× 401
POST /oauth/token	16	16× 200 — 9 are authorization_code grants (re-login), 7 are refresh_token grants that succeed silently
POST /oauth/register	16	16× 201

Critical: the server never returned 401 to claude.ai. Tokens were always valid when used. Yet claude.ai re-registered as a fresh dynamic OAuth client 16 times in 11 days. When the proxy does attempt the refresh_token grant, it succeeds — but it tries it inconsistently, falling back to a full DCR + interactive Google SSO too often.

Browser-side evidence (claude.ai web client storage)

Inspected via Chrome devtools on a logged-in claude.ai session. Connector OAuth state in browser storage is limited to:

localStorage["mcp-remote-connectors-state"] = {
  "<connector-uuid>": {
    "isConnected": bool,
    "hasPromptsOrResources": bool,
    "expiration": <ms epoch>
  },
  …
}

All 15 connector entries had expiration timestamps within a ~6-second window, exactly 2.79 days in the past at the time of inspection. No client_id, refresh_token, or access_token is stored anywhere in the browser (checked all IndexedDB databases — keyval-store, x-ark-arid-db, claude-notifications, etc. — plus localStorage, sessionStorage, and JS-readable cookies). Tokens are entirely server-side at mcp-proxy.anthropic.com.

The expiration field is a UI cache TTL — the trigger for the proxy to re-validate against its server-side token state. When the proxy's refresh path is broken (this issue), every cache-revalidation cycle has a non-trivial chance of flipping a connector to isConnected: false and triggering a fresh DCR + interactive auth.

Peer-server cross-check

Probed POST /oauth/register on 6 production remote MCP servers users connect to from claude.ai without symptoms (Sentry, Linear, Notion, Asana, Atlassian, Cloudflare). All return identically-shaped DCR responses to ours. So the problem is not something MCP server operators can fix by tweaking response fields.

Why this matters

The Claude Code path got a refresh fix in v2.1.59. The same fix has not landed on mcp-proxy.anthropic.com, which is what claude.ai web and mobile use for custom connectors. End users see this as an unstable/unreliable connector, even when the underlying server is healthy and would happily accept a refresh.

---

Happy to share full anonymized log evidence (HAR, JWT decodings, browser-storage dumps) if it would help. Server is @rekog/mcp-nest@1.9.8 if relevant; the same library has multiple production deployments seeing the same pattern.

[thatnetsecguy]

Confirming reproduction on Claude Desktop with Microsoft Entra ID — June 2026

Hitting the same root cause as described here. Adding a reproduction against a different IdP (Microsoft Entra ID).

Environment

• Client: Claude Desktop (latest, June 2026), Settings → Connectors → Add custom connector
• MCP server: self-hosted agentic-community/mcp-gateway-registry v1.24.4
• IdP: Microsoft Entra ID (single tenant), public client + PKCE, pre-registered client_id supplied via Advanced Settings

Observed authorize URL (Claude Desktop Client generated):

https://login.microsoftonline.com/<tenant>/oauth2/v2.0/authorize

?response_type=code

&client_id=<client-id>

&redirect_uri=https://claude.ai/api/mcp/auth_callback

&code_challenge=<pkce-challenge>

&code_challenge_method=S256

&state=<state>

No `scope` parameter.

IdP response: AADSTS900144: The request body must contain the following parameter: 'scope'

Unlike Google, Entra rejected the authorize request immediately with AADSTS900144: scope is required — no login prompt was shown and no token was issued.

Server-side verification: Both /.well-known/oauth-protected-resource and /.well-known/oauth-authorization-server correctly advertise scopes_supported including the gateway-specific api:// scope. Token validation works correctly when scope is included independently (confirmed via M2M flow). The issue appears to be client side.

[Brian-Gaffney]

Can confirm this on our end too.
We've watched claude.ai's actual consent screen for this connector request only 2 of the 3 scopes the People API MCP server needs, missing userinfo.profile.
The returned tokens don't work with the People MCP.

Matches what you're describing.

When we tested with all 3 scopes manually supplied via MCP Inspector instead of the connector UI, the token came back fine.

[singhyuk]

Same symptom here with the Google People API MCP server (https://people.googleapis.com/mcp/v1) as a custom connector.

Consent screen listed all 3 scopes, all granted per Google Account permissions. Connector shows "Connected." Every tool call fails:

"message": "The caller does not have permission to request \"people/me\". Request requires one of the following scopes: [profile]."

Cloud Metrics: 100% of requests to people.googleapis.com returning 403.

Confirmed it's not a config issue: same OAuth client (same ID/secret) authorized via Google's OAuth Playground with the same scopes → people/me request succeeds immediately. Same credentials work outside claude.ai, fail inside it. Three remove/re-add cycles, same result each time.

[un-211]

Reproduced the same class of bug with different Google Workspace custom connectors — not limited to the People API.

Connectors affected: Google Docs, Google Sheets, Google Slides (all set up as custom connectors, "Custom" type in the connector list)

Symptom: All read/write calls (e.g. documents.get, documents.batchUpdate) on existing files fail with The caller does not have permission. Creating a brand-new file works fine. Google Drive-only operations (metadata, content read, upload) on the same files also work fine — so it's specifically the Docs/Sheets/Slides API calls that fail, not Drive access in general.

What we tried (no effect):

• Enabling the relevant Google Cloud APIs (e.g. Sheets API)
• Manually adding all relevant OAuth scopes in the Google Cloud Console consent screen (drive.readonly, drive.file, spreadsheets.readonly, spreadsheets, documents.readonly, documents, presentations.readonly, presentations)
• Disconnecting and reconnecting the connectors in claude.ai to force re-authorization with the new scopes

None of the above resolved it, which matches this issue's root cause (claude.ai not including server-declared scopes in the Google OAuth request) rather than a project-side misconfiguration.

This suggests the bug isn't specific to the People API MCP server, but affects custom connectors to Google Workspace APIs more broadly.