claim: "project uses PostgreSQL 15"
confidence: 0.95
evidence: [chat_001]
"PostgreSQL 15" ←→ "MySQL"
truth_state: BOTH
PostgreSQL was recorded on Day 1.
Confirm migration before I update.
Cursor never saw Day 1's session. MnemeBrain surfaced the conflict from its persistent belief graph.
How it works
Architecture in 2 minutesCursor supports MCP — the Model Context Protocol — which lets it call external tools mid-session. MnemeBrain connects through this interface: a local backend stores your belief graph, and a lightweight MCP bridge translates Cursor's tool calls into HTTP requests.
Three parts: MnemeBrain backend (FastAPI, runs at localhost:8000, stores your belief graph in a local Kuzu database), MCP bridge (a stdio process Cursor spawns on startup), and Cursor itself, which now has 13 memory tools available in every chat session.
localhost:8000 only.
Install the MnemeBrain backend
One command, stays running in the backgroundInstall the Lite version — a fully local backend with no cloud dependencies:
pip install mnemebrain-lite mnemebrain-lite serve
You should see: Mnemebrain running at http://localhost:8000. Keep this terminal open — it needs to stay running while you use Cursor.
mnemebrain-lite serve & to your shell profile or a startup script so it launches automatically.
Clone and prepare the MCP bridge
The bridge Cursor uses to talk to MnemeBraingit clone https://github.com/mnemebrain/mnemebrain-mcp cd mnemebrain-mcp uv sync pwd # copy this path — you'll need it in the next step
pip install uv. It's a fast Python package runner used by the MCP bridge.
Register with Cursor via mcp.json
Tell Cursor where the MCP bridge livesOpen or create ~/.cursor/mcp.json and add the MnemeBrain entry:
{
"mcpServers": {
"mnemebrain": {
"command": "uv",
"args": [
"--directory",
"/path/to/mnemebrain-mcp",
"run",
"mnemebrain-mcp"
],
"env": {
"MNEMEBRAIN_URL": "http://localhost:8000"
}
}
}
}
Replace /path/to/mnemebrain-mcp with the path you copied from the pwd command in Step 3.
.cursor/mcp.json file inside your project directory and commit it to git. Each project gets its own belief graph.
Verify the connection
Confirm MnemeBrain is live in CursorRestart Cursor, then open Settings → MCP. You should see mnemebrain listed with a green connected indicator and 13 tools.
You can also verify directly in chat:
Check if the MnemeBrain backend is healthy.
Cursor will call the health tool and report back. If you see disconnected, confirm the backend is running (mnemebrain-lite serve) and the path in mcp.json is correct.
Use memory inside Cursor
Patterns for long-running coding projectsStore an architecture decision:
Remember: this project uses FastAPI with async SQLAlchemy. All database access must go through the repository pattern. Never use raw SQL outside the db/ directory.
Cursor calls believe to store three structured beliefs with evidence back to your instruction. Available in every future session.
Retrieve what Cursor knows about your project:
What do you know about our database architecture?
Contradiction detection when things change:
We've switched from FastAPI to Django REST Framework.
Session N: "switched to Django REST Framework"
// MnemeBrain detects the conflict
truth_state: BOTH ← not silently overwritten
belief_1: "FastAPI" confidence: 0.95 → 0.28
belief_2: "Django REST Framework" confidence: 0.92
Cursor: ⚡ Framework conflict detected.
FastAPI was stored in Session 1. Confirming Django migration before updating.
Most retrieval-based memory systems cannot represent contradictions explicitly — they silently overwrite the old fact. MnemeBrain creates an ATTACKS edge, flags truth_state: BOTH, and lets Cursor surface the conflict rather than guess.
What you've built
Cursor now has a persistent belief graph that survives across every session. Architecture decisions, migration history, team conventions, and code patterns are stored, tracked for contradictions, and retrieved semantically — exactly when relevant.
Typical belief lookup is <5ms on a local Kuzu store with ~100k beliefs. Everything runs on your machine.