[FEATURE] Allow MCP servers to replace auto memory backend
Preflight Checklist
- [x] I have searched existing requests and this feature hasn't been requested yet
- [x] This is a single feature request (not multiple features)
Problem Statement
Auto memory instructions live in the system prompt. MCP server instructions have lower priority. Agent follows system prompt, ignores MCP memory tools.
Users must choose:
- Auto memory on: MCP memory tools unused
autoMemoryEnabled: false: no context at session start- CLAUDE.md overrides: system prompt still wins
Every MCP memory server hits this. Related: #41283, #46050, #41473.
What happens today
- User installs a memory MCP server alongside Claude Code
- Auto memory instructions (in the system prompt) tell the agent to use
Write/Editon MEMORY.md - MCP server instructions (lower priority) tell the agent to use
memory_store/memory_search - Agent follows the system prompt. MCP memory tools go unused.
- User adds "use rekal, not auto memory" to CLAUDE.md. Helps sometimes, ignored other times.
- User sets
autoMemoryEnabled: false. No memory loads at session start. Cold starts every time.
There is no winning configuration. Either auto memory competes with the MCP server, or the user loses context injection at session start.
Proposed Solution
A setting that delegates memory to an MCP server:
{ "memoryProvider": "mcp:rekal" }When set:
- Session start: call MCP tool, inject result where MEMORY.md content goes
- Replace auto memory prompt with MCP server's instructions at same priority
- Built-in auto memory stays default when unset
Smaller alternative:
{ "autoMemoryStartupTool": "mcp__rekal__memory_build_context" }Call one MCP tool at session start, inject result, suppress auto memory write instructions. One branch in the memory orchestrator.
Alternative Solutions
Tried, all break:
- CLAUDE.md "don't use auto memory": system prompt priority wins
autoMemoryEnabled: false: no context injection at session start- Hooks injecting
additionalContext(memora's approach): fragile across versions autoMemoryDirectoryredirect: format mismatch, write conflicts
Priority
Low - Nice to have
Feature Category
MCP server integration
Use Case Example
I maintain rekal, an MCP memory server with hybrid search (FTS5 + vector + recency).
Step 1: Start Claude Code in a project with rekal configured as MCP server.
Step 2: Agent begins work. It should call memory_build_context to load relevant cross-session knowledge. Instead it reads MEMORY.md because the system prompt says to.
Step 3: Agent discovers a non-obvious debugging insight. It should call memory_store with deduplication. Instead it writes to MEMORY.md because the system prompt says to.
Step 4: Next session. Agent needs to recall that insight. It should call memory_search. Instead it reads the flat file. No search, no ranking.
With memoryProvider set:
- Step 2 calls the MCP tool, result injected at session start automatically
- Step 3 calls
memory_store, deduplicates against existing knowledge - Step 4 calls
memory_searchwith hybrid ranking across all past sessions
Same UX as auto memory. Better backend. No conflicting instructions.
Additional Context
- rekal: MCP memory server with hybrid search (FTS5 + vector + recency)
- memora: MCP memory server with knowledge graphs (uses hooks as workaround)
- The memory orchestrator already branches on
autoMemoryEnabled. AmemoryProviderbranch before existing logic is a contained change. autoMemoryDirectoryalready redirects storage path; this extends it to storage mechanism.- Fixes the problem for every MCP memory server at once.
Showing cached comments. Read the full discussion on GitHub ↗
5 Comments
Found 3 possible duplicate issues:
This issue will be automatically closed as a duplicate in 3 days.
🤖 Generated with Claude Code
None are duplicates. All three are bugs about MCP tools not working. Mine is a feature request for a memory provider abstraction.
Closing for now — inactive for too long. Please open a new issue if this is still relevant.
Fellow MCP memory server maintainer here, and we ran into this exact wall.
I maintain piia-engram (another memory MCP) and usually run it alongside Claude Code, Codex, and Cursor on the same machine at once. That multi-client setup is what turns the system-prompt priority issue from an annoyance into a real blocker.
One angle I haven't seen called out yet: auto memory is per-tool. Claude Code has its MEMORY.md, Codex has its own store, Cursor has its own. So even when auto memory works perfectly, your memory still lives in three silos that never see each other. The one thing that can be the shared layer across all of them is an external MCP server, which is exactly what the system prompt tells the agent to skip.
So for us it isn't "auto memory vs our backend, pick the better one." It's that auto memory actively fragments the exact thing we're trying to unify. That's why I'd personally bump this above "low / nice to have".
On the two proposals: the smaller autoMemoryStartupTool would already get most of the way there. Session start is where the agent reliably does what you tell it. Once the startup read isn't fighting MEMORY.md, the write side is mostly steerable through tool descriptions. If a full memoryProvider is a big lift, the one-tool startup hook is a solid first cut.
And yeah, CLAUDE.md didn't cut it for us either. We tried it too; the system prompt wins often enough that you can't rely on it.
Full disclosure: I maintain Data Olympus, a git-native governance knowledge base plus MCP server for coding agents: https://github.com/knaisoma/data-olympus
Strong +1 on allowing an MCP server to participate as a real memory/governance backend rather than competing with built-in MEMORY.md behavior from lower-priority tool descriptions.
The distinction I would add is that not every memory backend should be treated as the same kind of memory. For agent coding workflows, we have found it useful to keep a separate class for reviewed project knowledge: accepted standards, architectural decisions, migration notes, superseded rules, and "this is the pattern this repo follows" guidance.
That class wants a few properties that normal auto-memory usually does not have:
status,supersedes, andsuperseded_by;in_forceread mode so retired guidance is retained for history but excluded from governing retrieval;From that perspective, a
memoryProviderabstraction would be most useful if it could express capability and intent, not only "call this startup tool." For example: personal memory, episodic session recovery, shared team memory, and governed project knowledge are different stores with different trust rules. Data Olympus is deliberately in the last bucket.The practical integration shape I would want from Claude Code is: at session start and after compaction, call the configured provider for project-governing context; during work, allow query-time retrieval by topic; for writes, let the provider return proposed updates that require explicit promotion before becoming durable knowledge.