Disabled MCP servers still inject instructions into context window
Problem
When MCP servers are disabled before a session begins, their associated tool definitions AND instruction blocks are still injected into the system prompt, consuming context window space unnecessarily.
Root cause
The disabled check happens at tool execution time, not at definition loading time. When a disabled tool is invoked, it fails with "No such tool available" — but by then the tool schemas and instructions have already been loaded into context.
The filtering needs to happen before building the system prompt, not after.
What's injected despite being disabled
- Tool definitions — JSON schemas for each MCP tool (~400-650 tokens per MCP)
- Instruction blocks — prose sections like "# Claude in Chrome browser automation" covering GIF recording, console debugging, dialog handling, tab management — injected as a system prompt section regardless of MCP status
Both contribute to ~13% context usage before the user sends a single message.
Expected behavior
Disabled MCP servers should not inject tool definitions or instructions into the system prompt / context window.
Prior issues
This has been reported multiple times since August 2025 without being fixed:
- #6320 — "Denied MCP tools have their tool prompt in context" (closed as not planned)
- #8888 — duplicate of #6320
- #10456 — "MCP toggle disabled still consumes context window" (duplicate)
- #11370 — "Disabled MCP servers still load tool definitions into Claude's context" (duplicate of #6320)
- #13311 — "
disabledMcpServerssetting not enforced at session startup"
Environment
- Claude Code v2.1.63
- macOS (Darwin 25.3.0)
This issue has 3 comments on GitHub. Read the full discussion on GitHub ↗