Persistent Memory for
Cursor IDE — MCP Setup Guide

Cursor is the AI-first code editor used by hundreds of thousands of developers — but every session starts with a blank context window. Add the Kronvex MCP server and Cursor will remember your architectural decisions, recurring bugs, and project conventions across every session, forever.

Why Cursor forgets between sessions

Cursor is built on top of Claude, GPT-4o, and other frontier models. It reads your open files, your cursor position, and any context you paste into the chat. But the moment you close the IDE and reopen it the next day — or even start a new Composer session — the slate is wiped clean.

This matters more than it might seem. Consider a typical week of coding:

• You decide to use Zod schemas for all API validation instead of manual checks — and spend 20 minutes explaining why to the AI.
• You discover a subtle race condition in your WebSocket handler and walk the AI through the fix.
• You establish a naming convention for your database migrations and get the AI to follow it.
• You choose Drizzle ORM over Prisma for a specific project and document the reasoning.

None of that survives into the next session. You either re-explain it (expensive) or accept that the AI will suggest contradictory patterns (dangerous). Cursor's .cursorrules file helps for static conventions, but it cannot capture dynamic context — the kind that evolves as your project grows and bugs surface.

The Kronvex MCP server solves this by giving Cursor a persistent, semantically searchable memory store. Every decision, every bug fix rationale, every architectural choice can be stored and automatically surfaced when the AI needs it — across sessions, across days, across your entire project history.

Prerequisites — get your Kronvex API key

Before configuring Cursor, you need two things from Kronvex: an API key and an Agent ID. Both are free and take under 2 minutes to obtain.

Add the MCP server to Cursor

Cursor's MCP server configuration lives in its settings JSON. There are two ways to reach it: via Cursor Settings → MCP in the GUI, or by directly editing ~/.cursor/mcp.json (global) or .cursor/mcp.json in your project root (project-scoped).

The project-scoped file is recommended — it lets you commit the config to version control (with secrets in environment variables) and share the setup with your team.

{
  "mcpServers": {
    "kronvex-memory": {
      "command": "npx",
      "args": ["-y", "@kronvex/mcp-server"],
      "env": {
        "KRONVEX_API_KEY": "kv-your-api-key",
        "KRONVEX_AGENT_ID": "your-agent-id"
      }
    }
  }
}

Replace kv-your-api-key and your-agent-id with your actual values from the dashboard. The -y flag in the args array tells npx to auto-install the package without prompting — Cursor handles the process lifecycle automatically.

After saving the file, restart Cursor. The MCP server will appear as kronvex-memory in Cursor Settings → MCP → Active Servers with a green indicator if the connection is healthy.

Verify the connection

Open Cursor Composer (Cmd/Ctrl + I) and type a quick test prompt:

Store a memory: this project uses PostgreSQL with Drizzle ORM.
All queries must use the db instance from lib/db.ts, not direct SQL.

Cursor's AI will call the Kronvex remember tool automatically. You should see a tool call confirmation in the Composer panel. Then try recalling it:

What database setup conventions does this project use?

Kronvex will surface the memory you just stored, confirming the full loop works. You can also verify in the Kronvex dashboard — the memory will appear in your agent's memory list with a confidence score and timestamp.

What persistent memory unlocks in Cursor

Once the MCP server is running, Cursor's AI has access to four memory tools at inference time. Here is what each one enables in practice.

Remembering architectural decisions

Any time you make a significant technical choice — a library selection, a schema design, a trade-off between approaches — tell Cursor to store it:

Remember: we chose React Query over SWR because we need
optimistic updates on mutations. All data-fetching hooks
should use useQuery / useMutation from @tanstack/react-query.

In future sessions, when you ask Cursor to build a new data-fetching hook, it will recall this decision and use React Query automatically — without you needing to repeat the instruction.

Cross-session bug context

When debugging a complex issue, store the context before you close the IDE:

Remember: the websocket reconnection bug (GitHub issue #142)
is caused by the event listener not being cleaned up in the
useEffect return. The fix must call ws.removeEventListener
before ws.close(). Bug is in src/hooks/useWebSocket.ts.

The next day, you can ask "what was that WebSocket bug we were working on?" and Kronvex will recall the full context — file path, root cause, and fix approach — so you can pick up exactly where you left off.

Project conventions enforcement

Store your team's coding conventions as semantic memories:

• API routes must return { data, error, meta } — never raw objects
• Components go in src/components/ui/ if reusable, src/components/feature/ if feature-specific
• All database migrations must be prefixed with the date: YYYYMMDD_description.sql
• Error boundaries wrap every route-level component

These conventions are stored once and recalled automatically when Cursor is generating code in the relevant context — no need to re-paste them into every session.

Cross-project knowledge transfer

If you work on multiple projects with shared patterns (authentication flows, CI/CD pipelines, logging setups), you can query memories across agents via the Kronvex API or create a shared "infrastructure agent" whose memories all your projects can access via a single KRONVEX_AGENT_ID.

Daily workflow — how to use memory effectively

The highest-value habit is to treat session end as a memory checkpoint. Before closing Cursor, spend 30 seconds narrating what you worked on and any important decisions made.

Store these memories from today's session:
1. Added rate limiting middleware using express-rate-limit.
   Config is in src/middleware/rateLimit.ts. 100 req/15min per IP.
2. Discovered that the email service (Resend) has a 10-second
   timeout. Added retry logic with 3 attempts in src/services/email.ts.
3. Decided NOT to use Redis for session storage — too complex
   for current scale. Using signed JWTs with 7-day expiry.

At the start of the next session, inject context before starting a task:

What do I need to know about this project's authentication
and rate limiting setup before I add a new API endpoint?

Kronvex will surface the relevant memories and Cursor's AI will have full context before writing a single line of code.

The remember / recall loop

You do not need to explicitly invoke memory tools for every interaction. Once the MCP server is connected, Cursor's AI will automatically:

• Call remember when you ask it to store something or when it makes a significant decision
• Call recall when you ask a question about project history or conventions
• Call inject_context at the start of longer Composer sessions to pre-load relevant context

You can also invoke tools explicitly in plain English — "search my memories for anything about the payment integration" will trigger a semantic search against your stored memories.

Tips and troubleshooting

MCP server not appearing in Cursor

If the kronvex-memory server shows as inactive in Cursor Settings → MCP, check the following:

• Ensure Node.js 18+ is in your PATH: node --version in a terminal
• Try running the server manually: npx -y @kronvex/mcp-server — any startup errors will be visible
• Verify your API key starts with kv- and has no trailing spaces
• Check that the JSON is valid — use jsonlint.com to validate your config file

Memory quality — be specific when storing

Vague memories are hard to recall precisely. "We use TypeScript" will match almost anything. "We use TypeScript strict mode with noUncheckedIndexedAccess: true — all array accesses must be guarded" is a high-quality memory with precise retrieval signal.

Use memory types for better retrieval

The Kronvex API supports three memory types. Cursor's AI will use the default type, but you can specify them explicitly when storing:

• episodic — what happened ("we fixed the race condition on 2026-05-03")
• semantic — facts and conventions ("the API always returns ISO 8601 timestamps")
• procedural — how to do things ("to add a new route, scaffold it with the route generator in scripts/generate-route.ts")

GDPR and data residency

All memories are stored in Kronvex's EU infrastructure (Frankfurt, Germany). No data leaves the EU. If you need to delete all memories for a project — for compliance or to start fresh — use the Delete Agent option in the Kronvex dashboard. This permanently removes the agent and all associated memories.