MCP tool schemas consume context unconditionally, creating an unmanageable ceiling on project complexity

Problem

Every MCP tool definition (name, description, JSON parameter schema) is injected into the system prompt for every conversation, regardless of whether the tools are relevant to the current task. This creates a fixed context tax that scales with toolchain complexity — exactly the dimension that grows with real-world project complexity.

There is no visibility into this cost and no way for the user to manage it.

Real-world impact

Small project, already at the edge: A hobby monorepo (90K LOC, ESP32 firmware + KiCad PCB hardware) with a moderately complex toolchain (KiCad ~50 tools, Blender ~10, FreeCAD ~15, Chrome ~20, Claude Preview ~15) hit "Prompt is too long" crashes during a straightforward HTML refactoring task. The session was short (~6-8 turns), the files were small (80KB of HTML), and the task was simple (split one file into three).

Larger projects are effectively locked out: A 400K LOC enterprise monorepo with hooks into toolchains across multiple business units — deployment pipelines, data platforms, CI systems, monitoring, multiple cloud providers — would likely exhaust the context window before any meaningful conversation could begin. These are exactly the projects that benefit most from AI-assisted development, and they're the ones least able to use it.

Why this isn't user-manageable

The user has:

• No visibility into how much context the system prompt consumes. There's no dashboard, no token budget indicator, no warning before a session starts that says "your toolchain is consuming X% of available context."
• No control over which tools are loaded. MCP servers are configured at the project level; there's no per-session or per-task scoping.
• No desire to manage this. Asking users to manage context window allocation is like asking a driver to reach under the hood and manually adjust ignition timing. It's an implementation detail that should be invisible. Users configure tools because they need them for their project — the system should handle the resource implications.

Current behavior

All registered MCP tool schemas are injected into every conversation's system prompt, unconditionally. A project with 5 MCP servers and 110+ tools pays the full context cost even when the user is doing a task that requires zero MCP tools.

Possible approaches

These are suggestions, not prescriptions — the Claude Code team knows the constraints better:

• Task-scoped tool loading: Only inject tool schemas when they're relevant to the current task or first referenced
• Lazy schema injection: Start with tool names only; load full parameter schemas on first use
• Tool groups / profiles: Let users define session profiles ("firmware", "PCB layout", "web UI") that load subsets of tools
• Budget visibility: Show users what's consuming their context budget before and during a session
• Automatic tool pruning: If context pressure is high, deprioritize tool schemas for servers that haven't been used in the current session

Environment

• Claude Code with Opus 4.6 (200K token context)
• macOS, 5 MCP servers configured (KiCad, Blender, FreeCAD, Chrome, Claude Preview)
• Monorepo with chained CLAUDE.md files (~26KB) + memory (~7KB)
• Session crash documented in #23463