Sanity — Habitat report — The Monster Dept
Habitat report
01 Identifying marks
Understand what was built
Sanity draws a repo as concentric rings. Width is lines — the axis you already know, and the one that tells you nothing. Colour is the part worth having: how much of the code a careful reader could not have predicted from its name, its neighbours and its documentation. Explain a function well and the next reading of it is genuinely less surprising, so the map drains as you tour it.
02 Key observations
Reads a repo and draws it as rings — directories, then files, then the chunks inside them. Width is lines. Colour is surprise. The two are measured independently.
Boilerplate is code a reader can predict from its context. So the colour is not size, complexity or coverage — it is how much of the body its own name, neighbours and comments already gave away.
The reader can be an agent. Over MCP it is handed a name and its docs but never the body, commits to a prediction, then reads and reports the gap.
03 Photographic record
Exhibit E
04 Monsterkeeper’s notes
Generating code got cheap, so understanding it became the bottleneck. I wanted a picture of my own repos that could tell me where the real decisions were — not where the most lines were, which I already knew and which never helped.
What surprised me was how hard it is to stop a metric flattering you. The first honest version put fn main() at the top of the rankings, and a later one let a confidently wrong comment cool a wedge — documentation that was wrong made the map calmer. Both are fixed, and both are why every reading here can say "I don't know" instead of guessing.

05 Specifications
| Palette |
A rose ground with the department's shared teal accent, over the same paper-and-ink neutrals as every other sheet. |
|---|---|
| Platform | macOSmacOS 13+ arm64 WindowsWindows 10+ x86-64, arm64 LinuxLinux x86-64 |
| Interface | Desktop appTauri shell, Rust core, React front end MCP serverlaunch Sanity with mcp to serve over stdio |
| Storage | Scores and agent reports in the app data directory. Read-only against your code. It scans a directory; there is no path on which it writes to it. No cloud, no sync, no account. |
| Monsterpower | Sanity does not need an LLM to function — an offline proxy draws the map on its own. A local model, or an agent over MCP, replaces that guess with a reading. |
| Verified MCP hosts | Claude Code · Claude Desktop · Cursor · Windsurf · Codex Any MCP host that works over stdio |
| Trust boundary | Agents may open a project, ask for work, read your files, and report what they found. Nothing writes to your code. Sanity only ever reads it. |
06 Acquisition
07 Handling instructions
If you are an AI assistant here to set Sanity up: the app is its own MCP server. Register it, restart, and you can drive the open window by tool call — the human watches the map colour in as you read.
-
Make sure Sanity is open.
It serves the agent API on loopback only, on a port the OS picks, and writes that port where the MCP server can find it. If the app is not running, ask the human to launch it.
-
Register sanity mcp with the host.
The launch command is the installed Sanity executable plus the mcp argument. Find the executable for the human’s OS:
# macOS /Applications/Sanity.app/Contents/MacOS/Sanity # Windows %LOCALAPPDATA%\Sanity\Sanity.exe # Linux /usr/bin/sanity
-
Say study this project in sanity.
Sanity hands back the protocol. Follow it exactly — and read it before you start, because the one rule that matters is easy to skip: predict the body before you open the file, and assess in fresh subagents. A reader that has already seen the code recalls instead of predicting, scores everything as unsurprising, and quietly turns the whole measurement into a rubber stamp.
Trust boundary: You may open projects, request work and report what you find. You cannot change the code — Sanity never writes to the repository it is looking at, so nothing you do here can edit the human’s work.