ripwire: a zero-dependency C++23 CLI and MCP server that maps a repo before your coding agent reads it

What ripwire solves for an agent that keeps grepping

The README frames the problem in cost terms rather than accuracy terms. An agent asked about a repository typically greps, reads a few whole files, then greps again to fill the gaps. ripwire's own phrasing is that "a call followed by three greps is the same search paid for twice." The stated goal is terminality: one question, one answer complete enough that no follow-on search is needed.

That framing tells you who it is for. This is a tool for people paying per token for coding agents, not for people browsing a codebase by hand. The README lists Claude Code, Codex, Cursor, Windsurf, Gemini, opencode and aider as agents the installer can wire up, and describes the interface as a ranked, deterministic call graph covering what to touch, what it breaks, and which tests to run.

The second half of the pitch is about honesty rather than speed. Counts that cannot be totals are labelled floors. A zero means "none found", never "none exists". Truncation is disclosed. That design choice is worth more attention than the benchmark table, because it determines whether you can trust an answer at all when the tool is wrong.

One process, no daemon: how the call graph gets built

ripwire does not run an index server. The README is explicit: no API key, no embeddings, no index server, no daemon. According to the README, it indexes the project's own repository in 0.25 s using 6.6 MB, and warm queries answer in 197 ms.

The comparison figures the README publishes are against what it calls the leading graph-database code-context MCP server: 46.8 s and 391 MB for indexing, 1,082 ms for warm queries, measured on 48 matched questions across django, webpack and the ripwire repository itself. Across all three repositories the README states ripwire indexes in 0.25 to 0.45 s and 6.6 to 16.5 MB, against 23 to 52 s and 391 to 623 MB for the other server. The README says the full method, the wins named individually and the losses included, live in docs/EVALS.md. Treat those numbers as the project's own measurements, not an independent result.

The architecture that makes this possible is a single compiled executable. The repository is C++23 with a CMakeLists.txt at the top level, and the README advertises zero runtime dependencies with a link to THIRD_PARTY.md. Parsing appears to be tree-sitter based, given the topics list and the language matrix, which spans Rust, C++, Objective-C/C++, C, Metal, CUDA, Python, Go, Swift, TypeScript, JavaScript, Java, Ruby, PHP, Lua, Elixir, Bash, C#, JSON, TOML, YAML and Markdown. The README points readers to its languages section for support limits rather than claiming uniform coverage.

The README also mentions that signatures cost 74.7% fewer bytes than bodies, which is the mechanism behind the token savings: the agent sees call relationships and signatures, not function bodies. That is a compression strategy with an obvious failure mode, discussed below.

Installing ripwire and asking it a first question

The README gives a one-line install that also activates agent skills. The installer is fetched from the repository's scripts directory and takes the repository to install from as an environment variable. The README notes the installer prints the PATH line if you need it.

RIPWIRE_REPO=redhat-et/ripwire bash -c "$(curl -fsSL https://raw.githubusercontent.com/redhat-et/ripwire/main/scripts/install.sh)"
export PATH="$HOME/.local/bin:$PATH"

The install script installs to $HOME/.local/bin according to the README's own comment on that line. There is also an install.sh at the top level of the repository and an INSTALL.md, and the README's badge links CONTRIBUTING.md for the C++23 requirement, so building from source is a documented path rather than a guess.

The first real use is a single command run from inside the repository you care about. The --for flag takes the change you are about to make, in words.

cd your-repo
ripwire . --for="<the change you are about to make, in words>"

What you should see is a ranked call graph rather than a file listing. The README's claim is that this replaces the grep-then-read cycle, and its honesty rules mean any count that cannot be a total should appear labelled as a floor.

There is a second interface. The README describes the MCP server as optional and says the CLI is the cheaper way in, because MCP verb schemas sit in the agent's context every session whether or not they are called. A .mcp.json file sits at the repository root, and the README points to a section titled set it up in your coding agent for the configuration details, which the excerpt here does not reproduce. If you want MCP, read that section in the repository before editing any agent config.

Where the honest-limits design still leaves you exposed

