MemoryRouter
All posts

Persistent Memory for Cline: Keep the Memory Bank, Recover the Reasoning

John Rood··5 min read

A fresh Cline task opens and reads your Memory Bank. The brief matches where the project actually is, activeContext.md knows what was in flight, and the pattern notes are still true. Then it asks why the retry worker uses exponential backoff.

You know why. You worked it out nine days ago, between two designs you rejected, in a conversation that ended without anyone writing it down. The files kept the outcome. The reasoning left with the task.

That is not a flaw in the Memory Bank. It is what documentation is. A bank holds what somebody decided was worth writing and keeping current, which is exactly why it deserves trust. The rest of a working week does not look like a document. A rejected approach, a constraint that surfaced mid-debug, the reason an obvious design would have fallen over in production. Those live in conversations, and conversations close.

Keep the bank, add a searchable layer

The instinct is to push more into the bank. That trade is bad. A reviewed document and an append log are different artifacts, and the review is the property that makes the bank valuable. The conversational layer deserves its own home: something searched at the moment a task needs it, not a file tree that has to grow.

For Cline, that home plugs in over MCP. Cline supports remote MCP servers with OAuth, and MemoryRouter runs one, so the whole connection is a single entry in cline_mcp_settings.json:

{
  "mcpServers": {
    "memoryrouter": {
      "type": "streamableHttp",
      "url": "https://mcp.memoryrouter.ai/mcp"
    }
  }
}

Open it from Cline's MCP Servers icon under Configure MCP Servers, or edit the file directly. Cline notices the server needs authentication, opens a browser tab, and you sign in and choose which vault the connection uses. No API key sits in the config, and the connection can be revoked from your dashboard at any time. The entry works globally, or scoped to a single project.

The MCP documentation covers the server and its tools, and the Cline page walks through the same setup end to end. If you would rather route Cline's inference through the vault than connect memory tools, the coding tools guide documents that configuration too.

Once connected, three tools appear in Cline's MCP panel: search_memories for recall, store_memory for deliberate saves, and date_search_memories for time-window questions. Each one gets its own approve or auto-approve toggle.

Model-directed, so the ask matters

The connection is model-directed, not an automatic hook. Cline calls the memory tools when it judges they will help, the same way it decides when to use any other MCP tool. That makes one habit decisive: when a task depends on something from before, say so. "Check memory for the retry worker decision, then continue the refactor." When you explain a constraint worth keeping, say remember. A tool nobody asks is indistinguishable from no tool at all.

The reason to keep memory outside any single client shows up the first time you change tools. The same vault works from Claude Code, Cursor, ChatGPT, or anything else you connect it to. Store a decision in Cline and the next tool can recall it. Store it somewhere else and Cline gets it back.

Prove it with one throwaway fact

Before real decisions go in, run the wiring test on something synthetic. Ask Cline: "Store this in MemoryRouter: the demo app's retry worker uses exponential backoff because fixed intervals caused bursty retries." Approve the call, then read the tool result. No store_memory call means nothing was saved, whatever the reply text says.

Then open a fresh task with nothing carried over and ask: "Check memory: what retry strategy does the demo app's worker use, and why?" A working path shows the search call and both halves of the answer, the exponential backoff and the bursty retries that killed the fixed interval version. If it comes back empty, check two things: that you authorized the vault you meant to, and that the server is enabled in Cline's MCP panel.

Extend the test once. Connect a second tool to the same vault and ask the same question there. An answer showing up in a tool that never saw the original task is the reason the vault sits outside any single client.

What this does not do

  • It does not replace or edit your Memory Bank. Your files stay yours, nothing syncs into them, and the vault is a separate layer that gets searched.
  • It does not import your old conversations. Bringing prior history in is its own workflow; this connection covers everything from now on.
  • It is not a per-repo boundary. One connection authorizes one vault and the memory tools take no project argument, so hard separation between projects means separate vaults.
  • It is not passive capture. Entries arrive through store_memory calls, not from recording everything you do.

Your repo holds the code, the Memory Bank holds the documentation, and the reasoning behind both evaporates when the task ends. Give it one home. Create your MemoryRouter account, paste the server entry into cline_mcp_settings.json, and let tomorrow's first task start already caught up.

All posts