Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@MCP MITM Mem0 search for our last conversation about Docker commands"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
This project is experimental and deprecated. A new, improved version is being developed at https://github.com/terrymunro/mcp-claude-memories. Please consider using the new version for future projects.
A simplified memory service for Claude that intercepts conversations via MITM proxy and provides memory access through MCP.
This project provides three core components:
MITM Addon - Intercepts Claude API conversations and stores them in Mem0
MCP Server - Provides tools for Claude to query and manage memories
Reflection Agent - Analyzes conversations to identify patterns and provide insights
Related MCP server: acheron-mcp-server
Personal AI Assistant Memory
Give Claude memory of your past conversations
Enable continuity across sessions
Example: "Claude, what was that Docker command we used last week?"
Project Context Persistence
Maintain project-specific knowledge across conversations
Track decisions, approaches, and solutions
Example: Claude remembers your preferred coding style and project structure
Learning and Adaptation
Claude learns your preferences over time
Identifies patterns in your questions and needs
Example: Claude notices you prefer concise answers and adapts accordingly
Development Workflow Enhancement
Remember debugging sessions and solutions
Track what approaches worked or failed
Example: Claude recalls "We tried approach X for this error before, it didn't work because..."
Example 1: Continuing Work
User: "Let's continue working on that authentication system"
Claude: *searches memories* "I found our previous discussion about JWT authentication.
We were implementing refresh tokens and had decided to store them in HTTP-only cookies..."Example 2: Learning Preferences
Claude: *after analyzing conversations* "I've noticed you prefer functional programming
patterns and often ask about TypeScript. Should I prioritize these in my responses?"Example 3: Debugging History
User: "I'm getting that CORS error again"
Claude: *searches memories* "We encountered this CORS error before with your React app.
The solution was to add the proxy configuration in package.json..."Enterprise Knowledge Management
❌ Multi-tenant memory isolation with RBAC
❌ Compliance features (GDPR right-to-be-forgotten, HIPAA, SOC2)
❌ Complex retention policies and data governance
✅ Instead: Simple user-based memory storage
Team Collaboration
❌ Shared memory pools across team members
❌ Real-time sync between multiple Claude instances
❌ Collaborative knowledge base editing
✅ Instead: Personal memory for individual users
Structured Data Systems
❌ CRM replacement for tracking contacts/customers
❌ Project management tool with tasks and deadlines
❌ Documentation platform with versioning
✅ Instead: Conversational memory storage
High-Performance Requirements
❌ Sub-millisecond memory retrieval
❌ Real-time streaming of memories
❌ High-frequency trading or gaming applications
✅ Instead: Async cloud-based memory suitable for conversations
Complex Analytics
❌ Business intelligence dashboards
❌ Advanced NLP analysis pipelines
❌ Machine learning model training
✅ Instead: Simple pattern recognition for conversation insights
Don't try to use this as a general-purpose database
Don't expect ACID transactions or complex queries
Don't store sensitive data without understanding Mem0's security model
Don't assume memories are instantly available after storage
🎯 Simple & Focused - Just memory capture and retrieval, no enterprise complexity
🌐 Mem0 SaaS - Uses Mem0's cloud service, no local infrastructure needed
🔍 Memory Search - Natural language search across conversation history
📊 Reflection Analysis - Identifies patterns and suggests improvements
🛠️ MCP Tools - Direct integration with Claude via MCP protocol
📚 Memory Resources - Browse memories as MCP resources
Sign up at https://app.mem0.ai and get your API key.
cp .env.example .env
# Edit .env and add your MEM0_API_KEYuv sync# Start mitmproxy with the memory addon
mitmdump -s memory_addon.pyConfigure your Claude client to use the proxy (typically localhost:8080).
# Start the MCP server
uv run mcp-mitm-mem0Add to your .mcp.json:
{
"mcpServers": {
"memory-service": {
"command": "uv",
"args": ["run", "mcp-mitm-mem0"],
"cwd": "/path/to/mcp-mitm-mem0"
}
}
}search_memories(query, user_id?, limit?) - Search memories using natural language
list_memories(user_id?) - List all memories for a user
add_memory(messages, user_id?, metadata?) - Manually add memories
delete_memory(memory_id) - Delete a specific memory
analyze_conversations(user_id?, limit?) - Analyze patterns in recent conversations
suggest_next_actions(user_id?) - Get suggestions based on conversation history
memory://{user_id} - Browse all memories for a specific user
memory://recent - View the 10 most recent memories
┌─────────────────┐ ┌─────────────────┐ ┌─────────────────┐
│ Claude Client │────▶│ MITM Proxy │────▶│ Anthropic API │
└─────────────────┘ └────────┬────────┘ └─────────────────┘
│
▼
┌───────────────┐
│ Mem0 SaaS │
└───────▲───────┘
│
┌─────────────────┐ ┌───────┴───────┐
│ Claude │────▶│ MCP Server │
│ (via MCP) │ │ + Reflection │
└─────────────────┘ └───────────────┘Scenario: Working on a complex refactoring across multiple sessions
Day 1:
User: "I need to refactor the authentication system to use JWT"
Claude: "I'll help you refactor to JWT. Let's start by..."
[Discussion about JWT implementation]
Day 3:
User: "What was our plan for the refresh token rotation?"
Claude: _search_memories("JWT refresh token rotation")_
"From our discussion 2 days ago, we planned to implement refresh token rotation with
a 15-minute access token lifetime and 7-day refresh token lifetime..."Scenario: Debugging an intermittent production issue
Week 1:
User: "Production is throwing intermittent 504 errors"
Claude: "Let's investigate. Can you share the logs?"
[Long debugging session]
Week 2:
User: "Those 504 errors are back"
Claude: _analyze_conversations()_
"I see we've encountered this issue before. Last time, we found it correlated with
database connection pool exhaustion during peak hours. We should check if the connection
pool settings we adjusted have reverted..."Scenario: Learning a new technology with Claude as a mentor
Session 1:
User: "Can you teach me React hooks?"
Claude: "Let's start with useState..."
Session 5:
Claude: _analyze_conversations()_
"Based on our previous sessions, you've mastered useState and useEffect. You struggled
with useCallback dependencies. Today, let's focus on custom hooks which will reinforce
those concepts..."Scenario: Building a startup MVP over several months
Month 1:
User: "Should we use microservices or monolith for our MVP?"
Claude: "For an MVP, I recommend starting with a monolith..."
Month 3:
User: "We need to scale the payment processing"
Claude: _search_memories("architecture monolith microservices")_
"Three months ago, we chose a monolithic architecture for your MVP. Now that you need
to scale payment processing, we could extract just that service following the plan we
outlined where payments would be the first candidate for extraction..."Scenario: Claude learns and adapts to your style
After multiple sessions:
Claude: _analyze_conversations()_
Insights detected:
- User prefers functional components over class components
- User consistently asks for TypeScript examples
- User values comprehensive error handling
- User prefers explicit types over inference
Claude: "I'll prioritize functional TypeScript examples with explicit typing and robust
error handling in my responses."uv run pytestuv run ruff check .
uv run ruff format .All configuration is done via environment variables:
MEM0_API_KEY - Your Mem0 SaaS API key (required)
DEBUG - Enable debug logging (default: false)
DEFAULT_USER_ID - Default user ID for memories (default: "default_user")
MITM_HOST - MITM proxy host (default: "localhost")
MITM_PORT - MITM proxy port (default: 8080)
MCP_NAME - MCP server name (default: "memory-service")
MIT
Store important information to memory - AUTO-STORE user preferences and decisions
| Name | Required | Description | Default |
|---|---|---|---|
| messages | Yes | ||
| user_id | No | ||
| metadata | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It mentions storage behavior but lacks critical details: what permissions are needed, whether storage is permanent or temporary, rate limits, or what happens on success/failure. The 'AUTO-STORE' hint suggests automated behavior but doesn't clarify how it differs from manual storage.
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 brief and front-loaded with the core purpose, though the second part about 'AUTO-STORE' could be integrated more smoothly. It avoids unnecessary elaboration but could benefit from clearer structure to separate purpose from behavioral hints.
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, 0% schema coverage, no annotations, and sibling tools, the description is insufficient. It doesn't explain the storage mechanism, return values (despite having an output schema), or how it differs from related tools. The mention of 'AUTO-STORE' adds some context but doesn't compensate for the overall gaps.
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 description coverage is 0%, so the description must compensate but provides no parameter information. It doesn't explain what 'messages', 'user_id', or 'metadata' represent, their formats, or how they interact. The description adds no value beyond the bare schema, leaving all three parameters semantically undocumented.
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 the tool 'Store important information to memory' which provides a basic verb+resource combination, but it's vague about what 'memory' refers to and doesn't distinguish it from sibling tools like list_memories or search_memories. The 'AUTO-STORE user preferences and decisions' adds some specificity but remains ambiguous about scope.
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 list_memories or search_memories. The mention of 'AUTO-STORE user preferences and decisions' implies a context for automated storage but doesn't provide clear when/when-not criteria or prerequisites for usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Analyze conversation patterns and generate insights - AUTO-RUN at session start
| Name | Required | Description | Default |
|---|---|---|---|
| user_id | No | ||
| limit | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It mentions auto-run behavior which is useful, but doesn't describe what the analysis entails, what data sources are used, whether it's read-only or has side effects, what permissions might be needed, or any rate limits. The description is insufficient for a tool with behavioral implications.
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 brief and front-loaded with the core purpose. The auto-run information is efficiently appended. However, the dash formatting could be clearer, and the description could be more structured with separate sentences for different aspects of functionality.
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 has an output schema (which reduces need to describe return values), no annotations, and simple parameters, the description provides basic purpose and auto-run behavior but lacks crucial details about what analysis is performed, how parameters affect results, and behavioral characteristics. It's minimally adequate but has significant gaps.
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?
With 0% schema description coverage and 2 parameters, the description provides no information about the 'user_id' or 'limit' parameters. The schema shows defaults (null for user_id, 20 for limit) and types, but the description doesn't explain what user_id filters, what limit applies to, or how these affect the analysis. The description fails to compensate for the complete lack of schema documentation.
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 the tool 'analyze conversation patterns and generate insights', which provides a general purpose but lacks specificity about what patterns or insights are generated. It doesn't distinguish this analysis tool from potential siblings like 'suggest_next_actions' that might also analyze conversations. The description is vague about the exact nature of the analysis.
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 mentions 'AUTO-RUN at session start' which provides some usage context, but doesn't explain when to manually invoke this tool versus relying on auto-run, nor does it differentiate when to use this versus sibling tools like 'search_memories' or 'suggest_next_actions' for conversation analysis. No explicit alternatives or exclusions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete a specific memory by ID
| Name | Required | Description | Default |
|---|---|---|---|
| memory_id | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool deletes a memory, which implies a destructive mutation, but doesn't cover critical aspects like whether deletion is permanent, requires specific permissions, has side effects, or returns confirmation. This leaves significant gaps for a destructive operation.
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, direct sentence with zero wasted words. It's front-loaded with the core action and resource, making it highly efficient and easy to parse. 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?
Given the tool's destructive nature, no annotations, and an output schema (which should cover return values), the description is minimally adequate but lacks depth. It states what the tool does but omits important context like safety warnings, error conditions, or integration with siblings (e.g., using 'list_memories' first). The presence of an output schema helps but doesn't fully compensate.
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 mentions 'by ID', which adds meaning to the 'memory_id' parameter beyond the schema's minimal coverage (0%). However, it doesn't specify what format the ID should be (e.g., UUID, numeric) or where to obtain it. With one parameter and low schema coverage, this provides some but incomplete compensation.
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 action ('Delete') and the resource ('a specific memory by ID'), making the purpose immediately understandable. It doesn't explicitly distinguish from sibling tools like 'list_memories' or 'search_memories', but the verb 'Delete' inherently differentiates it from those read operations.
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. It doesn't mention prerequisites (e.g., needing a valid memory ID), exclusions (e.g., not for bulk deletion), or suggest alternatives like 'list_memories' to find IDs first. Usage is implied only by the action itself.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all stored conversation memories
| Name | Required | Description | Default |
|---|---|---|---|
| user_id | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure but only states the basic action. It doesn't mention whether this is a read-only operation, if it requires authentication, how results are paginated or sorted, or what the output format entails, leaving critical behavioral traits unspecified.
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, clear sentence with zero wasted words. It's front-loaded with the core action and resource, making it highly efficient and easy to parse at a glance.
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 low complexity (one optional parameter) and the presence of an output schema (which handles return values), the description is minimally adequate. However, it lacks details on behavioral aspects like permissions or result structure that would enhance completeness for a tool interacting with stored data.
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 implies no parameters are needed to list all memories, but the schema includes an optional 'user_id' parameter. Since schema description coverage is 0%, the description should compensate but doesn't explain this parameter's purpose. However, with only one optional parameter, the gap is minor, warranting a score above baseline.
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 verb ('List') and resource ('all stored conversation memories'), making the tool's function unambiguous. However, it doesn't differentiate from sibling tools like 'search_memories' or 'analyze_conversations' that also involve memory retrieval, which prevents a perfect score.
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 'search_memories' (which might filter memories) or 'analyze_conversations' (which might process them). It lacks any context about prerequisites, timing, or exclusions, leaving usage decisions entirely to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search conversation history using natural language - USE AUTONOMOUSLY based on conversation triggers
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | ||
| user_id | No | ||
| limit | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It mentions autonomous use but doesn't disclose key behavioral traits: whether this is a read-only operation, if it requires authentication, potential rate limits, or what the output contains. For a search tool with no annotation coverage, this is a significant gap in transparency.
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 concise with two clauses: one stating the purpose and another providing usage guidance. It's front-loaded with the core function. However, the second clause could be more clearly integrated, and there's room for slight improvement in flow.
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 has an output schema, the description doesn't need to explain return values. However, with no annotations, 3 parameters (1 required), and 0% schema coverage, the description is incomplete—it lacks details on behavioral traits and parameter meanings, making it only minimally adequate.
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 description coverage is 0%, so the description must compensate. It mentions 'natural language' for the query parameter but doesn't explain the semantics of 'user_id' (e.g., filtering by user) or 'limit' (e.g., result count). With 3 parameters largely undocumented, the description adds minimal value beyond the schema.
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's purpose: 'Search conversation history using natural language'. It specifies the resource (conversation history) and action (search via natural language). However, it doesn't explicitly differentiate from sibling tools like 'list_memories' or 'analyze_conversations', which prevents a perfect score.
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 includes usage guidance: 'USE AUTONOMOUSLY based on conversation triggers', which implies when to use it (in response to conversation triggers). However, it doesn't specify when NOT to use it or mention alternatives like 'list_memories' for non-search retrieval, leaving the guidance incomplete.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get personalized recommendations - AUTO-SUGGEST when user seems stuck or asks 'what now?'
| Name | Required | Description | Default |
|---|---|---|---|
| user_id | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. While it mentions the tool provides 'personalized recommendations' and suggests usage timing, it lacks critical behavioral details: what data sources it uses (e.g., memories, conversations), whether it requires specific permissions, how it generates recommendations, or what the output format looks like. For a recommendation tool with zero annotation coverage, this is insufficient.
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—just one sentence with no wasted words. It's front-loaded with the core purpose ('Get personalized recommendations') followed by usage context. Every part of the description adds value, making it efficient and well-structured.
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 moderate complexity (recommendation generation), no annotations, and an output schema exists (which should document return values), the description is partially complete. It covers purpose and usage timing but misses parameter semantics and behavioral details like data sources or algorithm behavior. The presence of an output schema helps, but the description should do more for a tool that likely involves personalization logic.
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 input schema has 1 parameter (user_id) with 0% description coverage in the schema itself. The tool description provides no information about this parameter—it doesn't explain what user_id represents, whether it's required, or how it affects the recommendations. With low schema coverage, the description fails to compensate, leaving the parameter's meaning unclear.
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's purpose: 'Get personalized recommendations' with the specific trigger condition 'when user seems stuck or asks 'what now?''. It uses a clear verb ('Get') and specifies the resource ('personalized recommendations'), though it doesn't explicitly distinguish from sibling tools like 'analyze_conversations' or 'search_memories' which might also provide insights.
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 explicit usage context: 'AUTO-SUGGEST when user seems stuck or asks 'what now?''. This gives clear guidance on when to invoke the tool. However, it doesn't specify when NOT to use it or mention alternatives among the sibling tools, which prevents a perfect score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
add_memoryanalyze_conversationsdelete_memorylist_memoriessearch_memoriessuggest_next_actionsScored across 6 tools
Each tool has a clearly distinct purpose with no overlap: add, delete, list, and search memories are distinct CRUD operations, while analyze_conversations and suggest_next_actions provide separate analytical functions. The descriptions reinforce this separation with specific use cases like 'AUTO-STORE' or 'AUTO-SUGGEST'.
All tool names follow a consistent verb_noun pattern with snake_case (e.g., add_memory, analyze_conversations). The verbs are clear and descriptive (add, analyze, delete, list, search, suggest), and the nouns align well with the memory/conversation domain, making the set predictable and readable.
With 6 tools, this server is well-scoped for managing conversation memories and providing insights. Each tool earns its place by covering essential operations (CRUD for memories, analysis, and suggestions) without being overly sparse or bloated, fitting a typical utility server range.
The tool set provides strong coverage for memory management (add, delete, list, search) and analytical functions (analyze, suggest), with no dead ends. A minor gap exists in update functionality for memories (e.g., edit_memory), but agents can work around this by deleting and re-adding, and the core workflows are well-supported.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Persistent AI memory shared across Claude, ChatGPT, coding agents, and compatible MCP clients.
Private persistent memory for Claude, ChatGPT & Gemini via MCP - semantic search, zero-code setup.
Persistent memory for Claude Code and Cursor. Stop re-explaining your project every session.
Persistent memory for AI agents across Claude, ChatGPT and any MCP client.
