Gortex: a codebase graph your coding agent queries over MCP

Your coding agent's biggest cost is not thinking. It is reading. Point one at an unfamiliar repository and watch: grep, open a file, read 400 lines, grep again, open another. Every one of those lines is a token you pay for, and most of them are not the answer. Gortex attacks that directly — it indexes a repository into a knowledge graph and exposes it to agents over MCP, so the agent asks for the three functions it needs instead of reading the neighborhood.

What actually happened

Gortex is an open-source code-intelligence engine published under Apache 2.0 on GitHub as zzet/gortex, currently sitting around 1.8k stars. It parses a repo into an in-memory graph of files, symbols, imports, call chains and type relationships, then serves that graph through four surfaces: an MCP server, a versioned HTTP API, a CLI, and a web UI.

The deployment story is the part we like. It is a single static binary with, in the project's words, "zero external dependencies — single binary, everything in-process." No database to stand up, no service to babysit, no model download to get started. Install is one line: curl -fsSL https://get.gortex.dev | sh, with a PowerShell equivalent on Windows. It runs fully local.

The README claims 257 languages and grammars, support for 19 AI coding agents including Claude Code, Cursor, Windsurf and VS Code/Copilot, and "up to 50× fewer tokens per response."

Two honest notes. That 50× figure is the project's own claim with no published methodology behind it, and "up to" is doing real work in that sentence — benchmark it on your repo before you put it in a budget. And the README quotes its MCP tool count two different ways, 175 configurable in one place and 100+ in another. That is a young, fast-moving project, not a red flag, but plan your pinning accordingly.

Why codebase graphs matter for your agent bill

Context window is not the constraint people think it is. A million-token window does not help if you fill it with files the agent did not need — it just means you pay for a million tokens and the model's attention gets worse. Retrieval precision beats window size, and a call graph is a far better retriever for code than embedding similarity, because code has real edges. Who calls this, what does it return, where is it defined: those are graph queries, not fuzzy matches.

Local and dependency-free is what makes it adoptable. We evaluate a lot of dev tooling. The ones that die in pilot are the ones that need a Postgres, a daemon, and a vendor account before anyone sees value. A static binary a developer runs once is a tool that actually gets used — and for client work under NDA, "no network" is not a nice-to-have.

MCP is the reason this is worth your time at all. Two years ago a tool like this meant an integration per editor. Now it is one server that Claude Code, Cursor and Copilot all speak. That is the portability argument we keep making: build against the protocol, not the product, and swapping your agent stops being a migration.

Measure it before you believe it. Run your agent on a real task with Gortex off, record the token count, then run it on again. If you cannot see the difference in your provider's usage dashboard, the tool is not earning its place. That is true of every agent optimization, this one included.

Sources: Gortex on GitHub, gortex.dev.