Claude Code is genuinely useful. You can hand it a gnarly bug, a half-finished feature, a green-field design question — and it will do real work. Then you close the terminal, open it the next morning, and it has forgotten all of it.
Your stack. The decisions you argued through. The "we tried that, it doesn't work" conversation that saved two days. Gone. You start from zero, and so does it.
This is not a flaw in any particular version of Claude. It is how large language models work. Every session is a blank slate. The only thing that persists across sessions is what you force into the context manually — which is what CLAUDE.md is for. But CLAUDE.md is a static file. It does not grow as you work, does not capture the lesson you learned at 11pm on Thursday, and does not know that last week you decided the jobs table should live in Redis, not Postgres.
What you need is memory that updates itself. The boring, infrastructure-level answer is an MCP server that lets Claude Code write and read from a persistent store. Here is how to wire one up in about 90 seconds.
Why CLAUDE.md alone is not enough
CLAUDE.md works great for stable facts — the language, the framework, the coding conventions that do not change week to week. The problem is the dynamic layer: the decisions, the lessons, the preference adjustments that accumulate over the life of a project.
You can maintain CLAUDE.md by hand. Developers who do this find themselves adding to it after important sessions, which is better than nothing. But it requires you to notice what is worth keeping, remember to write it down before you close the terminal, and keep the file tidy enough that Claude reads the important parts. That is cognition you are spending on infrastructure instead of on the problem.
The alternative is an agent that handles its own memory, the same way an agent handles its own file I/O or terminal commands. It writes a memory when a real decision gets made. It reads memories at the start of a session. The session history becomes an asset that compounds, not a buffer that resets.
MCP is how you give it the tools to do that.
The one-config-block fix
AgentPrizm exposes a memory layer as a remote MCP server — HTTP transport, no subprocess, nothing to install locally. Your MCP client (Claude Code, Cursor, Claude Desktop, Windsurf, or anything else that speaks MCP) connects with a URL and a Bearer key. That is the entire integration surface.
The connection lives inside your MCP config, wherever your client looks for server definitions:
{
"mcpServers": {
"agentprizm-memory": {
"type": "http",
"url": "https://agentprizm.com/api/mcp",
"headers": { "Authorization": "Bearer ap_..." }
}
}
}
For Claude Code specifically, this goes in .claude/settings.json (project-scoped) or ~/.claude/settings.json (global). For Cursor, it is .cursor/mcp.json. For Claude Desktop, it is the claude_desktop_config.json file in your Application Support folder. The JSON block is identical in all three — only the file path differs.
Step by step
Step 1 — Get an API key
Sign up at agentprizm.com/signup. The Hobby tier is free, no credit card, and covers 1,000 memories with 4,500 recalls per month — enough to see exactly what this does before committing to anything.
Once you are in, open the Agents page in the dashboard and create a key. It will be prefixed ap_. Copy it and treat it like a password.
Step 2 — Add the MCP server config
Add the block above to your client's MCP config, replacing ap_... with your actual key. Save the file and restart the client so it picks up the new server definition.
Because this uses HTTP transport rather than stdio, there is no local process to manage. The client talks directly to https://agentprizm.com/api/mcp and authenticates with the header on every request. Nothing running in the background, nothing to babysit.
Step 3 — Verify the tools loaded
In Claude Code, you can ask it to list its available MCP tools, or just ask it to remember something: "remember that this project uses Turso for the database, not Postgres." Watch for a memory_create call in the tool output. If the call goes through, you are connected.
What Claude Code can now do
The MCP server exposes eight tools. You will reach for two of them constantly, and the rest when you need them.
| Tool | What it does |
|---|---|
| memory_bootstrap | Loads owner info, directives, and lessons at the start of a session |
| memory_recall | Semantic search across your stored memories |
| memory_create | Store a new memory — a fact, decision, lesson, preference |
| memory_forget | Remove or supersede a memory, with a reason logged |
| memory_ingest | Extract discrete memories from a conversation transcript |
| memory_ingest_url | Fetch a web page, chunk it, store it as searchable content |
| memory_context | Return a token-budgeted context block ready to inject into a prompt |
| memory_profile | Generate an executive summary across a set of memories |
The workflow that changes things day-to-day is simple: memory_bootstrap at the start of a session pulls in everything relevant — directives, recent lessons, top memories for your containers. As you work, memory_create captures decisions and lessons as they happen. The next session, bootstrap runs again, and Claude Code already knows the things worth knowing.
The full tool reference is in the docs.
A CLAUDE.md snippet that wires this in
You can make the memory habit automatic by instructing Claude Code to use it via CLAUDE.md. Here is the relevant block:
## Memory
This project uses AgentPrizm for persistent memory via the `agentprizm-memory` MCP server.
At the start of every session, call `memory_bootstrap` to load context.
When recalling context for a task, call `memory_recall` with the relevant query.
Save a memory (`memory_create`) when:
- A non-obvious architectural decision is made
- A debugging approach succeeds or fails for a non-obvious reason
- A preference or working constraint is stated or updated
- A gotcha is discovered mid-task
Use container `your-project-name` for project-specific memories.
Use type `lesson` for hard-won discoveries, `fact` for architecture, `directive` for rules.
Adjust the container name and types to match what makes sense for your project. The key habit is "create on decision, not on completion" — you want the memory stored when the reasoning is fresh, not reconstructed at session end.
Going further: containers, types, and governance
The two concepts that keep memory usable at scale are containers and types.
Containers scope memories to a project or context. Tag a memory with payments-service and it will not surface when you are working in auth-service. You can recall across multiple containers when a task spans them. It is routing, not a folder hierarchy — lightweight, and it prevents one project's decisions from bleeding into another's. The solutions page for coding teams has more on how this applies specifically to developer workflows.
Memory types keep the categories small on purpose. There are six: fact (something true about the project), lesson (something learned, usually the hard way), directive (a rule the agent should follow), preference (how you like things done), contact (a person and why they matter), and bookmark (a link worth keeping). Typing a memory is what lets recall prioritize sensibly — a directive outranks a bookmark when the context block is being assembled.
On the governance side: every memory carries an audit trail — where it came from, when, via which agent key. memory_forget is a real deletion operation, not a visibility flag, and every forget logs a reason. Facts support validity windows, so a superseded decision does not contradict a current one; it gets marked expired. For the full picture on what is and is not covered, the pricing page has the tier details, and the docs cover the data model.
One honest note: AgentPrizm is not SOC 2 certified and is not HIPAA-compliant. Do not store PHI or data subject to compliance requirements you have not validated.
For more on the agentic memory problem in general — why context windows are not a substitute, what hybrid recall means, and when to build versus buy — the companion post on setting up a persistent MCP memory server covers the underlying concepts in depth.
FAQ
Does this work with Cursor, Claude Desktop, or Windsurf?
Yes. The config block is the same JSON in every MCP-compatible client; only the file path changes. Any client that supports MCP over HTTP (the type: "http" transport) will work. Claude Desktop, Cursor, and Windsurf all do.
Is it actually free?
The Hobby tier is $0 forever, no credit card required. It includes 1,000 stored memories, 4,500 recalls per month, and 2 containers. That is enough for a real project. When you outgrow it: Builder is $29/month (250,000 memories, 25,000 recalls/month included plus overage, 10 containers) and Scale is $249/month plus usage (1 million memories, 225,000 recalls/month included plus overage). Details on the pricing page.
Where is my data stored?
Memory content and embeddings are stored in AgentPrizm's hosted infrastructure — a VPS running MongoDB with vector search. Data is not sold, not used to train models. Each memory is scoped to your account. If you need to delete everything, the API has a forget endpoint and the dashboard exposes it in the UI.
What happens if the MCP server is unreachable?
Claude Code will surface a tool error and continue without memory context for that session. Nothing breaks — the agent just loses the persistent memory benefit until the connection is restored. Your project files, CLAUDE.md, and local context are all untouched.