Protocol
MCP Memory Server for Claude Code, Cursor, and Codex
Learn what an MCP memory server does, how it connects AI tools to durable context, and how Wenlan keeps that memory local and inspectable.
Article packet
Concepts
Developers and AI power users connecting multiple MCP clients
7 min read
01
MCP servers expose tools, resources, and prompts to AI applications through a standard protocol.
02
A memory server gives clients a way to store, search, recall, and manage durable work context.
03
Wenlan keeps the MCP memory path local, source-backed, and shared across Claude Code, Cursor, Codex, and other clients.
01
Quick answer
If you searched for an MCP memory server, you probably want an AI tool to remember project facts, decisions, preferences, and handoffs across sessions without pasting the same context every time.
Wenlan is the local-first version of that workflow: the daemon owns the memory store, wenlan-mcp is the connector clients launch, and MCP-compatible tools call Wenlan when they need context.
- Use MCP when the memory should be available outside one chat product.
- Use a local daemon when the memory includes private project context.
- Use Wenlan when you also want capture, recall, handoff, provenance, wiki pages, and human-readable artifacts.
02
What MCP adds to memory
The Model Context Protocol gives AI clients a standard way to call external capabilities. MCP servers expose those capabilities; MCP clients are created by host applications such as IDEs or AI tools to talk to particular servers.
For memory, that protocol boundary matters. The AI tool can stay focused on the conversation while the memory server handles durable context, search, and storage.
03
What a memory server should expose
A useful MCP memory server should do more than append notes. It needs a way to capture one durable fact, recall relevant context, list or inspect stored memory, forget stale entries, and diagnose whether the local route is connected.
Wenlan exposes that path through MCP tools around context, capture, recall, distillation, review, forget, and doctor checks. The goal is not a raw database endpoint; the goal is a memory loop agents can use safely during work.
04
Local vs hosted memory
Hosted memory servers are easy to start, but they require sending memory to someone else's infrastructure. Local memory servers take more care, but they keep private project context, preferences, and decisions under your control.
Wenlan is built around the local-first path. The daemon runs on your machine, owns the database, and serves memory to MCP clients through the local wenlan-mcp connector.
05
Install path
Claude Code users should start with the Wenlan plugin because it adds slash commands and setup checks around the same local memory layer. Other MCP clients should run Wenlan setup, then let the CLI add the client-specific MCP configuration.
The commands below are the normal non-Claude Code path for tools such as Cursor, Codex, Claude Desktop, VS Code, and Gemini CLI.
MCP client setup
npx -y wenlan setup
~/.wenlan/bin/wenlan mcp add cursor
~/.wenlan/bin/wenlan mcp add codex
# or: claude-desktop, vscode, gemini06
How Wenlan fits
Wenlan is more than a bare MCP store. It is a local runtime, CLI, MCP connector, and Claude Code plugin that carries work context forward, links related knowledge, detects contradictions, and keeps wiki pages and provenance attached.
The MCP server is the bridge: AI tools read and write memory, while Wenlan keeps the broader work context visible, searchable, and locally owned.
Connect an MCP memory server locally
Install Wenlan, add the MCP connector to your client, and verify capture and recall before trusting memory in real work.
FAQ