My Codex just spent 4 tool calls reading one file.

But it had to construct a shell command to grep for a symbol, handle the escape quoting, pipe through head to paginate, then read the file with the right line range — all before it could actually do something useful. But that’s 3–5 tool calls per file operation, and every one burns context budget that should be going toward understanding my code.

So FastCtx fixes this. It’s a lightweight Rust MCP server that gives your AI agent structured tools to read, grep, glob, and modify files — one call, one result, no shell mechanics needed.

TL;DR — FastCtx is an MCP-native Rust runtime (MIT/Apache-2.0, 585★ on GitHub) that replaces hand-crafted shell commands with structured MCP tool calls. Install it globally, run fastctx to auto-configure, and your agent gets 9 typed repo tools — read, grep, glob, replace, run, run_background, job_output, job_kill, job_list. But I deployed it on a 500-file TypeScript monorepo and my Codex sessions went from 4-step file ops to single structured calls. If you use AI coding agents daily, this tool alone can extend your context budget by 30–50%.

The Tool Overhead Problem Nobody Talks About

So here’s what actually happens when your AI coding agent needs to look something up:

  1. Agent realizes it needs to find a symbol definition in src/core/parser.ts
  2. It constructs: grep -rn "parseConfig" src/core/ --include="*.ts"
  3. Shell processes it, returns 47 matches
  4. Output wraps across your terminal width, agent has to paginate
  5. Agent reads the output, realizes file is at line 312, constructs sed -n '300,340p' src/core/parser.ts
  6. Shell reads the file, returns it
  7. Agent now has the context it needed — after 3–5 tool calls

So I counted. In a typical 30-minute Codex coding session on my monorepo, roughly 40% of tool calls were filesystem mechanics — not reasoning, not writing code, just getting the context to be able to reason. Still, that’s hundreds of wasted context tokens per exchange.

So FastCtx collapses those 3–5 calls into one structured tool call. So the agent calls fastctx.grep({pattern: "parseConfig", path: "src/core/"}) and gets back typed, paginated results. In one call.

Installing FastCtx (Takes About 30 Seconds)

npm install --global fastctx

So that’s it. npm then pulls the Rust binary as a prebuilt native package — no Rust toolchain needed, no cargo, no LLVM. On my Windows dev machine (Ryzen 9 7950X) it installed in about 8 seconds. Yet on a MacBook Air M3 it was 11 seconds.

After install, run:

fastctx

So this opens a TUI terminal. Here you’ll see a menu with Apply as the primary action — hit it, and FastCtx auto-detects which MCP client you’re running (Codex, Claude Code, or generic) and writes the config file in the right location. Then restart your agent, and it has 9 new tools ready.

Yet for headless setups (CI or provisioning scripts):

fastctx apply --tier standard --yes

Or for manual configuration in something like claude_desktop_config.json:

{
  "mcpServers": {
    "fastctx": {
      "command": "fastctx",
      "args": ["serve"]
    }
  }
}

The 9 MCP Tools FastCtx Gives Your Agent

Tool What It Does Why You’d Use It
read Read file content with line range & encoding Instead of constructing head/tail/sed commands
grep Pattern search with include/exclude filters Structured regex search, typed results
glob File matching with pattern Smarter than shell glob for complex patterns
replace In-file text replacement with dry-run mode Safe find-replace without manual sed
run Execute shell commands Structured command execution with timeout
run_background Background job with job ID For long-running builds, no blocking
job_output Read background job output Poll build logs programmatically
job_kill Stop a running background job Emergency stop without raw kill
job_list List all background jobs See what’s still running

Yet the difference feels immediate. In my first session with FastCtx enabled, I asked Codex to find all WebSocket-related code in a 500-file monorepo and summarize the connection lifecycle. Before FastCtx, that query would have generated 12+ tool calls — grep across directories, cat each file, paginate long files. But with FastCtx, it took 3 structured calls: grep for the pattern, glob for the relevant files, then read on the key files. Even done in 12 seconds.

Hands-On: Refactoring a Monorepo with FastCtx

So I was working on refactoring the service layer of a Node.js monorepo — roughly 500 TypeScript files across 15 packages. Before FastCtx, every refactoring cycle looked like:

  1. Agent guesses what imports are used where
  2. Agent greps manually via shell (3 tool calls just to get the right args right)
  3. Agent reads each file (2–4 tool calls per file due to pagination)
  4. Agent writes changes
  5. Agent runs tests
  6. If tests fail, go back to step 1

With FastCtx:

  1. Agent calls fastctx.grep({pattern: "import.*from.*'@core/service'", include: "*.ts"}) — one call, all 47 files found
  2. Agent calls fastctx.read({path: "packages/service/src/handler.ts"}) — one call, full content with proper encoding
  3. Agent writes changes → fastctx.run({command: "npm test"}) with structured output capture

So the before/after is stark. So I measured:

Without FastCtx: A single “find all X references and understand how they connect” query averaged 14 tool calls and burned about 38,000 context tokens across the conversation history.

With FastCtx: Same query took 4 tool calls and about 9,000 tokens.

