How to Add MCP Memory to Any Coding Assistant
Why MCP for Memory
Before MCP, adding memory to a coding assistant meant building a custom integration for each tool. Claude Code had its own API, Cursor had its own extension system, and Copilot had its own framework. If you wanted the same memory across all three, you built three integrations.
MCP standardizes the interface. A memory server exposes tools (store, recall, update, forget) through the MCP protocol, and any MCP-compatible client can call those tools. The server does not care which client is calling it. Claude Code, Cursor, and Windsurf all send the same MCP requests and receive the same responses. This means you invest once in a memory server and get persistent memory across every tool in your workflow.
The tools exposed by a memory server are straightforward. A store tool saves observations, decisions, and patterns with metadata like tags and namespaces. A recall tool retrieves relevant memories based on a query, using vector similarity, cognitive scoring, or both. An update tool modifies existing memories when information changes. A forget tool removes memories that are outdated or incorrect. Some servers expose additional tools for graph traversal, memory status, or consolidation triggers.
Step-by-Step Setup
You have two options: a hosted memory service or a self-hosted server. A hosted service like Adaptive Recall provides the memory server, storage, retrieval algorithms, and dashboard without infrastructure work. A self-hosted server gives you full control but requires you to build and maintain the retrieval pipeline, storage, and server process.
For a self-hosted server, the MCP SDK provides the framework. You need to implement the tool handlers for store, recall, update, and forget, backed by your choice of storage (SQLite for local, PostgreSQL for team, a vector database for semantic search). The minimum viable implementation is about 200 lines of code for basic keyword search, growing significantly if you add vector search, knowledge graphs, or cognitive scoring.
For most teams, a hosted service is the pragmatic choice. The retrieval quality of a memory system depends on sophisticated scoring algorithms (recency weighting, spreading activation, confidence scoring, entity graph traversal) that take significant engineering effort to build well. A hosted service provides these out of the box.
Add the memory server to your project's .mcp.json file for project-specific memory, or to ~/.claude/settings.json for global memory across all projects.
// .mcp.json (project-level)
{
"mcpServers": {
"memory": {
"type": "url",
"url": "https://mcp.adaptiverecall.com/mcp",
"headers": {
"Authorization": "Bearer YOUR_API_KEY"
}
}
}
}
// ~/.claude/settings.json (global)
{
"mcpServers": {
"memory": {
"type": "url",
"url": "https://mcp.adaptiverecall.com/mcp",
"headers": {
"Authorization": "Bearer YOUR_API_KEY"
}
}
}
}In Cursor, open Settings and navigate to the MCP section. Add a new server with the same URL and authentication. Cursor's MCP configuration uses the same format as Claude Code, so the server URL and headers are identical.
When the same memory server is connected to both Claude Code and Cursor, memories stored in one tool are available in the other. A convention you explained to Claude Code in a terminal session is recalled by Cursor when you are editing in the IDE. This cross-tool memory sharing eliminates the need to repeat yourself when switching between tools.
Any MCP-compatible coding assistant follows the same pattern: add the server URL and authentication credentials to the tool's MCP configuration. Windsurf, Cline, Roo Code, and other tools each have their own settings location for MCP servers, but the server configuration is the same. Check each tool's documentation for the specific settings file path.
Use namespaces or tags to keep memories organized. A namespace like "project:myapp" scopes memories to a specific project. A tag like "user:alice" distinguishes individual developer memories from shared team knowledge. This organization lets you share architectural knowledge across the team while keeping personal preferences private.
// Example: storing with namespace and tags
// The assistant calls this automatically:
{
"tool": "store",
"arguments": {
"content": "All API endpoints must validate the X-Tenant-ID header. Missing header returns 403.",
"namespace": "project:myapp",
"tags": ["convention", "api", "security"]
}
}In each tool, ask the assistant to store a test memory: "Remember that we connected the memory server on today's date." Then start a new session and ask "What do you remember about the memory server setup?" If the assistant recalls the test memory, the connection is working. If not, check the server URL, authentication, and MCP configuration syntax.
What Happens Behind the Scenes
When the assistant stores a memory, the MCP server receives the text, extracts entities and keywords, generates vector embeddings, assigns metadata (timestamp, namespace, tags), and persists everything to storage. When the assistant recalls memories, the server receives the query, generates query embeddings, searches for relevant memories using a combination of vector similarity, recency weighting, and entity graph connections, scores the results, and returns the top matches.
The quality of this retrieval pipeline is what separates a useful memory system from a noisy one. Simple keyword matching returns too many irrelevant results. Pure vector similarity misses memories that are related through entity connections rather than vocabulary overlap. Adaptive Recall's cognitive scoring combines base-level activation (how recently and frequently a memory was accessed), spreading activation through entity connections, and confidence weighting from corroboration and contradiction patterns to produce rankings that consistently surface the most useful memories.
One memory server for every coding assistant. Adaptive Recall connects to Claude Code, Cursor, Windsurf, and any MCP-compatible tool with a single configuration.
Get Started Free