# A connected memory server can still do nothing in Cursor

**URL:** <https://forum.cursor.com/t/a-connected-memory-server-can-still-do-nothing-in-cursor/171402>\
**Category:** Guides\
**Tags:** mcp, plugins, context, rules\
**Created:** [September 12, 2026, 12:59am UTC](https://forum.cursor.com/t/a-connected-memory-server-can-still-do-nothing-in-cursor/171402 "2026-09-12T00:59:35Z")\
**Posts on this page:** 1\
**Page:** 1

<div class="post-metadata">

**Author:** ![izgorodin](https://sea3.discourse-cdn.com/cursor1/user_avatar/forum.cursor.com/izgorodin/32/117016_2.png) [@izgorodin](https://forum.cursor.com/u/izgorodin)\
**Post date:** [September 12, 2026, 12:59am UTC](https://forum.cursor.com/t/a-connected-memory-server-can-still-do-nothing-in-cursor/171402/1 "2026-09-12T00:59:35Z")

</div>

I connected a memory MCP server to Cursor, saw the green status, and assumed the agent would start remembering. It didn’t.

The connection only gives the agent tools. It still needs an operating rule for when to call them. This is the small loop I use now.

Before project-specific work:

- Recall before choosing a library or pattern, touching tests or commits where conventions matter, or doing anything phrased as “again” or “like last time.”
- Search once with the user’s actual words plus the repository name. If the result is weak, broaden once, then proceed. Don’t turn memory into another agent loop.

After the work:

- Save only a decision that will matter next week, a user correction, a failed approach and why it failed, or an environment fact discovered the hard way.
- Keep one fact per memory, including what, why, when, and where it came from.
- When a fact changes, supersede the old entry instead of deleting it.
- If two entries conflict, surface both with their dates rather than silently choosing one.

Then test the setup in a genuinely new chat. Ask about one project convention without restating it. A same-session answer proves almost nothing.

One extra caveat: writing a correction is storage, not learning. If an old memory was retrieved and caused a bad result, the backend needs an outcome or feedback path attached to that retrieved item. Otherwise the mistake and its correction can both remain eligible next time.

This workflow works with a Markdown memory folder, a local MCP server, or a hosted one. The important part is the loop, not the vendor.

Disclosure: I co-founded Mnemoverse. We published this workflow as a backend-neutral CC0 skill and bundle it with our MIT Cursor plugin:

> **[GitHub - mnemoverse/cursor-plugin: Cursor plugin: persistent Mnemoverse memory over...](https://github.com/mnemoverse/cursor-plugin)**
>
> Cursor plugin: persistent Mnemoverse memory over MCP with OAuth sign-in, plus the agent-memory-discipline rule and skill.

What finally made memory reliable in your Cursor workflow: an explicit rule, a hook, or something else?