Cursor MCP Memory Bank: Keep Context Between Sessions

A Cursor MCP memory bank is a project record that Cursor reads and updates through an outside tool connection. You can also keep memory in ordinary project files; Cursor rules tell the assistant how to use either approach. Tools like fenbs keep shared tasks, decisions, and progress outside the editor so the work remains available when the next session uses a different assistant.

MCP means a standard way for an AI app to use an outside tool. It provides a connection, while the connected service provides storage. Begin by deciding what should survive the conversation and where its current version belongs. Installing several memory servers will not resolve contradictory project notes.

How do you start with a small, useful memory bank?

1. Choose one active project and write its goal in a short overview. Include the parts of the code or documents that explain the work, rather than pasting every file.
2. Write a current-state note: what is complete, what was checked, what is still uncertain, and the next action. A folder such as memory-bank is your own convention; its name does not make files load automatically.
3. Choose a home for each record. Keep code-specific reference material beside the code and put shared decisions and task progress in the service your team maintains.
4. Add a short Cursor rule directing the assistant to read the current record before work and save progress afterward. Test it in a fresh conversation before adding more material.

For example, a developer repairing a contact form could save that the UI change is complete but email delivery has not been tested. The next session should recover that distinction immediately. A summary saying the contact form is fixed would hide the only remaining action that matters.

The broader idea of a maintained project record is covered in AI memory banks. This setup focuses on the daily Cursor loop: find the right project, read its current state, do a bounded piece of work, and leave an accurate handoff.

What belongs in rules instead of memory files?

Use rules for stable operating instructions, such as where to read progress and what evidence to save. Use the memory record for changing facts, such as the latest test result. Putting every session summary into a rule makes the instructions grow while making yesterday’s unfinished work look permanent.

Cursor’s rules documentation↗ (opens in a new tab) describes project rules as .mdc files in .cursor/rules, with metadata controlling when they apply. An always-applied rule is useful for a short starting instruction. The following is a suggested local-file workflow, not a special memory feature or a required folder structure.

---
description: Read and maintain project progress
alwaysApply: true
---
Before work, read memory-bank/current.md and the sources it names.
Explain the next step and any conflicting information.
Treat proposals as proposals until a person approves them.
Before stopping, update current.md with completed work, checks,
open questions, and the next action. Do not store credentials.

For a connected service, replace the file instruction with the actual project and reading action that service provides. Keep only one authoritative handoff. In fenbs, the project context supplies Rules and Where we left off, as explained in how it works.

How do you connect storage through MCP?

Pick storage before writing a configuration. Ask where its data lives, how you correct it, which people can read it, and whether it records who changed it. A local experiment and a shared team record have different requirements. Our guide to agent memory over MCP explains those storage choices.

Cursor’s MCP documentation↗ (opens in a new tab) supports project configuration in .cursor/mcp.json and user-wide configuration in ~/.cursor/mcp.json. Use the provider’s documented connection details and authentication method. This example uses fenbs, whose connection is a remote URL followed by a browser sign-in.

{
  "mcpServers": {
    "fenbs": {
      "url": "https://fenbs.ai/api/mcp"
    }
  }
}

1. Add the documented server in Cursor and complete its sign-in. Check that the connection is enabled and the tools are available.
2. Ask the assistant to identify the intended project and read a small known record. Confirm the result yourself before granting it writing work.
3. Keep tool approval enabled while testing. Cursor documents approval before MCP tool use by default; inspect the arguments before allowing a change.
4. Create one harmless test entry, then retrieve it again. Verify it appears in the expected project and that you can correct or remove it through the storage service.

If your existing task system already supplies the needed record, connect that rather than maintaining another copy. The separate guides for ClickUp in Cursor and Jira in Cursor cover those services’ setup details.

How do you prove the memory survives a fresh session?

Save a short test handoff and close the conversation. Start a new one with only the instruction to continue the named project. Ask the assistant to explain the current state, identify its source, and name the next step before editing anything. Compare the answer with the actual record.

• Does it choose the correct project rather than another project with a similar name?
• Does it distinguish a completed change from a check that has not run?
• Does it recognize an open question instead of inventing an approval?
• Can it point to the source of the decision governing its next action?

Correct the record if the source is vague; correct the starting instruction if the assistant never read it. These are different failures. fenbs supports this transition through Where we left off and AI handoffs, but the next assistant still needs to read the saved context.

What causes a memory bank to become unreliable?

The common problem is two records claiming to be current. A local note says approval is pending while a connected task says it was granted. Assign one home for that answer and link to it elsewhere. If the records disagree, ask the person responsible rather than allowing a confident summary to settle the conflict.

Another problem is storing conclusions without evidence. A handoff saying all checks passed needs to say which checks ran and what they covered. A copied suggestion should remain labeled as a suggestion. Keeping that distinction prevents an abandoned idea from becoming an instruction in the next session.

Finally, test failure behavior. Disconnect the server or point your test instruction at a missing note. The assistant should report that it cannot recover the saved state and ask for the missing source. It should not reconstruct project history from guesses and then save those guesses as facts.

How to do this with fenbs

1. Create a free account, free for one person with no credit card, and add one active project.
2. Add the task you want Cursor to continue. Record the human-approved decisions and rules, plus the remaining checks and any source references.
3. Follow the Cursor guide in Integrations and complete the browser sign-in. Ask Cursor to read the project context and explain where it will start.
4. After the work, ask it to save task progress and the project’s Where we left off. Start a fresh session and check that it recovers the same next action.

fenbs does not import your Cursor chat history. If your goal is a private local record beside one codebase, ordinary files may be the better fit. fenbs is useful when tasks, decisions, and handoffs need a shared home beyond that editor.

What should you save before stopping work?

Save the result, the evidence, and the next action. For the contact form, that might mean the revised fields are implemented, the build check passed, and delivery still needs a real test. Name any person whose approval is needed. Leave out raw credentials and conversation details that do not change the next step.

Review that handoff before ending the session. A short, correct record is more useful than a long recap that blurs completed and unverified work. Explore the memory tools library if you need a different storage approach after testing this loop.