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:
- Agent realizes it needs to find a symbol definition in
src/core/parser.ts - It constructs:
grep -rn "parseConfig" src/core/ --include="*.ts" - Shell processes it, returns 47 matches
- Output wraps across your terminal width, agent has to paginate
- Agent reads the output, realizes file is at line 312, constructs
sed -n '300,340p' src/core/parser.ts - Shell reads the file, returns it
- 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:
- Agent guesses what imports are used where
- Agent greps manually via shell (3 tool calls just to get the right args right)
- Agent reads each file (2–4 tool calls per file due to pagination)
- Agent writes changes
- Agent runs tests
- If tests fail, go back to step 1
With FastCtx:
- Agent calls
fastctx.grep({pattern: "import.*from.*'@core/service'", include: "*.ts"})— one call, all 47 files found - Agent calls
fastctx.read({path: "packages/service/src/handler.ts"})— one call, full content with proper encoding - 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 serveon 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