[BUG] ReadMcpResourceTool refuses servers that correctly declare the `resources` capability — blocks Figma Make source access

[BUG] ReadMcpResourceTool refuses servers that correctly declare the resources capability — blocks Figma Make source access

Environment

• Claude Code version: 2.1.185 (desktop app session)
• Platform: macOS 15.3.1 (darwin arm64)
• MCP server: Figma Dev Mode MCP Server 1.0.0 (http://127.0.0.1:3845/mcp, streamable HTTP), and the remote Figma connector (mcp.figma.com)

Summary

ReadMcpResourceTool and ListMcpResourcesTool report "Server does not support resources" for the Figma Dev Mode MCP server, even though that server verifiably declares the full resources capability in its initialize response and serves resources/list / resources/read correctly.

This makes Figma Make files unusable from Claude Code: Figma's get_design_context tool returns the Make file's source as resource_link content blocks, which can never be dereferenced. Related prior reports (#2826, #4110, #38460, #53453) were closed without a fix; this report adds a clean repro showing the server side is spec-compliant and the failure is client-side.

Steps to reproduce

1. Open a Figma Make file in the Figma desktop app, with the Dev Mode MCP server enabled (http://127.0.0.1:3845/mcp, registered in Claude Code as figma-desktop).
2. In Claude Code, call the Figma server's get_design_context tool. The result contains resource_link blocks, e.g.:

``json
{"type":"resource_link","name":"src/app/App.tsx","uri":"file://figma/make/source/<fileKey>/src/app/App.tsx","mimeType":"text/plain"}
``

1. Ask Claude Code to read one of those URIs (it calls ReadMcpResourceTool with server: "figma-desktop" and the URI).

Expected behavior

The resource is read via resources/read and its contents returned, as the server declares:

"capabilities": {
  "tools":     {"listChanged": true},
  "resources": {"listChanged": true, "subscribe": true},
  "prompts":   {"listChanged": true}
}

(verbatim from the server's initialize response — capture below)

Actual behavior

Error: Server "figma-desktop" does not support resources

ListMcpResourcesTool on the same server also returns "No resources found" in situations where a raw resources/list succeeds.

Proof the server is compliant (raw JSON-RPC against the same endpoint)

Handshake — capability is declared:

$ curl -s -X POST http://127.0.0.1:3845/mcp \
    -H 'Content-Type: application/json' -H 'Accept: application/json, text/event-stream' \
    -d '{"jsonrpc":"2.0","id":1,"method":"initialize","params":{"protocolVersion":"2025-06-18","capabilities":{},"clientInfo":{"name":"probe","version":"1.0.0"}}}'

data: {"result":{"protocolVersion":"2025-06-18","capabilities":{"tools":{"listChanged":true},"resources":{"listChanged":true,"subscribe":true},"prompts":{"listChanged":true}},"serverInfo":{"name":"Figma Dev Mode MCP Server","version":"1.0.0", ...}}}

resources/read works (after tools/call get_design_context registers the Make resources in the session):

data: {"result":{"contents":[{"uri":"file://figma/make/source/<fileKey>/src/app/App.tsx","mimeType":"text/plain","text":"import { useState } from \"react\";\n..."}]},"jsonrpc":"2.0","id":5}

Using this raw path we mirrored all 64 source files of a Make project without issues — so the server, the capability declaration, and the reads are all fine. Only Claude Code's tool layer refuses.

Impact

• Figma Make design-to-code workflows are broken in Claude Code but work in other MCP clients (e.g. Cursor), since Make source is only delivered via resource_links.
• Any MCP server whose resources are registered dynamically per session (i.e. absent from an initial resources/list) is likely affected the same way.
• The same "does not support resources" error also fires for the remote Figma connector (mcp.figma.com) even after its get_design_context successfully returns resource_links through Claude Code — there is no fallback there, since the remote server is OAuth/catalog-gated and cannot be reached out-of-band.

Suggested fixes (any of these would unblock)

1. Honor the server's declared resources capability from the live handshake when gating ReadMcpResourceTool (the current check appears stale or evaluated against something other than the actual initialize result).
2. When a tool result contains a resource_link, allow resources/read on that URI regardless of the cached capability snapshot.
3. Optionally: render/dereference resource_link content blocks natively, as tracked in the earlier closed issues.