[BUG] claude.ai marketplace MCP server instructions inject into context on every session regardless of Tool Search

Found 3 possible duplicate issues:

1. https://github.com/anthropics/claude-code/issues/39854
2. https://github.com/anthropics/claude-code/issues/44536
3. https://github.com/anthropics/claude-code/issues/45515

This issue will be automatically closed as a duplicate in 3 days.

• If your issue is a duplicate, please close it and 👍 the existing issue instead
• To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

Marking this as not a duplicate of the three flagged issues — the mechanism here is distinct enough to warrant a separate bug report.

Why this isn't #39854 — That's a feature request about lazy-loading CLAUDE.md instructions by action type. This issue is about MCP server instruction blocks (system prompt injections from claude.ai marketplace servers) that load unconditionally at session start — not CLAUDE.md, and not controllable via any existing mechanism.

Why this isn't #44536 — That's a broad feature request for lazy context loading across all context components. This is a specific bug: Tool Search already exists as a deferral mechanism for MCP tool schemas, and it works for schemas — but it has no effect on instruction blocks. The two mechanisms are decoupled, and only one is covered by Tool Search. This report is specifically about that gap.

Why this isn't #45515 — That issue is about phantom token counts that don't appear in /context breakdowns. This issue is about tokens that do appear and are reproducibly tied to MCP server instruction injection.

The core bug: Tool Search defers tool schema loading ✓ — but MCP server instruction blocks inject unconditionally regardless of whether Tool Search is enabled ✗. These are separate mechanisms. On a fresh session with 3+ claude.ai marketplace servers connected, instruction injection alone accounts for 30–55% of context before any user input. There's no existing setting, flag, or workaround that addresses the instructions specifically (as opposed to disabling the servers entirely).

Related: #20412 covers the broader auto-injection problem. This issue is specifically the Tool Search gap — the partial fix that doesn't actually fix the context overhead.

I think the deeper issue is that MCP server initialize.instructions are the wrong abstraction, not just an expensive one.

With deferred MCP tools, the model no longer has the actual tool schemas in context. Yet server instructions are still injected eagerly into a separate part of the system prompt, only loosely tied to deferred tools by naming or prefix conventions. They are not grounded in the tools being considered, not scoped to a tool call, and not retrieved with the relevant tool metadata.

So they become global, server-authored behavioral text with weak linkage to lazily discovered tools.

That seems worse than:

• putting guidance in tool descriptions, which are retrieved when needed
• exposing server-level guidance as a deferred resource
• not supporting server instructions at all

In a world where deferred tools are searched globally, eager MCP server instructions do not provide reliable discovery or guidance. They mostly add context cost, prompt pollution, and another trust-boundary problem.

Claude Code should not inject or honor MCP server initialize.instructions as system-prompt text. At most, they should be non-authoritative deferred metadata, retrieved only when the associated server or tools are selected.

+1, confirming the same behaviour on Linux.

Concrete repro from two independent Claude Code sessions on this machine within the same week:

• Session A (cwd /home/gudro/Development/projects/rosaparks/) — no Cloudflare tool calls during the session.
• Session B (cwd /home/gudro/.claude/) — no Cloudflare tool calls during the session.

In both, the cloudflare-observability marketplace MCP server injected its full instructions block as a <system-reminder> at session start. Same for cloudflare-api and cloudflare-graphql (three Cloudflare-flavoured servers installed for adjacent work, all firing unconditionally). The model has no opportunity to defer or scope — the instruction injection is decoupled from any tool use, exactly as the issue describes.

Side-effect worth flagging: because these <system-reminder> blocks fire at the top of every fresh session even when irrelevant, the model is implicitly trained to treat the entire <system-reminder> channel as low-signal. That degrades reminders that are load-bearing later in the session (e.g. coordination hints from project-aware MCP servers). The fix is the right one to prioritise.

Environment

• Claude Code CLI, current build
• Model: claude-opus-4-7[1m]
• OS: Fedora 43

Additional context from #64143: the same eager-injection concern also applies to plugin-contributed instruction blocks and CLAUDE.md content; reporter also asks for a per-source token billing breakdown so users can see what's consuming context.

+1, hitting this hard. Adding data points from an unmanaged personal seat running Claude Code 2.1.185 on Windows 11:

Measured impact (single fresh session, no user input)

| Connector | Instruction block size |
|---|---|
| Higgsfield (claude.ai marketplace) | ~100 KB |
| computer-use (claude.ai) | ~40 KB |
| Claude_in_Chrome (claude.ai) | ~35 KB |
| comfyui (local stdio MCP, ~115 tools) | ~80 KB schemas + ~5 KB instructions |
| Higgsfield Marketing/Soul/etc. skill descriptions auto-loaded | ~15 KB |

Total instruction injection on fresh window: ~270-300 KB before a single prompt — context bar starts at ~19-25% on a 200K window.

This is non-managed, so distinct from #64311 (which is about managed-seat re-injection per turn). My case is the baseline scenario @betson-g described: instructions block load unconditionally on startup, Tool Search has zero effect on them.

What would actually help (in priority order)

1. ENABLE_TOOL_SEARCH_DEFER_INSTRUCTIONS=true (or similar) — defer the instructions field of every MCP server the same way schemas are deferred, loading only when the agent first hits a tool from that server. This is the surgical fix.
2. Per-server opt-out — settings.json key like "mcpInstructionsDefer": ["Higgsfield", "computer-use"] so the user can pick which marketplace servers' instructions go on-demand.
3. /context attribution — show instruction blocks as a separate line, not bundled into Messages. Right now there's no way to see this cost in the UI.

Workaround currently in use

Removing marketplace servers and re-adding via claude mcp add per session-type, with helper scripts. This is the "the user has to know when they'll need it" anti-pattern — fundamentally the agent should be the one deciding, not the user. Hot reload is also not-planned per #46426, which leaves no clean path.

Without a fix, the only honest mitigation is asking users to manually disable every marketplace connector they don't use today in claude.ai/settings/connectors — terrible UX for an "agent infrastructure" feature.

I believe my team is impacted by the same bug. We are on Claude Enterprise and have many claude.ai connectors configured at the org-level. As of today, individuals cannot disable unauthenticated connectors on https://claude.ai/customize/connectors. These end up wasting context:

<img width="3024" height="1898" alt="Image" src="https://github.com/user-attachments/assets/b54499e6-8b31-4a96-b730-462f3caa9e35" />