mem0 Memory System
@pinkpixel/mem0-mcp MCP-Server ✨
Ein Model Context Protocol (MCP)-Server, der in Mem0.ai integriert ist, um persistenten Speicher für LLMs bereitzustellen. Er ermöglicht KI-Agenten das Speichern und Abrufen von Informationen über Sitzungen hinweg.
Dieser Server verwendet für seine Kernfunktionalität das mem0ai Node.js SDK.
Funktionen 🧠
Werkzeuge
add_memory: Speichert einen Textinhalt als Speicher, der mit einer bestimmtenuserIdverknüpft ist.Erforderlich:
content(Zeichenfolge),userId(Zeichenfolge)Optional:
sessionId(Zeichenfolge),agentId(Zeichenfolge),orgId(Zeichenfolge),projectId(Zeichenfolge),metadata(Objekt)Erweitert (Cloud-API):
includes(Zeichenfolge),excludes(Zeichenfolge),infer(Boolesch),outputFormat(Zeichenfolge),customCategories(Objekt),customInstructions(Zeichenfolge),immutable(Boolesch),expirationDate(Zeichenfolge)Speichert den bereitgestellten Text, sodass er bei zukünftigen Interaktionen wieder aufgerufen werden kann.
search_memory: Durchsucht gespeicherte Erinnerungen basierend auf einer Abfrage in natürlicher Sprache nach einer bestimmtenuserId.Erforderlich:
query(Zeichenfolge),userId(Zeichenfolge)Optional:
sessionId(Zeichenfolge),agentId(Zeichenfolge),orgId(Zeichenfolge),projectId(Zeichenfolge),filters(Objekt),threshold(Zahl)Erweitert (Cloud-API):
topK(Zahl),fields(Array),rerank(Boolesch),keywordSearch(Boolesch),filterMemories(Boolesch)Ruft relevante Erinnerungen auf der Grundlage semantischer Ähnlichkeit ab.
delete_memory: Löscht einen bestimmten Speicher anhand seiner ID aus dem Speicher.Erforderlich:
memoryId(Zeichenfolge),userId(Zeichenfolge)Optional:
agentId(Zeichenfolge),orgId(Zeichenfolge),projectId(Zeichenfolge)Entfernt den angegebenen Speicher dauerhaft.
Related MCP server: mindcore-memory-mcp
Voraussetzungen 🔑
Dieser Server unterstützt zwei Speichermodi:
Cloud-Speichermodus ☁️ (empfohlen)
Erfordert einen Mem0-API-Schlüssel (bereitgestellt als Umgebungsvariable
MEM0_API_KEY)Erinnerungen werden dauerhaft auf den Cloud-Servern von Mem0 gespeichert
Keine lokale Datenbank erforderlich
Lokaler Speichermodus 💾
Erfordert einen OpenAI-API-Schlüssel (bereitgestellt als Umgebungsvariable
OPENAI_API_KEY)Erinnerungen werden in einer In-Memory-Vektordatenbank gespeichert (standardmäßig nicht persistent).
Daten gehen beim Neustart des Servers verloren, sofern sie nicht für die dauerhafte Speicherung konfiguriert sind.
Installation & Konfiguration ⚙️
Sie können diesen Server hauptsächlich auf drei Arten ausführen:
1. Globale Installation (Empfohlen für häufigen Gebrauch)
Installieren Sie das Paket global und verwenden Sie den Befehl mem0-mcp :
npm install -g @pinkpixel/mem0-mcpNach der globalen Installation können Sie den Server direkt ausführen:
mem0-mcpKonfigurieren Sie Ihren MCP-Client für die Verwendung des globalen Befehls:
Cloud-Speicherkonfiguration (globale Installation)
{
"mcpServers": {
"mem0-mcp": {
"command": "mem0-mcp",
"args": [],
"env": {
"MEM0_API_KEY": "YOUR_MEM0_API_KEY_HERE",
"DEFAULT_USER_ID": "user123",
"ORG_ID": "your-org-id",
"PROJECT_ID": "your-project-id"
},
"disabled": false,
"alwaysAllow": [
"add_memory",
"search_memory",
"delete_memory"
]
}
}
}Lokale Speicherkonfiguration (Globale Installation)
{
"mcpServers": {
"mem0-mcp": {
"command": "mem0-mcp",
"args": [],
"env": {
"OPENAI_API_KEY": "YOUR_OPENAI_API_KEY_HERE",
"DEFAULT_USER_ID": "user123"
},
"disabled": false,
"alwaysAllow": [
"add_memory",
"search_memory",
"delete_memory"
]
}
}
}2. Verwenden von npx (Empfohlen für gelegentliche Verwendung)
Konfigurieren Sie Ihren MCP-Client (z. B. Claude Desktop, Cursor, Cline, Roo Code usw.), um den Server mit npx auszuführen:
Cloud-Speicherkonfiguration (npx)
{
"mcpServers": {
"mem0-mcp": {
"command": "npx",
"args": [
"-y",
"@pinkpixel/mem0-mcp"
],
"env": {
"MEM0_API_KEY": "YOUR_MEM0_API_KEY_HERE",
"DEFAULT_USER_ID": "user123",
"ORG_ID": "your-org-id",
"PROJECT_ID": "your-project-id"
},
"disabled": false,
"alwaysAllow": [
"add_memory",
"search_memory",
"delete_memory"
]
}
}
}Lokale Speicherkonfiguration (npx)
{
"mcpServers": {
"mem0-mcp": {
"command": "npx",
"args": [
"-y",
"@pinkpixel/mem0-mcp"
],
"env": {
"OPENAI_API_KEY": "YOUR_OPENAI_API_KEY_HERE",
"DEFAULT_USER_ID": "user123"
},
"disabled": false,
"alwaysAllow": [
"add_memory",
"search_memory",
"delete_memory"
]
}
}
}3. Ausführen aus einem geklonten Repository
Hinweis: Für diese Methode müssen Sie zuerst das Repository per Git klonen.
Klonen Sie das Repository, installieren Sie Abhängigkeiten und erstellen Sie den Server:
git clone https://github.com/pinkpixel-dev/mem0-mcp
cd mem0-mcp
npm install
npm run buildKonfigurieren Sie dann Ihren MCP-Client so, dass das erstellte Skript direkt mithilfe von node ausgeführt wird:
Cloud-Speicherkonfiguration (geklontes Repository)
{
"mcpServers": {
"mem0-mcp": {
"command": "node",
"args": [
"/absolute/path/to/mem0-mcp/build/index.js"
],
"env": {
"MEM0_API_KEY": "YOUR_MEM0_API_KEY_HERE",
"DEFAULT_USER_ID": "user123",
"ORG_ID": "your-org-id",
"PROJECT_ID": "your-project-id"
},
"disabled": false,
"alwaysAllow": [
"add_memory",
"search_memory",
"delete_memory"
]
}
}
}Lokale Speicherkonfiguration (geklontes Repository)
{
"mcpServers": {
"mem0-mcp": {
"command": "node",
"args": [
"/absolute/path/to/mem0-mcp/build/index.js"
],
"env": {
"OPENAI_API_KEY": "YOUR_OPENAI_API_KEY_HERE",
"DEFAULT_USER_ID": "user123"
},
"disabled": false,
"alwaysAllow": [
"add_memory",
"search_memory",
"delete_memory"
]
}
}
}Wichtige Hinweise:
Ersetzen Sie
/absolute/path/to/mem0-mcp/durch den tatsächlichen absoluten Pfad zu Ihrem geklonten RepositoryVerwenden Sie die Datei
build/index.js, nicht die Dateisrc/index.tsDer MCP-Server benötigt sauberes stdout für die Protokollkommunikation – alle Bibliotheken oder Codes, die in stdout schreiben, können das Protokoll stören
Standard-Benutzer-ID (optionaler Fallback)
Sowohl das Tool add_memory als auch das Tool search_memory erfordern ein userId Argument, um Erinnerungen einem bestimmten Benutzer zuzuordnen.
Zur Vereinfachung beim Testen oder in Einzelbenutzerszenarien können Sie beim Serverstart optional die Umgebungsvariable DEFAULT_USER_ID festlegen. Wenn diese Variable gesetzt ist und das Argument userId beim Aufruf des Tools search_memory weggelassen wird, verwendet der Server den Wert von DEFAULT_USER_ID für die Suche.
Hinweis: Obwohl dieser Fallback vorhanden ist, wird generell empfohlen, dass der aufrufende Agent (LLM) sowohl beim Hinzufügen als auch beim Suchen von Speichern explizit die richtige userId angibt, um Mehrdeutigkeiten zu vermeiden.
Beispielkonfiguration mit DEFAULT_USER_ID :
{
"mcpServers": {
"mem0-mcp": {
"command": "npx",
"args": [
"-y",
"@pinkpixel/mem0-mcp"
],
"env": {
"MEM0_API_KEY": "YOUR_MEM0_API_KEY_HERE",
"DEFAULT_USER_ID": "user123",
"ORG_ID": "your-org-id",
"PROJECT_ID": "your-project-id"
}
}
}
}Oder bei direkter Ausführung mit node :
git clone https://github.com/pinkpixel-dev/mem0-mcp
cd mem0-mcp
npm install
npm run build{
"mcpServers": {
"mem0-mcp": {
"command": "node",
"args": [
"path/to/mem0-mcp/build/index.js"
],
"env": {
"OPENAI_API_KEY": "YOUR_OPENAI_API_KEY_HERE",
"DEFAULT_USER_ID": "user123"
}
}
}
}Cloud vs. lokaler Speicher 🔄
Cloud-Speicher (Mem0 API)
Standardmäßig persistent – Ihre Erinnerungen bleiben über Sitzungen und Serverneustarts hinweg verfügbar
Keine lokale Datenbank erforderlich – Alle Daten werden auf den Servern von Mem0 gespeichert
Höhere Abrufqualität – Verwendet die optimierten Suchalgorithmen von Mem0
Zusätzliche Felder – Unterstützt
agent_idundthresholdErfordert - Ein Mem0 API-Schlüssel
Lokaler Speicher (OpenAI API)
Standardmäßig im Arbeitsspeicher – Daten werden nur im RAM gespeichert und sind nicht dauerhaft persistent . Zwar kann es zu einem gewissen Caching kommen, aber Sie sollten sich für die dauerhafte Speicherung nicht darauf verlassen.
Datenverlustrisiko - Speicherdaten gehen beim Neustart des Servers, des Systems oder bei Beendigung des Prozesses verloren
Empfohlen für : Entwicklung, Tests oder nur vorübergehende Verwendung
Für dauerhaften Speicher - Verwenden Sie die Cloud-Speicheroption mit Mem0-API, wenn Sie zuverlässigen Langzeitspeicher benötigen
Verwendet OpenAI-Einbettungen – Für die Vektorsuchfunktion
In sich geschlossen – Alle Daten bleiben auf Ihrem Computer
Erfordert - Einen OpenAI API-Schlüssel
Entwicklung 💻
Klonen Sie das Repository und installieren Sie Abhängigkeiten:
git clone https://github.com/pinkpixel-dev/mem0-mcp
cd mem0-mcp
npm installErstellen Sie den Server:
npm run buildFür die Entwicklung mit automatischem Neuaufbau bei Dateiänderungen:
npm run watchDebuggen 🐞
Da MCP-Server über Standarddio kommunizieren, kann das Debuggen eine Herausforderung darstellen. Hier sind einige Ansätze:
Verwenden Sie den MCP Inspector : Dieses Tool kann die MCP-Protokollkommunikation überwachen:
npm run inspectorKonsolenprotokollierung : Verwenden Sie beim Hinzufügen von Konsolenprotokollen immer
console.error()anstelle vonconsole.log()um Störungen des MCP-Protokolls zu vermeidenUmgebungsdateien : Verwenden Sie eine
.envDatei für die lokale Entwicklung, um das Festlegen von API-Schlüsseln und anderen Konfigurationsoptionen zu vereinfachen
Hinweise zur technischen Implementierung 🔧
Erweiterte Mem0-API-Parameter
Wenn Sie den Cloud-Speichermodus mit der Mem0-API verwenden, können Sie zusätzliche Parameter für eine anspruchsvollere Speicherverwaltung nutzen. Obwohl sie im Toolschema nicht explizit angezeigt werden, können diese beim Hinzufügen von Speichern in das metadata aufgenommen werden:
Erweiterte Parameter für add_memory :
Parameter | Typ | Beschreibung |
| Objekt | Speichern Sie zusätzlichen Kontext zum Speicher (z. B. Ort, Zeit, Kennungen). Dies kann zum Filtern beim Abrufen verwendet werden. |
| Schnur | Spezifische Präferenzen, die in den Speicher aufgenommen werden sollen. |
| Schnur | Bestimmte Einstellungen, die aus dem Speicher ausgeschlossen werden sollen. |
| Boolescher Wert | Ob Erinnerungen abgeleitet oder Nachrichten direkt gespeichert werden sollen (Standard: true). |
| Schnur | Formatversion, entweder v1.0 (Standard, veraltet) oder v1.1 (empfohlen). |
| Objekt | Liste der Kategorien mit Namen und Beschreibungen. |
| Schnur | Projektspezifische Richtlinien zum Umgang mit und zur Organisation von Erinnerungen. |
| Boolescher Wert | Ob der Speicher unveränderlich ist (Standard: false). |
| Schnur | Wann der Speicher abläuft (Format: JJJJ-MM-TT). |
| Schnur | Mit diesem Speicher verknüpfte Organisations-ID. |
| Schnur | Mit diesem Speicher verknüpfte Projekt-ID. |
| Schnur | Speicherversion (v1 ist veraltet, v2 wird für neue Anwendungen empfohlen). |
Um diese Parameter mit dem MCP-Server zu verwenden, fügen Sie sie beim Aufruf des Tools add_memory in Ihr Metadatenobjekt ein. Beispiel:
{
"content": "Important information to remember",
"userId": "user123",
"sessionId": "project-abc",
"metadata": {
"includes": "important context",
"excludes": "sensitive data",
"immutable": true,
"expiration_date": "2025-12-31",
"custom_instructions": "Prioritize this memory for financial questions",
"version": "v2"
}
}Erweiterte Parameter für search_memory :
Die Mem0 v2-Such-API bietet leistungsstarke Filterfunktionen, die über den filters genutzt werden können:
Parameter | Typ | Beschreibung |
| Objekt | Komplexe Filter mit logischen Operatoren und Vergleichsbedingungen |
| ganze Zahl | Anzahl der zurückzugebenden Top-Ergebnisse (Standard: 10) |
| Zeichenfolge[] | Spezifische Felder, die in die Antwort aufgenommen werden sollen |
| Boolescher Wert | Ob die Erinnerungen neu eingestuft werden sollen (Standard: „false“) |
| Boolescher Wert | Ob auf Grundlage von Schlüsselwörtern gesucht werden soll (Standard: false) |
| Boolescher Wert | Ob die Erinnerungen gefiltert werden sollen (Standard: false) |
| Nummer | Minimaler Ähnlichkeitsschwellenwert für Ergebnisse (Standard: 0,3) |
| Schnur | Organisations-ID zum Filtern von Erinnerungen |
| Schnur | Projekt-ID zum Filtern von Erinnerungen |
Der filters unterstützt komplexe logische Operationen (AND, OR) und verschiedene Vergleichsoperatoren:
Operator | Beschreibung |
| Entspricht einem der angegebenen Werte |
| Größer als oder gleich |
| Kleiner oder gleich |
| Größer als |
| Weniger als |
| Ungleich |
| Groß- und Kleinschreibung ignorierende Eingrenzungsprüfung |
Beispiel für die Verwendung komplexer Filter mit dem Tool search_memory :
{
"query": "What are Alice's hobbies?",
"userId": "user123",
"filters": {
"AND": [
{
"user_id": "alice"
},
{
"agent_id": {"in": ["travel-agent", "sports-agent"]}
}
]
},
"threshold": 0.5,
"top_k": 5
}Dies würde nach Erinnerungen suchen, die mit Alices Hobbys in Zusammenhang stehen, wobei die Benutzer-ID „Alice“ UND die Agenten-ID entweder „Reisebüro“ ODER „Sportbüro“ ist. Dabei würden höchstens 5 Ergebnisse mit einem Ähnlichkeitswert von mindestens 0,5 zurückgegeben.
Ausführlichere Informationen zu diesen Parametern finden Sie in der Mem0-API-Dokumentation .
SafeLogger
Der MCP-Server implementiert eine SafeLogger -Klasse, die Console.log-Aufrufe aus der Mem0ai-Bibliothek selektiv an stderr umleitet, ohne das MCP-Protokoll zu unterbrechen:
Fängt console.log-Aufrufe ab und untersucht Stacktraces, um die Quelle zu bestimmen
Leitet nur Protokollaufrufe aus der mem0ai-Bibliothek oder unserem eigenen Code um
Bewahrt eine saubere Standardausgabe für die MCP-Protokollkommunikation
Bereinigt Ressourcen automatisch beim Beenden des Prozesses
Dies ermöglicht eine ordnungsgemäße Funktion innerhalb von MCP-Clients, während nützliche Debuginformationen erhalten bleiben.
Umgebungsvariablen
Der Server erkennt mehrere Umgebungsvariablen, die sein Verhalten steuern:
MEM0_API_KEY: API-Schlüssel für den Cloud-SpeichermodusOPENAI_API_KEY: API-Schlüssel für den lokalen Speichermodus (Einbettungen)DEFAULT_USER_ID: Standard-Benutzer-ID für SpeicheroperationenORG_ID/YOUR_ORG_ID: Standard-Organisations-ID für den Cloud-SpeichermodusPROJECT_ID/YOUR_PROJECT_ID: Standard-Projekt-ID für den Cloud-Speichermodus
Wichtige Hinweise:
Sitzungs-IDs werden als Tool-Parameter übergeben (z. B.
"sessionId": "my-session"), nicht als UmgebungsvariablenBei der Verwendung der Tools haben direkt bereitgestellte Parameter (z. B.
orgId,projectId,sessionId) Vorrang vor Umgebungsvariablen, was Ihnen maximale Flexibilität bietet
Hergestellt mit ❤️ von Pink Pixel
Available Tools
3 toolsadd_memoryC
Stores a piece of text as a memory in Mem0.
| Name | Required | Description | Default |
|---|---|---|---|
| agentId | No | Optional agent ID to associate with the memory (for cloud API). | |
| content | Yes | The text content to store as memory. | |
| metadata | No | Optional key-value metadata. | |
| sessionId | No | Optional session ID to associate with the memory. | |
| userId | Yes | User ID to associate with the memory. |
TDQS
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 stores text as memory but doesn't mention whether this is a write operation (implied), what permissions are needed, how the memory is persisted, rate limits, or what happens on success/failure. This is inadequate for a mutation tool with zero annotation coverage.
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, efficient sentence that gets straight to the point with zero wasted words. It's appropriately sized and front-loaded, making it easy for an agent to parse quickly.
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 mutation tool with no annotations and no output schema, the description is insufficient. It doesn't explain what the tool returns, error conditions, or behavioral nuances like idempotency. Given the complexity (5 parameters including nested objects) and lack of structured coverage, more context is needed.
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 100%, so the schema fully documents all 5 parameters. The description doesn't add any parameter-specific details beyond what's in the schema (e.g., it doesn't explain format constraints or usage examples). Baseline 3 is appropriate when the schema does the heavy lifting.
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 ('Stores') and resource ('a piece of text as a memory in Mem0'), making the purpose immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'delete_memory' or 'search_memory' beyond the obvious verb difference, 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_memory' or 'delete_memory'. It doesn't mention prerequisites, typical use cases, or exclusions, leaving the agent to infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
delete_memoryC
Deletes a specific memory from Mem0 by ID.
| Name | Required | Description | Default |
|---|---|---|---|
| agentId | No | Optional agent ID associated with the memory (for cloud API). | |
| memoryId | Yes | The unique ID of the memory to delete. | |
| sessionId | No | Optional session ID associated with the memory. | |
| userId | Yes | User ID associated with the memory. |
TDQS
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, implying a destructive operation, but doesn't cover critical aspects like permissions needed, whether deletion is permanent or reversible, rate limits, or error handling. This leaves significant gaps for a mutation tool.
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 waste—it directly states the tool's function without unnecessary words. It's appropriately sized and front-loaded, making it highly efficient.
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 complexity (a destructive operation with 4 parameters) and lack of annotations and output schema, the description is insufficient. It doesn't explain behavioral traits, return values, or usage context, leaving the agent with incomplete information for safe and effective invocation.
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 schema description coverage is 100%, so all parameters are documented in the input schema. The description mentions 'by ID', which aligns with the 'memoryId' parameter but doesn't add meaningful semantic context beyond what the schema already provides. Baseline 3 is appropriate when the schema does the heavy lifting.
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 ('Deletes') and resource ('a specific memory from Mem0 by ID'), making the purpose unambiguous. However, it doesn't explicitly differentiate from sibling tools like 'add_memory' or 'search_memory' beyond the obvious verb difference, which is why it doesn't reach a 5.
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_memory' or 'add_memory', nor does it mention prerequisites or exclusions. It's a straightforward statement of function without contextual usage advice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_memoryC
Searches stored memories in Mem0 based on a query.
| Name | Required | Description | Default |
|---|---|---|---|
| agentId | No | Optional agent ID to filter search (for cloud API). | |
| filters | No | Optional key-value filters for metadata. | |
| query | Yes | The search query. | |
| sessionId | No | Optional session ID to filter search. | |
| threshold | No | Optional similarity threshold for results (for cloud API). | |
| userId | Yes | User ID to filter search. |
TDQS
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 only states the basic action of searching without detailing aspects like whether it's read-only (implied but not explicit), potential side effects, rate limits, authentication needs, or what the search returns. This leaves significant gaps for a tool with multiple parameters and no output schema.
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, efficient sentence that directly states the tool's purpose without any fluff or redundancy. It's appropriately sized and front-loaded, making it easy to parse quickly.
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 complexity (6 parameters, no output schema, and no annotations), the description is insufficient. It lacks details on behavioral traits, return values, or how to interpret results, leaving the agent with incomplete information to use the tool effectively in context with its siblings.
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 'based on a query,' which aligns with the 'query' parameter, but adds no additional meaning beyond what the schema provides. With 100% schema description coverage, the baseline is 3, as the schema already documents all parameters well, and the description doesn't compensate with extra context or examples.
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 ('searches') and resource ('stored memories in Mem0'), making the purpose understandable. However, it doesn't differentiate from sibling tools like 'add_memory' or 'delete_memory' beyond the basic verb difference, missing specific scope or functional distinctions that would warrant a 5.
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, such as how it differs from 'add_memory' or 'delete_memory' in practice, nor does it mention any prerequisites or exclusions. It's a generic statement that offers no contextual usage advice.
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
v1.0.0- First observed
add_memory - First observed
delete_memory - First observed
search_memory
TDQS
Scored across 3 tools
Each tool has a clearly distinct purpose: add_memory stores new data, delete_memory removes by ID, and search_memory retrieves based on queries. There is no overlap or ambiguity between these three core operations.
All tools follow a consistent verb_noun pattern (add_memory, delete_memory, search_memory) with snake_case throughout. The naming is predictable and uniform across the set.
With only 3 tools, the set feels minimal for a memory system. While it covers basic CRUD operations (create, delete, read), it lacks update functionality and other potential features like listing or managing memory collections, making it borderline thin for the domain.
The tools provide essential CRUD coverage (add, delete, search) for a memory system, but there are minor gaps such as no update_memory tool to modify existing memories and no way to list all memories without a query. Agents can work around this by deleting and re-adding, but it's not ideal.
Maintenance
Related MCP Connectors
An MCP memory server. One memory your agents share — across models, devices and apps.
One memory, every AI. A shared, user-owned markdown memory your AI clients read and write over MCP.
Persistent, portable memory for AI assistants — your private memory graph, from any MCP client.
Persistent memory for AI agents to retain, retrieve, and recall conversation context through MCP.
Related MCP Servers
- AlicenseNot gradedqualityAmaintenanceAn MCP-native, local-first memory server that gives AI agents persistent, structured memory across sessions and tools, enabling them to maintain identity and context without reconfiguration.3MIT
- AlicenseAqualityCmaintenanceA production-grade long-term memory MCP server that enables AI agents to persist and recall memories across sessions with importance weighting, confidence calibration, and efficient context window management.973 PyPI1MIT
- AlicenseAqualityDmaintenanceAn MCP server that provides persistent memory capabilities for AI agents using Mem0, enabling storage, search, and management of contextual information across conversations with support for multiple backends and LLM providers.1824 PyPIMIT
- AlicenseNot gradedqualityDmaintenanceA portable MCP server providing a shared intelligent memory system for any MCP-compatible AI tool, enabling storage, retrieval, extraction, and governance of memories across sessions.10 npmMIT