MCP toolsCursor

Cursor

In Cursor’s Agent mode, Mnemosyne becomes the long-term memory of your codebase. The agent can remember “we decided to use Drizzle, not Prisma, because of the bitemporal SQL we write”, and recall it months later when considering a migration.

Open Cursor settings

Cmd ⌘ + , → search “MCP” → Add MCP server.

Configure

{
  "name": "mnemosyne",
  "command": "npx",
  "args": ["-y", "@mnemosyne/mcp"],
  "env": {
    "MNEMO_URL": "http://localhost:3000",
    "MNEMO_KEY": "mns_live_xxx"
  }
}

The workspace is derived from the API key, so use a different MNEMO_KEY per repo — that way each codebase gets isolated memories.

Verify

In an Agent mode chat, ask:

“What MCP tools do you have available?”

You should see the Mnemosyne tools, including memory_recall, memory_remember, memory_forget, memory_pin, memory_timeline and the rest of the 26-tool surface. If not, restart Cursor.

How the agent uses it

Cursor’s Agent mode is good at deciding when to call tools. Typical behaviour:

  • Before suggesting a refactor, it memory_recalls prior decisions about patterns.
  • After finishing a task, it memory_remembers the strategy used.
  • When it spots a stale fact in the codebase, it memory_forgets the old one and stores the new one.
💡

Per-repo memory is the killer pattern. Each repo gets its own MNEMO_KEY (and therefore its own workspace). The same Mnemosyne instance serves many repos without cross-contamination because RLS isolates at the database level.