Context Mode
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@Context ModeShow me a summary of the latest errors from the log file, don't dump raw data"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Context Mode
The other half of the context problem.
The Problem
Every MCP tool call dumps raw data into your context window. A Playwright snapshot costs 56 KB. Twenty GitHub issues cost 59 KB. One access log — 45 KB. After 30 minutes, 40% of your context is gone. And when the agent compacts the conversation to free space, it forgets which files it was editing, what tasks are in progress, and what you last asked for. On top of that, the agent wastes output tokens on filler, pleasantries, and verbose explanations — burning context from both sides.
How Context Mode Solves It
Context Mode is an MCP server that solves all four sides of this problem:
Context Saving — Sandbox tools keep raw data out of the context window. 315 KB becomes 5.4 KB. 98% reduction.
Session Continuity — Every file edit, git operation, task, error, and user decision is tracked in SQLite. When the conversation compacts, context-mode doesn't dump this data back into context — it indexes events into FTS5 and retrieves only what's relevant via BM25 search. The model picks up exactly where you left off. If you don't
--continue, previous session data is deleted immediately — a fresh session means a clean slate.Think in Code — The LLM should program the analysis, not compute it. Instead of reading 50 files into context to count functions, the agent writes a script that does the counting and
console.log()s only the result. One script replaces ten tool calls and saves 100x context. This is a mandatory paradigm across all 17 supported clients, plus the OpenClaw gateway integration: stop treating the LLM as a data processor, treat it as a code generator.// Before: 47 × Read() = 700 KB. After: 1 × ctx_execute() = 3.6 KB. ctx_execute("javascript", ` const files = fs.readdirSync('src').filter(f => f.endsWith('.ts')); files.forEach(f => console.log(f + ': ' + fs.readFileSync('src/'+f,'utf8').split('\\n').length + ' lines')); `);No prose-style enforcement — context-mode keeps raw data out of context but never dictates how the model writes its final answer. Brevity, completeness, formatting — your model's call (or yours via your own
CLAUDE.md/AGENTS.md). Aggressive brevity prompts have been shown to degrade coding/reasoning benchmarks (Moonshot AI onkimi-k2.5) — the routing block stays focused on where data goes, not on how the model talks.
Related MCP server: Context Mode
Install
Platforms are grouped by install complexity. Hook-capable platforms get automatic routing enforcement. Non-hook platforms need a one-time routing file copy.
Prerequisites: Claude Code v1.0.33+ (claude --version). If /plugin is not recognized, update first: brew upgrade claude-code or npm update -g @anthropic-ai/claude-code.
Install:
/plugin marketplace add mksglu/context-mode
/plugin install context-mode@context-modeRestart Claude Code (or run /reload-plugins).
Verify:
/context-mode:ctx-doctorAll checks should show [x]. The doctor validates runtimes, hooks, FTS5, and plugin registration.
Routing: Automatic. The SessionStart hook injects routing instructions at runtime — no file is written to your project. The plugin registers all hooks (PreToolUse, PostToolUse, UserPromptSubmit, PreCompact, SessionStart, Stop) and 11 MCP tools — six sandbox tools (ctx_batch_execute, ctx_execute, ctx_execute_file, ctx_index, ctx_search, ctx_fetch_and_index) plus five meta-tools (ctx_stats, ctx_doctor, ctx_upgrade, ctx_purge, ctx_insight).
Slash Command | What it does |
| Context savings — per-tool breakdown, tokens consumed, savings ratio. |
| Diagnostics — runtimes, hooks, FTS5, plugin registration, versions. |
| Index a local file or directory into the persistent FTS5 knowledge base. |
| Search previously indexed content. |
| Pull latest, rebuild, migrate cache, fix hooks. |
| Permanently delete all indexed content from the knowledge base. |
| Opens the hosted Insight dashboard (context-mode.com/insight) in your browser — org analytics for AI-assisted engineering teams. |
Note: Slash commands are a Claude Code plugin feature. On other platforms, type
ctx stats,ctx doctor,ctx index,ctx search,ctx upgrade, orctx insightin the chat — the model calls the MCP tool automatically. See Utility Commands.
Status line (optional): Claude Code's plugin manifest cannot declare a status line, so this is a one-time manual edit to ~/.claude/settings.json:
{
"statusLine": {
"type": "command",
"command": "context-mode statusline"
}
}After saving, restart Claude Code. The bar shows $ saved this session · $ saved across sessions · % efficient so you can see savings accumulate in real time. The wiring is path-free — context-mode statusline resolves through the bundled CLI regardless of where the plugin cache lives.
claude mcp add context-mode -- npx -y context-modeThis gives you all 11 MCP tools without automatic routing. The model can still use them — it just won't be nudged to prefer them over raw Bash/Read/WebFetch. Good for trying it out before committing to the full plugin.
Prerequisites: Node.js >= 22.5 (or Bun), Gemini CLI installed.
Install:
Install context-mode globally:
npm install -g context-modeAdd the following to
~/.gemini/settings.json. This single file registers the MCP server and all four hooks:{ "mcpServers": { "context-mode": { "command": "context-mode" } }, "hooks": { "BeforeTool": [ { "matcher": "run_shell_command|read_file|read_many_files|grep_search|search_file_content|web_fetch|activate_skill|mcp__plugin_context-mode|mcp__context-mode|mcp__(?!.*context-mode)", "hooks": [{ "type": "command", "command": "context-mode hook gemini-cli beforetool" }] } ], "AfterTool": [ { "matcher": "", "hooks": [{ "type": "command", "command": "context-mode hook gemini-cli aftertool" }] } ], "PreCompress": [ { "matcher": "", "hooks": [{ "type": "command", "command": "context-mode hook gemini-cli precompress" }] } ], "SessionStart": [ { "matcher": "", "hooks": [{ "type": "command", "command": "context-mode hook gemini-cli sessionstart" }] } ] } }Restart Gemini CLI.
Verify:
/mcp listYou should see context-mode: ... - Connected.
Routing: Automatic via SessionStart hook. Optionally copy routing instructions for full model awareness:
cp node_modules/context-mode/configs/gemini-cli/GEMINI.md ./GEMINI.mdWhy the BeforeTool matcher? It targets only tools that produce large output (
run_shell_command,read_file,read_many_files,grep_search,search_file_content,web_fetch,activate_skill) plus context-mode's own tools (mcp__plugin_context-mode). This avoids unnecessary hook overhead on lightweight tools while intercepting every tool that could flood your context window.
Full config reference: configs/gemini-cli/settings.json
Prerequisites: Node.js >= 22.5 (or Bun), VS Code with Copilot Chat v0.32+.
Install:
Install context-mode globally:
npm install -g context-modeCreate
.vscode/mcp.jsonin your project root:{ "servers": { "context-mode": { "command": "context-mode" } } }Create
.github/hooks/context-mode.json:{ "hooks": { "PreToolUse": [ { "type": "command", "command": "context-mode hook vscode-copilot pretooluse" } ], "PostToolUse": [ { "type": "command", "command": "context-mode hook vscode-copilot posttooluse" } ], "SessionStart": [ { "type": "command", "command": "context-mode hook vscode-copilot sessionstart" } ] } }Restart VS Code.
Verify: Open Copilot Chat and type ctx stats. Context-mode tools should appear and respond.
Routing: Automatic via SessionStart hook. Optionally copy routing instructions for full model awareness:
cp node_modules/context-mode/configs/vscode-copilot/copilot-instructions.md .github/copilot-instructions.mdFull hook config including PreCompact: configs/vscode-copilot/hooks.json
Prerequisites: Node.js >= 22.5 (or Bun), JetBrains IDE with GitHub Copilot plugin v1.5.57+.
Install:
Install context-mode globally:
npm install -g context-modeAdd MCP server via Settings UI: Settings > Tools > AI Assistant > Model Context Protocol (MCP) > Add Server:
Name:
context-modeCommand:
context-mode
Create
.github/hooks/context-mode.json:{ "hooks": { "PreToolUse": [ { "type": "command", "command": "context-mode hook jetbrains-copilot pretooluse" } ], "PostToolUse": [ { "type": "command", "command": "context-mode hook jetbrains-copilot posttooluse" } ], "SessionStart": [ { "type": "command", "command": "context-mode hook jetbrains-copilot sessionstart" } ] } }Restart the JetBrains IDE.
Verify: Open Copilot Chat and type ctx stats. Context-mode tools should appear and respond.
Routing: Automatic via SessionStart hook. Optionally copy routing instructions for full model awareness:
cp node_modules/context-mode/configs/jetbrains-copilot/copilot-instructions.md .github/copilot-instructions.mdFull hook config including PreCompact: configs/jetbrains-copilot/hooks.json
Full setup guide: docs/jetbrains-copilot.md
Prerequisites: Node.js >= 22.5 (or Bun), GitHub Copilot CLI (copilot) installed. Set COPILOT_HOME first if you use an isolated Copilot home.
Install — Option A (plugin, one command — recommended):
npm install -g context-mode # the plugin's MCP server runs the global binary
copilot plugin install mksglu/context-mode:configs/copilot-cli # registers MCP + hooks + routing skillThe bundle's .mcp.json pins CONTEXT_MODE_PLATFORM=copilot-cli, so context-mode self-identifies as Copilot — ctx_upgrade and platform detection resolve copilot-cli even when Claude Code is co-installed (whose ~/.claude/ would otherwise win). No context-mode upgrade / agent call needed. To try it from a local clone before it lands on the default branch, point Copilot at the bundle directory: copilot --plugin-dir /path/to/context-mode/configs/copilot-cli.
Install — Option B (manual, no plugin):
Install context-mode globally:
npm install -g context-modeRegister the MCP server with Copilot CLI's built-in command (writes
~/.copilot/mcp-config.jsonfor you):copilot mcp add context-mode -- context-modeConfigure hooks in
~/.copilot/hooks/context-mode.json(or$COPILOT_HOME/hooks/context-mode.json). The config uses flat{ "type": "command", "command": "..." }entries; context-mode also writes a top-level"version": 1, but that field is optional — the Copilot CLI accepts hook configs that omit it (it is pinned only for self-documentation). Copilot CLI fires six events context-mode uses:{ "version": 1, "hooks": { "preToolUse": [{ "type": "command", "command": "context-mode hook copilot-cli pretooluse" }], "postToolUse": [{ "type": "command", "command": "context-mode hook copilot-cli posttooluse" }], "preCompact": [{ "type": "command", "command": "context-mode hook copilot-cli precompact" }], "sessionStart": [{ "type": "command", "command": "context-mode hook copilot-cli sessionstart" }], "userPromptSubmitted": [{ "type": "command", "command": "context-mode hook copilot-cli userpromptsubmit" }], "agentStop": [{ "type": "command", "command": "context-mode hook copilot-cli stop" }] } }Or let context-mode write this hooks file for you:
context-mode upgrade(run from a Copilot CLI context, or withCONTEXT_MODE_PLATFORM=copilot-cli).upgradewrites the hooks file only — register the MCP server withcopilot mcp addin step 2.Restart Copilot CLI.
Plugins: Option A above uses Copilot CLI's plugin system, which registers MCP servers (
.mcp.json), hooks (hooks.json), and skills (skills/) together — not just skills/agents. The shipped bundle isconfigs/copilot-cli/;copilot plugin install owner/repo:pathinstalls it in one command (no clone). Option B is the equivalent without a plugin.
Version note: the hook commands run the global
context-mode(context-mode hook copilot-cli …), so they need a context-mode version with Copilot CLI support. On an older global the hooks are inert (no routing/capture) until you upgrade — but they do not block your tools (context-mode fails open). Upgrade withnpm install -g context-mode@latest.
Verify: In a Copilot CLI session, type ctx stats. Context-mode tools should appear and respond. Run context-mode doctor to confirm hook + MCP registration.
Routing: Automatic via hooks (PreToolUse interception + SessionStart routing block). Auto-detected via MCP clientInfo.name (GitHub Copilot CLI) or, in a bare shell, a context-mode-written marker (~/.copilot/mcp-config.json or ~/.copilot/hooks/context-mode.json) — not a bare ~/.copilot/ dir, so a co-installed-but-unconfigured Copilot CLI is not mis-detected as context-mode-on-copilot.
See docs/platform-support.md for the full reference. Tracking: #775.
Prerequisites: Node.js >= 22.5 (or Bun), Cursor with agent mode.
🚧 Work in progress — the Marketplace plugin is awaiting Cursor team review. Until it's listed, install via the local-folder path described in Option A. Tracking in #485 / #489.
Option A — Marketplace plugin (recommended once published)
After Cursor lists context-mode in the Marketplace, install with one click. The plugin auto-registers MCP, hooks (preToolUse, postToolUse, sessionStart, stop, afterAgentResponse), rules, and skills. No manual config required.
Until then, use the local-folder path:
Windows (PowerShell) — Cursor does not follow Windows symlinks/junctions, so use robocopy:
git clone https://github.com/mksglu/context-mode.git
cd context-mode
robocopy . "$env:USERPROFILE\.cursor\plugins\local\context-mode" /MIR `
/XD node_modules .git build web tests scripts .vscode `
/XF *.log .gitignore *.bundle.mjs.mapmacOS / Linux:
git clone https://github.com/mksglu/context-mode.git
ln -s "$PWD/context-mode" ~/.cursor/plugins/local/context-modeRestart Cursor. The plugin appears in Settings → Plugins as "Context Mode (Local)". To pull updates, re-run the same robocopy / ln -s line.
Note: if
.cursor/hooks.jsonalready contains context-mode entries from a priorOption Binstall,context-mode doctorwill warn about duplicate hook firings. Remove one configuration to keep events single-fire.
Option B — Manual install (existing path)
Install context-mode globally:
npm install -g context-modeCreate
.cursor/mcp.jsonin your project root (or~/.cursor/mcp.jsonfor global):{ "mcpServers": { "context-mode": { "command": "context-mode" } } }Create
.cursor/hooks.json(or~/.cursor/hooks.jsonfor global):{ "version": 1, "hooks": { "preToolUse": [ { "command": "context-mode hook cursor pretooluse", "matcher": "Shell|Read|Grep|WebFetch|Task|MCP:ctx_execute|MCP:ctx_execute_file|MCP:ctx_batch_execute" } ], "postToolUse": [ { "command": "context-mode hook cursor posttooluse" } ], "stop": [ { "command": "context-mode hook cursor stop" } ] } }The
preToolUsematcher is optional — without it, the hook fires on all tools. Thestophook fires when the agent turn ends and can send a followup message to continue the loop.afterAgentResponseis also available (fire-and-forget, receives full response text).Copy the routing rules file. Cursor lacks a SessionStart hook, so the model needs a rules file for routing awareness:
mkdir -p .cursor/rules cp node_modules/context-mode/configs/cursor/context-mode.mdc .cursor/rules/context-mode.mdcRestart Cursor or open a new agent session.
Verify: Open Cursor Settings > MCP and confirm "context-mode" shows as connected. In agent chat, type ctx stats.
Routing: Hooks enforce routing programmatically via preToolUse/postToolUse/stop. The .cursor/rules/context-mode.mdc file provides routing instructions at session start since Cursor's sessionStart hook is currently rejected by their validator (forum report). Project .cursor/hooks.json overrides ~/.cursor/hooks.json.
Known limitation: Cursor accepts additional_context in hook responses but does not surface it to the model (forum #155689). Routing relies on the .mdc rules file instead of hook context injection.
Full configs: configs/cursor/hooks.json | configs/cursor/mcp.json | configs/cursor/context-mode.mdc
Prerequisites: Node.js >= 22.5 (or Bun), OpenCode installed.
Install:
Add to
opencode.jsonin your project root (or~/.config/opencode/opencode.jsonfor global):{ "$schema": "https://opencode.ai/config.json", "plugin": ["context-mode"] }The
pluginentry registers all 11ctx_*tools natively and enables hooks — OpenCode calls context-mode's TypeScript plugin in-process, so there is no redundant stdio MCP child per session.(Optional) Copy the routing rules file. The model needs an
AGENTS.mdfile for routing awareness:cp node_modules/context-mode/configs/opencode/AGENTS.md AGENTS.mdThis tells the model which tools to use and which commands are blocked. Without it, hooks still enforce routing — but the model won't know why a command was denied.
Restart OpenCode.
Verify: In the OpenCode session, type ctx stats. Context-mode tools should appear and respond.
Upgrade note: If an existing config has BOTH plugin: ["context-mode"] AND mcp.context-mode, OpenCode will register zero ctx_* tools — the plugin path correctly suppresses MCP duplicates, but the legacy MCP entry confuses the loader. Run context-mode upgrade to remove the legacy mcp.context-mode entry; your other MCP servers are preserved. v1.0.140+ emits a stderr diagnostic with the same guidance when this happens.
Routing: Hooks enforce routing programmatically via tool.execute.before and tool.execute.after. The optional AGENTS.md file provides routing instructions for model awareness. The experimental.session.compacting hook builds resume snapshots when the conversation compacts. The experimental.chat.system.transform hook injects the routing block and prior-session snapshots at session start, enabling session continuity across restarts. The chat.message hook captures user prompts and decisions (UserPromptSubmit equivalent).
Note: OpenCode lacks a real SessionStart hook (#14808, #5409). The plugin uses
experimental.chat.system.transformas a surrogate — it injects both the routing block and resume snapshots into the system prompt. User-prompt capture useschat.messageinstead of the missing UserPromptSubmit hook. AGENTS.md/CLAUDE.md/CONTEXT.md rules are captured automatically on first hook fire per project.
Full configs: configs/opencode/opencode.json | configs/opencode/AGENTS.md
Prerequisites: Node.js >= 22.5 (or Bun), KiloCode installed.
Install:
Add to
kilo.jsonin your project root (or~/.config/kilo/kilo.jsonfor global):{ "$schema": "https://app.kilo.ai/config.json", "plugin": ["context-mode"] }The
pluginentry registers all 11ctx_*tools natively and enables hooks — KiloCode calls context-mode's TypeScript plugin in-process, so there is no redundant stdio MCP child per session.(Optional) Copy the routing rules file. KiloCode shares the OpenCode plugin architecture, so the model needs an
AGENTS.mdfile for routing awareness:cp node_modules/context-mode/configs/opencode/AGENTS.md AGENTS.mdRestart KiloCode.
Verify: In the KiloCode session, type ctx stats. Context-mode tools should appear and respond.
Upgrade note: If an existing config has BOTH plugin: ["context-mode"] AND mcp.context-mode, KiloCode will register zero ctx_* tools — the plugin path correctly suppresses MCP duplicates, but the legacy MCP entry confuses the loader. Run context-mode upgrade to remove the legacy mcp.context-mode entry; your other MCP servers are preserved. v1.0.140+ emits a stderr diagnostic with the same guidance when this happens.
Routing: Hooks enforce routing programmatically via tool.execute.before and tool.execute.after. The optional AGENTS.md file provides routing instructions for model awareness. The experimental.session.compacting hook builds resume snapshots when the conversation compacts. The experimental.chat.system.transform hook injects the routing block and prior-session snapshots at session start, enabling session continuity across restarts. The chat.message hook captures user prompts and decisions (UserPromptSubmit equivalent).
Note: KiloCode shares the same plugin architecture as OpenCode, using the OpenCodeAdapter with platform-specific configuration paths (
kilo.jsoninstead ofopencode.json,~/.config/kilo/instead of~/.config/opencode/). Like OpenCode, it lacks a real SessionStart hook — the plugin usesexperimental.chat.system.transformas a surrogate. User-prompt capture useschat.messageinstead of the missing UserPromptSubmit hook. AGENTS.md/CLAUDE.md/CONTEXT.md rules are captured automatically on first hook fire per project.
Prerequisites: OpenClaw gateway running (>2026.1.29), Node.js 22+.
context-mode runs as a native OpenClaw gateway plugin, targeting Pi Agent sessions (Read/Write/Edit/Bash tools). Unlike other platforms, there's no separate MCP server — the plugin registers directly into the gateway runtime via OpenClaw's plugin API.
Install:
Clone and install:
git clone https://github.com/mksglu/context-mode.git cd context-mode npm run install:openclawThe installer uses
$OPENCLAW_STATE_DIRfrom your environment (default:/openclaw). To specify a custom path:npm run install:openclaw -- /path/to/openclaw-stateCommon locations: Docker —
/openclaw(the default). Local —~/.openclawor wherever you setOPENCLAW_STATE_DIR.The installer handles everything:
npm install,npm run build,better-sqlite3native rebuild, extension registration inruntime.json, and gateway restart via SIGUSR1.Open a Pi Agent session.
Verify: The plugin registers 8 hooks via api.on() (lifecycle) and api.registerHook() (commands). Type ctx stats to confirm tools are loaded.
Routing: Automatic. All tool interception, session tracking, and compaction recovery hooks activate automatically — no manual hook configuration or routing file needed.
Minimum version: OpenClaw >2026.1.29 — this includes the
api.on()lifecycle fix from PR #9761. On older versions, lifecycle hooks silently fail. The adapter falls back to DB snapshot reconstruction (less precise but preserves critical state).
Full documentation: docs/adapters/openclaw.md
Prerequisites: Node.js >= 22.5 (or Bun), Codex CLI installed.
Install:
Add the context-mode marketplace and install the plugin from Codex's plugin UI:
codex plugin marketplace add mksglu/context-modeEnable plugin-provided hooks while the Codex feature is still gated:
[features] plugin_hooks = true hooks = trueFeature flag note: Current Codex builds expose hooks under
[features].hooks(orcodex --enable hooks). Prefer[features].hooks;[features].codex_hooksremains accepted as a legacy alias in current Codex builds. Bundled plugin hooks additionally requireplugin_hooksuntil Codex enables plugin hooks by default.Custom storage location: if Codex cannot write the adapter default storage directory, set
CONTEXT_MODE_DIRto an absolute writable root in the environment that launches Codex. Sessions and stats use<root>/sessions; indexed content uses<root>/content.CONTEXT_MODE_DIR="$HOME/.codex-context-mode" codexRestart Codex CLI and verify MCP with
ctx stats.ctx statsproves the plugin MCP server is installed and reachable; it does not prove hooks are trusted or running.Review and trust the context-mode plugin hooks if Codex prompts for hook approval. Plugin hooks are only active after both feature flags are enabled and Codex has accepted the hook commands.
The Codex plugin manifest provides MCP via .codex-plugin/mcp.json, skills via
skills/, and bundled hooks via .codex-plugin/hooks.json. No manual
[mcp_servers.context-mode] block or $CODEX_HOME/hooks.json is needed when
plugin_hooks is enabled and the plugin hooks are trusted.
Node/PATH note: context-mode still needs
nodevisible to the Codex process. The plugin removes manual Codex config, but it does not vendor Node or inherit login-shell PATH fixes automatically.
Manual fallback for Codex builds without plugin_hooks:
Install context-mode globally:
npm install -g context-modeAdd to
~/.codex/config.toml:[features] hooks = true [mcp_servers.context-mode] command = "context-mode" [mcp_servers.context-mode.env] CONTEXT_MODE_PLATFORM = "codex"Create
$CODEX_HOME/hooks.json(or~/.codex/hooks.jsonwhenCODEX_HOMEis unset):{ "hooks": { "PreToolUse": [{ "matcher": "local_shell|shell|shell_command|exec_command|Bash|Shell|apply_patch|Edit|Write|grep_files|ctx_execute|ctx_execute_file|ctx_batch_execute|ctx_fetch_and_index|ctx_search|ctx_index|mcp__", "hooks": [{ "type": "command", "command": "context-mode hook codex pretooluse" }] }], "PostToolUse": [{ "hooks": [{ "type": "command", "command": "context-mode hook codex posttooluse" }] }], "SessionStart": [{ "hooks": [{ "type": "command", "command": "context-mode hook codex sessionstart" }] }], "PreCompact": [{ "hooks": [{ "type": "command", "command": "context-mode hook codex precompact" }] }], "UserPromptSubmit": [{ "hooks": [{ "type": "command", "command": "context-mode hook codex userpromptsubmit" }] }], "Stop": [{ "hooks": [{ "type": "command", "command": "context-mode hook codex stop" }] }] } }PreToolUseenforces deny/block routing today and is prepared for input rewrites once Codex supports them.PostToolUsecaptures session events.PreCompactbuilds the resume snapshot before compaction.SessionStartrestores state after compaction.UserPromptSubmitcaptures user decisions and corrections.Stoprecords turn-end state.Note: Codex PreToolUse routing currently supports deny rules only (blocks dangerous commands). It still needs upstream
updatedInputsupport before context-mode can rewrite tool input; track openai/codex#18491. Context injection (additionalContext) is not supported in Codex PreToolUse — it works via PostToolUse and SessionStart instead. This is handled automatically.PreCompactsupport is runtime-gated: it is present in Codex CLI 0.130.0, while the public Codex hooks docs may lag the shipped hook-event list. Older Codex builds that do not emitPreCompactwill not create pre-compaction snapshots.Copy routing instructions (recommended even with hooks for full routing awareness):
CM_ROOT="$(npm root -g)/context-mode" cp "$CM_ROOT/configs/codex/AGENTS.md" ./AGENTS.mdFor global use:
CM_ROOT="$(npm root -g)/context-mode"; cp "$CM_ROOT/configs/codex/AGENTS.md" ~/.codex/AGENTS.md. Global applies to all projects. If both exist, Codex CLI merges them.Restart Codex CLI.
Verify: Start a session and type ctx stats to verify MCP. To verify hook routing, confirm Codex lists/trusts the context-mode plugin hooks, then run a command that matches the routing rules.
Routing: MCP tools work after plugin install. Plugin hook routing is active only when hooks and plugin_hooks are enabled and Codex trusts the plugin hook commands. Manual hook routing is active when $CODEX_HOME/hooks.json or ~/.codex/hooks.json is configured. The AGENTS.md file provides routing instructions for model awareness.
Prerequisites: Node.js >= 22.5 (or Bun), Kimi Code CLI installed.
Install context-mode:
npm install -g context-modeAdd context-mode as an MCP server. Add to
~/.kimi-code/mcp.json:{ "mcpServers": { "context-mode": { "command": "context-mode", "args": [] } } }Add hooks to
~/.kimi-code/config.toml:[[hooks]] event = "PreToolUse" matcher = "Bash|Shell|Read|Edit|Write|WebFetch|Agent|ctx_execute|ctx_execute_file|ctx_batch_execute|ctx_fetch_and_index|ctx_search|ctx_index|mcp__" command = "context-mode hook kimi pretooluse" timeout = 30 [[hooks]] event = "PostToolUse" command = "context-mode hook kimi posttooluse" timeout = 30 [[hooks]] event = "SessionStart" command = "context-mode hook kimi sessionstart" timeout = 30 [[hooks]] event = "PreCompact" command = "context-mode hook kimi precompact" timeout = 30 [[hooks]] event = "UserPromptSubmit" command = "context-mode hook kimi userpromptsubmit" timeout = 30 [[hooks]] event = "Stop" command = "context-mode hook kimi stop" timeout = 30Restart Kimi Code CLI and verify MCP with
ctx stats.Note: Kimi Code uses the same JSON stdin/stdout wire protocol as Codex, but accepts
additionalContext,updatedInput, andpermissionDecision: "ask"in PreToolUse responses (Codex rejects these). The kimi hook normalizesContentPart[]prompt arrays to strings for downstream extractors.(Optional) Copy the routing instructions file for your project:
cp "$(npm root -g)/context-mode/configs/codex/AGENTS.md" ./AGENTS.mdOr for global use:
CM_ROOT="$(npm root -g)/context-mode"; cp "$CM_ROOT/configs/codex/AGENTS.md" ~/.kimi-code/AGENTS.md
Full documentation: docs/adapters/kimi-code.md
Prerequisites: Node.js >= 22.5 (or Bun), Qwen Code installed (npm install -g @qwen-code/qwen-code).
Install context-mode:
npm install -g context-modeAdd context-mode as an MCP server. Add to
~/.qwen/settings.json:{ "mcpServers": { "context-mode": { "command": "context-mode", "args": [] } } }Add hooks for routing enforcement and session tracking. Add to
~/.qwen/settings.json:{ "hooks": { "PreToolUse": [{ "matcher": "run_shell_command|read_file|read_many_files|grep_search|web_fetch|agent|mcp__plugin_context-mode_context-mode__ctx_execute|mcp__plugin_context-mode_context-mode__ctx_execute_file|mcp__plugin_context-mode_context-mode__ctx_batch_execute|mcp__(?!.*context-mode)", "hooks": [{ "type": "command", "command": "context-mode hook qwen-code pretooluse" }] }], "PostToolUse": [{ "matcher": "", "hooks": [{ "type": "command", "command": "context-mode hook qwen-code posttooluse" }] }], "SessionStart": [{ "matcher": "", "hooks": [{ "type": "command", "command": "context-mode hook qwen-code sessionstart" }] }], "PreCompact": [{ "matcher": "", "hooks": [{ "type": "command", "command": "context-mode hook qwen-code precompact" }] }], "UserPromptSubmit": [{ "matcher": "", "hooks": [{ "type": "command", "command": "context-mode hook qwen-code userpromptsubmit" }] }] } }Copy routing instructions (recommended for full routing awareness):
cp node_modules/context-mode/configs/qwen-code/QWEN.md ./QWEN.mdFor global use:
cp node_modules/context-mode/configs/qwen-code/QWEN.md ~/.qwen/QWEN.mdRestart Qwen Code.
Verify: Start a session and type ctx stats. Context-mode tools should appear and respond.
Note: Qwen Code uses the same hook wire protocol as Claude Code (JSON stdin/stdout, same event names). Auto-detected via MCP clientInfo (qwen-cli-mcp-client-*) or QWEN_PROJECT_DIR env var.
This is the Antigravity desktop IDE. For the
agycommand-line tool, see Antigravity CLI (agy) below — it installs as a full plugin with hooks.
Prerequisites: Node.js >= 22.5 (or Bun), the Antigravity IDE installed.
Install:
Install context-mode globally:
npm install -g context-modeAdd to
~/.gemini/antigravity/mcp_config.json:{ "mcpServers": { "context-mode": { "command": "context-mode" } } }Copy routing instructions (Antigravity has no hook support):
cp node_modules/context-mode/configs/antigravity/GEMINI.md ./GEMINI.mdRestart Antigravity.
Verify: In an Antigravity session, type ctx stats. Context-mode tools should appear and respond.
Routing: Manual. The GEMINI.md file is the only enforcement method (~60% compliance). There is no programmatic interception. Auto-detected via MCP protocol handshake (clientInfo.name) — no manual platform configuration needed.
Full configs: configs/antigravity/mcp_config.json | configs/antigravity/GEMINI.md
The
agycommand-line tool, not the Antigravity desktop IDE above.
Prerequisites: Node.js >= 22.5 (or Bun), Antigravity CLI (agy) ≥ 1.0.7 (agy update to upgrade). Verified on agy 1.0.10.
Install:
npm install -g context-mode # the plugin's MCP server + hooks run the global binary
agy plugin install https://github.com/mksglu/context-mode/tree/main/configs/antigravity-cli # registers MCP + rule + skill + hooksRestart agy.
MCP-only (no plugin, no hooks): if you only want the ctx_* tools, skip the plugin and add context-mode to agy's global MCP profile ~/.gemini/config/mcp_config.json (distinct from the Antigravity IDE's ~/.gemini/antigravity/ path), then restart agy:
{ "mcpServers": { "context-mode": { "command": "context-mode" } } }Verify: type ctx stats in an agy session, or run any prompt from Try It and check the savings. context-mode doctor confirms MCP + hook registration. Remove with agy plugin uninstall context-mode.
Routing: the routing rule and skill provide the instruction layer; bounded PreToolUse blocks high-flood tools and PostToolUse captures sessions. The bundle pins CONTEXT_MODE_PLATFORM=antigravity-cli so agy is detected even when Claude Code is co-installed (#774).
Prerequisites: Node.js >= 22.5 (or Bun), Kiro with MCP enabled (Settings > search "MCP").
Install:
Install context-mode globally:
npm install -g context-modeAdd to
.kiro/settings/mcp.jsonin your project (or~/.kiro/settings/mcp.jsonfor global):{ "mcpServers": { "context-mode": { "command": "context-mode" } } }Create
.kiro/hooks/context-mode.json:{ "name": "context-mode", "description": "Context-mode hooks for context window protection", "hooks": { "preToolUse": [ { "matcher": "execute_bash|fs_read|@context-mode/ctx_execute|@context-mode/ctx_execute_file|@context-mode/ctx_batch_execute|@(?!context-mode/)", "command": "context-mode hook kiro pretooluse" } ], "postToolUse": [ { "matcher": "*", "command": "context-mode hook kiro posttooluse" } ] } }Copy routing instructions. Kiro's
agentSpawn(SessionStart) is not yet implemented, so the model needs a routing file at session start:cp node_modules/context-mode/configs/kiro/KIRO.md ./KIRO.mdRestart Kiro.
Verify: Open the Kiro panel > MCP Servers tab and confirm "context-mode" shows a green status indicator. In chat, type ctx stats.
Routing: Hooks enforce routing programmatically via preToolUse/postToolUse. The KIRO.md file provides routing instructions since agentSpawn (SessionStart equivalent) is not yet wired. Tool names appear as @context-mode/ctx_batch_execute, @context-mode/ctx_search, etc. Auto-detected via MCP protocol handshake.
Full configs: configs/kiro/mcp.json | configs/kiro/agent.json | configs/kiro/KIRO.md
Prerequisites: Node.js >= 22.5 (or Bun), Zed installed.
Install:
Install context-mode globally:
npm install -g context-modeAdd to
~/.config/zed/settings.json(Windows:%APPDATA%\Zed\settings.json):{ "context_servers": { "context-mode": { "command": "context-mode", "args": [], "env": {} } } }Note: Zed uses
"context_servers"instead of"mcpServers".argsandenvare optional for context-mode, but are shown here to match Zed's custom MCP server shape.Copy routing instructions (Zed has no hook support):
cp node_modules/context-mode/configs/zed/AGENTS.md ./AGENTS.mdRestart Zed (or save
settings.json— Zed auto-restarts context servers on config change).
Verify: Open the Agent Panel (Cmd+Shift+A), go to settings, and check the indicator dot next to "context-mode" — green means active. Type ctx stats in the agent chat.
Routing: Manual. The AGENTS.md file is the only enforcement method (~60% compliance). There is no programmatic interception. Tool names appear as mcp:context-mode:ctx_batch_execute, mcp:context-mode:ctx_search, etc. Auto-detected via MCP protocol handshake.
Prerequisites: Node.js >= 22.5 (or Bun), Pi Coding Agent installed.
Install:
Install context-mode globally:
npm install -g context-modeInstall the package into Pi:
pi install npm:context-modeAlternative — add it manually to
~/.pi/agent/settings.json(or.pi/settings.jsonfor project-level):{ "packages": ["npm:context-mode"] }Add to
~/.pi/agent/mcp.json(or.pi/mcp.jsonfor project-level):{ "mcpServers": { "context-mode": { "command": "context-mode" } } }Restart Pi.
Verify: In a Pi session, type ctx stats. Context-mode tools should appear and respond.
Routing: Automatic. The extension registers all key lifecycle events (tool_call, tool_result, session_start, session_before_compact), providing full session continuity and routing enforcement.
Prerequisites: Node.js >= 22.5 (or Bun), Oh My Pi installed.
Install — plugin path (recommended):
Run the OMP plugin install:
omp plugin install context-modeRestart OMP.
Verify:
omp plugin list omp plugin doctorBoth should show
context-modeasenabled.The plugin self-registers its MCP server in
~/.omp/agent/mcp.jsonon first load (spawned asnode <plugin>/server.bundle.mjs, since the plugin-install package directory is not onPATH), so the 11ctx_*tools become reachable after the restart in step 2 — no manualmcp.jsonedit needed (#677). An existingcontext-modeentry is never overwritten; remove it if you want the plugin to re-register the bundled path.
Install — manual plugin path (if omp plugin install is unavailable):
OMP loads anything listed under ~/.omp/plugins/package.json dependencies whose own package.json carries an omp (or pi) field. New plugins default to enabled — the lock file at ~/.omp/plugins/omp-plugins.lock.json is only consulted when a plugin needs to be explicitly disabled (loader skips runtimeState && !runtimeState.enabled per extensibility/plugins/loader.ts:89-94). So the manual install is two commands:
cd ~/.omp/plugins
bun add context-mode # or: npm install context-modeThen restart OMP. No lock file edit, no version pin — version is read from the freshly-installed package each time the loader runs (see loader.ts:87 manifest.version = pluginPkg.version).
Install — MCP-only path (no plugin):
Install context-mode globally:
npm install -g context-modeAdd to
~/.omp/agent/mcp.json(user scope) or<project>/.omp/mcp.json(project scope):{ "mcpServers": { "context-mode": { "command": "context-mode" } } }Copy routing instructions:
cp node_modules/context-mode/configs/omp/SYSTEM.md ~/.omp/agent/SYSTEM.mdProject-scoped alternative:
cp ... .omp/SYSTEM.md. OMP also auto-discovers anyAGENTS.mdin the project tree.Restart OMP.
Verify (any path): In an OMP session, type ctx stats. Context-mode tools should appear and respond.
Routing: Plugin path — programmatic enforcement via four pi.on(...) handlers (tool_call returns { block: true, reason } for curl/wget/inline-fetch per upstream hooks/types.ts:566, tool_result captures session events, session_start initializes the per-session DB row, session_before_compact persists a resume snapshot). ~98% compliance, parity with Claude Code hooks. MCP-only path — rule-based via SYSTEM.md, ~60% compliance. Auto-detected via PI_CODING_AGENT_DIR env var or presence of ~/.omp/. Storage roots at ~/.omp/context-mode/ so OMP and Pi installs never share session DBs, content indices, or stats files.
Full configs: configs/omp/mcp.json | configs/omp/SYSTEM.md | plugin source: src/adapters/omp/plugin.ts
Context Mode uses better-sqlite3 on Node.js, which ships prebuilt native binaries for most platforms. On glibc >= 2.31 systems (Ubuntu 20.04+, Debian 11+, Fedora 34+, macOS, Windows), npm install works without any build tools.
Linux + Node.js >= 22.5: Context Mode automatically uses the built-in node:sqlite module instead of better-sqlite3. This eliminates the native addon entirely, avoiding sporadic SIGSEGV crashes caused by V8's madvise(MADV_DONTNEED) corrupting the addon's .got.plt section on Linux. No configuration needed — detection is automatic. Linux + Node < 22.5 is unsupported (#564) — npm install will fail with remediation instructions.
Bun users: No native compilation needed. Context Mode automatically detects Bun and uses the built-in bun:sqlite module via a compatibility adapter. better-sqlite3 and all its build dependencies are skipped entirely.
On older glibc systems (CentOS 7/8, RHEL 8, Debian 10), prebuilt binaries don't load and better-sqlite3 automatically falls back to compiling from source via prebuild-install || node-gyp rebuild --release. This requires a C++20 compiler (GCC 10+), Make, and Python with setuptools.
Windows / missing binding self-heal: if better_sqlite3.node ends up missing after install (e.g. prebuild-install not on cmd.exe PATH, no MSVC toolchain), the postinstall script and the runtime hook automatically re-fetch the prebuild and repair the binding — no manual npm rebuild needed (#408).
CentOS 8 / RHEL 8 (glibc 2.28):
dnf install -y gcc-toolset-10-gcc gcc-toolset-10-gcc-c++ make python3 python3-setuptools
scl enable gcc-toolset-10 'npm install -g context-mode'CentOS 7 / RHEL 7 (glibc 2.17):
yum install -y centos-release-scl
yum install -y devtoolset-10-gcc devtoolset-10-gcc-c++ make python3
pip3 install setuptools
scl enable devtoolset-10 'npm install -g context-mode'Alpine Linux:
Alpine prebuilt binaries (musl) are available in better-sqlite3 v12.8.0+. With the ^12.6.2 dependency range, npm install resolves to the latest 12.x and works without build tools on Alpine. If you pin an older version:
apk add build-base python3 py3-setuptools
npm install -g context-modeTools
Tool | What it does | Context saved |
| Run multiple commands + search multiple queries in ONE call. Opt-in | 986 KB → 62 KB |
| Run code in 12 languages. Only stdout enters context. | 56 KB → 299 B |
| Process files in sandbox. Raw content never leaves. | 45 KB → 155 B |
| Chunk markdown into FTS5 with BM25 ranking. | 60 KB → 40 B |
| Query indexed content with multiple queries in one call. | On-demand retrieval |
| Fetch URL, chunk and index. Cache reuses content within TTL (default 24h, override per-call with | 60 KB → 40 B |
| Show context savings, call counts, and session statistics. | — |
| Diagnose installation: runtimes, hooks, FTS5, versions. | — |
| Upgrade to latest version from GitHub, rebuild, reconfigure hooks. | — |
| Permanently deletes all indexed content from the knowledge base. | — |
How the Sandbox Works
Each ctx_execute call spawns an isolated subprocess with its own process boundary. Scripts can't access each other's memory or state. The subprocess runs your code, captures stdout, and only that stdout enters the conversation context. The raw data — log files, API responses, snapshots — never leaves the sandbox.
Twelve language runtimes are available: JavaScript, TypeScript, Python, Shell, Ruby, Go, Rust, PHP, Perl, R, Elixir, and C#. Bun is auto-detected for 3-5x faster JS/TS execution.
Authenticated CLIs work through credential passthrough — gh, aws, gcloud, kubectl, docker inherit environment variables and config paths without exposing them to the conversation.
When output exceeds 5 KB and an intent is provided, Context Mode switches to intent-driven filtering: it indexes the full output into the knowledge base, searches for sections matching your intent, and returns only the relevant matches with a vocabulary of searchable terms for follow-up queries.
How the Knowledge Base Works
The ctx_index tool chunks markdown content by headings while keeping code blocks intact, then stores them in a SQLite FTS5 (Full-Text Search 5) virtual table. The SQLite backend is selected automatically at runtime: bun:sqlite on Bun, node:sqlite on Node.js >= 22.5, and better-sqlite3 everywhere else. Search uses BM25 ranking — a probabilistic relevance algorithm that scores documents based on term frequency, inverse document frequency, and document length normalization. Porter stemming is applied at index time so "running", "runs", and "ran" match the same stem. Titles and headings are weighted 5x in BM25 scoring for precise navigational queries.
When you call ctx_search, it returns relevant content snippets focused around matching query terms — not full documents, not approximations, the actual indexed content with smart extraction around what you're looking for. ctx_fetch_and_index extends this to URLs: fetch, convert HTML to markdown, chunk, index. The raw page never enters context. Use the contentType parameter to filter results by type (e.g. code or prose).
Ranking: Reciprocal Rank Fusion
Search runs two parallel strategies and merges them with Reciprocal Rank Fusion (RRF):
Porter stemming — FTS5 MATCH with porter tokenizer. "caching" matches "cached", "caches", "cach".
Trigram substring — FTS5 trigram tokenizer matches partial strings. "useEff" finds "useEffect", "authenticat" finds "authentication".
RRF merges both ranked lists into a single result set, so a document that ranks well in both strategies surfaces higher than one that ranks well in only one. This replaces the old cascading fallback approach where trigram results were only used if porter returned nothing.
Proximity Reranking
Multi-term queries get an additional reranking pass. Results where query terms appear close together are boosted — "session continuity" ranks passages with adjacent terms higher than pages where "session" and "continuity" appear paragraphs apart.
Fuzzy Correction
Levenshtein distance corrects typos before re-searching. "kuberntes" becomes "kubernetes", "autentication" becomes "authentication".
Smart Snippets
Search results use intelligent extraction instead of truncation. Instead of returning the first N characters (which might miss the important part), Context Mode finds where your query terms appear in the content and returns windows around those matches.
TTL Cache
Indexed content persists in a per-project SQLite database at ~/.context-mode/content/. When ctx_fetch_and_index is called for a URL that was already indexed within its TTL window, the fetch is skipped entirely and the model searches the existing index directly.
Default TTL: 24 hours. Override per-call with
ttl: <milliseconds>(PR #666). Longer for stable specs, shorter for changelogs you want re-checked often.Cache hit (within TTL): Returns a cache hint (~0.3KB) instead of re-fetching (48KB+). Model proceeds to
ctx_search.Cache miss (TTL expired): Re-fetches silently. No user action needed.
ttl: 0orforce: true: Bypasses cache and re-fetches regardless of freshness.14-day cleanup: Content databases and sources older than 14 days are removed on startup.
This means --continue sessions preserve indexed docs across restarts. No re-fetching, no wasted context tokens.
ctx_stats reports cache performance separately: hits, data avoided, network requests saved, and total context savings including cache.
Progressive Throttling
Calls 1-3: Normal results (2 per query)
Calls 4-8: Reduced results (1 per query) + warning
Calls 9+: Blocked — redirects to
ctx_batch_execute
Session Continuity
When the context window fills up, the agent compacts the conversation — dropping older messages to make room. Without session tracking, the model forgets which files it was editing, what tasks are in progress, what errors were resolved, and what you last asked for.
Context Mode captures every meaningful event during your session and persists them in a per-project SQLite database. When the conversation compacts (or you resume with --continue, --resume, or /resume), your working state is rebuilt automatically — the model continues from your last prompt without asking you to repeat anything.
Resuming a non-latest session via
/resume <picker>works the same way: the SessionStart hook detects the empty live-event table for the freshly issued session id and falls back to the most recent unconsumed snapshot for the project (session_resumetable). The picker selects the conversation; context-mode rehydrates the prior working state.
Session continuity requires 5 hooks working together:
Hook | Role | Claude Code | Gemini CLI | VS Code Copilot | JetBrains Copilot | GitHub Copilot CLI | Cursor | OpenCode | KiloCode | OpenClaw | Codex CLI | Antigravity | Antigravity CLI ( | Kiro | Zed | Pi | OMP |
PreToolUse | Enforces sandbox routing before tool execution | Yes | -- | -- | -- | Yes | Yes | -- | -- | -- | Yes | -- | Bounded | Yes | -- | ✓ (via tool_call event) | ✓ (via tool_call event) |
PostToolUse | Captures events after each tool call | Yes | Yes | Yes | Yes | Yes | Yes | Plugin | Plugin | Plugin | Yes | -- | Yes (capture-only) | Yes | -- | ✓ (via tool_result event) | ✓ (via tool_result event) |
UserPromptSubmit | Captures user decisions and corrections | Yes | -- | -- | -- | Yes | -- | Plugin (via chat.message) | Plugin (via chat.message) | -- | Yes | -- | -- | -- | -- | -- | -- |
Stop | Captures assistant turn-end state | Yes | -- | -- | -- | Yes | Yes | -- | -- | -- | Yes | -- | Best-effort | -- | -- | -- | -- |
PreCompact | Builds snapshot before compaction | Yes | Yes | Yes | Yes | Yes | -- | Plugin | Plugin | Plugin | Yes | -- | -- | -- | -- | ✓ (via session_before_compact) | ✓ (via session_before_compact) |
SessionStart | Restores state after compaction or resume | Yes | Yes | Yes | Yes | Yes | -- | ✓ (via experimental.chat.system.transform) | ✓ (via experimental.chat.system.transform) | Plugin | Yes | -- | -- | -- | -- | ✓ (via session_start event) | ✓ (via session_start event) |
Session completeness | Full | High | High | High | High | Partial | Full | Full | High | Partial | -- | Partial | Partial | -- | High | High |
Note: Full session continuity (capture + snapshot + restore) works on Claude Code, Gemini CLI, VS Code Copilot, JetBrains Copilot, OpenCode, and KiloCode. GitHub Copilot CLI uses its own camelCase hook config keys (
preToolUse,postToolUse,preCompact,sessionStart,userPromptSubmitted,agentStop) and top-level hook responses; it captures prompt, tool, compaction, session-start, and stop events when the plugin hooks are installed. OpenCode and KiloCode useexperimental.chat.system.transformas a SessionStart surrogate to inject the routing block and restore prior sessions, pluschat.messagefor user-prompt capture; full SessionStart hook support is not yet available (#14808, #5409), but prior-session continuity and user-decision capture work fully. Cursor captures tool events viapreToolUse/postToolUse, butsessionStartis currently rejected by Cursor's validator (forum report), so session restore after compaction is not available yet. OpenClaw uses native gateway plugin hooks (api.on()) for full session continuity. Pi Coding Agent provides high session continuity via extension hooks (tool_call,tool_result,session_start,session_before_compact). Codex CLI provides partial hook-based session tracking through PreToolUse, PostToolUse, PreCompact, SessionStart, UserPromptSubmit, and Stop; MCP tools work. Antigravity IDE and Zed have no hook support in the current release, so session tracking is not available there. Antigravity CLI (agy) is separate from the IDE and supports boundedPreToolUse, capture-onlyPostToolUse, and best-effortStopthrough its plugin hooks. Kiro captures tool events via nativepreToolUse/postToolUsehooks, but its SessionStart equivalent (agentSpawn) is not yet wired, so session restore after compaction is unavailable. OMP (Oh My Pi) ships full plugin-based hook support —omp plugin install context-moderegisterstool_call,tool_result,session_start, andsession_before_compacthandlers and storage roots cleanly under~/.omp/context-mode/so OMP and Pi installs never share state.
Every tool call passes through hooks that extract structured events:
Category | Events | Priority | Captured By |
Files | read, edit, write, glob, grep | Critical (P1) | PostToolUse |
Tasks | create, update, complete | Critical (P1) | PostToolUse |
Plans | enter, exit, approved, rejected, file write | Critical (P1) | PostToolUse |
Rules | CLAUDE.md / GEMINI.md / AGENTS.md paths + content | Critical (P1) | SessionStart |
User Prompts | Every user message (for last-prompt restore) | Critical (P1) | UserPromptSubmit |
Decisions | User corrections, preferences ("use X instead", "don't do Y") | High (P2) | UserPromptSubmit |
Git | checkout, commit, merge, rebase, stash, push, pull, diff, status | High (P2) | PostToolUse |
Errors | Tool failures, non-zero exit codes | High (P2) | PostToolUse |
Error Resolution | Error → fix pairs detected across sequential tool calls | High (P2) | PostToolUse |
Constraints | Discovered limitations ("not supported", "permission denied") | High (P2) | PostToolUse |
Blockers | "blocked on", "waiting for", "depends on" — tracked until resolved | High (P2) | UserPromptSubmit |
Rejected Approaches | Tool calls denied by user (PreToolUse → PostToolUse marker) | High (P2) | PreToolUse |
Environment | cwd changes, venv, nvm, conda, worktree, package installs | High (P2) | PostToolUse |
Agent Findings | Completed subagent results (first 500 chars) | High (P2) | PostToolUse |
Iteration Loops | Same tool called 3+ times with similar input (retry detection) | High (P2) | PostToolUse |
Latency | Tool calls exceeding 5s (tool name + duration in ms) | Normal (P3) | PreToolUse |
MCP Tools | All | Normal (P3) | PostToolUse |
Subagents | Agent tool launches and completions | Normal (P3) | PostToolUse |
Skills | Slash command invocations | Normal (P3) | PostToolUse |
External Refs | URLs, GitHub issue references (#123), deduped | Normal (P3) | PostToolUse |
Role | Persona / behavioral directives ("act as senior engineer") | Normal (P3) | UserPromptSubmit |
Intent | Session mode classification (investigate, implement, review) | Low (P4) | UserPromptSubmit |
Data | Large user-pasted data references (>1 KB) | Low (P4) | UserPromptSubmit |
PreCompact fires
→ Read all session events from SQLite
→ Build priority-tiered XML snapshot (≤2 KB)
→ Store snapshot in session_resume table
SessionStart fires (source: "compact")
→ Retrieve stored snapshot
→ Write structured events file → auto-indexed into FTS5
→ Build Session Guide with 15 categories
→ Inject <session_knowledge> directive into context
→ Model continues from last user prompt with full working stateThe snapshot is built in priority tiers — if the 2 KB budget is tight, lower-priority events (intent, MCP tool counts) are dropped first while critical state (active files, tasks, rules, decisions) is always preserved.
After compaction, the model receives a Session Guide — a structured narrative with actionable sections:
Last Request — user's last prompt, so the model continues without asking "what were we doing?"
Tasks — checkbox format with completion status (
[x]completed,[ ]pending)Plans — plan mode entries, exits, approvals, and rejections
Key Decisions — user corrections and preferences ("use X instead", "don't do Y")
Files Modified — all files touched during the session
Unresolved Errors — errors that haven't been fixed, plus error→fix resolution pairs
Constraints — discovered limitations and boundaries
Blockers — open and resolved blockers ("blocked on X", "waiting for Y")
Git — operations performed (checkout, commit, push, status)
Project Rules — CLAUDE.md / GEMINI.md / AGENTS.md paths
MCP Tools Used — tool names with call counts
Subagent Tasks — delegated work summaries + agent findings
Skills Used — slash commands invoked
Rejected Approaches — tool calls the user denied
External References — URLs and GitHub issue references
Environment — working directory, env variables, worktrees
Data References — large data pasted during the session
Session Intent — mode classification (implement, investigate, review, discuss)
User Role — behavioral directives set during the session
Detailed event data is also indexed into FTS5 for on-demand retrieval via ctx_search().
Claude Code — Full session support. All 5 hook types fire, capturing tool events, user decisions, building compaction snapshots, and restoring state after compaction, --continue, --resume, or /resume.
Gemini CLI — High coverage. PostToolUse (AfterTool), PreCompact (PreCompress), and SessionStart all fire. Missing UserPromptSubmit, so user decisions and corrections aren't captured — but file edits, git ops, errors, and tasks are fully tracked.
VS Code Copilot — High coverage. Same as Gemini CLI — PostToolUse, PreCompact, and SessionStart all fire. User decisions aren't captured but all tool-level events are.
JetBrains Copilot — High coverage. Same capabilities as VS Code Copilot — PostToolUse, PreCompact, and SessionStart all fire. Uses the same hook wire protocol and response format. User decisions aren't captured but all tool-level events are.
GitHub Copilot CLI — High coverage. Native plugin hooks use camelCase config keys (preToolUse, postToolUse, preCompact, sessionStart, userPromptSubmitted, agentStop) and top-level hook response fields. The plugin captures user prompts, tool events, compaction snapshots, session start restore, and stop events.
Cursor — Partial coverage. Native preToolUse and postToolUse hooks capture tool events. sessionStart is documented by Cursor but currently rejected by their validator, so session restore is not available. Routing instructions are delivered via MCP server startup instead.
OpenCode — Full session support. The TypeScript plugin captures PostToolUse events via tool.execute.after, user prompts and decisions via chat.message, builds compaction snapshots via experimental.session.compacting, and restores prior sessions via experimental.chat.system.transform (SessionStart surrogate). Routing block is injected on first chat.system.transform per session. AGENTS.md/CLAUDE.md/CONTEXT.md rules are captured automatically on first hook fire.
KiloCode — Full session support. Shares the same plugin architecture as OpenCode via the OpenCodeAdapter. The TypeScript plugin captures PostToolUse events via tool.execute.after, user prompts and decisions via chat.message, builds compaction snapshots via experimental.session.compacting, and restores prior sessions via experimental.chat.system.transform (SessionStart surrogate).
OpenClaw / Pi Agent — High coverage. All tool lifecycle hooks (after_tool_call, before_compaction, session_start) fire via the native gateway plugin. User decisions aren't captured but file edits, git ops, errors, and tasks are fully tracked. Falls back to DB snapshot reconstruction if compaction hooks fail on older gateway versions. See docs/adapters/openclaw.md.
Codex CLI — MCP active, hooks require [features].hooks = true. Hook scripts (PreToolUse, PostToolUse, PreCompact, SessionStart, UserPromptSubmit, Stop) are implemented and tested; PreCompact remains runtime-gated on Codex builds that emit the event. PreToolUse deny routing works; input rewriting still depends on upstream updatedInput support (openai/codex#18491).
Antigravity — No session support. No hooks, no event capture. Requires manually copying GEMINI.md to your project root. Auto-detected via MCP protocol handshake (clientInfo.name).
Antigravity CLI (agy) — Partial coverage. The standalone CLI is separate from the IDE and supports bounded native PreToolUse enforcement for mapped high-flood tools, capture-only PostToolUse, and best-effort Stop through the shipped plugin hooks. It does not currently provide PreCompact/SessionStart/UserPromptSubmit coverage.
Zed — No session support. No hooks, no event capture. Requires manually copying AGENTS.md to your project root. Auto-detected via MCP protocol handshake (clientInfo.name).
Kiro — Partial coverage. Native preToolUse and postToolUse hooks capture tool events and enforce sandbox routing. agentSpawn (the Kiro equivalent of SessionStart) is not yet implemented, so session restore after compaction is not available. Requires manually copying KIRO.md to your project root. Auto-detected via MCP protocol handshake (clientInfo.name).
Pi Coding Agent — High coverage. The extension registers all key lifecycle events: tool_call (PreToolUse), tool_result (PostToolUse), session_start (SessionStart), and session_before_compact (PreCompact). File edits, git ops, errors, and tasks are fully tracked. Session restore after compaction works via the extension's event hooks.
Tool call output can be collapsed/expanded with the default Pi's default keybinding (Ctrl+O)
OMP (Oh My Pi) — High coverage. The plugin (installed via omp plugin install context-mode) registers all key lifecycle events: tool_call (PreToolUse), tool_result (PostToolUse), session_start (SessionStart), and session_before_compact (PreCompact). Storage roots cleanly under ~/.omp/context-mode/ so OMP and Pi installs never share state (issue #473). Auto-detected via PI_CODING_AGENT_DIR env var or presence of ~/.omp/.
Platform Compatibility
Feature | Claude Code | Qwen Code | Gemini CLI | VS Code Copilot | JetBrains Copilot | GitHub Copilot CLI | Cursor | OpenCode | KiloCode | OpenClaw | Codex CLI | Kimi Code | Antigravity | Antigravity CLI ( | Kiro | Zed | Pi | OMP |
MCP Server / Native Tools | Yes | Yes | Yes | Yes | Yes | Yes | Yes | Native plugin | Native plugin | Yes | Yes | Yes | Yes | Yes | Yes | Yes | Yes | Yes |
PreToolUse Hook | Yes | Yes | Yes | Yes | Yes | Yes | Yes | Plugin | Plugin | Plugin | Yes | Yes | -- | Bounded | Yes | -- | Yes (extension) | Plugin |
PostToolUse Hook | Yes | Yes | Yes | Yes | Yes | Yes | Yes | Plugin | Plugin | Plugin | Yes | Yes | -- | Yes (capture-only) | Yes | -- | Yes (extension) | Plugin |
SessionStart Hook | Yes | Yes | Yes | Yes | Yes | Yes | -- | ✓ (via experimental.chat.system.transform) | ✓ (via experimental.chat.system.transform) | Plugin | Yes | Yes | -- | -- | -- | -- | Yes (extension) | Plugin |
PreCompact Hook | Yes | Yes | Yes | Yes | Yes | Yes | -- | Plugin | Plugin | Plugin | Yes | Yes | -- | -- | -- | -- | Yes (extension) | Plugin |
Can Modify Args | Yes | Yes | Yes | Yes | Yes | Yes | Yes | Plugin | Plugin | Plugin | -- | Yes | -- | -- | -- | -- | Yes (extension) | -- |
Can Block Tools | Yes | Yes | Yes | Yes | Yes | Yes | Yes | Plugin | Plugin | Plugin | Yes | Yes | -- | Bounded | Yes | -- | Yes (extension) | Plugin |
Utility Commands (ctx) | Yes | Yes | Yes | Yes | Yes | Yes | Yes | Yes | Yes | Yes | Yes | Yes | Yes | Yes | Yes | Yes | Yes (/ctx-stats, /ctx-doctor) | Yes |
Slash Commands | Yes | -- | -- | -- | -- | -- | -- | -- | -- | -- | -- | -- | -- | -- | -- | -- | -- | -- |
Plugin Marketplace | Yes | -- | -- | -- | -- | -- | -- | -- | -- | -- | -- | -- | -- | -- | -- | -- | -- | -- |
OpenCode uses a TypeScript plugin paradigm — hooks run as in-process functions via
tool.execute.before,tool.execute.after,experimental.session.compacting,experimental.chat.system.transform, andchat.message, providing full routing enforcement, session continuity, and user-prompt capture. Theexperimental.chat.system.transformhook acts as a SessionStart surrogate to inject the routing block and restore prior sessions. Thechat.messagehook captures user prompts and decisions (UserPromptSubmit equivalent).KiloCode shares the same TypeScript plugin architecture as OpenCode via the OpenCodeAdapter, with platform-specific configuration paths (
kilo.jsoninstead ofopencode.json,~/.config/kilo/instead of~/.config/opencode/). Hook capabilities match OpenCode, including SessionStart surrogate viaexperimental.chat.system.transformand user-prompt capture viachat.message.OpenClaw runs context-mode as a native gateway plugin targeting Pi Agent sessions. Hooks register via
api.on()(tool/lifecycle) andapi.registerHook()(commands). All tool interception and compaction hooks are supported. Seedocs/adapters/openclaw.md.Codex CLI hooks require
[features].hooks = true. MCP tools work, and hook scripts activate through$CODEX_HOME/hooks.jsonor~/.codex/hooks.json. PreToolUse supportspermissionDecision: "deny"only; input modification still needs upstreamupdatedInputsupport (openai/codex#18491).additionalContextis not supported in PreToolUse (context injection works via PostToolUse and SessionStart instead; the codex formatter handles this automatically). PreCompact stores resume snapshots before compaction on Codex builds that emit the event, SessionStart restores them, and UserPromptSubmit/Stop capture prompt and turn-end continuity events. See the Codex install section for setup. Antigravity and Zed do not support hooks. They rely solely on manually-copied routing instruction files (AGENTS.md/GEMINI.md) for enforcement (~60% compliance). See each platform's install section for copy instructions. Antigravity and Zed are auto-detected via MCP protocol handshake — no manual platform configuration needed.Antigravity CLI (
agy) supports boundedPreToolUseblocking for mapped Bash/Read/Grep/WebFetch surfaces, plusPostToolUsecapture and best-effortStopcapture through its pluginhooks.json. The routing rule and routing skill remain the broader instruction layer;PreInvocation/PostInvocationare not wired until their payload/response semantics are verified.Kiro supports native
preToolUseandpostToolUsehooks for routing enforcement and tool event capture.agentSpawn(SessionStart equivalent) andstopare not yet wired. Requires manually copyingKIRO.mdto your project root. Kiro is auto-detected via MCP protocol handshake (clientInfo.name).Pi Coding Agent runs context-mode as an extension with full hook support. The extension registers
tool_call,tool_result,session_start, andsession_before_compactevents, providing high session continuity coverage. The MCP server provides all 11 MCP tools.OMP (Oh My Pi) runs context-mode as a plugin via
omp plugin install context-mode. The plugin registerstool_call,tool_result,session_start, andsession_before_compactevents for hard-block routing and full session continuity. Storage isolated under~/.omp/context-mode/so OMP and Pi never share state. Auto-detected viaPI_CODING_AGENT_DIR(default agent dir~/.omp/agent) or~/.omp/directory. See issue #473 for the storage-isolation history.
Routing Enforcement
Hooks intercept tool calls programmatically — they can block dangerous commands and redirect them to the sandbox before execution. Instruction files guide the model via prompt instructions but cannot block anything. Always enable hooks where supported.
Note: Routing instruction files were previously auto-written to project directories on first session start. This was disabled to prevent git tree pollution (#158, #164). Hook-capable platforms (Claude Code, Gemini CLI, VS Code Copilot, JetBrains Copilot, GitHub Copilot CLI, Cursor, OpenCode, OpenClaw, Codex CLI, Antigravity CLI for bounded tool hooks, Kiro for tool hooks, OMP via plugin) inject or enforce routing without writing files. Platforms without hook support — Zed and Antigravity IDE — require a one-time manual copy of the routing file; see each platform's install section.
Platform | Hooks | Instruction File | With Hooks | Without Hooks |
Claude Code | Yes (auto) | ~98% saved | ~60% saved | |
Gemini CLI | Yes | ~98% saved | ~60% saved | |
VS Code Copilot | Yes | ~98% saved | ~60% saved | |
JetBrains Copilot | Yes | ~98% saved | ~60% saved | |
GitHub Copilot CLI | Yes | ~98% saved | ~60% saved | |
Cursor | Yes | ~98% saved | ~60% saved | |
OpenCode | Plugin | ~98% saved | ~60% saved | |
OpenClaw | Plugin | ~98% saved | ~60% saved | |
Codex CLI | Yes | ~98% saved | ~60% saved | |
Antigravity | -- | -- | ~60% saved | |
Antigravity CLI ( | Bounded | bounded Bash/Read/Grep/WebFetch enforcement | ~60% saved | |
Kiro | Yes | ~98% saved | ~60% saved | |
Zed | -- | -- | ~60% saved | |
Pi | ✓ | ~98% saved | ~60% saved | |
OMP | Plugin | ~98% saved | ~60% saved |
Without hooks, one unrouted curl or Playwright snapshot can dump 56 KB into context — wiping out an entire session's worth of savings.
See docs/platform-support.md for the full capability comparison.
Utility Commands
Inside any AI session — just type the command. The LLM calls the MCP tool automatically:
ctx stats → context savings, call counts, session report
ctx doctor → diagnose runtimes, hooks, FTS5, versions
ctx index → index a local file or directory for later search
ctx search → search previously indexed content
ctx upgrade → update from GitHub, rebuild, reconfigure hooks
ctx purge → permanently delete all indexed content from the knowledge base
ctx insight → opens the hosted Insight dashboard in your browserFrom your terminal — run directly without an AI session:
context-mode doctor
context-mode index . --source project:my-app
context-mode search "authentication middleware" --source project:my-app
context-mode upgrade
context-mode insight # opens the hosted Insight dashboard in browser
bash scripts/ctx-debug.sh # full diagnostic report for bug reportsThe debug script collects OS info, runtime versions, better-sqlite3 status, adapter detection, config files (redacted), hook validation, FTS5/SQLite test, executor test, process check, session databases, and environment variables into a single pasteable markdown report.
Works on all platforms. On Claude Code, slash commands (/ctx-stats, /ctx-doctor, /ctx-index, /ctx-search, /ctx-upgrade, /ctx-purge, /ctx-insight) are also available.
Benchmarks
Scenario | Raw | Context | Saved |
Playwright snapshot | 56.2 KB | 299 B | 99% |
GitHub Issues (20) | 58.9 KB | 1.1 KB | 98% |
Access log (500 requests) | 45.1 KB | 155 B | 100% |
Context7 React docs | 5.9 KB | 261 B | 96% |
Analytics CSV (500 rows) | 85.5 KB | 222 B | 100% |
Git log (153 commits) | 11.6 KB | 107 B | 99% |
Test output (30 suites) | 6.0 KB | 337 B | 95% |
Repo research (subagent) | 986 KB | 62 KB | 94% |
Over a full session: 315 KB of raw output becomes 5.4 KB. Session time extends from ~30 minutes to ~3 hours.
Full benchmark data with 21 scenarios →
Try It
These prompts work out of the box. Run /context-mode:ctx-stats after each to see the savings.
Deep repo research — 5 calls, 62 KB context (raw: 986 KB, 94% saved)
Research https://github.com/modelcontextprotocol/servers — architecture, tech stack,
top contributors, open issues, and recent activity. Then run /context-mode:ctx-stats.Git history analysis — 1 call, 5.6 KB context
Clone https://github.com/facebook/react and analyze the last 500 commits:
top contributors, commit frequency by month, and most changed files.
Then run /context-mode:ctx-stats.Web scraping — 1 call, 3.2 KB context
Fetch the Hacker News front page, extract all posts with titles, scores,
and domains. Group by domain. Then run /context-mode:ctx-stats.Large JSON API — 7.5 MB raw → 0.9 KB context (99% saved)
Create a local server that returns a 7.5 MB JSON with 20,000 records and a secret
hidden at index 13000. Fetch the endpoint, find the hidden record, and show me
exactly what's in it. Then run /context-mode:ctx-stats.Documentation search — 2 calls, 1.8 KB context
Fetch the React useEffect docs, index them, and find the cleanup pattern
with code examples. Then run /context-mode:ctx-stats.Session continuity — compaction recovery with full state
Start a multi-step task: "Create a REST API with Express — add routes, tests,
and error handling." After 20+ tool calls, type: ctx stats to see the session
event count. When context compacts, the model continues from your last prompt
with tasks, files, and decisions intact — no re-prompting needed.Privacy & Architecture
Context Mode is not a CLI output filter or a cloud analytics dashboard. It operates at the MCP protocol layer — raw data stays in a sandboxed subprocess and never enters your context window. Web pages, API responses, file analysis, Playwright snapshots, log files — everything is processed in complete isolation.
Nothing leaves your machine. No telemetry, no cloud sync, no usage tracking, no account required. Your code, your prompts, your session data — all local. The SQLite databases live in your home directory and die when you're done.
This is a deliberate architectural choice, not a missing feature. Context optimization should happen at the source, not in a dashboard behind a per-seat subscription. Privacy-first is our philosophy — and every design decision follows from it. License →
Security
Context Mode enforces the same permission rules you already use — but extends them to the MCP sandbox. If you block sudo, it's also blocked inside ctx_execute, ctx_execute_file, and ctx_batch_execute.
Zero setup required. If you haven't configured any permissions, nothing changes. This only activates when you add rules.
{
"permissions": {
"deny": [
"Bash(sudo *)",
"Bash(rm -rf /*)",
"Read(.env)",
"Read(**/.env*)"
],
"allow": [
"Bash(git:*)",
"Bash(npm:*)"
]
}
}Add this to your project's .claude/settings.json (or ~/.claude/settings.json for global rules). All platforms read security policies from Claude Code's settings format — even on Gemini CLI, VS Code Copilot, and OpenCode. Codex CLI security enforcement requires the Codex hooks in $CODEX_HOME/hooks.json or ~/.codex/hooks.json to be configured.
The pattern is Tool(what to match) where * means "anything".
Commands chained with &&, ;, or | are split — each part is checked separately. echo hello && sudo rm -rf /tmp is blocked because the sudo part matches the deny rule.
deny always wins over allow. More specific (project-level) rules override global ones.
Project-boundary containment
ctx_execute_file is confined to the project root. A path that resolves outside the workspace — an absolute path like /home/user/secrets, a ../../ traversal, or a project-local symlink whose target escapes the project — is refused with a File access blocked error. This closes the #852 escape vector where an agent, denied an out-of-project read by the host sandbox, retried through the MCP sandbox (the host's MCP approval prompt cannot inspect the tool's input params, so the escape was invisible to the approver).
The guard is on by default and requires no configuration. To intentionally process a file outside the project (e.g. a shared log under /var/log), opt that path back in with the same permissions.allow rule you already use for the host Read tool — there is no context-mode-specific env flag:
{
"permissions": {
"allow": ["Read(/var/log/**)"]
}
}context-mode honors that allow rule (read from your .claude/settings.json / ~/.claude/settings.json) exactly as Claude Code does, so an out-of-project grant lives in one place and stays meaningful.
Reviewing the prompt: the ctx_execute / ctx_execute_file approval titles now read as code execution ("Run code in a sandbox…", "Run code over a file…") so an unfamiliar reviewer can recognise the action class even though the MCP prompt renders only the tool title and raw arguments. ctx_execute and ctx_batch_execute run arbitrary code and still inherit the process's filesystem access, so the boundary guard is a defense-in-depth layer for the file-read tool, not a full OS sandbox — treat approving any execution tool as approving arbitrary code, and keep host-level sandboxing enabled.
Network fetch hardening
ctx_fetch_and_index blocks dangerous URL targets by default:
Schemes: only
http:andhttps:allowed (nofile://,gopher://,javascript:,data:).Cloud metadata + link-local:
169.254.0.0/16(incl. AWS/GCP/Azure IMDS endpoint169.254.169.254) hard-blocked even if a hostname resolves to it (DNS-rebinding defense).Multicast / reserved:
224.0.0.0/4,0.0.0.0/8, IPv6ff00::/8,fe80::/10blocked.Loopback + RFC1918 (
localhost,127.x,10.x,172.16-31.x,192.168.x, IPv6::1,fc00::/7) allowed by default so local dev servers + internal-network fetches keep working.
For hosted/CI environments where you want to block private targets too, set:
export CTX_FETCH_STRICT=1That blocks loopback + RFC1918 + ULA in addition to the always-blocked ranges. Useful when context-mode runs as a shared service, not on a developer's own machine.
tool_input for any mcp__* tool call is also redacted before persistence — the regex matcher in hooks/posttooluse.mjs masks authorization, auth_token, access_token, refresh_token, bearer, token, secret, password, passwd, pwd, api_key / apikey / x_api_key, cookie / set-cookie, signature, private_key, and client_secret (case-insensitive, hyphen/underscore-insensitive) to [REDACTED] so credentials in MCP arguments don't end up in the session DB.
Storage environment variables
Variable | Default | Purpose |
| Adapter default, for example | Since v1.0.147. Absolute writable root for context-mode storage. Sessions and stats use |
Routing-guidance environment variables
Variable | Default | Purpose |
|
| Cadence (in tool calls) at which the PreToolUse hook re-injects the "wrap large external-MCP payloads in |
Contributing
See CONTRIBUTING.md for the development workflow and TDD guidelines.
git clone https://github.com/mksglu/context-mode.git
cd context-mode && npm install && npm testLicense
Licensed under Elastic License 2.0 (source-available). You can use it, fork it, modify it, and distribute it. Two things you can't do: offer it as a hosted/managed service, or remove the licensing notices. We chose ELv2 over MIT because MIT permits repackaging the code as a competing closed-source SaaS — ELv2 prevents that while keeping the source available to everyone.
Available Tools
11 toolsctx_batch_executeBatch Execute & SearchADestructive
Run multiple commands in ONE call. Every command's output is auto-indexed into the knowledge base; if you also pass queries, the matching sections come back in the same round trip so a follow-up search call is not needed.
Concurrency parallelizes the FETCH phase (run-the-commands). The DERIVATION phase — turning raw output into an answer — still belongs in code: add a processing command that consumes the indexed output and prints only the answer, so the raw bytes never enter your conversation (Think-in-Code, same principle as the sandbox tool).
WHEN:
You have 3+ related commands you would otherwise run sequentially (multi-issue lookups, git log + git diff + git blame, multi-file reads, multi-region cloud queries)
You want to gather AND query in one round trip — pass
queriesso the matching sections come back inlineYou want to parallelize I/O-bound work — pass
concurrency2-8 (network calls, gh CLI, cloud APIs, multi-repo git reads)The combined output is large enough that piping it through ctx_search later would itself be expensive — let auto-index + inline queries do both in one shot
WHEN NOT:
Single command with no follow-up query — run it in the sandbox tool directly
CPU-bound or stateful commands — keep concurrency at 1 (npm test, build, lint, port-binding servers, lock-file holders, anything that races on the same resource)
RETURNS:
Auto-indexed section list per command label, plus top matches per query (when queries is passed). Raw output is NOT echoed in full — only the matched windows. Concurrency>1 switches each command to its own per-command timeout (no shared budget); concurrency=1 preserves the legacy shared-budget cascading-skip-on-timeout path. Use 4-8 for I/O-bound batches; keep at 1 for CPU work or shared-state commands; lower the value when target hosts enforce per-IP rate limits.
EXAMPLE: ctx_batch_execute( commands: [ {label: "issue 1", command: "gh issue view 1"}, {label: "issue 2", command: "gh issue view 2"}, {label: "summarize", command: "echo done"} ], queries: ["root cause", "proposed fix"], concurrency: 2 )
| Name | Required | Description | Default |
|---|---|---|---|
| cwd | No | Optional working directory for all shell commands in this batch. | |
| queries | Yes | Search queries to extract information from indexed output. Use 5-8 comprehensive queries. Each returns top 5 matching sections with full content. This is your ONLY chance — put ALL your questions here. No follow-up calls needed. | |
| timeout | No | Max execution time in ms. When omitted, no server-side timer fires — the MCP host's RPC timeout governs. With concurrency=1, the value (when set) is a shared budget across commands; with concurrency>1, it is applied per-command. | |
| commands | Yes | Commands to execute as a batch. Output is labeled with the section header. Default order is sequential; pass concurrency>1 to run in parallel (output stays in input order). | |
| concurrency | No | Max commands to run in parallel (1-8, default: 1). Use 4-8 for I/O-bound batches (network, gh, curl, multi-repo git reads). Keep at 1 for CPU-bound (npm test, build, lint) or stateful commands (ports, locks). >1 switches to per-command timeouts (no shared budget) and individual `(timed out)` blocks instead of cascading skip. | |
| query_scope | No | Scope for `queries` (default: `batch`). `batch` searches ONLY the chunks produced by this batch's commands — useful when you want answers about the just-fetched output. `global` searches the entire persistent index (same scope as ctx_search) — useful when you want the batch commands to enrich context and the queries to also surface related prior knowledge in one round trip. | batch |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses significant behavioral context beyond annotations: auto-indexing side effects, that raw output is not echoed in full, concurrency>1 switches to per-command timeouts, and concurrency=1 preserves shared-budget cascading-skip behavior. These details are not present in the annotations or schema and are critical for correct use.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with WHEN, WHEN NOT, RETURNS, and EXAMPLE sections, and it is appropriately detailed for a complex tool. However, concurrency guidance is repeated in multiple sections (WHEN, WHEN NOT, RETURNS), making it slightly less concise than ideal.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description compensates by explaining return values (auto-indexed section list, top matches per query) and the non-echoing of raw output. It covers when to use, when not, behavioral nuances, and provides a concrete example, making it complete for reliable invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds practical semantics for concurrency and queries, such as 'Use 4-8 for I/O-bound batches; keep at 1 for CPU work' and per-command vs shared timeout behavior. This adds value beyond the schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Run multiple commands in ONE call' and clearly states that outputs are auto-indexed and queries return matching sections inline. This distinguishes it from sibling tools like ctx_execute (single command) and ctx_search (follow-up search), establishing a specific verb+resource+scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The WHEN and WHEN NOT sections provide explicit guidance: use for 3+ related commands, gathering+querying in one round trip, or I/O-bound parallelization; avoid for single commands (use sandbox directly) or CPU/stateful commands (keep concurrency at 1). This clearly states when to use versus alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
ctx_doctorRun DiagnosticsARead-onlyIdempotent
Diagnose context-mode installation. Runs all checks server-side and returns a plain-text status report with [OK]/[FAIL]/[WARN] prefixes (renderer-safe across MCP clients). No CLI execution needed.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds value by stating that all checks run server-side, returns a plain-text report with specific prefixes, and that no CLI execution is needed—useful behavioral context beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: two sentences that immediately state the purpose and then add key details about execution and output. No filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a no-parameter diagnostic tool, the description covers purpose, execution model, and output format. It does not enumerate the specific checks run, but given the simplicity and the presence of key behavior details, it is sufficiently complete for an agent to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline is 4. The description correctly focuses on behavior rather than parameters, and there is nothing more needed for parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as a diagnostic for context-mode installation with a specific verb ('Diagnose') and resource. It distinguishes itself from the sibling tools by focusing on installation health reporting rather than execution, search, or index management.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool: to diagnose context-mode installation issues. It also implies that it is a server-side alternative to CLI methods, but it does not explicitly name alternative tools or exclusions, so it stops short of full guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
ctx_executeRun code in a sandbox (executes the supplied code)ADestructive
Run code in a sandboxed subprocess. Languages: javascript, shell, typescript, python, perl.
Think-in-Code — the core philosophy: the bytes your code processes never enter your conversation memory; only what you console.log() does. Reading a 700 KB log directly means 700 KB of your remaining reasoning capacity gets spent on raw bytes. Running code over that same log in this sandbox and printing a 3 KB summary leaves you with 697 KB of capacity for the actual work.
Concrete shape — analyze 47 source files without reading any of them:
ctx_execute(language: "javascript", code: const fs = require('fs'); const files = fs.readdirSync('src').filter(f => f.endsWith('.ts')); files.forEach(f => { const lines = fs.readFileSync('src/'+f,'utf8').split('\\n').length; console.log(f + ': ' + lines + ' lines'); }); )
// 47 files analyzed, 15,314 LoC summarized — output ~3.6 KB instead of 47 Read() calls = ~700 KB.
WHEN:
You intend to derive an answer FROM data (filter, count, aggregate, parse, compare, transform) — do the derivation in code and print only the answer
Output shape or size cannot be predicted before execution (recursive finds, repo-wide greps, list endpoints, query results, log scans)
You would otherwise read raw output and then mentally compute — that compute belongs here, in code, where its inputs stay out of your conversation
You need to keep a long-running process alive (dev server, watcher, daemon) — pass
background: trueto detach on timeout instead of killing the processThe output may legitimately be large but you only want recall-by-topic later — pass an
intentstring; outputs over ~5KB are auto-indexed into the knowledge base and only the section titles + previews come back, retrievable via ctx_search
WHEN NOT:
Single observational command whose entire short output you intend to consume verbatim (whoami, pwd, git status on a clean tree) — Bash is simpler
File mutations (Edit/Write) or navigation (cd/ls) — Bash is the right surface
You already know the output is one short fixed line and you want to read it as-is
RETURNS:
Only what your code prints. Wrap risky calls in try/catch — uncaught errors go to stderr and may leak more than intended. When intent is set and output exceeds the auto-index threshold, the response carries searchable section titles + previews instead of the raw stdout; use ctx_search(queries: [...]) to drill into specific sections.
EXAMPLE: ctx_execute(language: "javascript", code: "const out = require('child_process').execSync('npm test', {encoding:'utf8', stdio:['ignore','pipe','pipe']}); console.log(out.split('\n').filter(l => /(FAIL|✗|×|Error:|Tests +.*(failed|passed))/i.test(l)).slice(0, 60).join('\n'))")
EXAMPLE: ctx_execute(language: "javascript", code: "const out = require('child_process').execSync('gh issue list --json number,title --limit 100', {encoding:'utf8'}); const hooks = JSON.parse(out).filter(i => /hook|routing/i.test(i.title)); console.log(${hooks.length} hook-related issues)")
| Name | Required | Description | Default |
|---|---|---|---|
| cwd | No | Optional working directory for shell commands. Non-shell languages still execute from their sandbox temp directory. | |
| code | Yes | Source code to execute. Use console.log (JS/TS), print (Python/Ruby/Perl/R), echo (Shell), echo (PHP), fmt.Println (Go), IO.puts (Elixir), or Console.WriteLine (C#) to output a summary to context. | |
| intent | No | What you're looking for in the output. When provided and output is large (>5KB), indexes output into knowledge base and returns section titles + previews — not full content. Use ctx_search(queries: [...]) to retrieve specific sections. Example: 'failing tests', 'HTTP 500 errors'. TIP: Use specific technical terms, not just concepts. Check 'Searchable terms' in the response for available vocabulary. | |
| timeout | No | Max execution time in ms. When omitted, no server-side timer fires — the MCP host's RPC timeout governs (which is the right layer for this policy). Pass an explicit value for long-running builds (Gradle/Maven/SBT). | |
| language | Yes | Runtime language | |
| background | No | Keep process running after timeout (for servers/daemons). Returns partial output without killing the process. IMPORTANT: Do NOT add setTimeout/self-close timers in background scripts — the process must stay alive until the timeout detaches it. For server+fetch patterns, prefer putting both server and fetch in ONE ctx_execute call instead of using background. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that only console.log output returns, uncaught errors go to stderr, and intent auto-indexes outputs over ~5KB into the knowledge base, returning only section titles+previews. It also details background detachment behavior and warns against self-close timers, all beyond the annotations' destructive/openWorld hints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but structured with WHEN/WHEN NOT/RETURNS/EXAMPLE sections; every sentence earns its place. The 'Think-in-Code' philosophy paragraph is slightly verbose but illuminates the core trade-off, and the concrete example demonstrates usage. Not maximally concise, but justified for a complex tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite lacking an output schema, the description covers return behavior, error handling, background mode, intent indexing, and common usage examples. For a six-parameter arbitrary-code-execution tool, this is complete enough for correct selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (all six parameters described), so baseline is 3. The description adds meaningful context for `background` (detach on timeout, no self-close timers), `intent` (auto-index threshold and retrieval via ctx_search), and provides examples illustrating language/code usage, elevating it above baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a clear verb+resource: 'Run code in a sandboxed subprocess' and lists supported languages. It distinguishes from siblings by explicitly naming the sandbox execution model and contrasting with Bash, making the purpose unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The WHEN section lists five concrete scenarios (derive answers from data, unpredictable output, offload compute, background processes, large output intent) and the WHEN NOT section names alternatives (Bash for simple commands, file mutations/navigation). This is explicit, actionable guidance with clear alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
ctx_execute_fileRun code over a file (executes code, reads the given path)ADestructive
Read a file into a sandboxed FILE_CONTENT variable and run code over it. Only what you console.log() enters your conversation — the file bytes stay in the sandbox.
Think-in-Code applied to file-level analysis: Reading the whole file means every byte enters your conversation memory and costs reasoning capacity for the rest of the session. Running code over it here lets you keep the raw bytes out and only the derived answer in. Same principle as ctx_execute, scoped to one named file via the FILE_CONTENT variable.
WHEN:
You want to KNOW SOMETHING ABOUT a file (line count, matches of a pattern, parsed structure, statistical aggregate) without needing to SEE all of it
The file is structured (CSV, JSON, log, code) and a code-level derivation is cheaper than reading verbatim
The file is large enough that reading the full content would burn meaningful conversation memory you need for the actual work
The derivation may itself produce a large output you want recall-by-topic on later — pass an
intentstring; outputs over ~5KB are auto-indexed and only matching sections come back, retrievable via ctx_search
WHEN NOT:
You intend to EDIT the file — use Read so the subsequent Edit can match the exact text
You only need one specific line and you know its offset — Read with offset/limit is the simplest path
The file is small AND you will consume all of it for understanding/editing — Read directly
RETURNS:
Only what your code prints. The FILE_CONTENT variable holds the raw bytes inside the sandbox; nothing else leaves. When intent is set and output exceeds the auto-index threshold, the response carries searchable section titles + previews instead of the raw stdout.
EXAMPLE: ctx_execute_file(path: "huge.log", language: "javascript", code: "const errs = FILE_CONTENT.split('\n').filter(l => /ERROR|FATAL/.test(l)); console.log(${errs.length} error lines); console.log(errs.slice(-5).join('\n'))")
EXAMPLE: ctx_execute_file(path: "data.csv", language: "javascript", code: "const rows = FILE_CONTENT.split('\n'); console.log(rows: ${rows.length - 1}, header: ${rows[0]})")
| Name | Required | Description | Default |
|---|---|---|---|
| code | Yes | Code to process FILE_CONTENT (file_content in Elixir). Print summary via console.log/print/echo/IO.puts/Console.WriteLine. | |
| path | Yes | Absolute file path or relative to project root | |
| intent | No | What you're looking for in the output. When provided and output is large (>5KB), returns only matching sections via BM25 search instead of truncated output. | |
| timeout | No | Max execution time in ms. When omitted, no server-side timer fires — the MCP host's RPC timeout governs. | |
| language | Yes | Runtime language |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description claims the tool is sandboxed and that 'file bytes stay in the sandbox', implying safe, non-destructive execution. However, annotations declare destructiveHint=true and readOnlyHint=false, which contradicts this safety implication. Per the rule, this is an annotation contradiction and scores 1.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with a clear purpose, uses structured sections (WHEN, WHEN NOT, RETURNS, EXAMPLE) for scannability, and includes relevant examples. It is long but every section earns its place; no filler or tautology.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Even without an output schema, the description explains return behavior ('Only what your code prints'), large-output auto-indexing, and the memory rationale. Combined with thorough usage guidance and examples, it is nearly complete for a tool of this complexity, only undermined by the annotation contradiction.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3, but the description adds significant value: it explains the FILE_CONTENT variable, clarifies that only console.log output is returned, details the intent param's auto-indexing behavior, and provides concrete examples for code and path. This goes beyond the schema's terse descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb+resource pattern: 'Read a file into a sandboxed FILE_CONTENT variable and run code over it.' It also explicitly distinguishes itself from sibling ctx_execute by saying 'Same principle as ctx_execute, scoped to one named file via the FILE_CONTENT variable.' This clearly differentiates it from alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes explicit 'WHEN' and 'WHEN NOT' sections, listing specific scenarios for use and alternatives such as Read, ctx_execute, and ctx_search. It names exact tools and conditions, making the choice logic unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
ctx_fetch_and_indexFetch & Index URL(s)A
Fetches URL content, converts HTML to markdown (JSON is chunked by key paths, plain text indexed directly), persists it in a searchable knowledge base, and returns a small preview window per source. The raw page bytes never enter your conversation — they live in storage and you retrieve any section on-demand via ctx_search.
Caching: every fetch is cached on disk and reused for repeat calls within the TTL window. The default TTL is 24 hours; override per-call with the ttl parameter (milliseconds, ttl: 0 bypasses cache like force: true). Stored content older than 14 days is cleaned up on startup.
WHEN:
You need web content (docs, changelogs, API references, spec pages) and the raw page bytes should NOT enter your conversation
Multi-URL research (library evaluation, migration scans, doc comparisons): pass the
requestsarray and aconcurrencyvalue 2-8 for parallel I/OYou want repeat lookups against the same URL to be cheap (TTL cache hits return only a hint, no re-fetch)
You want a long-lived cache window (override
ttlupward for stable specs) or a guaranteed-fresh fetch (ttl: 0orforce: true)
WHEN NOT:
You already have the content locally — store it via the inline index tool
The page is SPA-rendered (JavaScript-required to materialize content) — this is a plain HTTP fetch, no headless browser
RETURNS: Per-source preview windows extracted around indexable headings plus indexing metadata (chunk counts, source labels, cache state). Raw content is NOT echoed back — retrieve any section on-demand via ctx_search(source: ""). Concurrency parallelizes the fetch phase up to your chosen value (capped by the host's logical CPU count); the FTS5 write phase always runs serially because SQLite is a single-writer store. Net latency = max(fetch latency across the pool) + sum(per-source index write time). Cache hits skip both phases and return a small freshness hint instead of re-fetching. Use 4-8 for stable I/O-bound batches; lower the value when the target host enforces a per-IP rate limit you cannot raise.
EXAMPLE: ctx_fetch_and_index( requests: [{url: "https://react.dev/...", source: "react"}, {url: "https://vuejs.org/...", source: "vue"}], concurrency: 5 )
| Name | Required | Description | Default |
|---|---|---|---|
| ttl | No | Override the cache freshness window for this call, in milliseconds. `ttl: 0` bypasses the cache like `force: true`; omit to use the default 24h TTL. | |
| url | No | Single URL to fetch and index (legacy single-shape) | |
| force | No | Skip cache and re-fetch even if content was recently indexed | |
| source | No | Label for the indexed content when using single `url` (e.g., 'React useEffect docs', 'Supabase Auth API'). For batch, put source in each requests entry. | |
| requests | No | Batch shape: array of {url, source?} entries. Use with concurrency>1 for parallel fetch. Each request indexed under its own source label. Output preserves input order. | |
| concurrency | No | Max URLs to fetch in parallel (1-8, default: 1). Use 4-8 for I/O-bound multi-URL batches (library docs, changelogs, pricing pages). Capped by os.cpus().length on small machines (response notes when capped). Indexing is always serial regardless — only fetches race. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses significant non-obvious behaviors: raw page bytes never enter the conversation, disk caching with TTL, 14-day cleanup, serial FTS5 writes, concurrency cap, and rate-limit implications. These go well beyond the annotations (readOnlyHint=false, openWorldHint=true, etc.) and add critical operational detail.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but exceptionally well-structured with clear sections (WHEN, WHEN NOT, RETURNS, EXAMPLE). It front-loads the core purpose and each section conveys distinct, essential information without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers caching behavior, return values (preview windows, indexing metadata), concurrency latency, cache-hit behavior, and even operational constraints like rate limits. Despite no output schema, it paints a complete picture for an agent to use the tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Even though schema coverage is 100%, the description enriches parameter understanding by explaining ttl:0 is equivalent to force:true, how concurrency interacts with indexing (serial writes, net latency), and when to lower concurrency due to rate limits. The example clarifies batch usage with requests and concurrency.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description precisely states what the tool does: 'Fetches URL content, converts HTML to markdown... persists it in a searchable knowledge base, and returns a small preview window per source.' It also distinguishes from siblings by referencing ctx_search for on-demand retrieval and an inline index tool for local content.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit WHEN and WHEN NOT sections provide clear guidance: use for web content that should not enter conversation, multi-URL research, and caching; avoid when content is already local or the page is SPA-rendered. It names the inline index tool as an alternative for local content.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
ctx_indexIndex ContentA
Store content in a searchable knowledge base (BM25 over FTS5). Splits markdown by headings, keeps code blocks intact, and persists the raw chunks. The full content stays in storage — retrieve any section on-demand via ctx_search; nothing is summarized or truncated.
WHEN:
Documentation from Context7, Skills, or MCP tools (API docs, framework guides, code examples)
API references (endpoint details, parameter specs, response schemas)
MCP tools/list output (exact tool signatures and descriptions)
Skill prompts and instructions that are too large to keep verbatim in conversation
README files, migration guides, changelog entries
Any content with code examples you may need to reference precisely later
WHEN NOT:
Log files, test output, CSV, or build output — use ctx_execute_file, which processes in-sandbox without persisting bytes
Single-use ephemeral content you will not query later — keep it inline if it fits, or ctx_execute_file it
RETURNS:
Indexing metadata: chunk counts (total, code-bearing), source label, and the exact ctx_search call shape to query the indexed content. Raw content is NOT echoed back — it lives in storage, retrievable via ctx_search(source: ""). When path is provided, a content hash is stored so ctx_search results auto-flag staleness on future calls.
EXAMPLE: ctx_index(content: "# React useEffect\n\nThe Effect Hook lets you ...", source: "react-useeffect-docs") EXAMPLE: ctx_index(path: "/path/to/large-spec.md", source: "openapi-v2-spec")
| Name | Required | Description | Default |
|---|---|---|---|
| path | No | File OR directory path to read and index (content never enters context). Provide this OR content. Directory paths trigger a bounded recursive walk (#687). | |
| source | No | Label for the indexed content (e.g., 'Context7: React useEffect', 'Skill: frontend-design') | |
| content | No | Raw text/markdown to index. Provide this OR path, not both. | |
| exclude | No | Directory-only: glob patterns to exclude. Merged with defaults (node_modules, .git, dist, build, .next, coverage, .venv, __pycache__, .DS_Store). | |
| include | No | Directory-only: glob patterns to include (default: all matching extensions). | |
| maxDepth | No | Directory-only: max recursion depth from root (default: 5). | |
| maxFiles | No | Directory-only: hard cap on files indexed (default: 200) — FTS5 blow-up guard. | |
| extensions | No | Directory-only: allowed file extensions (default: .md .mdx .txt .json .yaml .yml .ts .tsx .js .jsx .py .rs .go .sh). | |
| followSymlinks | No | Directory-only: follow directory symlinks (default: false — cycle hazard + escape risk). | |
| respectGitignore | No | Directory-only: apply nearest .gitignore (default: true). |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the four annotation hints, the description discloses meaningful behavior: content is not summarized or truncated, raw chunks persist in storage, and returned metadata excludes raw content. It also explains that when path is provided a content hash enables staleness detection, and that directory indexing is a bounded recursive walk.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with a two-sentence summary of the tool's essence, followed by clearly labeled WHEN/WHEN NOT/RETURNS/EXAMPLE sections. Each section adds unique information without filler, making the length justified by the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, so the description compensates by explicitly stating RETURNS: chunk counts, source label, and the exact ctx_search call shape. It also covers edge cases like path-vs-content, directory walking bounds, and staleness flags, making the description self-sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema covers all 10 parameters with detailed descriptions (100% coverage), so the baseline is 3. The description adds context by clarifying that content never enters context when using path and that path triggers hash-based staleness detection, plus two concrete examples showing how to call the tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Store content in a searchable knowledge base (BM25 over FTS5).' It clearly distinguishes itself from siblings by specifying it splits markdown by headings, preserves code blocks, and stores raw chunks for later retrieval, with the explicit contrast to ctx_execute_file in WHEN NOT.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The WHEN section enumerates concrete use cases (Context7 docs, API references, MCP tool lists, skill prompts) and the WHEN NOT section explicitly excludes log files/test output and directs to ctx_execute_file. It also names ctx_search as the retrieval counterpart, giving clear decision criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
ctx_insightOpen Insight DashboardAIdempotent
Opens the context-mode Insight dashboard (https://context-mode.com/insight) in your default browser — a dashboard launcher for the hosted analytics layer, not a Q&A engine. Insight surfaces per-engineer productive rate, retry waste, blocker detection, and role-narrowed views for CTO, EM, IC, CISO, FinOps, and DevOps. For natural-language queries over your indexed content, use ctx_search.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare idempotentHint=true and destructiveHint=false, and the description adds that it opens a browser (openWorldHint context) and clarifies it's a launcher rather than a data-returning tool. It also details the dashboard contents, which is useful behavioral context beyond the safety flags.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences with a clear hierarchy: the core action, the dashboard's analytics content, and the alternative for queries. Every sentence adds distinct value without redundancy, and the most important information (opens dashboard) is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple side-effecting launcher with no parameters and no output schema, the description covers the primary action, the domain of the dashboard, and the correct alternative for a different use case. Given the annotations cover safety and the schema is empty, this is fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has zero parameters, and the rubric sets a baseline of 4 for no-parameter tools. The description adds no unnecessary parameter details, which is appropriate since there are none.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb+resource: 'Opens the context-mode Insight dashboard in your default browser,' and immediately distinguishes it from a Q&A engine by noting it's a launcher, not a query tool. It also clearly maps to sibling differentiation by pointing to ctx_search for natural-language queries.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly states the tool's scope ('dashboard launcher for the hosted analytics layer, not a Q&A engine') and provides an explicit alternative: 'For natural-language queries over your indexed content, use ctx_search.' This gives the agent clear when-to-use and when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
ctx_purgePurge Knowledge BaseADestructiveIdempotent
DESTRUCTIVE: permanently delete indexed content. Cannot be undone. Requires confirm:true and exactly one scope.
WHEN:
User explicitly asks to clear a specific session ('purge this session', 'wipe this conversation')
User explicitly asks to reset the whole project ('reset everything', 'wipe the knowledge base')
WHEN NOT:
User says 'reset', 'clear', or 'wipe' without naming a scope -> ask which scope before calling
User wants to free memory or improve performance -> recommend ctx_stats first, do not purge
SCOPES (pass exactly one):
Per-session: ctx_purge(confirm: true, sessionId: "") deletes that session's events (auto-captured decisions, errors, plans, user prompts, rejected approaches, etc.) and per-session FTS5 chunks; sibling sessions and stats file are preserved.
Per-project: ctx_purge(confirm: true, scope: "project") wipes FTS5 knowledge base, every session DB row, events markdown, and resets the stats file. Use ctx_stats first to preview category counts before purging.
CONTRACT:
confirm:true is required; confirm:false returns 'purge cancelled'.
sessionId and scope:'project' together return 'ambiguous - pick one'.
scope:'session' without sessionId throws (sessionId required).
Bare {confirm:true} is deprecated: maps to scope:'project' with a stderr warning; will hard-error in a future major.
RETURNS: A summary of removed rows + the resolved scope.
EXAMPLE: ctx_purge(confirm: true, sessionId: "7c8a-1234-5678-9abc-def012345678") EXAMPLE: ctx_purge(confirm: true, scope: "project")
| Name | Required | Description | Default |
|---|---|---|---|
| scope | No | Explicit scope selector. 'session' REQUIRES sessionId. 'project' wipes the entire project (FTS5 + every session + stats). Omit only for the deprecated bare-{confirm:true} back-compat path. | |
| confirm | Yes | MUST be true. Destructive operation; false returns 'purge cancelled'. | |
| sessionId | No | UUID of a single session. Pairs with confirm:true to wipe only that session's events + per-session FTS5 chunks. Sibling sessions and the stats file are preserved. MUST NOT be combined with scope:'project'. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (readOnlyHint=false, destructiveHint=true), the description discloses irreversible deletion, confirm:true requirement, error cases for ambiguous/invalid scopes, deprecated bare-confirm behavior, and the return summary. This gives the agent a rich behavioral contract without contradicting the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is organized with clear sections (DESTRUCTIVE, WHEN, WHEN NOT, SCOPES, CONTRACT, RETURNS, EXAMPLE), making it scannable and front-loaded with the most critical warning. Every line conveys necessary behavioral or usage information with no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a highly destructive tool with no output schema, the description fully covers return values, error conditions, deprecated paths, and scope-specific effects. It addresses all three parameters and even includes examples, making it complete for an agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although the input schema already fully documents each parameter, the description adds critical meaning: exactly one scope must be passed, sessionId cannot be combined with scope:'project', scope:'session' requires sessionId, and confirm:false cancels. It also provides two valid example invocations, which materially improves correct usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'DESTRUCTIVE: permanently delete indexed content. Cannot be undone,' which clearly identifies the action, resource, and severity. It also distinguishes the two scopes (session vs project), making the tool's purpose unmistakable relative to its siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit WHEN and WHEN NOT sections, including concrete user phrasing triggers and instructions to ask for a scope if ambiguous. It even recommends an alternative tool (ctx_stats) for memory/performance concerns, giving clear guidance on when not to purge.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
ctx_searchSearch Indexed ContentARead-onlyIdempotent
Search a unified knowledge base with a multi-strategy ranking pipeline. Two parallel matchers run on every query: a Porter-stemming matcher ("caching" finds "cached", "caches", "cach") and a trigram-substring matcher ("useEff" finds "useEffect"). Their ranked lists are merged via Reciprocal Rank Fusion, so a document that ranks well in both surfaces above one that wins only on a single strategy. Multi-term queries get an additional proximity-rerank pass that boosts passages where the query terms appear close together. Typos are corrected via Levenshtein distance and re-searched. Result snippets are window-extracted around the matched terms, not blindly truncated.
The knowledge base is unified: queries reach indexed content you stored (ctx_index, ctx_fetch_and_index, ctx_batch_execute output) AND auto-captured session memory written by hooks (decisions, errors, blockers, plans, user prompts, rejected approaches, tool failures, compaction guides — 26 event categories). File-backed sources carry a content hash and auto-flag staleness when the source file changes.
WHEN:
You want to recall something that exists in storage (recently indexed content, prior session events, auto-memory) instead of re-reading raw sources
You have multiple related questions about the same body of knowledge — batch every question into one call (the ranking pipeline runs per-query but the round-trip cost is paid once)
You want to scope the query to one labelled source (pass
source— partial match is fine)You want a chronological view across current session + prior sessions + persistent auto-memory (pass
sort: "timeline"— the defaultrelevancemode only ranks within the current session)You want to filter ranked results by content shape (pass
contentType: "code"to surface implementation snippets orcontentType: "prose"to surface explanations)
WHEN NOT:
The data you want to query has never been stored in the knowledge base AND no session memory has accumulated around it — capture first (run a gather-and-index call), then come back here to query
You have one ad-hoc question against data that is not in the knowledge base — answer it inline by running code in the sandbox tool; one round-trip instead of capture-then-query
RETURNS:
Per-query ranked sections with window-extracted snippets. Use 2-4 specific technical terms per query. Common session-memory source labels: decision (user corrections / preferences), error and error-resolution (past failures + their fixes), blocker, plan, user-prompt, rejected-approach, compaction (post-compact session guide). See ctx_stats for live category counts. Each response carries a throttle counter (call #N/M in the rolling time window); results taper toward the soft cap and calls block after the hard cap. Tune via CONTEXT_MODE_SEARCH_WINDOW_MS, CONTEXT_MODE_SEARCH_MAX_RESULTS_AFTER, CONTEXT_MODE_SEARCH_BLOCK_AFTER.
EXAMPLE: ctx_search(queries: ["root cause", "proposed fix", "test coverage"], source: "issue-#683") EXAMPLE: ctx_search(queries: ["what did we decide about caching"], source: "decision", sort: "timeline") EXAMPLE: ctx_search(queries: ["useEffect cleanup pattern"], source: "react-docs", contentType: "code", limit: 5) EXAMPLE: ctx_search(queries: ["last user prompt", "active skills", "open blockers"], sort: "timeline")
| Name | Required | Description | Default |
|---|---|---|---|
| sort | No | Sort mode. 'relevance' (default): BM25 ranked, current session only. 'timeline': chronological across current session, prior sessions, and auto-memory. | relevance |
| limit | No | Results per query (default: 3) | |
| source | No | Filter to a specific indexed source (partial match). | |
| queries | No | Array of search queries. Batch ALL questions in one call. | |
| contentType | No | Filter results by content type: 'code' or 'prose'. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/destructive hints. The description adds extensive behavioral detail: stemming and trigram matching, Reciprocal Rank Fusion, proximity rerank, typo correction, snippet windowing, unified KB scope, staleness flagging, and throttle behavior with tunable environment variables. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Although lengthy, the description is tightly organized into clear sections (WHEN, WHEN NOT, RETURNS, EXAMPLES) and every sentence delivers operational value. It is front-loaded with the core search mechanism and uses headers to aid scanning, making the length justified and structurally clean.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, but the description compensates fully: it explains per-query ranked sections, window-extracted snippets, throttle counters and caps, common source labels, and references ctx_stats for live counts. With five parameters and complex ranking behavior, the description leaves no significant gaps for an agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but description enriches param meaning: source permits partial match, sort 'timeline' vs 'relevance' differences, contentType examples ('code' vs 'prose'), and the recommendation to pass 2-4 terms per query. Examples show usage of queries, source, sort, contentType, and limit in context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Search a unified knowledge base with a multi-strategy ranking pipeline,' using a specific verb ('search') and resource ('unified knowledge base'). It clearly distinguishes from siblings by referencing stored content from ctx_index, ctx_fetch_and_index, and ctx_batch_execute, plus auto-captured session memory, which no other sibling covers.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit WHEN and WHEN NOT sections. It states when to use the tool (recalling stored content, batching related questions, scoping by source, timeline sort) and when not to (data never stored, one-off ad-hoc questions best handled with sandbox code). This is textbook differentiation from alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
ctx_statsSession StatisticsARead-onlyIdempotent
Returns context consumption statistics for the current session. Shows total bytes returned to context, breakdown by tool, call counts, estimated token usage, and context savings ratio.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering safety. The description adds valuable behavioral detail by listing exactly what statistics are returned (total bytes, breakdown by tool, call counts, estimated token usage, context savings ratio), which goes beyond the annotations and helps the agent understand the tool's output.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that front-loads the core purpose ('Returns context consumption statistics') and then enumerates the specific stats in a compact list. No filler or redundant information is present.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (no parameters, no output schema), and the description fully covers its scope, behavior, and return values. It lists the types of statistics provided, which is sufficient for an agent to understand what it will receive. Annotations cover safety traits, so no further information gaps exist.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the description does not need to explain parameter meanings. The schema coverage is trivially 100% with an empty properties object. Per the rubric, baseline for 0 parameters is 4, and the description adequately complements the schema by explaining what the tool reports without needing parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns context consumption statistics for the current session, with a specific verb ('Returns'), resource ('context consumption statistics'), and scope ('current session'). This distinguishes it from siblings like ctx_execute or ctx_search, which perform actions or queries rather than reporting statistics.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied rather than explicitly stated. The description tells what it does but does not provide explicit 'when to use' or 'when not to use' guidance, nor does it mention alternatives. While the purpose makes its use case obvious, there is no direct comparison with sibling tools or contextual exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
ctx_upgradeUpgrade PluginAIdempotent
Upgrade context-mode to the latest version. Returns a shell command to execute. You MUST run the returned command using your shell tool (Bash, shell_execute, run_in_terminal, etc.) and display the output as a checklist. Tell the user to restart their session after upgrade.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses key behavior beyond annotations: it returns a shell command rather than performing the upgrade directly, and it mandates a restart. This adds context to the readOnlyHint=false and idempotentHint=true annotations, though it could elaborate on potential side effects or prerequisites. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences with no wasted words. It front-loads the purpose, then gives essential execution instructions, and closes with a necessary user-facing step. Every sentence contributes value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters and no output schema, the description adequately covers the tool's behavior and required follow-up actions. It could mention what the returned command actually does or any prerequisites, but the core workflow is clear.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With zero parameters and 100% schema coverage, the baseline is 4. The description correctly avoids discussing parameters, as there are none to explain, and the empty schema already conveys this.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Upgrade context-mode to the latest version' with a specific verb and resource, clearly distinguishing it from siblings like ctx_execute, ctx_search, and ctx_purge. The purpose is unambiguous and directly tied to the tool name and title.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit execution guidance: the returned command must be run via a shell tool, output displayed as a checklist, and the user told to restart. However, it does not explicitly discuss when to use this tool versus alternatives or when not to use it, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
TDQS
Tools are largely distinct: execution (ctx_execute, ctx_execute_file, ctx_batch_execute), indexing (ctx_index, ctx_fetch_and_index), retrieval (ctx_search), and admin (ctx_stats, ctx_doctor, ctx_upgrade, ctx_purge, ctx_insight) form clear groups. The main ambiguity is between ctx_execute and ctx_execute_file (both run code, one inline vs. over a file), but descriptions and parameters make the distinction clear.
All tools share the ctx_ prefix and snake_case, following an imperative verb pattern (ctx_execute, ctx_search, ctx_purge). Minor deviations like ctx_execute_file (noun modifier) and ctx_fetch_and_index (two verbs) are still readable and consistent with the overall style.
11 tools is well-scoped for a server that handles sandboxed code execution, knowledge-base indexing/search, batch processing, and lifecycle administration. Each tool serves a distinct function without redundancy, and the count sits comfortably in the ideal 3-15 range.
The surface covers the full workflow: ingest (ctx_index, ctx_fetch_and_index), process (ctx_execute, ctx_execute_file, ctx_batch_execute), retrieve (ctx_search), monitor (ctx_stats), and maintain (ctx_purge, ctx_upgrade, ctx_doctor, ctx_insight). The only theoretical gap is fine-grained single-item deletion, but ctx_purge's scoped delete handles that adequately.
Maintenance
Resources
Unclaimed servers have limited discoverability.
Looking for Admin?
If you are the server author, to access and configure the admin panel.
Related MCP Connectors
One shared context your team's AI tools read & write over MCP. No re-explaining. Free.
Stateless agentic tools over MCP: concept extraction, long-context, knowledge graph, planning.
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
A paid remote MCP for OpenAI Codex context compressor, built to return verdicts, receipts, usage log
Related MCP Servers
- AlicenseNot gradedqualityDmaintenanceA meta-server that aggregates multiple MCP servers into a single interface, reducing token usage by 98%+ through progressive tool discovery and direct code execution that processes data between tools without consuming context window space.1610Apache 2.0
- AlicenseAqualityAmaintenanceAn MCP server that preserves LLM context by intercepting large data outputs and returning only concise summaries or relevant sections. It enables efficient sandboxed code execution, file processing, and documentation indexing across multiple programming languages and authenticated CLIs.1117,96020,295Elastic 2.0
- AlicenseNot gradedqualityCmaintenanceMCP server that cuts cloud LLM costs 36-42% by indexing context locally and giving agents precision retrieval tools instead of raw context dumps.157MIT
- AlicenseNot gradedqualityDmaintenanceToken-optimized MCP server that reduces context window usage by 59.5% by grouping 12 tools into 5 semantic operations, preserving all original functionality for AI assistants.81MIT
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
MCP directory API
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/Everflow-Utilities/context-mode'
If you have feedback or need assistance with the MCP directory API, please join our Discord server