[BUG] MCP deferred tools not available on first turn — breaks scheduled/automated tasks
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
- Configure remote MCP servers (e.g., Axiom, Slack) in Claude Code
- Set up a scheduled/automated task that uses those MCP tools on session start
- Session starts, prompt executes immediately
- ToolSearch returns: "No matching deferred tools found. Some MCP servers are still connecting"
- Retrying ToolSearch within the same turn always fails — the deferred tool list is frozen for the turn
- 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
- MCP servers take ~10-30s to initialize
- The first turn's deferred tool list is generated before servers finish connecting
- ToolSearch retries within the same turn always fail
- 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
- Configure remote MCP servers (e.g., Axiom, Slack) in Claude Code
- Set up a scheduled/automated task that uses those MCP tools on session start
- Session starts, prompt executes immediately
- ToolSearch returns: "No matching deferred tools found. Some MCP servers are still connecting"
- Retrying ToolSearch within the same turn always fails — the deferred tool list is frozen for the turn
- 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_
8 Comments
Adding another case here. My setup:
bambuddy-mcpviauvx) configured in~/.claude/mcp.jsonclaude mcp listshows✓ ConnectedToolSearchreturns nothing — zero deferred tools from any of my 3 custom MCP servers (bambuddy, nixos, swim)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 listshould surface whether tools were actually registered, not just whether the transport connected.Environment: macOS, Claude Code latest, MCP server via stdio transport.
Same issue here with scheduled triggers (reported separately in #43812, now closed as duplicate).
Additional data points from my testing:
sleep 5/sleep 10before 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.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.
Throw another one in the hat
https://github.com/anthropics/claude-code/issues/44736
Here's a minimal repro
repro-mcp-race.ts
Also experienced this
also experience this, in the logs I see
If I manually add a prompt to the scheduled tasks session "try to send the message to slack again" , it works.
Duplicate of #35899
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.