Claude Design agent can't use a connected filesystem MCP — defaults to per-file download cards and loops expensive rework

Summary

When working in the Claude Design app (Fable), the agent does not appear to have access to a filesystem MCP server that is connected on the user's side. As a result it repeatedly produces per-file download cards instead of writing files directly to the project folder — even after being explicitly told the filesystem MCP is available and asked to use it. Because nothing is written to disk, the same files get regenerated turn after turn, which burns a large amount of usage on the most expensive model tier for no net progress. Two secondary problems compound it (below).

Environment

• Surface: Claude Design app (Fable model)
• A filesystem MCP server is connected/configured on the user's side and works in Claude Code (CLI) against the same project folder.

Primary behavior — filesystem MCP not surfaced → download-card fallback

1. User connects a filesystem MCP and asks the Design agent to read/write files in the project folder.
2. The agent responds with downloadable file cards (one per file) instead of writing to disk.
3. User repeatedly tells it the MCP is connected and to use it.
4. The agent either keeps producing download cards, or (when pressed) reports that no filesystem MCP tools are present in its tool list for that conversation — "the connection genuinely isn't visible from here" — and suggests enabling the connector in the app, which the user had already done.

Whether the MCP is genuinely not exposed to Design conversations, or the agent is failing to discover/use tools that are present, the user-visible result is identical: no direct-write path, so it defaults to the expensive through-chat download-card route.

Why it's costly
Each regenerated file's content is emitted as output tokens (the card) and then re-billed as input tokens every subsequent turn it stays in context — the same mechanism described in #78268 — except here there is no direct-write path to fall back to, so the rework loop repeats indefinitely. On the Fable tier this is a large, silent usage multiplier: the session's cost is dominated by re-emitting the same deliverable rather than by new work.

Compounding problem 2 — doesn't read the source that already contains the answer
The project's own source files contain the information the agent needs (e.g., the intended ordering/spec it keeps guessing at), but the agent generates from scratch instead of reading those files first — partly because, without the filesystem MCP, it cannot read them at all.

Compounding problem 3 — no way for the agent to see its own rendered output
There is no mechanism for the agent to view what it actually produced, so the user has to paste many screenshots (roughly 19 in one session) just to show the agent its own work before it can iterate. (Related: #69986.)

Expected

• A connected filesystem MCP should be available to Claude Design conversations, and direct-write to disk should be the default so files land in the project folder without a per-file download card (cf. #78268).
• The agent should read existing project files before regenerating from scratch.
• The agent should have a way to observe its rendered output without the user having to screenshot it.

Impact
Repeated full regeneration of the same deliverable, nothing persisted to disk, and heavy usage consumption on the most expensive tier — the failure mode presents as "an expensive session that produced nothing that stuck."

Related

• #78268 — download-card routing instead of direct disk write, ~2x token usage (same mechanism; this issue is the Design-surface case where no direct-write path exists to fall back to)
• #69986 — agent unable to capture/see its own Claude Design output
• #75429 — automatic usage/credit refund when a response fails to meet the request
• Connected-filesystem-MCP-not-visible cluster: #2682, #15180