Cursor MCP Memory: Persistent Context Setup Guide

Cursor MCP memory is configured through a remote server, not a plugin. Cursor starts every chat with an empty context window, and a single MCP entry gives the agent memory that survives new sessions. Point Cursor at https://memory-mcp.audaxic.com/mcp and authenticate with your project key; the agent then gains five tools for storing and searching facts.

Why Cursor sessions start fresh

Every Cursor chat opens with an empty context window. The editor knows your repository, your open tabs, and your indexed symbols, but it forgets what the last chat decided: the package manager the team settled on, the migration that was rejected, the command that runs integration tests, the header the staging API requires. Close the tab, start a new one, and all of it is gone.

You feel this as repetition. You explain the same constraints, correct the same wrong assumption, and re-derive the same architecture note. The agent is not being careless — it can only reason over what is in front of it. Persistent memory moves those facts into a store that lives outside the conversation, so any session can pull them back on demand. That is the difference between an agent that knows your project and one that relearns it every morning, and it is the same problem behind coding agents forgetting conventions.

Nothing about Cursor is broken here. A context window is working memory, and working memory has a budget: the model holds only so much before older turns are trimmed or summarized. Facts you want to keep need somewhere else to live, which is what a memory layer provides.

Cursor has no Audaxic plugin, and this guide will not pretend otherwise. Cursor MCP memory runs through the remote MCP server, and it takes one configuration entry.

How Cursor MCP memory works

MCP (Model Context Protocol) is the open standard Cursor already uses to connect external tools. Audaxic exposes a single endpoint:

https://memory-mcp.audaxic.com/mcp

It speaks Streamable HTTP, and you authenticate with a project key. The key is an ak_... string created in the dashboard; pass it as a Bearer token in the Authorization header, and the server knows which project's memories to read and write. The MCP overview covers the protocol side if you have not worked with MCP before.

There is no local process to babysit and nothing to install. Many MCP servers are launched per client with npx or a bundled binary; a remote server is reachable from every machine you use and behaves the same on macOS, Windows, and Linux. Point two machines at the same key and they share one memory layer, with no files to sync.

Memories are project-scoped and isolated per organization with namespace-scoped vector search. Project scoping is strict: each key identifies one project, and searches reach only that project's namespace, so a fact from your web app repository does not surface in the platform repository where it is irrelevant. If you work across several repos, create a project per repo and keep the keys separate; if the repos genuinely share conventions, use one project on purpose.

Storage runs on servers in the US and EU, and we never train on customer data. For the architectural context — how this differs from a vector database with a prompt bolted on — see the memory layer comparison.

Add the Cursor MCP memory server to Cursor

Cursor reads MCP servers from .cursor/mcp.json inside a project or from its global MCP settings. Either location works. Use the project file when you want the configuration checked in for a team, and the global file when you want the same memory available in every repository on your machine. If you commit the project file, keep the key out of public repos.

Create the key first. In the dashboard, open Projects, create a project, click View, then Create API Key, and copy the value immediately — it is shown once. Then add the server to your Cursor MCP config:

{
  "mcpServers": {
    "audaxic-memory": {
      "url": "https://memory-mcp.audaxic.com/mcp",
      "headers": {
        "Authorization": "Bearer ak_your_api_key_here"
      }
    }
  }
}

Save the file and reload Cursor, then check the MCP server list. A healthy server appears with its tool list. Two failures account for most broken setups: a missing Bearer prefix before the key, and a key created in a different project than the one you meant to use.

Treat the key like any other credential. It travels in the Authorization header, so it does not belong in a public repository, a screenshot, or a shared document. The project file is convenient for a private team repo; otherwise keep the entry in your global Cursor settings and commit a placeholder instead.

Client-specific variants for Claude Desktop, Windsurf, OpenCode, and Codex live in the MCP setup guide. For your Cursor MCP memory server, the snippet above is the whole configuration.

