How to Give Cursor Long-Term Memory with MCP

TL;DR

• Cursor starts every session with a blank context window. The agent forgets architecture decisions, conventions, and debugging history the moment you close it.
• An MCP memory server fixes this by giving Cursor a persistent store it can read and write through named tools like remember and recall.
• Simple key-value or vector stores let deprecated patterns resurface and old decisions overwrite new ones.
• Sentra's bi-temporal knowledge graph marks facts invalid instead of deleting them, so Cursor never restates a deprecated pattern as current.
• The setup is a config change to .cursor/mcp.json, not a rewrite. Sentra adds memory to Cursor, and the same graph is shared with Claude, Codex, and your teammates.

Why Cursor Forgets Everything Between Sessions

Cursor starts every session with an empty context window. It can read your open files and your .cursor/rules, but it remembers nothing from the work you did yesterday. The architecture decisions, the conventions you established, the library you ruled out two sessions ago all vanish. That blank slate is not a bug. Large language models are stateless by design, with no built-in mechanism to carry knowledge from one conversation to the next.

Most developers patch this by hand-maintaining .cursor/rules or a CLAUDE.md file, and that approach hits a hard ceiling fast. The practical limit sits around 200 lines before the file becomes unwieldy. Worse, Cursor loads the entire file into every session whether the rules are relevant to the task or not, which burns tokens on context the agent does not need. The file also drifts out of sync with the codebase. You deprecate a pattern in the repo, forget to update the rules, and the agent keeps suggesting the old one.

So you are not fixing forgetfulness. You are giving Cursor a persistent store it can read from and write to across sessions.

What an MCP Memory Server Actually Does

The Model Context Protocol is the open standard Anthropic created to connect AI tools to external capabilities, and Cursor supports it natively. A memory server is one such capability. You add it with a single entry in .cursor/mcp.json, and Cursor can then call it the same way it calls any other tool (varunpratap.com).

A memory server exposes named functions the agent invokes directly. Most servers ship some variant of remember, recall, and forget. When Cursor hits a decision worth keeping, it calls remember to write it to a persistent store. At the start of a new session, a hook calls recall and injects the relevant context before your first prompt, so the agent opens with prior knowledge instead of a blank slate (hindsight.vectorize.io).

A memory server differs from stuffing more text into a file. A .cursor/rules file is static. The agent reads it but cannot update it, and you load the whole thing into every session whether it applies or not. A memory server gives the agent both read and write access to a persistent store, so it pulls only the facts that match the current task. One open-source server injects roughly 1,900 tokens per session against 22,000-plus for loading a full rules file (aibuilderclub.com).

The Problem with Simple Memory Stores: Stale and Deprecated Context

A basic key-value or vector store fails the moment your codebase changes. When you migrate off a deprecated auth library, the old decision still sits in the store as a valid fact. A vector search returns it because it is semantically close to the query, not because it is still correct. The agent reads "we use library X," suggests library X, and you fix the same mistake you fixed last month.

The deeper problem is that simple stores record only what was true, never when it stopped being true. They overwrite or append, and neither handles a fact that was correct in March and wrong by June. Append leaves both versions in the store with no way to rank them. Overwrite destroys the history you need to understand why the change happened.

Token cost compounds the failure. When the store cannot tell the agent what is current, the agent re-crawls the repo on every query to rediscover the truth, and that crawl scales with codebase size. A memory layer that solves this needs bi-temporal awareness. It has to track when each fact became true and when it was invalidated, so a deprecated pattern is marked stale rather than served back as current advice.

How Sentra's Bi-Temporal Knowledge Graph Solves This

Every fact in Sentra's graph carries two timestamps: one for when it became true and one for when it stopped being true. When your team retires a library or replaces an auth pattern, Sentra marks the old fact invalid rather than deleting it. The deprecated convention stays in the graph with a clear end date, so Cursor reads the current pattern as current and treats the old one as history. A simple key-value or vector store cannot do this, because it has no concept of a fact expiring. It stores both the old pattern and the new one as equally valid, and Cursor cannot tell which to follow.

Sentra also resolves meaning when a fact enters the graph, not when you query it. Semantics are resolved at ingestion against a per-organization ontology, so the system already knows what "the burst window" or "ENG-318" refers to before any agent asks. Without write-time comprehension, every request crawls Slack, docs, and the repo again to rediscover what something means. That re-crawling is where token cost compounds. You pay to reconstruct context on each session instead of reading a graph that already understands it.

The benchmark gap is the proof. On the MEME benchmark (KAIST, 2026), Sentra scores 40% on Cascade against a field average of 3%, and 43% on Absence against a field average of 1%, making it the only system above 30% on both. Cascade measures reasoning about what changes when facts update, and Absence measures whether the system notices a fact is missing or invalidated. Both are exactly the failures that surface deprecated code in a coding agent.

None of this replaces Cursor. Sentra is the memory layer underneath it, giving your existing agent context that survives across sessions.

Connecting Sentra to Cursor via MCP: The Setup

Wiring Sentra into Cursor takes a configuration change, not a rewrite. Cursor reads MCP servers from a single file, and once Sentra is registered there, the agent can call memory tools the same way it calls any other MCP function. The steps below are conceptual. Confirm exact server names, environment variables, and authentication against the current Sentra MCP docs before you copy anything, because config keys change as the product ships.

1. Locate `.cursor/mcp.json`. Cursor stores MCP server definitions in this file inside your workspace. If it does not exist, create it. The hindsight-cursor installer writes this file automatically, and the Sentra setup follows the same pattern.

