I Was Wasting 31% of My Context Window Before I Fixed My MCP Setup

Key Takeaways

• Unfiltered MCP tool schemas consumed ~31% of Claude’s context window.
• Excess schemas cause slower agents and higher tool‑selection errors.
• The MCP Stack Diet trims, filters, and progressively loads tools.
• Atlassian’s mcp‑compressor implements Layer 1 compression via proxy.
• Layered approach restores context for tasks and reduces token costs.

Pulse Analysis

Large language models like Claude and GPT‑4o operate within strict token windows, and every token counts toward both latency and cost. When developers attach multi‑tool agents, each tool’s description, JSON schema, and examples are injected into the prompt. At scale—dozens of tools across multiple servers—this overhead can gobble up a third of the available context, leaving less room for the actual user query and forcing the model to waste compute parsing irrelevant data.

Recent measurements, including the author’s audit and Quandri’s "MCP is dead" study, show tool definitions alone consuming 10‑16% of context windows. The side effects are tangible: agents become slower, mis‑route calls, and retry operations that a human would avoid. The hidden cost isn’t just token usage; it’s degraded decision quality, higher API bills, and a poorer user experience. As AI agents proliferate in enterprise settings, unchecked schema bloat threatens scalability and ROI.

The proposed MCP Stack Diet offers a pragmatic, layered remedy. Compression (Layer 1) shrinks schemas via a proxy like Atlassian’s mcp‑compressor, while filtering (Layer 2) hides irrelevant tools. Progressive discovery (Layer 3) loads full definitions only when needed, and CLI bypass (Layer 4) opts for direct command execution when state isn’t required. Finally, isolating third‑party servers (Layer 5) prevents rogue tools from contaminating the context. Early adopters report faster tool selection, lower token consumption, and smoother agent interactions, making the diet a best‑practice blueprint for any organization deploying LLM‑powered automation.