claude.ai-scoped connectors (Slack/HubSpot/Gmail/Calendar/Drive) show 'Connected' via claude mcp list but are never loaded as tools in a CLI session

Status Open

Reported on v2.1.197

Maintainer reply None cached

Activity 3 comments · opened Jul 1, 2026

Summary

MCP servers that come from claude.ai account-level connectors (shown by claude mcp list with the claude.ai <Name> prefix, e.g. claude.ai Slack, claude.ai HubSpot, claude.ai Gmail, claude.ai Google Calendar, claude.ai Google Drive) report ✔ Connected and Scope: claude.ai config, but their tools are never actually registered/loaded into a normal Claude Code CLI coding session. This makes the "Connected" status misleading — it appears to reflect only a claude.ai-side health check, not actual availability inside Claude Code.

Steps to reproduce

Have several connectors enabled/authorized in claude.ai account settings (Slack, HubSpot, Gmail, Google Calendar, Google Drive in my case — Ramp, QuickBooks, Pylon, AWS Marketplace also show Connected and are presumably affected the same way).
Run claude mcp list in Claude Code CLI — the connectors show ✔ Connected.
Start a normal Claude Code session and try to use any Slack/HubSpot/Gmail/Calendar/Drive tool, or search for one via the tool-search mechanism — no matching tool exists.
Run claude --debug -p "list every distinct MCP tool name you currently have access to, one per line, nothing else" and inspect the debug log — there is zero mention of slack/hubspot/gmail/drive/calendar anywhere in the MCP handshake log. The CLI never even attempts to connect to these servers for tool loading during a session; claude mcp list's health check appears to be a separate code path from the session's actual MCP client bootstrap.

Attempted workaround (also worth fixing/documenting)

I tried registering the same services as ordinary local user-scoped HTTP MCP servers to route around this:

claude mcp add --transport http slack "https://mcp.slack.com/mcp" -s user
claude mcp add --transport http hubspot "https://mcp.hubspot.com/anthropic" -s user
claude mcp add --transport http gmail "https://gmailmcp.googleapis.com/mcp/v1" -s user
claude mcp login slack

This fails at the OAuth step with:

Couldn't complete authentication for "slack": SDK auth failed: Incompatible auth server: does not support dynamic client registration

Same error for hubspot and gmail. So these hosted MCP endpoints only accept Anthropic's own pre-registered OAuth client (the one presumably used by claude.ai's connector flow), not a generically-added Claude Code MCP client via claude mcp add + claude mcp login. There's currently no supported way for a Claude Code CLI user to get a working, tool-call-capable connection to these same services, despite claude.ai showing them as fully connected under the same account.

Expected behavior

Either:

Connectors authorized at the claude.ai account level should have their tools actually loaded into Claude Code CLI sessions (so "Connected" in claude mcp list means what it appears to mean), or
claude mcp list/claude mcp get should clearly indicate that claude.ai-config-scoped servers are informational only and not usable from CLI sessions, so users don't spend time debugging a connection that was never wired up to begin with.

Environment

Claude Code version: 2.1.197
macOS (Darwin 25.5.0)
claude mcp list shows the affected servers with Scope: claude.ai config

View original on GitHub ↗

3 Comments

Bjcon211 · 3 months ago

Confirming reproduction on Windows 11, Claude Code CLI, claude.ai Gmail and claude.ai Google Calendar connectors.

claude mcp list reports both as ✔ Connected, but no Gmail/Calendar tool schemas are ever surfaced in a session (checked exhaustively via the deferred-tool lookup mechanism — nothing gmail/calendar/mail/inbox/event-related turns up, only unrelated tools). Running /mcp to reconnect other servers (github, chrome-devtools-mcp, resend, supabase) succeeds and their tools do load correctly afterward — so the reconnect flow itself works, it's specifically the claude.ai-scoped connectors (Gmail, Calendar) that never get bootstrapped into the session's tool list.

Beyond just fixing the status-display mismatch, I'd like to request this be treated as a feature ask too: it would be genuinely useful to have real support for claude.ai Google Workspace connectors (Gmail, Calendar) inside Claude Code CLI sessions, not just an accurate "unavailable" status. Day-planning / inbox-triage workflows are a natural fit for the CLI and currently have no path to it short of switching to claude.ai web/desktop.

tevdoskiart · 3 months ago

Confirming this on Windows too — same symptom across both surfaces.

Claude Code v2.1.207, Windows 11, Windows Terminal (PowerShell) + separately tested VS Code extension
claude mcp list / /mcp shows: claude.ai Gmail · ✓ connected (13 tools listed)
Asking Claude to search/read Gmail in the session fails — no Gmail tool is ever exposed via ToolSearch, in either surface
Tested in a fresh, non-VS Code terminal session specifically to rule out the IDE-extension variant of this bug (#32450, #44890) — same failure
Same account's Gmail connector works correctly in claude.ai chat (web), confirming this is scoped to Claude Code specifically, not an account/auth issue

Auth method: logged in via /login with claude.ai account (Claude Pro), not ANTHROPIC_API_KEY, so this isn't the auth-method mismatch some other reports describe.

m13v · 1 month ago

the two halves here are one root cause. the health check passes because it runs inside the claude.ai auth context; the CLI session doesn't inherit that OAuth client, so it can't load those tools AND mcp add can't register its own (dynamic client registration is off on those endpoints). so 'Connected' is green precisely because it's checking the one path that holds the credential the session lacks. labeling it informational (option 2) is honest, but the quiet gap it papers over is the session never inheriting the connector's client identity, and until that's wired there's no CLI path to those tools at all.