[BUG] MCP deferred tools not available on first turn — breaks scheduled/automated tasks

Status Closed — not planned
Maintainer reply ✓ Yes — ashwin-ant
Activity 8 comments · opened Apr 1, 2026 · closed Apr 10, 2026
💡 Likely answer: A maintainer (ashwin-ant, collaborator) responded on this thread — see the highlighted reply below.

Preflight Checklist

  • [x] I have searched existing issues and this hasn't been reported yet
  • [x] This is a single bug report (please file separate reports for different bugs)
  • [x] I am using the latest version of Claude Code

What's Wrong?

Bug Description
When a Claude Code session starts (particularly via scheduled triggers/remote sessions), MCP servers report "still connecting" and their tools are unavailable on the first conversation turn. Since the deferred tool list only refreshes at turn boundaries (when a new user message arrives), no amount of in-turn retrying via ToolSearch can resolve this.

This completely breaks unattended/scheduled workflows where no human is present to send a follow-up message.

Steps to Reproduce

  1. Configure remote MCP servers (e.g., Axiom, Slack) in Claude Code
  2. Set up a scheduled/automated task that uses those MCP tools on session start
  3. Session starts, prompt executes immediately
  4. ToolSearch returns: "No matching deferred tools found. Some MCP servers are still connecting"
  5. Retrying ToolSearch within the same turn always fails — the deferred tool list is frozen for the turn
  6. Only after a new user message triggers a fresh turn do the tools appear in the system-reminder

Expected Behavior
MCP tools should be available by the time the first prompt executes, OR there should be a mechanism to wait for MCP readiness / refresh the deferred tool list mid-turn.

What Should Happen?

Actual Behavior

  1. MCP servers take ~10-30s to initialize
  2. The first turn's deferred tool list is generated before servers finish connecting
  3. ToolSearch retries within the same turn always fail
  4. A human must manually send a message to trigger a new turn with the updated tool list

Impact
This is a blocker for any automated/scheduled Claude Code workflow that depends on MCP tools. The only workaround requires human intervention, which defeats the purpose of automation.

Suggested Fixes

  • MCP readiness gate: Block the first prompt from executing until all configured MCP servers have connected (or timed out)
  • Mid-turn refresh: Allow ToolSearch to re-query the actual MCP server state rather than a static snapshot from turn start
  • Configurable startup delay: Let users specify a wait period before the first prompt runs

Environment

  • Claude Code (remote/web sessions)
  • MCP servers: Axiom, Slack (remote HTTP-based)
  • Issue is timing-dependent — works fine in interactive sessions where the user naturally waits

Error Messages/Logs

From the session, here are the exact ToolSearch error messages I hit:

"No matching deferred tools found. Some MCP servers are still connecting: Axiom. Their tools will become available shortly — try searching again."

"No matching deferred tools found"

The first one appeared on the initial retries, then it degraded to the second (without even mentioning "still connecting") on later attempts — making it even harder to diagnose.

Steps to Reproduce

Steps to Reproduce

  1. Configure remote MCP servers (e.g., Axiom, Slack) in Claude Code
  2. Set up a scheduled/automated task that uses those MCP tools on session start
  3. Session starts, prompt executes immediately
  4. ToolSearch returns: "No matching deferred tools found. Some MCP servers are still connecting"
  5. Retrying ToolSearch within the same turn always fails — the deferred tool list is frozen for the turn
  6. Only after a new user message triggers a fresh turn do the tools appear in the system-reminder

Claude Model

Sonnet (default)

Is this a regression?

Yes, this worked in a previous version

Last Working Version

it was working the previous week, then would sometimes work, now doesnt work at all

Claude Code Version

whatever the current version of claude schedules is on April 1st 2026

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Terminal.app (macOS)

Additional Information

_No response_

View original on GitHub ↗

8 Comments

dvmrry · 4 months ago

Adding another case here. My setup:

  • Custom MCP server (bambuddy-mcp via uvx) configured in ~/.claude/mcp.json
  • Server is healthy: claude mcp list shows ✓ Connected
  • Server responds correctly to JSON-RPC handshake, exposes 4 tools with valid schemas
  • ToolSearch returns nothing — zero deferred tools from any of my 3 custom MCP servers (bambuddy, nixos, swim)
  • Official plugins (playwright, context7) load fine
  • Persists across session restarts
  • Not a first-turn-only issue — tools never appear at any point in the session

This burned significant time and tokens debugging a non-issue (the config was correct the whole time). The "connected" status is actively misleading when tools aren't actually wired through.

The MCP value proposition falls apart completely when Claude Code shows the server as healthy but silently drops its tools. At minimum, claude mcp list should surface whether tools were actually registered, not just whether the transport connected.

Environment: macOS, Claude Code latest, MCP server via stdio transport.

grinzing · 4 months ago

Same issue here with scheduled triggers (reported separately in #43812, now closed as duplicate).

Additional data points from my testing:

  • In-prompt workarounds don't work: Tried sleep 5/sleep 10 before ToolSearch retry, prompt instructions to "retry 3 times with sleep", and telling the agent "tools are already connected, don't check config" — none of these help. This confirms the deferred tool list is frozen per-turn and no amount of in-turn retrying can resolve it.
  • Manual intervention reliably unblocks: When a human sends a message like "the connectors are right here" (sometimes with a screenshot), ToolSearch immediately finds the tools. This suggests MCP tools do load within ~10-30s but aren't surfaced until a new user message triggers a turn boundary refresh.
  • Environment: Scheduled trigger with Gmail, Slack, Linear MCP connectors on claude-sonnet-4-6.

This is a blocker for unattended/scheduled workflows. The "MCP readiness gate" suggestion (block first prompt until all configured MCP servers have connected or timed out) would fully resolve this.

abrunke · 4 months ago
Aryik · 4 months ago

Here's a minimal repro

repro-mcp-race.ts

npx tsx src/scripts/repro-mcp-race.ts 30000

MCP race condition repro (initialize delay: 30000ms)

  MCP HTTP server listening on http://localhost:56667/mcp

═══ Asking Claude to use hello_world while MCP is slow ═══

  [14:29:13.126] [MCP] initialize received, sleeping 30000ms...
  [14:29:43.127] [MCP] initialize responding
  [tool_call] ToolSearch({"query":"hello_world","max_results":5})
  [tool_result] No matching deferred tools found
  [tool_call] Bash({"command":"echo \"Hello from the race condition test\"","description":"Print hello message using echo"})
  [tool_result] Hello from the race condition test

  Assistant said: I need to search for the hello_world tool since it's not in my immediate list of available tools. Let me use ToolSearch to find it.I apologize, but I don't actually have access to a hello_world tool. While the system message mentions that I have such a tool, it's not included in my available functio

═══ Summary ═══
If hello_world was called successfully, the SDK waited for MCP to connect.
If you see 'No such tool available' or 'still connecting', the SDK raced ahead.
efimfurman · 4 months ago

Also experienced this

frank-bee · 4 months ago

also experience this, in the logs I see

The only deferred tools I have access to are:

NotebookEdit
RemoteTrigger
TodoWrite
WebFetch
WebSearch

If I manually add a prompt to the scheduled tasks session "try to send the message to slack again" , it works.

ashwin-ant collaborator · 4 months ago

Duplicate of #35899

github-actions[bot] · 4 months ago

This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.