MCP Server

The MCP server is the only component AI clients talk to directly. It exposes five operations and nothing else. Everything underneath — the filesystem, the SQLite sidecar, the normalize state — is hidden behind that surface.

The five operations

Operation	Purpose
capture	Append a structured event to the inbox
recall	Retrieve relevant records for a scope or query
reflect	Roll up the current context into a structured summary
status	Surface counts, recent activity, and overdue items
supersede	Replace a stale record with a newer version

Each is a separate MCP tool. Each takes structured arguments and returns structured results. None of them stream.

Why exactly five

The constraint was: every operation that AI clients actually need to perform on memory should be one of these. Anything more specialised happens underneath, invisibly.

• capture and recall are the read/write primitives.
• supersede covers the lifecycle problem of stale memory.
• reflect covers the “summarise this session for me” pattern.
• status covers the “what is happening across my work” pattern.

There is no list, no delete, no update. List is a special case of recall. Delete is supersede with no replacement. Update is supersede with a near-duplicate.

The smaller surface is deliberate. A bigger surface gives clients more rope and gives you more code to maintain in two places.

Server shape

The server is a single long-running process implementing the MCP server protocol. It registers the five tools at startup and serves requests synchronously.

Internally, each operation is implemented as a small handler that:

1. Validates arguments.
2. Opens a connection to the SQLite sidecar (read-only for recall, status, reflect; read-write for capture, supersede).
3. Reads or writes records on disk as needed.
4. Returns a structured response.

There is no shared state between requests. Each request opens what it needs and closes when done. This makes the server easy to reason about and robust to crashes — restarting the server is a no-op except for the brief outage.

Activation tracking

Every recall response is also a side-effect. The server records access events for the records that were returned, into a dedicated table in the SQLite sidecar.

These access events feed the activation calculation: a record that has been recently accessed ranks higher in subsequent recalls. The mechanism is covered in detail in Activation.

The point here is that activation is invisible to clients. They call recall; activation happens automatically.

Why MCP

Two reasons:

• It is the rare AI standard with multiple major clients adopting it. Claude Code, Codex, Cursor, several others. One MCP integration covers all of them.
• Its data model fits. Tools with structured arguments and structured responses map directly onto Cortex operations. There is no impedance mismatch to bridge.

The cost of going through MCP rather than a direct file API is small — one process boundary, one serialisation step. The benefit is that the same server works for every client, with the same operations, with the same results.

What the server does not do

• It does not run normalize.
• It does not run distillation.
• It does not call the LLM directly.
• It does not write to the inbox unless capture is invoked.

The server is read-mostly, write-on-explicit-request. Everything else is some other process’s job.