An AI coding agent spends most of its budget rediscovering a repository it has already read. Hilum replaces that rediscovery with one index it attaches to — resolved structure instead of grep-and-guess.
The problem
Every session starts from zero. The agent greps for a symbol, opens whole files to find out what they contain, follows imports by hand, and reconstructs conventions it was told about yesterday. Then the session ends and all of it evaporates. The next task pays for the same investigation again.
This is not a weak-model problem. It is a missing-substrate problem: the agent has a language model and a filesystem, and nothing in between that knows what the code actually is. So it guesses, and you pay for the guessing in tokens, in latency, and in the regressions that follow a confident wrong answer.
The solution
Hilum Tools is an MCP platform that gives agents structured access to a codebase instead of raw text. One server exposes nine tool domains over the Model Context Protocol; any MCP host — Claude Code, Cursor, Cline, Continue, or your own SDK consumer — connects to the same index.
It is written in Rust: roughly 358,000 lines across ~4,700 source files, on the official Rust MCP SDK, with stdio and streamable-HTTP transports and per-session runtime tool filtering. I designed and built all of it, and it runs daily against a multi-repository workspace — including the one this website lives in.
Nine domains, one server
| Domain | What an agent asks it |
|---|---|
| Code | Project structure, go-to-definition, references, call hierarchy — hybrid LSP + tree-sitter, not regex |
| Find | Budget-aware retrieval: "return exactly enough material to answer X in N tokens" |
| Docs | Current, version-pinned documentation for the libraries actually in the lockfile — private APIs included |
| Memory | One briefing call returns conventions, recent decisions, last-green state, and known pitfalls |
| Graph | The decision graph: why a component works this way, and what an edit puts at risk |
| Lineage | Provenance for a symbol — the pain that created it, the specs it satisfies, how it evolved |
| Setup | Repository onboarding: navigation indexes, marker validation, generated maps |
| Audit | Standing checks over the repo, surfaced as findings rather than a wall of output |
| Agent | Coordination: work queue, claim arbitration, durable mailbox, worker dispatch |
What it changes
- Fewer tokens per task. Retrieval answers to a budget instead of returning the top ten matches and letting the model pay for whatever they weigh.
- Context that survives the session. Decisions, pitfalls and conventions are read automatically and written deliberately; a stale record is archived, not silently deleted.
- Answers that state their own reliability. An empty result distinguishes "nothing matched" from "nothing was searched" — an agent acting unsupervised cannot tell those apart otherwise.
- Parallel agents that do not collide. Ownership is arbitrated where work is handed out, each worker gets an isolated tree, and output outlives the process that produced it.
Built with its own discipline
The architecture is not documented after the fact — it is the input. 191 decision records form a validated graph where a dangling reference fails the build rather than printing a warning, and a change puts its dependants in question automatically.
Underneath sits a normative model of fifteen areas describing how a service should behave when its consumer is an autonomous agent rather than a human: an answer is a claim about its own reliability, and the service is accountable for that claim as much as for the content. The model names no language, no storage engine and no product, and a build guard enforces that portability.
Where the paid line falls
Everything that runs against your checked-out tree is free and works offline — code intelligence, local indexing, memory, lineage, the decision graph, single-host orchestration. The paid tier begins where data crosses to another machine or another team member: hosted sync, shared team memory, fleet coordination.
The boundary is architectural rather than a feature paywall. Your source never enters the sync path; only memory records do, and the index is rebuildable from the tree.
Status
Early access. The product site and the documentation are live, and the distribution repository is public with the installers and the release-signing key already in place — the first signed binaries are the next thing to land. The source stays private under BSL 1.1, converting to Apache-2.0 on 2030-08-01.
Want it pointed at your codebase, or something like it built for your stack? That is what the AI development and AI optimisation engagements are for.