[BUG] MCP tools registered and visible in /mcp but model refuses to invoke them

Resolved 💬 2 comments Opened May 11, 2026 by frshaka Closed May 11, 2026

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?

Summary

MCP tools are successfully registered, connected, and visible via /mcp, but the model consistently fails to invoke
them at decision time. Instead, it spawns subagents (which lack MCP access), falls back to Bash echo commands, tries
listMcpResources, or claims "tools not available in this session."

Environment

  • Claude Code: v2.1.139
  • Model: claude-sonnet-4-6 (1M context)
  • OS: Windows 11 Pro 10.0.26200
  • Shell: PowerShell 7
  • MCP SDK: mcp[cli] v1.27.1 (Python, FastMCP)
  • Transport: stdio
  • Tools registered: 10 (all show "connected" in /mcp)

MCP Server Configuration

  • Custom MCP server (sankhya-schema) built with FastMCP Python SDK
  • Registered globally in ~/.claude/.claude.json
  • Permission mcp__sankhya-schema__* added to user's allowlist in settings.json
  • Server instructions appear correctly in system-reminder tags
  • Oracle database connection verified independently

Reproduction Steps

  1. Set up any MCP server with FastMCP (stdio transport)
  2. Register it globally in ~/.claude/.claude.json
  3. Add mcp__servername__* to permissions allowlist in settings.json
  4. Start Claude Code, verify /mcp shows all tools as "connected"
  5. Ask a question that should trigger the MCP tools (e.g., "search tables related to quality samples")
  6. Observe model behavior

Expected Behavior

When the model receives a request about database tables/queries and has MCP tools available and permitted, it should
invoke them directly (e.g., call search_tables) as its first action.

Actual Behavior

The model behaves as if the MCP tools do not exist in its available toolset. Observed failure patterns:

  1. Subagent delegation: Spawns an Agent tool call first — subagents cannot access MCP tools, so the delegation always

fails.

  1. Bash fallback: Runs echo 'Searching MCP...' or similar no-op shell commands.
  2. Wrong tool type: Calls listMcpResources (which lists resources, not tools) instead of invoking the actual tool.
  3. Gives up: Responds with "tools not available in this session."
  4. Hallucination: Invents fake table/column names instead of querying the real schema via MCP.

When explicitly instructed (e.g., "use the tool search_tables from MCP sankhya-schema"), it occasionally works (saw
"Called sankhya-schema 2 times" once), but most of the time fails with the same patterns above.

## What Was Tried (All Ineffective)

  • --dangerously-skip-permissions → Same behavior
  • Without --dangerously-skip-permissions → Same behavior
  • Added mcp__sankhya-schema__* to allowlist → Same behavior
  • Added detailed instructions in MCP server telling model to use tools immediately → Same behavior
  • Added instructions prohibiting Agent delegation, Bash, listMcpResources → Same behavior
  • Added CLAUDE.md with explicit instructions to use MCP tools → Same behavior
  • Restarted Claude Code multiple times → Same behavior
  • Verified server connectivity independently → Server works fine

Hypothesis

The MCP tools may not be consistently included in the API request's tools array sent to the model, even though the
/mcp UI reports them as connected. This would explain why:

  • The model says "tools not available" — they literally are not in its tool list for that turn
  • Explicit instructions in CLAUDE.md and server instructions have no effect — you cannot instruct a model to use a

tool it cannot see

  • The behavior is intermittent — sometimes the tools are included and invocation works

Additional Context

  • The MCP server itself is confirmed working — when the model does invoke the tools (rare), correct results are

returned

  • This is not a permission issue — the wildcard permission is in the allowlist and --dangerously-skip-permissions

produces the same behavior

  • This is not a connectivity issue — /mcp shows "connected" and the server responds to health checks
  • This appears to be a gap between what /mcp reports (tools registered) and what the model actually receives in its

tool list at inference time

What Should Happen?

Claude should invoke MCP tools (search_tables, describe_table) directly when asked about database tables, instead of using Bash echo commands or claiming tools are unavailable.

Error Messages/Logs

No error messages. The model simply does not invoke the MCP tools. Instead it runs Bash echo commands like `echo "Searching MCP..."` and eventually responds with "tools not available in this session" despite /mcp showing all 10 tools as connected.

Steps to Reproduce

  1. Create a FastMCP server (Python, stdio transport) with at least one tool registered:

```python
from mcp.server.fastmcp import FastMCP

mcp = FastMCP(name="my-server")

@mcp.tool()
def search_tables(keyword: str) -> str:
"""Search tables by keyword."""
return f"Results for {keyword}"

if __name__ == "__main__":
mcp.run()

  1. Register the server globally in ~/.claude/.claude.json:

{
"mcpServers": {
"my-server": {
"type": "stdio",
"command": "python",
"args": ["path/to/server.py"]
}
}
}

  1. Add permission to ~/.claude/settings.json:

{
"permissions": {
"allow": ["mcp__my-server__*"]
}
}

  1. Start Claude Code and verify /mcp shows the server as connected with tools listed.
  2. Ask: "use the tool search_tables to search for 'quality'"
  3. Observe: model runs Bash(echo "Searching...") or calls listMcpResources instead of invoking

mcp__my-server__search_tables. Eventually says "tools not available in this session."

  1. Run /mcp again — server still shows as connected with tools listed.

Claude Model

Sonnet (default)

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

2.1.139

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

PowerShell

Additional Information

_No response_

View original on GitHub ↗

This issue has 2 comments on GitHub. Read the full discussion on GitHub ↗