MCP integration

Overview — the two servers

Prometheus ships two MCP servers — a code-context engine and an agent memory. They are complementary and most setups run both. Start here, then pick your editor.

Prometheus is two MCP servers, and the default assumption everywhere in these docs is that you run both:

@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, …).
@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.

One stays in the present (the code as it is now); the other 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. You can run either alone, but they are designed to be used together.

The one config you'll reuse everywhere

Both servers register in the same mcpServers block. This block is identical across every editor — only the file it goes in changes (Claude Desktop, Cursor and VS Code each have their own path, covered on their pages):

{
  "mcpServers": {
    "prometheus": {
      "command": "npx",
      "args": ["-y", "@prom.codes/context-mcp@latest"],
      "env": {
        "PROMETHEUS_API_KEY": "<your-api-key>",
        "PROMETHEUS_WORKSPACE_ROOT": "/absolute/path/to/your/repo"
      }
    },
    "prometheus-memory": {
      "command": "npx",
      "args": ["-y", "@prom.codes/memory-mcp@latest"],
      "env": {
        "PROMETHEUS_API_KEY": "<your-api-key>",
        "PROMETHEUS_WORKSPACE_ROOT": "/absolute/path/to/your/repo"
      }
    }
  }
}

Then pick your editor and drop that block into the right file: Claude Desktop · Cursor · Visual Studio Code · Custom (stdio + HTTP).

Configuration reference (read this once)

These four environment variables are everything you need. Two questions trip people up — both are answered here so you don't have to wonder on every page.

Variable	Used by	Purpose
`PROMETHEUS_API_KEY`	both	Beta key (`prom_live_…` / `prom_test_…`), validated at startup. Same value for both servers.
`PROMETHEUS_WORKSPACE_ROOT`	both	Absolute path of the repository to work on. Both servers hash it into the same project identity, so context and memory always agree on what "this project" is.
`PROMETHEUS_DB_PATH`	context	Optional. Override for the local SQLite code index (default `~/.prometheus/<hash>.db`).
`PROMETHEUS_MEMORY_DB_PATH`	memory	Optional. Override for the memory database (default `~/.prometheus/memory.db`).

The two databases are separate files: the code index is per-project and rebuildable, while the memory database is shared across projects and partitioned internally by scope.

What the agent does with both

A typical loop touches both servers:

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.
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.
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.

Run memory_setup once per workspace to install the rule block that teaches a runtime when to recall and capture. For the memory model and the full tool surface see Agent Memory; for the context engine's tools see MCP tools.