MCP resources: ReadMcpResourceTool intermittently "not enabled in this context" after reconnect

Environment

• Claude Code version: 2.1.206
• OS: macOS (Darwin 25.5.0)
• MCP server: custom stdio server built with Python mcp.server.fastmcp.FastMCP

Summary

A custom stdio MCP server correctly registers several endpoints via the MCP resources primitive (@mcp.resource("proxmox://nodes"), etc. — verified in source, not @mcp.tool()). Per the docs ("Claude Code automatically provides tools to list and read MCP resources when servers support them"), Claude Code should expose ListMcpResourcesTool/ReadMcpResourceTool for the agent to call these directly.

Observed behavior across one continuous session, in order:

1. First call to ReadMcpResourceTool for proxmox://nodes succeeded in the sense that it reached the tool and returned a genuine backend error (an SSL certificate verification failure from the underlying API call) — proving the resource-read pathway was functional at that point.
2. After restarting Claude Code (to pick up an MCP server config change), the same ReadMcpResourceTool call failed with:

``
No such tool available: ReadMcpResourceTool. ReadMcpResourceTool exists but is not enabled in this context. Use one of the available tools instead.
``
even though a system reminder in the same turn stated the tool was "available again" after the MCP server reconnected.

1. Later in the same session, ToolSearch (the deferred-tool lookup mechanism) stopped returning ReadMcpResourceTool/ListMcpResourcesTool at all for select: queries — the tools were no longer discoverable, even though the MCP server itself remained connected (claude mcp list showed ✔ Connected) and its @mcp.tool()-registered tools continued to work reliably throughout.

Expected behavior

ReadMcpResourceTool/ListMcpResourcesTool should reliably reflect the current resources of a connected MCP server, consistent with how @mcp.tool()-registered tools are bridged (which worked reliably in every test).

Workaround

Dual-registering the same functions with both @mcp.resource(...) and @mcp.tool() decorators (FastMCP allows stacking since both decorators just register and return the function unchanged) makes the data reliably accessible via the tool-calling pathway, sidestepping the resources bridge entirely.

Impact

Any MCP server author who follows the spec correctly (using resources for read-only data, tools for mutations) currently gets an unreliable experience for the read-only half of their server when used from Claude Code, with no clear signal about why ReadMcpResourceTool becomes unavailable.