memorybridge
MemoryBridge provides a shared, persistent memory layer for MCP-compatible AI tools (e.g., Claude Code, Cursor, Windsurf, Gemini CLI), storing project context in a local Markdown file (.ai-memory.md) to eliminate re-explaining across sessions — no cloud, accounts, or telemetry required.
Core tools:
memory_load: Loads session memory. Call without arguments for a header/summary, or pass asection(e.g.,preference,decision,issue) to retrieve specific context.memory_save: Persists durable information. Requirescontent(the memory text) andcategory(one ofpreference,decision,issue,resolved,env,note,map). Optionally setscopetoproject(default) orglobal.memory_search: Queries stored memories using aquerystring, returning up to 10 relevant matches.
Additional capabilities:
Cross-tool memory sharing: A single
.ai-memory.mdfile is accessible by multiple AI tools, ensuring consistent context across environments.Memory versioning: Snapshot, diff, and roll back memory changes.
Code symbol extraction: Save extracted code exports (JS/TS/Py/Go) to improve AI understanding of project structure.
Config generation: Emit AI-specific config files (e.g.,
AGENTS.md,CLAUDE.md,.cursorrules) from the central memory source.Cross-project search: Search memories across all indexed projects.
System diagnostics: Verify installation, paths, token budget, and scan for installed AI tools.
MemoryBridge — Cross-Tool AI Memory for Claude Code, Cursor, Antigravity & every MCP-compatible AI
One file. Every AI. 400 tokens, not 4,000.
MemoryBridge is an MCP (Model Context Protocol) server that gives every AI coding tool you use — Claude Code, Cursor, Google Antigravity, Windsurf, Gemini CLI, Continue.dev, VS Code Copilot, Claude Desktop — a shared memory of your project. One Markdown file (.ai-memory.md) lives in your project folder. Every AI tool reads it on session start. You stop re-explaining your stack, decisions, and known bugs every time you start a new chat.
Why it matters: developers on $20/month AI plans burn through their quota re-pasting project context. MemoryBridge cuts that overhead by ~94% on input tokens and up to 75% on output tokens (with the built-in response-style toggle). On a Sonnet-class model at heavy usage, that's $50–$100/month back in your pocket.
📑 Table of contents
Related MCP server: Cortex
⚡ Quick install
npx memorybridge initThat's it. The installer auto-detects your AI tools and wires memorybridge into each one's MCP config. Restart your AI tool and you're done.
Currently you can run from source while we finalize the npm publish. See Manual install.
📖 Step-by-step guide (first time using MemoryBridge)
If you've never used an MCP server before, follow these eight steps. Total time: ~5 minutes.
Step 1 — Prerequisites
You need:
Node.js 20 or newer (download) — check with
node --versionAt least one MCP-compatible AI tool installed: Claude Code, Cursor, Google Antigravity, Windsurf, Gemini CLI, Continue.dev, VS Code (+ Copilot), or Claude Desktop
That's it. No Docker, no databases, no API keys.
Step 2 — Install MemoryBridge
Option A — npx (recommended, when published to npm):
npx memorybridge initOption B — Clone and build from source (right now):
git clone https://github.com/IamRamgarhia/memorybridge.git
cd memorybridge
npm install
npm run build
node dist/cli.js initYou'll see output like:
=== MemoryBridge Init ===
Configured:
[✓] Claude Code added ~/.claude.json
[✓] Cursor added ~/.cursor/mcp.json
Next steps:
1. Restart your AI tool(s) so they pick up the MCP config.
2. cd into a project, then run: memorybridge add "<your first memory>"Step 3 — Restart your AI tool
This is required. AI tools read their MCP config only on startup, so quit (fully close) and reopen Claude Code, Cursor, or whichever tool you use.
Step 4 — Verify it's working
Open your AI tool, then ask:
"What MCP tools are available to you?"
You should see memory_load, memory_save, and memory_search in the list. If you don't, run memorybridge doctor from your terminal — it'll diagnose the issue.
Step 5 — Use it normally (the AI saves automatically)
Open any project folder in your AI tool. Tell it something durable about your project:
"This project uses Supabase for auth instead of NextAuth. Remember that."
The AI will call memory_save and persist this to .ai-memory.md in your project folder. You can verify:
cat .ai-memory.mdYou'll see:
## @decisions
- [2026-05-28] Auth chosen: Supabase over NextAuthThat's it — MemoryBridge is now active. Every future session in this folder, regardless of which AI tool you use, will start by reading this file.
Step 6 — See what you've saved
Three ways to look at your memory:
memorybridge open # opens .ai-memory.md in your default editor
memorybridge list # CLI listing of every entry
memorybridge load # exactly what the AI sees on session start
memorybridge settings # one-page dashboard with everythingStep 7 — Tune for max token savings
memorybridge shorter # cut AI response length (saves output tokens)
memorybridge style 1 # jump straight to "ultra-terse" (~75% output saved)
memorybridge savings # see real measured + estimated savings
memorybridge compare # side-by-side before/after with $ math
memorybridge dashboard # open the visual web dashboard in your browserOutput tokens cost 5× more than input tokens, so the style toggle is the biggest dollar saver. Start at level 3 (balanced) and tighten if you want shorter answers.
The dashboard command opens a full HTML report in your default browser — charts of token activity over the last 30 days, every project's memory file, $ saved per model tier, and the recent activity log. Refresh by running the command again any time.
Step 8 — Roll back or uninstall anytime
Undo a bad save (preserves every snapshot):
memorybridge undo # restore the previous version
memorybridge log # see snapshot history with timestamps
memorybridge diff 3 # diff current vs 3 snapshots agoUninstall cleanly (preserves your .ai-memory.md files in projects):
memorybridge uninstall # remove MemoryBridge from all MCP configs
memorybridge uninstall --purge # also delete ~/.memorybridge/ folderAfter uninstalling, your project's .ai-memory.md files are still there — they're your data, not ours. Delete them manually if you don't want them.
🎯 The problem MemoryBridge solves
Every AI tool forgets your project the moment a session ends:
Vibe coders re-paste "this is a Next.js app using Supabase…" every single session
Pros switching between Claude Code and Cursor start over from zero each time
Teams lose architecture decisions because nothing remembers them between hires
Users on cheaper plans burn their token quota explaining context the AI already heard yesterday
21+ frameworks exist to solve this. None work across every tool, are free, and small enough to run locally. MemoryBridge is.
✨ What you get
Feature | What it does |
🧠 Cross-tool memory | One |
⚡ Token frugality | Default |
🎚 Response-length toggle | 5 levels — ultra-terse to verbose — controls AI output size, your biggest $-saver |
📁 Project-local file | Memory lives in your project folder, travels with your repo, can be Git-versioned for team sharing |
🛡️ Safe writes | Banner + SHA-1 hash protection — refuses to overwrite hand-written |
↩️ Memory undo | Every save is snapshotted. |
🔀 Universal emitter | Generate |
🔍 Cross-project search |
|
📊 Real savings dashboard |
|
🗺️ Symbol extraction |
|
🔒 Zero cloud, zero accounts | Everything is a local file. No telemetry. No vendor lock-in. |
↪️ Clean uninstall |
|
🆚 How it compares
Mem0 | CLAUDE.md | basic-memory | ChatGPT Memory | MemoryBridge | |
Works across all AI tools | ❌ | ❌ | ⚠️ | ❌ | ✅ |
Zero setup | ❌ | ⚠️ | ⚠️ | ✅ | ✅ |
Plain markdown (no DB) | ❌ | ✅ | ✅ | ❌ | ✅ |
File lives in project folder | ❌ | ✅ | ❌ | ❌ | ✅ |
Token-frugal (< 500 tokens default) | ❌ | ⚠️ | ❌ | ❌ | ✅ |
Controls AI output length | ❌ | ❌ | ❌ | ❌ | ✅ |
Shows real savings ($ + tokens) | ❌ | ❌ | ❌ | ❌ | ✅ |
AGENTS.md / .cursorrules emitter | ❌ | ❌ | ❌ | ❌ | ✅ |
Memory undo | ❌ | manual git | ❌ | ❌ | ✅ |
Local, no cloud, no accounts | ⚠️ | ✅ | ✅ | ❌ | ✅ |
🚀 60-second walkthrough
# 1. Install (auto-detects Claude Code, Cursor, Antigravity, etc.)
npx memorybridge init
# 2. See everything in one dashboard
memorybridge settings
# 3. Use any AI tool in any project. When you say "I prefer TypeScript strict mode",
# the AI calls memory_save automatically. Next session, it already knows.
# 4. Make AI responses shorter to save output tokens (5× cost vs input)
memorybridge shorter
# 5. Watch real savings accumulate
memorybridge savings
# 6. Generate AGENTS.md, CLAUDE.md, .cursorrules — all from one source
memorybridge emit --all
# 7. Search across every project you've ever worked on
memorybridge global-search "supabase"
# 8. Roll back a bad memory save
memorybridge undo📊 Real token savings (measured)
After 7 calls in a test project:
INPUT token savings (vs. re-pasting ~3,000 tokens of context per session):
Baseline: 21,000 tokens
Actual served: 1,405 tokens
Saved: 19,595 tokens (93%)
OUTPUT token savings (style level 2 — concise):
Estimated saved: 2,640 tokens (55%)At 500 sessions/month on Sonnet, you save roughly $6.50/month. At 100 sessions on Opus you save $3.40/month. Heavy users on Opus see $23+/month. Run memorybridge compare --sessions 500 to see your projected savings.
Honest disclaimer: "Tokens saved" assumes a 3,000-token re-paste baseline per session. If you don't re-paste, savings are smaller. If you re-paste more, savings are larger. Tokens served (1,405 above) are real, measured by
gpt-tokenizeron the actual returned text.
🔧 How it works
flowchart TD
A["You: 'I prefer TypeScript strict mode'"] -->|AI calls memory_save| B[("📄 .ai-memory.md<br/>in your project folder")]
B -->|next session loads| C[Claude Code]
B -->|next session loads| D[Cursor]
B -->|next session loads| E[Antigravity]
B -->|next session loads| F[Windsurf / Gemini CLI / Continue / Copilot]
C --> G["AI already knows.<br/>~400 tokens of context, not 4,000.<br/>Zero re-explaining."]
D --> G
E --> G
F --> G
style A fill:#161a22,stroke:#79c0ff,color:#e6edf3
style B fill:#0d1117,stroke:#7ee787,color:#e6edf3,stroke-width:3px
style C fill:#161a22,stroke:#30363d,color:#e6edf3
style D fill:#161a22,stroke:#30363d,color:#e6edf3
style E fill:#161a22,stroke:#30363d,color:#e6edf3
style F fill:#161a22,stroke:#30363d,color:#e6edf3
style G fill:#0d1117,stroke:#fbbf24,color:#fbbf24,stroke-width:2px🎛️ One dashboard for everything
memorybridge settings shows your current style level, savings so far, every file path MemoryBridge knows about, which AI tools are wired up, and the exact command to change each one. Run it any time.
🛠️ CLI reference
Command | What it does |
| Detect AI tools and wire MemoryBridge into their MCP configs |
| Cleanly remove (preserves your data unless |
| Single-page dashboard — everything tunable + current values |
| Token + $ savings, measured + estimated |
| Side-by-side before/after with cost math |
| Show all installed AI tools + their existing memory files |
| Manually save a memory entry |
| Show all saved memories |
| Search current project memory |
| Search across ALL indexed projects |
| Rebuild cross-project index |
| List indexed projects |
| Preview what AI sees on session start |
| Alias for |
| Open the memory file in your editor |
| Verify install, paths, token budget |
| Score your memory for junk content (grade A–F) |
| Archive entries older than N days (default 90) |
| Generate AGENTS.md / CLAUDE.md / .cursorrules / etc. |
| Control AI response length |
| Step style by one |
| Pin sections to always-load |
| Snapshot history |
| Extract JS/TS/Py/Go exports for AI navigation |
| Same as |
| Full command list |
❓ FAQ
Will this actually save me tokens?
Yes, if (a) you currently re-paste project context across sessions, (b) you use AI tools regularly, and (c) the AI calls memory_load (it does, automatically, when MemoryBridge is configured). The savings are real for most coding workflows. They are zero if you don't re-paste at all. See the savings section above for the honest math.
Will it break my project?
No. We never modify your source code. We refuse to overwrite hand-written files (banner + hash check). Every memory write is snapshotted for memorybridge undo. The full safety contract is in SAFETY.md.
What AI tools does it work with?
Any AI tool that supports MCP (Model Context Protocol). Currently auto-detected: Claude Code, Cursor, Google Antigravity, Windsurf, Gemini CLI, Continue.dev, VS Code (+ Copilot), Claude Desktop, OpenCode. More will work as MCP adoption grows.
Where is my data stored?
Per-project memory:
<your-project>/.ai-memory.md— in your project folderGlobal preferences + history:
~/.memorybridge/— your home directoryOverride with the
MEMORYBRIDGE_PATHenvironment variable
Nothing leaves your machine. Zero cloud. Zero accounts. Zero telemetry.
How does it compare to Mem0?
Mem0 uses an LLM to extract memories into a vector DB. Powerful but heavy: requires Docker, vector store setup, an LLM API key, and per their own audit produces ~97% junk memories. MemoryBridge is the opposite: explicit saves, plain markdown, no DB, no LLM extraction, < 60 second install.
How does it compare to CLAUDE.md / AGENTS.md?
CLAUDE.md and AGENTS.md are static files you write by hand and one tool reads. MemoryBridge lets the AI write to and read from a single source of truth, then can emit all those formats automatically (memorybridge emit --all). One source. Every format.
What about ChatGPT memory?
ChatGPT memory is invisible (you can't see what's stored), single-tool (doesn't work in Claude/Cursor), and cloud-only (your data goes to OpenAI's servers). MemoryBridge is human-readable, cross-tool, and local.
Will it work on my OS?
Yes — Windows, macOS, Linux. We test on Node 20+.
Is it open source?
Yes — MIT licensed. Contributions welcome.
What's the future roadmap?
See BUILD_PLAN.md and WHY_AND_HOW.md for the full plan and research findings.
🤝 Contributing
PRs welcome. Good first issues:
Adding new AI tool detection paths (we currently detect 9 — there are more)
Adding emit formats for new tools (e.g. JetBrains AI when MCP support lands)
Improving symbol extraction patterns (especially Python and Go)
Writing tests
Translating the CLI output
Open an issue first if you're planning a big change.
🧐 Is it actually helping me?
Read HONEST.md for the brutally honest answer — including:
Who MemoryBridge helps a lot (30%+ savings) vs barely (under 5%)
A worked dollar example based on real Claude Code usage patterns
Exactly what's measured vs estimated in our numbers
How to verify on your own machine
When to uninstall
We'd rather you uninstall on month 1 than feel cheated on month 6.
🔒 Safety
Read the full safety contract: SAFETY.md. TL;DR: we only ever write to .ai-memory.md, .ai-memory.archive.md, the optional emitted files (with banner protection), and ~/.memorybridge/. We never touch your source code. Uninstall is a single command and fully reversible.
🧪 Manual install (while we publish to npm)
git clone https://github.com/IamRamgarhia/memorybridge.git
cd memorybridge
npm install
npm run build
node dist/cli.js init🔎 Common questions (long-form)
How do I share AI memory between Claude Code and Cursor?
Install MemoryBridge once with npx memorybridge init. It detects both tools and configures the MCP server in ~/.claude.json and ~/.cursor/mcp.json. Restart both tools. From then on, the same .ai-memory.md file in your project folder is read by both. When Claude Code learns something, Cursor sees it next session. Same for Antigravity, Windsurf, Gemini CLI, and any other MCP-compatible AI tool.
How do I stop my AI from forgetting things between sessions?
The reason AI forgets is that each session starts with a fresh context window. MemoryBridge solves this by giving the AI a tool (memory_load) it calls at the start of every session to retrieve project context from a local file. When you state preferences or make decisions, the AI calls memory_save to persist them. Nothing leaves your machine — it's all in a Markdown file you can read in any text editor.
How do I save tokens on Claude Code, Cursor, or Anthropic's API?
Three mechanisms compound:
Cut input tokens — stop re-pasting project context every session (saves 1,500–3,000 tokens/session)
Cut output tokens — set
memorybridge style 1for ultra-terse AI responses (saves up to 75% of output tokens, which cost 5× more than input)Cut search/grep tokens — the
@mapand@symbolssections cache where things live, so AI doesn't re-grep
Run memorybridge compare --sessions 300 to see your projected monthly savings at typical Sonnet pricing.
What is AGENTS.md and how does MemoryBridge handle it?
AGENTS.md is the emerging cross-tool convention for project instructions to AI agents (see the 300-comment thread on the Claude Code repo). MemoryBridge can generate AGENTS.md, CLAUDE.md, .cursorrules, .windsurfrules, GEMINI.md, .continuerules, and .github/copilot-instructions.md — all from one source .ai-memory.md — with a single command: memorybridge emit --all. Files are protected by a SHA-1 hash banner so MemoryBridge refuses to overwrite hand-written content.
Does MemoryBridge work offline?
Yes, completely. No network calls. No telemetry. No API keys required. The MCP server runs locally as a subprocess of your AI tool. The only network traffic is your AI tool talking to its own provider (Anthropic, OpenAI, etc.) — MemoryBridge sits between you and that traffic, not on top of it.
Is MemoryBridge a replacement for Mem0 / Letta / basic-memory?
It overlaps with them but solves a different problem. Mem0 and Letta are designed for agent applications that need vector search and LLM-extracted memories — they require servers, databases, and API keys. MemoryBridge is designed for individual developers using AI coding tools who want context to persist across sessions and tools without setup. If you need vector search or graph memory in an agent framework, use Mem0 or Letta. If you want your IDE's AI to stop forgetting your project, use MemoryBridge.
How do I install MemoryBridge in Windsurf / Continue.dev / VS Code Copilot?
npx memorybridge init auto-detects them and writes the right MCP config. If detection misses your tool, the MCP entry to add manually is:
{
"mcpServers": {
"memorybridge": {
"command": "node",
"args": ["/absolute/path/to/memorybridge/dist/server.js"]
}
}
}Add it to your tool's MCP config file and restart. Check your tool's docs for the file location.
Can I share AI memory with my team?
Yes. The .ai-memory.md file is plain Markdown in your project folder. Commit it to Git. New teammates clone the repo and their AI immediately knows the project's architecture, decisions, and known bugs. This turns ad-hoc tribal knowledge into version-controlled team context.
Where can I see what MemoryBridge has stored?
Three ways:
memorybridge open # opens the memory file in your default editor
memorybridge list # CLI listing of every entry
memorybridge load # exactly what the AI sees on session startIt's all plain Markdown. No black box.
📚 Related projects
Model Context Protocol — the standard MemoryBridge speaks
modelcontextprotocol/servers — official MCP server directory
awesome-mcp-servers — community list
📄 License
MIT — see LICENSE
Built because every AI tool forgetting your project at the start of every session is the dumbest tax on developer time. Free, local, cross-tool. Take your context back.
Available Tools
3 toolsmemory_loadB
Load session memory. Header by default; pass section for more.
| Name | Required | Description | Default |
|---|---|---|---|
| section | No |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It says 'Load session memory' but does not explain what loading means, whether it is read-only, or any side effects. The term 'Header' is not defined, and there is no mention of return format or permissions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with two sentences, no redundancy. The first sentence states the primary purpose, and the second adds key detail. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one optional parameter and no output schema, the description covers purpose and basic usage. However, it lacks details on return values, error conditions, and parameter constraints, making it incomplete for an agent to fully understand behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description ties the single parameter 'section' to the phrase 'pass section for more', indicating it is optional and controls detail level. However, it does not explain valid values or default behavior when omitted. With 0% schema coverage, the description adds some but not sufficient meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool loads session memory, distinguishing it from sibling tools memory_save and memory_search. It specifies default behavior (Header) and how to get more detail (pass section).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives like memory_save or memory_search. The description only implies usage through functionality but does not provide context for choosing between siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
memory_saveC
Save a durable preference, decision, or recurring issue.
| Name | Required | Description | Default |
|---|---|---|---|
| content | Yes | ||
| category | Yes | ||
| scope | No |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must fully disclose behavioral traits. It only mentions 'durable' but omits critical details such as whether it overwrites existing data, storage limits, persistence mechanism, or any side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no unnecessary words. It is front-loaded and efficient, though it could benefit from slightly more detail without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 3 parameters, no output schema, and no annotations, the description is incomplete. It fails to explain the full range of categories, parameter behavior, or what happens after saving. The agent would need to infer too much.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It mentions only three of seven possible category values and does not explain the 'content' or 'scope' parameters. The description adds minimal clarity beyond the enum names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that it saves a durable preference, decision, or recurring issue, which conveys the core purpose. However, it doesn't explicitly distinguish from sibling tools, and it only lists three category types while the enum has seven, which may cause partial coverage confusion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like memory_load or memory_search. It lacks any 'when not to use' instructions or context for optimal invocation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
memory_searchC
Search memory. Returns up to 10 matches.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavior; it only mentions a return limit but fails to explain search type, results format, or error handling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short (two sentences) but lacks structure and omits necessary details, making it insufficiently informative despite brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no annotations, no output schema), the description should be sufficient but fails to explain core semantics like memory scope and search mechanics.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds no information about the 'query' parameter beyond the schema, leaving the agent uninformed about what constitutes a valid query.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Search memory' which identifies the action and resource vaguely, and adds that it returns up to 10 matches, providing some specificity but lacking clarity on what 'memory' encompasses compared to siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus siblings memory_load or memory_save, leaving the agent without criteria for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
3 tool updates
v0.1.0- First observed
memory_load - First observed
memory_save - First observed
memory_search
TDQS
Scored across 3 tools
Each tool targets a distinct operation: loading, saving, and searching memory. No overlap or confusion between them.
All tools follow a consistent 'memory_verb' pattern (memory_load, memory_save, memory_search), making the naming predictable and easy to understand.
With 3 tools, the set is tightly scoped for a memory bridge server. Each tool serves a clear purpose without unnecessary bloat or missing essentials.
The set covers core operations (load, save, search) but lacks a deletion tool. While most workflows are supported, a delete operation would make it fully complete.
Maintenance
Related MCP Connectors
- mcpOAuthai.butlerbrain
Persistent memory for AI assistants. Save once; recall from Claude, ChatGPT, or any MCP client.
Persistent AI memory shared across Claude, ChatGPT, coding agents, and compatible MCP clients.
One memory, every AI. A shared, user-owned markdown memory your AI clients read and write over MCP.
One memory, every AI: Claude, ChatGPT, Perplexity, Gemini, Cursor, OpenClaw, Hermes, any MCP client.
Related MCP Servers
- AlicenseAqualityAmaintenanceLocal-first MCP server that gives any AI coding agent per-project memory, workflow intelligence, and always-on, lossless token & context optimization.3760 npm6MIT
- AlicenseNot gradedqualityDmaintenancePersistent memory MCP server for Claude Code that captures and recalls project context across sessions, eliminating the need to re-explain architecture and decisions daily.292 npm1MIT
- FlicenseNot gradedqualityDmaintenanceA persistent, conflict-aware memory MCP server for AI coding assistants (Cursor, Claude Code).-
- AlicenseAqualityAmaintenanceLocal-first MCP server that watches your coding sessions and injects a compact summary at the start of each new session. 85.6% token reduction, SQLite storage, no cloud. Works with Claude Code, Cursor, Cline, and Windsurf.1321 npm8MIT