Solving multi-session context loss in Cursor without blowing up your prompt tokens (Local MCP workflow)

Showcase Built for Cursor
, ,
1

Hey everyone,

Like many of you, I hit a recurring wall when running long projects with Cursor: the agent forgets architectural decisions between sessions.

The standard fixes usually come with major trade-offs:

  1. Dumping everything into .cursorrules: Your baseline token count explodes before you even type a single line, and the model starts suffering from context dilution.
  2. Vector DB plugins: Often pull outdated code snippets because semantic similarity doesn’t understand when a pattern was deprecated or refactored.

Over the weekend, I built and open-sourced a lightweight, zero-cloud MCP server called OpenContext to solve this deterministically using plain markdown in Git.

How this workflow works in Cursor

Instead of cramming rules into the system prompt, Cursor gets two lightweight MCP tools: read_context and save_context.

  1. Lightweight Index (~100 tokens): Cursor checks an auto-generated topic list and only loads what it actually needs for the current task (e.g., read_context("api-contracts")).
  2. In-place updates: When an architectural invariant changes, the agent updates .opencontext/<topic>.md directly. No hallucinated duplicates in vector space.
  3. Git-native & Transparent: Context lives as plain .md files in your repo. You can review memory updates directly in your Git diffs/PRs or .gitignore them for private local sessions.

Cursor Setup (1 Minute)

Add this to your Cursor MCP settings (Cursor Settings > Features > MCP or your config file):

{
  "mcpServers": {
    "opencontext": {
      "command": "npx",
      "args": ["-y", "opencontext-mcp"]
    }
  }
}

Recommended Agent Instruction

Add this simple rule to your system prompt or .cursorrules:

“Before making structural changes, check available context using read_context. Whenever a new architectural decision or invariant is established, record it using save_context.”

It’s completely free, MIT-licensed, and runs locally over stdio without third-party services.

Curious to hear how others here are managing persistent architectural rules across sessions—are you mostly sticking to custom rules files or experimenting with MCP tools?

7

I’ve found that plain Markdown solves inspectability, but not stale truth by itself. I keep each decision with a stable ID, scope, provenance, and a supersedes link, then require the agent to amend an existing record rather than append a near-duplicate; retrieval filters superseded entries before relevance ranking.

8

Spot on, Edward. That “stale truth” problem is exactly why simple append-only memory patterns eventually break down when codebases evolve.

The way OpenContext currently mitigates this is by scoping context into explicit topics (.opencontext/<topic>.md) with strict in-place rewriting rather than letting the model dump loose append logs. In the current v1.1.0 engine, we force validation and sanitize updates against the existing topic file so changes remain atomic and inspectable in Git diffs.

That said, your ADR-style pattern—specifically stable IDs, provenance, and an explicit supersedes link—is a brilliant mental model. Adding structured frontmatter with supersedes metadata to topics could automate that deprecation lifecycle even more cleanly while keeping the underlying storage plain Markdown.

Are you handling the retrieval/filtering of superseded records via a custom script/MCP tool right now, or how are you enforcing that amendment flow with the model?