HTTP MCP tools (Gmail/Calendar/Drive) connected at daemon level but schemas not mounted in new sessions (regression in 2.1.144)

Summary

In Claude Code 2.1.144, HTTP-based MCP servers (claude.ai Gmail, claude.ai Google Calendar, claude.ai Google Drive) report ✓ Connected from claude mcp list, but their tool schemas are not mounted into new conversations. The assistant cannot see or call the tools, even via ToolSearch. A local plugin MCP (plugin:slack:slack) on the same session is unaffected once reconnected from /mcp.

This appears to be a regression — these integrations worked in prior sessions on the same machine without any user action.

Environment

• Claude Code: 2.1.144
• macOS: 26.3.1 (Darwin 25.3.0)
• Install location: ~/.local/bin/claude
• Binary mtime: May 18, 2026 (regression observed May 19, 2026 — ~24h after a CLI update)
• Install method: standalone binary (not Homebrew)

What I expected

A fresh claude session in a project whose .claude/settings.json allowlists tools such as:

mcp__claude_ai_Gmail__gmail_search_messages
mcp__claude_ai_Gmail__gmail_read_thread
mcp__claude_ai_Google_Calendar__gcal_list_events

…should have those tool schemas available to the assistant on first prompt.

What actually happened

The daemon reports the servers are healthy and connected:

$ claude mcp list
claude.ai Gmail: https://gmailmcp.googleapis.com/mcp/v1            - ✓ Connected
claude.ai Google Drive: https://drivemcp.googleapis.com/mcp/v1     - ✓ Connected
claude.ai Google Calendar: https://calendarmcp.googleapis.com/mcp/v1 - ✓ Connected
plugin:slack:slack: https://mcp.slack.com/mcp (HTTP)               - ✓ Connected

…but inside the session, the assistant cannot find any of the mcp__claude_ai_* tools. ToolSearch returns "No matching deferred tools found" for queries such as +claude_ai, +gmail_, +gcal_, and even select: queries with the exact tool names from the project's allowlist.

The Slack server behaved similarly at first (only OAuth-bootstrap tools were exposed), but after a /mcp reconnect a system-reminder arrived listing the full Slack tool surface as newly-available deferred tools. The three Google MCPs have not produced an equivalent reminder.

Repro

1. On a machine with the three claude.ai Google MCPs previously authenticated and working.
2. Start a fresh claude session in any project (ideally one whose .claude/settings.json allowlists Gmail/Calendar tools so the names are unambiguous).
3. In a separate shell: claude mcp list — confirm all three Google MCPs report ✓ Connected.
4. In the session, ask the assistant to call gmail_get_profile or gcal_list_events, or to list available MCP tools.
5. Observe: the assistant reports the tools are not available; ToolSearch cannot find them.

Hypothesis

For HTTP-hosted MCPs, the tool-manifest fetch appears to race the initial session bootstrap. If the manifest doesn't arrive before the session's tool registry is snapshotted, the schemas never make it into the conversation — even though the underlying connection later reports healthy. The Slack local plugin doesn't hit this because its manifest is available synchronously (or because its later registration triggers a deferred-tool announcement that the Google MCPs don't trigger).

A telling detail: the daemon's claude mcp list and the in-session tool surface disagree at the same instant. Whatever pushes "new tools are available" system-reminder messages mid-session is firing for Slack-on-reconnect but not for the Google MCPs.

Suggested workaround (worth confirming)

/mcp → select a Google MCP → Reconnect. If this re-pushes the schemas into the active session via a deferred-tools system-reminder, that confirms the bug is in initial session mounting, not in OAuth or transport.

Possibly-related areas to check

• Changes between 2.1.143 and 2.1.144 in MCP startup / tool-registration code paths
• Timing/ordering between session start and HTTP MCP manifest fetch
• Whether HTTP MCPs need a different "tools changed" notification pattern than local plugin MCPs
• Whether an empty initial manifest fetch is being cached as "no tools" for the session

Logs

Happy to attach a claude --debug session log if maintainers can point at which subsystem to enable. The standard session transcript captures the divergence above but does not include MCP-handshake telemetry.