Does Sandboxing MCP Output Fix the Agent Context Problem?
context-mode crossed 23,900 GitHub stars this week claiming a 98% context cut, while a 251-point Hacker News thread argued MCP was always a bad idea. Output sandboxing is worth doing. It doesn't fix cross-source context.
TL;DR: Sandboxing MCP output shrinks what a single tool call puts in the context window, and it's a cheap win for chatty servers like Playwright or GitHub. It doesn't rank results across sources, resolve contradictions between them, or know your team's vocabulary. For cross-source questions, you still need a context engine.
Two numbers moved this week. context-mode, an open source MCP server that sandboxes tool output, sits at about 23,900 GitHub stars as of September 21. It claims a 98% cut in context usage; one README example turns "47 × Read() = 700 KB" into "1 × ctx_execute() = 3.6 KB." The same weekend, a Hacker News thread titled "MCP was always a bad idea?" passed 251 points and 223 comments. Both are reacting to the same complaint: MCP burns tokens.
So does sandboxing MCP output fix the agent context problem? Partly. It fixes the size of what one tool call returns, and that's worth doing today. It doesn't fix what sits underneath: raw connectors hand back unranked, single-silo documents that the agent still has to assemble and reconcile on its own.
What does context-mode actually do?#
context-mode is an MCP server plus a set of editor hooks. It intercepts what a tool returns, keeps the full payload in a sandbox outside the conversation, and hands the model a compact result instead. Per its README, the project stores indexed content in a SQLite FTS5 database with BM25 ranking so the agent can pull details back on demand, and it routes across 17 platforms including Claude Code and Codex (context-mode README, 2026).
The numbers it advertises are its own. The README claims a 98% reduction in context usage, a worked example where 315 KB becomes 5.4 KB, and a script-execution case where 47 file reads totaling 700 KB collapse into one 3.6 KB call. None of that has been independently benchmarked, and the license is Elastic License v2 rather than a permissive one, which matters if you plan to build on it.
Treat it as one instance of a wider technique: MCP output sandboxing. We've measured the same family of tricks in our own token-tax reporting. What's new this week is how many people suddenly want it, at roughly 1,700 forks and climbing.
Why is "sandbox the output" this week's loudest MCP argument?#
Because the loudest MCP critics and the most popular MCP tooling are now saying the same thing. Maharshi Patel's September 14 post, "Why MCP Was Always a Bad Idea", argues that MCP was designed for weaker models. Today, he writes, "agents with terminal access can replace most MCP servers and often are more capable." His closing verdict: "MCP is now a protocol of a bygone era."
The Hacker News discussion mostly agreed on the overhead, if not the verdict. One commenter, 0x445442, put it bluntly: "Just tell the clanker to read the api documentation that should already exist. You dont need an MCP server for that." Another, jimbokun, answered a proposal for a standardized discovery layer with "Congrats you just invented the Unix shell!" A third, shibel, described moving off Linear's MCP to a CLI "because of the MCP's egregious token-usage" (Hacker News, 2026).
Read those together and the shared complaint is overhead and indirection. Nobody in the thread argues that agents should stop using tools. Output sandboxing is, structurally, the MCP ecosystem conceding that point from the inside.
GitHub MCP server uses too many tokens: what are the alternatives?#
Start with the number people search for. The official GitHub MCP server loads about 55,000 tokens across 93 tool definitions before the agent does any work, per our line-item breakdown of the GitHub MCP token cost. That's schema overhead, before a single result comes back. Anthropic's own tool-search documentation describes a typical GitHub, Slack, Sentry, Grafana and Splunk setup as consuming "~55k tokens in definitions before Claude does any work" (Anthropic docs, 2026).
GitHub knows. Its January 2026 changelog consolidated the Projects toolset into three tools and reported a reduction "of around 23,000 tokens (50%)" for that toolset alone (GitHub Changelog, 2026). The server also ships an allow-list, --toolsets or the GITHUB_TOOLSETS variable, so you load repos, issues and pull requests instead of everything (github-mcp-server README, 2026).
So the alternatives fall into four buckets: filter which tools load, compress the schemas that do load, sandbox what comes back, or stop routing the question through the raw connector at all. context-mode lives in the third bucket.
What are the GitHub MCP alternatives with lower token usage?#
Each bucket has a working implementation in 2026, and the savings are large enough that picking one matters more than which one.
Tool filtering and deferred loading. Anthropic's tool search loads only the 3 to 5 tools a request needs and "typically reduces this by over 85 percent" (Anthropic docs, 2026). An April 2026 arXiv paper on dynamic tool gating measured per-turn tool tokens dropping 95.0%, from 47.3k to 2.4k (Sadani and Kumar, arXiv:2604.21816, 2026). A March 2026 paper on vector-based tool selection reported a 99.6% cut in tool-related tokens with a 97.1% hit rate at K=3 across 121 tools from five MCP servers (Mudunuri et al., arXiv:2603.20313, 2026).
Schema compression. Atlassian Labs' Apache-2.0 mcp-compressor wraps a server so "the model sees a small compressed surface first," with four levels from low to max.
Output limits and sandboxing. Codex now supports a per-tool output_token_limit and enabled_tools allow-lists in its MCP config (OpenAI Codex docs, 2026). context-mode goes further and keeps the full payload retrievable.
Routing to a context engine. Our MCP token budget autopsy prices the first three per server. The fourth is the rest of this piece.
Sandboxing vs filtering vs a context engine: what each one fixes#
Anthropic's programmatic tool calling is the clearest statement of what output sandboxing buys you. Claude's code "filters and aggregates large tool outputs, or writes them to files, and only the final output enters the context window." On a 75-tool benchmark, that cut billed input tokens by roughly 38% with no change in accuracy (Anthropic docs, 2026). That is the ceiling for the technique: it returns the same answer with fewer tokens.
It also carries a cost the star count doesn't show. A February 2026 study of code-execution MCP designs found that while it "significantly reduces token usage and execution latency, it introduces a vastly expanded attack surface." The authors catalogue sixteen attack classes across five execution phases and recommend containerized sandboxing plus semantic gating (Felendler et al., arXiv:2602.15945, 2026). Sandbox the output, and you now own a sandbox.
None of these techniques changes what the agent gets: one system's view, unranked. A context engine does the assembly server-side and returns resolved, cited context before it reaches the agent. That's why the MCP plateau shows up regardless of how lean each individual server is.
| Technique | What it fixes | What it leaves |
|---|---|---|
| Raw MCP, no mitigation | Nothing. Full tool definitions and full output hit the window every call | Token cost, cross-source assembly, contradiction resolution |
| Output sandboxing or filtering (context-mode, programmatic tool calling) | The size of what one tool call returns, up to 98% per context-mode's own examples | Still per-source and unranked. The agent queries each system separately and reconciles the results itself |
| Schema compression or tool filtering (mcp-compressor, toolsets, tool search) | Verbose tool definitions and the per-turn schema tax | Doesn't touch what a call returns or cross-source reasoning. A fresh question still starts from zero |
| Context engine | Cross-source assembly, contradiction resolution, and unwritten-convention gaps, done before the agent sees anything | Not a drop-in for one chatty call inside a system you already know. Pair it with per-call hygiene where that's the bottleneck |
Frequently asked questions#
What is MCP output sandboxing?#
MCP output sandboxing intercepts what a tool returns, stores the full payload outside the model's context window, and passes back a compact summary or reference instead. context-mode does this with a SQLite index the agent can query later. Anthropic's programmatic tool calling does it by running tool calls in code so only the final result enters context.
Does context-mode replace a context engine?#
No. context-mode shrinks what a single tool call returns. It doesn't rank results across Slack, Jira and GitHub, resolve two documents that disagree, or know that your team calls the billing service "ledger." Those are the jobs a context engine does and MCP connectors don't. Use both if you have both problems.
Why does the GitHub MCP server use so many tokens?#
Because it loads 93 tool definitions up front, about 55,000 tokens of JSON schema before any request runs, per our GitHub MCP token cost breakdown above. Restricting toolsets, deferring tool loading, or swapping to the gh CLI for scoped operations each cut that bill substantially.
Does sandboxing MCP output fix the agent context problem?#
Not on its own. It solves token volume per call and leaves untouched the three problems that make agents guess: assembling context across sources, resolving contradictions between them, and knowing conventions nobody wrote down. Sandboxing MCP output delivers a smaller document, and a smaller document isn't a better one.
The April 2026 tool-gating paper is candid about this. Its authors tie the tools tax to reasoning degradation "as context utilization approaches published fracture points around 70%" (arXiv:2604.21816, 2026). Fewer tokens keep the model sharper for longer. Which of four Slack threads is current is a separate question, and no filter answers it.
That is the job of institutional context for coding agents. In our published benchmark, an agent with Unblocked context finished a Kotlin SDK task 83% faster, used 48% fewer tokens and cost 60% less than the same agent working through raw connectors (MCP connectors are not a context engine). You don't have to take our word for it. The context-engine-simulator is open source, so you can rerun it against your own repos.
What to do with your GitHub MCP setup this week#
Diagnose the pain first. If one chatty server is flooding sessions, and Playwright and GitHub are the usual suspects, turn on toolset allow-listing today and try output sandboxing or a per-tool output limit tomorrow. It's cheap, it's fast, and this week's 23,900 stars suggest plenty of teams are doing exactly that.
If the pain is different, if agents are guessing across Slack, Jira, GitHub and Confluence and getting it wrong, no per-call filter helps, because the problem was never the size of one response. That's when you want something that unifies Slack, Jira, GitHub, Notion and Confluence into the answer an agent can act on, rather than another system to search.
Russ Nealis at Webflow described both effects at once:
It saves a ton of tokens on our bill, but it also saves people a lot of time getting to what they actually want to deliver.
Russ Nealis — Staff Technical Product Manager, Webflow
Sandboxing gets you the first half. Resolved context is what gets you the second.
