Proposal: Official Memori MCP server for Claude Code / Cursor / Cline

[colygon]

Title: Proposal: Official Memori MCP server for Claude Code / Cursor / Cline (first-class "memory" tool)

Summary

Developers increasingly interact with LLMs through IDE/agent shells (Claude Code, Cursor, Cline), not by importing a Python library directly. Today, Memori integrates by registering against a Python LLM client object. That works great when you control the code making the LLM call, but it doesn’t help when the IDE tool owns the call.

Proposal: ship an official, lightweight Memori MCP server (reference implementation) that exposes recall and remember tools backed by Memori. This makes Memori usable in Claude Code/Cursor/Cline in ~5 minutes, and reduces support load + repeated “how do I use this with X” issues.

Problem statement

• Many tools (Claude Code/Cursor/Cline) own the LLM call, so users can’t wrap the internal client with Memori(...).llm.register(...).
• Users still want persistent memory across sessions and repos.
• Current advice (e.g. “run vLLM”) is often a mismatch for the real need: they want memory integration, not local inference.

Related: #66

Goals

• Enable “time-to-first-success” for IDE tools: store one memory + recall it in <10 minutes.
• Provide a blessed integration path that is:
  • framework/tool agnostic
  • easy to install
  • safe by default (explicit scoping)
  • debuggable (logs + doctor-style checks)

Non-goals

• Replace native SDK integrations for Python apps.
• Store secrets or full codebases by default.
• Provide an always-on hosted service (this proposal is local-first).

Proposed solution

1) Add a new repo package: memori-mcp (or in memori-cookbook initially)

A small MCP server that exposes:

• memori.recall:

  • inputs: query, limit, optional entity_id, process_id, optional session_id
  • output: list of facts/memories (structured)

• memori.remember:

  • inputs: text (or messages), plus scoping fields
  • output: success + stored ids

Implementation notes:

• Uses Memori SDK internally.
• Uses an explicit datastore config (SQLite by default; Postgres/Mongo via env vars).
• Enforces scoping:
  • entity_id defaults to current OS user (or configurable)
  • process_id defaults to repo name (or CWD hash)

2) Provide turnkey setup docs for Claude Code / Cursor / Cline

• Install (pipx/uvx/pip): memori-mcp
• Start server
• Add tool config snippet for each client
• A 2-step verification:
  1. call memori.remember with “my favorite editor is …”
  2. call memori.recall and confirm retrieval

3) Add a “safe by default” memory policy

• Limit what’s stored unless explicitly requested:
  • prefer summaries, decisions, TODOs, user preferences
  • avoid raw file contents unless the user/tool opts in

Alternatives considered

1. HTTP companion service only
   • Pros: universal
   • Cons: worse UX where MCP is supported, more bespoke config
2. Ask IDE vendors to integrate natively
   • Pros: best UX
   • Cons: slow, non-deterministic, and varies by tool

Success metrics

• Reduce/close IDE integration support issues (starting with Any way to use this with Claude Code? #66)
• Add a docs section + reference server such that a new user can reach a passing “remember+recall” demo in <10 minutes.

Open questions

• Where should this live?
  • (A) Memori repo under tools/ or integrations/
  • (B) memori-cookbook as a reference project
  • (C) a new repo: MemoriLabs/memori-mcp
• Preferred configuration mechanism (env vars vs config file)?

I’m happy to help

I can implement the reference MCP server, the docs, and add a minimal “doctor” command or self-test for connectivity.