2. Add the Sentra MCP server entry. Register Sentra as a named server with its command, transport, and credentials. Sentra exposes its memory layer over both REST and MCP, so the entry points Cursor at the MCP endpoint and authenticates against your organization's graph.

3. Confirm the connection. Restart Cursor and open the MCP settings panel. A healthy Sentra server shows as connected and lists its available tools, the read and write functions the agent uses to recall and retain context.

4. Verify the agent can call memory tools. Start a session and ask the agent to recall a known fact, then have it retain a new one. If the recalled context appears at session start and the new fact survives into a fresh session, the loop works.

Watch for one known issue. Cursor 3.x has a confirmed bug in the additionalContext channel, the native path for injecting session-start hook output into the agent's system prompt. Cursor staff acknowledged it, and it remained open against 3.6.31 as of the Hindsight writeup. The reliable workaround writes recalled memories to a .cursor/rules/*.mdc file with alwaysApply: true, which Cursor's rules engine injects every session. That file regenerates on each start and lands in .gitignore.

What to Store: High-Value Memory for a Coding Agent

Store the decisions and reasoning that Cursor cannot reconstruct from the code itself. The repository already holds the implementation. What it loses is why you built it that way, what you abandoned, and what you promised to revisit. Sentra organizes this into three layers, and each maps to a question your agent keeps re-asking.

Factual memory holds what is true about the architecture. Record the conventions your team enforces, the patterns you have standardized on, and the libraries you deprecated. When you mark a pattern deprecated, Sentra invalidates the old fact rather than deleting it, so the agent stops suggesting the abandoned approach without losing the record that it once existed.

Action memory tracks open work the agent should respect. Capture the TODO left in PR #4128, the deprecation plan for a legacy module, and the work blocked on an external dependency. The agent reads these before suggesting changes, so it does not reopen a file you already flagged for rewrite.

Interaction memory captures provenance, the part most stores throw away. Record who decided to ship without the burst window, the Linear ticket that descoped it, and the constraint that drove the call. When the agent recalls a decision, it cites the chain instead of guessing.

Skip anything the repository already version-controls and keeps stable. Generated code, ephemeral debug output, and the current state of a file all live in Cursor's workspace context already. Storing them duplicates what Cursor reads for free and pollutes recall with noise.

What Good Looks Like: A Before and After

Picture a developer opening Cursor on Monday to fix a token refresh issue. Without memory, the agent starts blind. It reopens the auth files, re-crawls the repo to infer how sessions are stored, and asks the developer which library handles refresh. Then it suggests jsonwebtoken manual verification, the exact pattern the team deprecated three sprints ago in favor of a managed provider. The developer corrects it, the agent burns tokens reconstructing context it had no way to keep, and the same correction will be needed again next session.

Now run the same task with Sentra wired in over MCP. The agent calls recall at session start and opens with the auth pattern already loaded. It knows the team moved off manual JWT verification, because that fact is marked invalid in the graph rather than sitting alongside the current one. It references ENG-318, the Linear ticket that descoped the old approach, and proposes the refresh fix using the managed provider on the first try.

Same developer, same Cursor, two sessions. The difference is whether the agent reasons from current truth or rediscovers it every time.

Sharing Memory Across Agents and Teammates

The same graph Cursor reads is the one Claude, Codex, and Windsurf read. Sentra stores memory in one org-wide graph rather than a per-tool store, so a convention you teach Cursor during a refactor shows up when a teammate opens Claude the next morning. Point each MCP client at the same memory store with a bankId-style identifier, and every agent draws from and writes to the same source of truth.

The graph also fills from your existing tools, not just from agent chatter. Sentra connects GitHub, Linear, Sentry, and Slack among its 200+ integrations, so a Linear ticket that descopes a feature or a Sentry error that retires a code path becomes a fact every agent can recall. That feed matters because the strongest context often lives outside the editor. A coding agent that knows why ENG-318 shipped without the burst window reasons better than one that only sees the diff.

Sentra is the memory layer under all of them. Each tool keeps doing its job, and they finally share what they learn.

FAQ

Does this work with Cursor's free tier?

MCP support in Cursor does not depend on your subscription level, so the connection to a memory server works the same on the free tier. Sentra connects over MCP regardless of which Cursor plan you run. You get persistent memory without upgrading Cursor itself.

Does Sentra store my code?

Sentra stores decisions, conventions, and the reasoning behind them, not your source files. Sentra does not train models on your data and offers cloud, isolated VPC, or air-gapped on-prem deployment, backed by SOC 2 Type II and ISO 27001. Your repository stays in version control where it belongs.

What happens to memories when a convention changes?

Sentra marks the old fact invalid and records when it stopped being true, rather than deleting it. Sentra's bi-temporal graph keeps both the current convention and the history of what it replaced. Your agent stops suggesting the deprecated pattern while you retain a full audit trail of why it changed.

Does this replace `.cursor/rules`?

No, Sentra complements it. The .cursor/rules file works for stable, project-wide instructions, while Sentra holds the evolving decisions and context that a static file cannot track across sessions. You keep your rules and add a memory layer underneath them.

Which other agents does Sentra support?

Sentra connects to Claude, ChatGPT, Codex, Perplexity, and Windsurf over MCP, alongside Cursor. The same graph one agent writes, every other agent reads. You teach a convention once and every connected agent recalls it.