Overview — all three servers

prom.codes is three MCP servers. Two of them — context and memory — are the everyday pair (most setups run both); the third is a one-shot installer you add on top.

• @prom.codes/context-mcp answers "what does this codebase look like?" — it indexes the workspace and serves grounded code retrieval (search_code, find_references, expand_context, …). See Code context engine.
• @prom.codes/memory-mcp answers "what did we already learn, decide and agree on?" — durable facts, decisions and procedures that survive context-window resets and agent restarts. See Agent Memory.
• @prom.codes/saver answers "why is this agent burning tokens narrating itself?" — a one-shot installer that writes an efficient-output rule block into your runtime so the agent spends fewer tokens on its own prose while keeping code, commands and context verbatim. Pure JS (no database, no embeddings, no native modules), no API key. See Token Saver.

Context stays in the present (the code as it is now); memory carries the past forward (the conventions and decisions behind it). Together the agent can ground a change in the real call sites and remember the team's rules about how that change should be made.

Install

All three install with one command each in Claude Code — see Install for Claude Code for the canonical commands. Cursor and VS Code use the same JSON shape in their own config files.

You need one prom_live_… key (mint it at /app/api-keys) for context and memory; the saver needs no key.

What the agent does with them

A typical loop touches context and memory:

1. Recall first. At session start the agent calls memory_read (or memory_search) to pull the project's conventions and prior decisions — "use pnpm test:int for integration tests", "the billing module owns retry logic". The memory server returns a token-capped markdown block ready to drop into the prompt.
2. Retrieve code. When it needs the actual implementation it calls search_code / find_references / expand_context against the context engine to find the real symbols and call sites — no hallucinated names.
3. Capture at the end. After finishing, the agent calls memory_capture so the session's plan, outcome and any new facts become durable memory for next time.

The token saver sits outside this loop: its one setup tool installs an efficient-output rule block once, and from then on every turn the agent writes is leaner — without touching what it retrieves or remembers.

Environment-variable reference

These are the variables that matter day-to-day — the specialised tuning knobs live on each server's own page (Agent Memory has the full memory matrix). All are optional except the API key for context and memory — workspace root and DB paths are auto-detected.

Where your data lives locally

Everything is plain SQLite under one folder in your home directory, so you can open it with any SQLite viewer (sqlite3, DB Browser for SQLite, …):

The code index never leaves your machine and is safe to delete — it rebuilds on the next run. The server prints the resolved root and db path to stderr at startup (… workspace=… db=…). Quick peek:

sqlite3 ~/.prometheus/memory.db '.tables'
ls -la ~/.prometheus/