That’s a 74% reduction in tool overhead. And your agent gets to spend all that reclaimed budget on actual reasoning.

How FastCtx Compares to the Alternatives

Dimension FastCtx Codex Built-in MCP Claude Code Native Tools code-review-graph
Setup time ~30s (npm install + apply) Built-in (no setup) Built-in ~2 min (pip install)
Number of repo tools 9 structured tools ~5 basic MCP tools ~4 shell wrappers 1 tool (context-aware code search)
Context overhead Low — structured schemas Medium — bespoke commands per call Medium — shell-escaped commands Low — only sends relevant context
VPS/daemon mode fastctx serve ✅ Docker mode
Platform support Linux, macOS, Windows (prebuilt binaries) Platform-dependent via client macOS/Linux only Linux, macOS
Performance Rust — near-instant startup Varies by client Node.js — moderate Python + Tree-sitter — fast for queries
Security model Tools disabled by default, approval modes Per-MCP client config Built-in sandbox Read-only by design
Primary use case General repo file ops Varies by client Agent-native operations Code review context prep

Now, FastCtx and code-review-graph are complementary, not competitors. CRG tells your agent what code is relevant for a review. But FastCtx handles how the agent reads, searches, and modifies files. I run both — CRG for review prep, FastCtx for everyday coding sessions.

What I Like

But the single binary approach is the right call. Still no Python venvs, no Node version manager conflicts, no Docker daemon to babysit. Because it’s one Rust binary that sits in your PATH and does exactly one thing.

Plus the fastctx apply system is polished. While it auto-detects your running MCP clients — I had it write config for Codex in under 3 seconds. Plus the TUI isn’t just a gimmick; it shows you exactly which tools will be registered before they go live.

The security model is thoughtful too. The replace tool defaults to dry-run mode — the agent has to explicitly confirm before modifying files. Plus background job management (run_background + job_output + job_kill) means a build that runs away won’t hang your agent session.

Plus the Rust performance edge is also real. fastctx serve starts in about 150ms on my machine, and grep operations over 500 files complete in under 300ms.

Where It Falls Short

Bash tools are disabled by default. So you have to pass an --enable-bash flag to fastctx serve for the run and run_background tools to work. The reasoning is security — your agent can’t just execute arbitrary shell commands by accident. I get the rationale, but it means the setup isn’t truly “install and forget” if you actually want to run builds or scripts through the agent.

Even for non-Codex agents (Claude Code, Cursor), there’s still manual MCP config needed. The fastctx apply command handles it well, though you’re not getting the out-of-box experience Codex users get.

Also, the MCP dependency is a real limitation. FastCtx only works inside an MCP-compatible agent. If you use raw CLI tools or non-MCP workflows, it’s not useful alone.

Running FastCtx as a Persistent MCP Server

So for team setups or CI pipelines, FastCtx can run as a persistent MCP server daemon:

fastctx serve --port 3000 --enable-bash

But this is where the VPS angle comes in. A small cloud instance running fastctx serve means every agent session in your team connects to the same repo tooling layer — shared grep cache, consistent tool behavior, no per-device setup. Sign up for DigitalOcean ($200 free credit) to spin up a $6/month droplet in under a minute — enough runway to run fastctx serve for months without a bill. Plus I run mine on a $6/month VPS, and for multi-agent teams, this approach justifies the infrastructure cost.

I’ve been impressed enough that I’m exploring mcpsnoop to debug the MCP traffic between my agents and FastCtx — after all, the two tools together make a solid MCP development stack. So if you’re building an MCP toolchain, this pair is a strong core.

Who Should Use FastCtx

  • Codex / Cursor / Claude Code daily users — If your agent spends noticeable time on file operations, FastCtx is a 30-second install that pays for itself in the first session.
  • Monorepo maintainers — The grep + glob + read combo is impressive for codebases with 500+ files.
  • Multi-agent teams — Running fastctx serve on a Vultr $100 trial instance gives every agent session the same tool interface. Or go budget with Hostinger VPS from $3/month for smaller teams.
  • Rust ecosystem explorers — It’s a well-engineered Rust project with clean architecture. Worth knowing about even if you don’t need it today.

The Bottom Line

Look, FastCtx doesn’t reinvent MCP or agent tooling. Because it just does one thing well — replaces 3–5 shell-crafted tool calls with one structured MCP call. And for anyone using AI coding agents daily, the context savings are real. I measured 74% fewer tool calls on my monorepo refactoring sessions, and the difference in agent responsiveness is noticeable within minutes of installing.

Still, it’s not a silver bullet — the MCP dependency, disabled bash tools, and manual config for non-Codex agents are real pain points. But for what it does, FastCtx is one of the best implementations I’ve found so far.

Verdict: Install it. It takes 30 seconds, and the context savings start immediately.

Disclosure: Some links below are affiliate links. If you sign up through them, I may earn a commission at no extra cost to you.

  • Vultr — $100 trial credit for new users
  • DigitalOcean — $200 free credit for new users
  • Hostinger — VPS from $3/month for smaller teams