What the memory tools can do

Once connected, Cursor sees five tools:

The workflow is conversational. Say "remember that we deploy with pnpm, not npm" and the agent calls add_memory. Ask "what do you know about our deploy setup?" and it calls search_memories before answering. You never write the calls; the agent decides when to use them, and you decide what deserves to be stored.

Two notes from practice. There is no update tool in the MCP surface, so correct a fact by deleting it and storing the replacement, or call the REST API's update endpoint from a script. And keep one fact per memory: "Staging requires the X-Env header" retrieves cleanly, while a three-sentence summary of last week retrieves poorly and consumes more of your monthly retrieves. Parameter shapes and response formats are documented in the tools reference.

Worth saving: preferences ("always use pnpm"), decisions with a reason ("chose Postgres over SQLite for concurrent writes"), and gotchas ("the staging build needs JAVA_HOME set"). Not worth saving: temporary debugging state, secrets, or anything that will be false by tomorrow. The agent will not always classify this correctly on its own, so early on, state it explicitly.

MCP is discoverable by design: Cursor reads each tool's name and description when it connects and picks one based on your request. That is why explicit phrasing helps. "Save this as a memory" routes to add_memory; "do you remember our deploy setup" routes to search_memories. Vague prompts leave the tools unused.

Verify recall in a fresh chat

A green indicator only proves the transport opened. Test recall end to end:

1. In a new Cursor chat, ask the agent to remember something specific: "Remember that the release branch is release/2026.09."
2. Ask it back in the same chat: "What is the release branch?"
3. Open a second, fresh chat with no prior context and ask the same question.
4. Optionally, ask Cursor to list memories with get_memories and confirm the fact is there.

The second chat is the real test. Same-chat recall can be satisfied from the conversation itself, but a fresh chat has nothing to draw on, so a correct answer there proves the fact came from the memory server. If the answer is missing, search the project from the dashboard or over the REST API to separate a storage problem from a retrieval problem — that one extra check saves a lot of guessing.

Shared keys deserve one more check. Every client authenticated with the same project key writes into the same namespace, so a memory saved from Cursor is immediately available to a teammate using another MCP client with that key. If you meant to keep two projects apart, verify with a second machine rather than assuming isolation.

When the editor compacts its context to stay inside the window, the conversation gets rewritten, but the memory store is untouched, so facts saved earlier stay available. Compaction stops being a data-loss event; the mechanics match the ones described for Claude Code context compaction.

Costs, limits, and other MCP clients

Hobby is $0 per month: 10,000 adds, 1,000 retrieves, unlimited projects, no credit card. Paid tiers start at $12 per month for 50,000 adds and 5,000 retrieves, and graph memory is included on every plan from Hobby through Enterprise.

Flat monthly pricing means the bill does not move when a busy week produces more adds than usual: there are no per-token fees and no overages on top of the plan. The quota is the limit.

Understand counting before you let the agent save freely. An add request is counted per memory extracted from a message batch, so one call that extracts five facts counts as five adds. Retrieves are tiered: the first ten memories returned count as one request, and each additional ten counts as one more, so a search returning 25 memories counts as three requests.

Two limits to know. Management operations are capped at 100 creates per hour per IP. On the data plane, 100 failed authentication attempts per four hours per IP trigger a 429 with Retry-After; that is a brute-force guard rather than a request cap, so normal traffic will not see it. The REST API also takes a date-based X-Api-Version header, currently 2026-09-25, which is worth pinning if scripts call the API directly.

The same URL and key work in Claude Desktop, Windsurf, and any MCP-compatible client, so nothing here is Cursor-specific lock-in. Claude Code, Codex, and OpenCode have plugins that save and inject memories automatically; Cursor goes through MCP. Either way, one memory layer serves all of them, and facts written from Cursor are the same ones those tools can retrieve.

FAQ

Written by Efe — Sep 25, 2026 · More articles · X @AudaxicTech