# How Strata19 runs URL: /documentation/getting-started/how-it-works ## What it is [#what-it-is] Strata19 is a local MCP server and a local index, one index per repository. Your coding agent calls its tools; the tools answer from the index rather than by reading files into a model. Nothing leaves the machine on the Free Local tier: no account, no uploaded source, no model key, and no network call on any deterministic path. That design has one consequence worth understanding before you use it, because it is the only part of Strata19 that is ever slow. An index has to be built before it can answer anything, and building one over a real repository is minutes of work, not milliseconds. Strata19 does not do that at install time, and it does not do it when you bind a repository. It does it the first time you ask a question that needs it — which means the first genuinely interesting thing you ask is the one that waits. Knowing that in advance is the difference between a tool that looks like it hung and a tool that is doing what you asked. ## How it works [#how-it-works] **Installing registers a server. It analyses nothing.** The host starts `server/facade-stdio.js` as a child process and lists its tools. At this point Strata19 knows nothing about any repository. **Binding resolves a repository, and returns immediately.** When you initialize a project, the server works out which repository it is answering about — an explicit `STRATA19_PROJECT_ROOT`, then a repository named this session, then a workspace root the host declared, then its own working directory — and records it. It also does one cheap pass over the directory tree, without parsing anything, so it can tell you up front which languages in your repository have no analysis backend and will therefore return empty results. That pass is a directory walk; it does not build the index. **The first question that needs the index builds it.** Blast-radius and change-impact questions, the deep implementation-context tier, specbook generation, and the dead-code detector behind verification all require a built index. The first of those calls pays for the build. Subsequent calls do not. **Before it starts, the tool tells you what it is about to cost.** Rather than beginning a multi-minute job silently, the calls that can trigger a cold build quote a preflight estimate first: how many files were seen and in which languages, an estimated wall-clock and peak memory, and — deliberately — the provenance of that estimate. The estimate is a straight-line projection from a single recorded measurement: 36,409 analyzable TypeScript and JavaScript files indexed in 576 seconds, peaking at 3.85 GiB of memory, measured on 2026-07-25. One measurement cannot fit a curve, and the estimate says so rather than presenting a confident number it cannot support. The estimate informs the call. It does not gate it, shorten it, or defer it — the work runs to completion regardless of what the number said. An estimate that could cancel the work would be a timeout wearing a different name. **After the first build, updates are incremental.** The index is keyed by content hash, so a later run re-parses only what changed and skips the rest. On this project's own repository a warm run reports something on the order of dozens of files to parse out of forty thousand candidates. That is why the preflight estimate always states whether an index already exists: the full-build figure is shown for reference, not as the cost of the call you are making. **The index lives in your repository.** It is a SQLite database under `.strata19/` at the repository root. It is local, it is yours, and deleting it costs you the next cold build and nothing else. ## Boundaries [#boundaries] **The estimate is a projection, not a promise.** It is drawn from one data point on one codebase, and it scales wall-clock linearly in analyzable file count while deliberately refusing to scale memory the same way. Treat it as an order of magnitude. **Very large repositories cost disproportionately more.** The sample above is not an upper bound, and repositories well past it have taken substantially longer than a straight line predicts. If your repository is very large, scope the question to a subdirectory rather than assuming the whole-tree figure. **Not every language is analysed.** Files in a language with no implemented backend are walked, counted, and inventoried, but no symbols, calls, or cross-file relationships are extracted from them. Strata19 discloses this on the first call of a session rather than letting you mistake an empty result for a clean one — an empty result for an un-analysed language means nothing was looked at, not that nothing was found. **Nothing here involves a model.** The index, the findings, change impact, and the completion check are deterministic and run without a key. Model-assisted features — drafting, explanations, specbook generation — are a separate surface that reports itself unavailable when no inference route is configured, rather than degrading silently. **A host without hooks has no automatic gate.** Skills and lifecycle hooks come from a host manifest. A client configured by hand gets the tools and none of the automatic behaviour, so verification is something you ask for. ## Related [#related] * [Install the plugin](/documentation/getting-started/install) — the four hosts with a shipped manifest * [Install in any MCP client](/documentation/getting-started/install-mcp-client) — the manual route for every other client * [Your first project](/documentation/getting-started/first-project) — the first real loop, end to end * [Code intelligence](/documentation/plugin/code-intelligence) — what the index can actually answer once it is built * [Local data](/documentation/plugin/local-data) — what Strata19 writes to disk and where * [Verification](/documentation/plugin/verification) — the deterministic completion check