The labelling scheme is a genuine improvement over tools that present partial results as complete, but it does not make the underlying analysis complete. A call graph built from static parsing has known blind spots: dynamic dispatch, reflection, generated code, and anything resolved at runtime. The README's language list includes Python, Ruby, PHP, JavaScript and Lua, all of which support dynamic call patterns that a static pass cannot fully resolve. The README does not document how ripwire handles those cases, and the languages section is where it says limits are written down.

The second exposure is the signature compression. If an agent only sees signatures and call edges, it can miss behaviour that lives in a function body: validation logic, side effects, error handling. The 74.7% byte reduction is real, but it is a lossy representation by construction, and the README's own framing acknowledges this by saying every loss is published. Whether the published losses are enough for your codebase is something only a run against your code will show.

Third, the benchmark comparison is self-reported. The README is unusually candid about including losses, but a project measuring itself against a competitor it selected is not neutral evidence. docs/EVALS.md is where the method lives, and that is the document to read before repeating the 0.25 s figure to anyone.

Finally, the README excerpt does not document rollback of the installer's changes to agent configuration. The installer activates skills for every agent it finds, and the README does not say how to undo that. If you run it on a machine with several configured agents, review the script before executing it.

ripwire against a graph-database code-context MCP server

The real alternative named in the README is the graph-database code-context MCP server, which the project benchmarks itself against. The difference in approach is architectural rather than incremental. That category of tool persists a graph in a database, which is why the README's comparison shows indexing times in the tens of seconds and memory footprints in the hundreds of megabytes. Persistence buys you a graph that survives restarts and can be queried repeatedly without reindexing, and it is the right shape if you want a long-lived service that many clients share.

ripwire takes the opposite position. It builds the graph in-process, on demand, in a fraction of a second, and keeps nothing running. That means every invocation pays the indexing cost again, which the README's 0.25 s figure makes tolerable, but it also means there is no shared state to inspect, back up or migrate. For a single developer running an agent locally, the trade favours ripwire. For a team that wants one indexed graph serving many consumers, the database approach is doing something ripwire explicitly declines to do.

The README does not name the competing server, so you cannot verify the comparison directly from this page. docs/EVALS.md is the only place the method is described.

Licence, maintenance and what an upgrade costs you

ripwire is Apache-2.0, with the LICENSE file at the repository root and a badge linking to it. Apache-2.0 includes an express patent grant and requires attribution and notice retention, which matters if you vendor the binary or the install script into an internal distribution. This is a description of the licence text, not legal advice; if you are redistributing it inside a commercial product, read the LICENSE file and THIRD_PARTY.md, since the zero-runtime-dependency claim is backed by that third-party document.

The repository is not archived, and the last push was on 2026-09-10. Releases are frequent and recent: v0.5.0 on 2026-09-08, v0.4.0 on 2026-09-07, and v0.3.8 on 2026-08-13. The gap between v0.4.0 and v0.5.0 is one day, which suggests the version numbers move quickly and that pinning a version matters more here than with a slower-moving tool.

That release cadence is the upgrade cost. With three releases inside five weeks, and a CHANGELOG.md at the root, you should expect the CLI surface and the MCP verb schemas to change between minor versions. The README already warns that MCP schemas occupy agent context every session, so a schema change is not just a rebuild; it changes what your agent sees. Pin the version in your install and read CHANGELOG.md before moving. The README does not document a stability or deprecation policy, and the excerpt does not describe a rollback path.

Editorial conclusion

Adopt ripwire if you run a coding agent over a repository large enough that whole-file reads dominate the bill, and you want an offline binary with no API key, no embeddings and no index server. Do not adopt it if you need a fully documented MCP tool surface, or if your workflow depends on the graph-database MCP server it benchmarks against, since the README only summarises that comparison. Before trusting it, verify three things: that your compiler and platform are covered by INSTALL.md, that the installer's PATH line works in your shell, and that a run against your own repository produces the labelled floors and truncation notices the README promises rather than silent omissions.

Frequently asked questions

Official sources

1. Issues
2. License: Apache-2.0
3. README
4. redhat-et/ripwire on GitHub
5. Releases