Context Mode: An MCP Server That Keeps Tool Output Out of the Context Window

The four context leaks Context Mode is built to plug

The README frames the problem in numbers. A Playwright snapshot costs 56 KB. Twenty GitHub issues cost 59 KB. One access log costs 45 KB. The claim is that after 30 minutes, 40% of the context window is gone. Alongside that, conversation compaction discards working state: which files were being edited, which tasks are in progress, what the user last asked for. A third leak is on the output side, where the agent burns tokens on pleasantries and verbose explanation.

The project positions itself as the other half of the context problem, meaning it does not try to make the model write more concisely. The README is explicit that context-mode keeps raw data out of context but never dictates how the model writes its final answer, and it cites a Moonshot AI note about kimi-k2.5 in an opencode issue to argue that aggressive brevity prompts degrade coding and reasoning benchmarks. That is a defensible split: routing decisions are mechanical and enforceable, writing style is not. The audience is anyone running an agent that calls MCP tools returning large payloads, which in practice means people using Playwright, GitHub, or log-reading tools inside Claude Code, Cursor, Codex or one of the other listed clients.

Sandboxed tools, SQLite plus FTS5, and the think-in-code rule

Three mechanisms sit under the four claims. The first is sandboxing: tool output is intercepted and kept out of the context window, with the README giving 315 KB becoming 5.4 KB as its headline reduction. The second is session continuity. Every file edit, git operation, task, error and user decision is tracked in SQLite. On compaction, the project does not dump that history back into context. It indexes events into FTS5 and retrieves only relevant rows via BM25 search. That is a retrieval layer over an event log, and it is the part of the design that is easiest to get wrong in a way users will notice, because a BM25 query that misses an event looks identical to an event that was never recorded.

The third mechanism is the one the README calls mandatory: think in code. The agent writes a script that performs the analysis and logs only the result, rather than reading files into context to reason over them. The example given is a JavaScript snippet passed to ctx_execute that reads every .ts file in src and prints a line count per file, replacing what the README estimates as 47 Read calls at 700 KB with one call at 3.6 KB. Whether that ratio holds depends entirely on the task; a one-file lookup gains nothing from being turned into a script. The routing block is described as staying focused on where data goes, not how the model talks, which is a narrower mandate than the surrounding copy might suggest.

Install paths differ sharply by client

The README groups platforms by install complexity and states the rule plainly: hook-capable platforms get automatic routing enforcement, non-hook platforms need a one-time routing file copy. Claude Code is documented as a plugin marketplace install that is fully automatic, with a stated prerequisite of Claude Code v1.0.33 or later, checkable with claude --version. The README lists 17 supported clients, including Claude Code, Gemini CLI, Codex, Cursor, VS Code Copilot and opencode, plus an OpenClaw gateway integration.

That grouping is the single most important thing to check before you start, because the difference between the two groups is not cosmetic. On a hook-capable client, routing enforcement happens without you doing anything after install. On a non-hook client, you copy a routing file once. Confirm which group your client falls into on the project's install page rather than assuming it from the client name.

The 98% number is a property of sandboxed tools, not your session

The headline reduction is easy to misread. It describes what happens to the output of tools that go through the sandbox. It does not describe your whole context window, and it does not apply to anything the agent reads directly. If your workflow is mostly a few small file reads and short shell commands, the sandbox has little to intercept and the percentage is meaningless for you.

The session memory has a sharper edge. The README states that if you do not pass --continue, previous session data is deleted immediately, and calls this a fresh session meaning a clean slate. That is a deliberate design choice, not a bug, but it inverts the usual expectation. Most tools accumulate history until you clear it. Here, forgetting is the default and continuity is opt-in per invocation. Anyone who installs the server, works for an hour, closes the terminal, and reopens expecting the SQLite event log to still be there will be surprised.

Where a plain MCP filesystem server is the better answer

The obvious alternative is to run no context-management layer at all and use a standard MCP filesystem or shell server, accepting that tool output lands in the context window and relying on the client's own compaction. The difference in approach is not a matter of degree. A standard MCP server is transparent: what the tool returns is what the model sees, and you can reason about the context budget by counting tool calls. Context Mode inserts a retrieval layer between the tool and the model, which buys you a smaller window but costs you direct inspection. When a sandboxed result looks wrong, you are now debugging two things: the tool and the routing.

For short sessions, one-off questions, or work where the tool output is the thing you actually want the model to read in full, that trade is bad. The think-in-code rule makes it worse for those cases, because it asks the agent to write a script to answer a question it could have answered by reading one file. Context Mode is for the opposite shape of work: long sessions, repeated tool calls, large payloads, and a real cost to losing working state at compaction. If your sessions are ten minutes long, a plain filesystem server is simpler and has fewer moving parts to misconfigure.

Licence, release cadence and what you are signing up to maintain

The repository metadata reports the licence as NOASSERTION while package.json declares Elastic-2.0 (ELv2, the Elastic License 2.0). Those two signals disagree, and the discrepancy matters more than usual here because ELv2 is not an OSI-approved open source licence. It permits most internal use but restricts providing the software as a hosted or managed service and removing licence notices. The project describes itself as used across teams at a long list of companies, rendered as badges with no links, which is a marketing claim rather than a verifiable one. If you need to redistribute Context Mode inside a product, read the LICENSE file yourself rather than the badge. This is not legal advice.

The latest GitHub releases are v2.0.0-next.33 and v2.0.0-next.32 (both 2026-11-03) and v2.0.0-next.30 (2026-11-02), with the repository's last push dated 2026-11-02, while package.json still reads 1.0.169. Three prereleases in two days tells you the project ships fixes continuously and that pinning a version is the only way to get a stable surface.

Editorial conclusion

Adopt Context Mode if you run long agent sessions against noisy tools (Playwright snapshots, GitHub issue fetches, access logs) inside a hook-capable client such as Claude Code, and you accept ELv2 terms plus a fast-moving release cadence. Do not adopt it if your client has no hook support and you are unwilling to copy a routing file by hand, or if you need an OSI-approved licence for redistribution. Before installing, confirm three things: your client version meets the stated minimum, whether you will pass --continue (without it the previous session's data is deleted), and which tools you are willing to route through the sandbox, since the 98% figure is a property of the sandboxed tools, not of your whole session.

Frequently asked questions

Official sources

1. Issues
2. mksglu/context-mode on GitHub
3. Project website
4. README
5. Releases