What can you do with this server?

The mem0-mcp-selfhosted server provides persistent memory management for Claude Code through 11 MCP tools, enabling cross-session context retention with optional knowledge graph capabilities using Qdrant, Neo4j, and Ollama. Core Memory Operations * add_memory — Store text or conversation history as memories, with optional LLM-based fact extraction, metadata tagging, and per-call graph toggling * search_memories — Semantically search memories using natural language queries, with filters, relevance thresholds, reranking, and optional graph search * get_memories — Page through memories using scope filters (user, agent, run) without semantic search * get_memory — Fetch a single memory by UUID * update_memory — Overwrite and re-embed an existing memory's text by UUID * delete_memory — Delete a single memory by UUID * delete_all_memories — Bulk-delete all memories within a given scope Entity & Graph Management * list_entities — List all users, agents, and runs with stored memories and counts * delete_entities — Cascade-delete an entire entity and all its associated memories * mcp_search_graph — Search the Neo4j knowledge graph for entities by name/topic, returning entities and outgoing relationships * mcp_get_entity — Retrieve all bidirectional relationships for a specific entity in the knowledge graph Additional Features * Session hooks for automatic memory injection on startup and summary saving on exit * CLAUDE.md integration to instruct Claude Code to proactively use memory tools * Flexible LLM configuration: Anthropic (Claude), Ollama, or Gemini for main LLM, embeddings, and graph operations * Multiple transport modes: stdio, SSE, and streamable-http * Automatic OAT token handling for zero-config use within Claude Code * Structured filter support (AND/OR operators) and scoped memory via user_id, agent_id, run_id * Suppressed telemetry for privacy

Which integrations are available for this server?

Supports using Google Gemini models as a provider for knowledge graph extraction and entity relationship processing. Integrates with Neo4j as a knowledge graph backend to store and retrieve bidirectional entity relationships. Enables fully local operation by using Ollama for both embedding generation and as the primary LLM for memory management.

mem0-mcp-selfhosted

by elvismdev

Overview Schema Related Servers Score Discussions

Python

Hybrid

mem0-mcp-selfhosted

Self-hosted mem0 MCP server for Claude Code. Run a complete memory server against self-hosted Qdrant + Neo4j + Ollama, with your choice of Anthropic (Claude) or Ollama as the main LLM.

Uses the mem0ai package directly as a library, supports both Claude's OAT token and fully local Ollama setups, and exposes 11 MCP tools for full memory management.

Prerequisites

Service	Required	Purpose
Qdrant	Yes	Vector memory storage and search
Ollama	Yes	Embedding generation (`bge-m3`) and optionally local LLM
Neo4j 5+	Optional	Knowledge graph (entity relationships)
Google API Key	Optional	Required only for `gemini`/`gemini_split` graph providers

Python >= 3.10 and uv.

Authentication: The default setup uses Claude (Anthropic) as the LLM for fact extraction. No API key needed, the server automatically uses your Claude Code session token. For fully local setups, set MEM0_PROVIDER=ollama. See Authentication for advanced options.

Related MCP server: mem0-mcp

Quick Start

Default (Anthropic)

Add the MCP server globally (available across all projects):

claude mcp add --scope user --transport stdio mem0 \
  --env MEM0_USER_ID=your-user-id \
  -- uvx --from git+https://github.com/elvismdev/mem0-mcp-selfhosted.git mem0-mcp-selfhosted

All defaults work out of the box: Qdrant on localhost:6333, Ollama embeddings on localhost:11434 with bge-m3 (1024 dims). Override any default via --env (see Configuration).

uvx automatically downloads, installs, and runs the server in an isolated environment, no manual installation needed. Claude Code launches it on demand when the MCP connection starts.

The server auto-reads your OAT token from ~/.claude/.credentials.json, no manual token configuration needed.

Fully Local (Ollama)

For a fully local setup with no cloud dependencies, use Ollama for both the main LLM and embeddings:

claude mcp add --scope user --transport stdio mem0 \
  --env MEM0_PROVIDER=ollama \
  --env MEM0_LLM_MODEL=qwen3:14b \
  --env MEM0_USER_ID=your-user-id \
  -- uvx --from git+https://github.com/elvismdev/mem0-mcp-selfhosted.git mem0-mcp-selfhosted

MEM0_PROVIDER=ollama cascades to both the main LLM and graph LLM providers. Same infrastructure defaults apply (Qdrant on localhost:6333, bge-m3 embeddings). Per-service overrides (e.g. MEM0_LLM_URL, MEM0_EMBED_URL) still work when needed.

Or add it to a single project by creating .mcp.json in the project root:

{
  "mcpServers": {
    "mem0": {
      "command": "uvx",
      "args": ["--from", "git+https://github.com/elvismdev/mem0-mcp-selfhosted.git", "mem0-mcp-selfhosted"],
      "env": {
        "MEM0_PROVIDER": "ollama",
        "MEM0_LLM_MODEL": "qwen3:14b",
        "MEM0_USER_ID": "your-user-id"
      }
    }
  }
}

Try It

Restart Claude Code, then:

> Search my memories for TypeScript preferences
> Remember that I prefer Hatch for Python packaging
> Show me all entities in my knowledge graph

CLAUDE.md Integration

Add these rules to your project's CLAUDE.md (or ~/.claude/CLAUDE.md for global use) so Claude Code proactively uses memory tools throughout the session:

# MCP Servers

- **mem0**: Persistent memory across sessions. At the start of each session, `search_memories` for relevant context before asking the user to re-explain anything. Use `add_memory` whenever you discover project architecture, coding conventions, debugging insights, key decisions, or user preferences. Use `update_memory` when prior context changes. Save information like: "This project uses PostgreSQL with Prisma", "Tests run with pytest -v", "Auth uses JWT validated in middleware". When in doubt, save it, future sessions benefit from over-remembering.

This gives Claude Code behavioral instructions to actively search and save memories during the session. For best results, combine with Claude Code Hooks, the CLAUDE.md rules tell Claude how to use memory tools mid-session, while hooks handle the automatic injection and saving at session boundaries.

Claude Code Hooks

Session hooks automate memory at session boundaries, injecting memories on startup and saving summaries on exit. This happens automatically without manual tool calls.

Hook	Event	What it does
`mem0-hook-context`	SessionStart (`startup`, `compact`)	Searches mem0 for project-relevant memories and injects them as `additionalContext`
`mem0-hook-stop`	Stop	Reads the last ~3 user/assistant exchanges from the transcript and saves a summary to mem0 via `infer=True`

Both hooks are non-fatal, if mem0 is unreachable or any error occurs, Claude Code continues normally.

Install

Install hooks into your project:

mem0-install-hooks

Or install globally (all projects):

mem0-install-hooks --global

This adds the hook entries to .claude/settings.json. The installer is idempotent, running it twice won't create duplicates.

How it works

On session start, the context hook searches mem0 with two queries (project architecture + recent session summaries), deduplicates by memory ID, and formats the results as numbered lines under a # mem0 Cross-Session Memory header. These are injected via the hook's additionalContext response field.

On session stop, the stop hook reads the JSONL transcript, extracts the last 6 user/assistant messages (a sliding window via bounded deque), builds a summary prompt, and calls memory.add(infer=True) to extract atomic facts. Graph is force-disabled in hooks to stay within the 15s/30s timeout budgets.

Entry points

Command	Function	Registered in `pyproject.toml`
`mem0-hook-context`	`hooks:context_main`	SessionStart hook
`mem0-hook-stop`	`hooks:stop_main`	Stop hook
`mem0-install-hooks`	`hooks:install_main`	CLI installer

Hooks + CLAUDE.md

Hooks and CLAUDE.md are complementary layers that work best together:

Layer	Role	When
Hooks	Automated data flow, injects stored memories on startup, saves session summaries on exit	Session boundaries (start/stop)
CLAUDE.md	Behavioral instructions, tells Claude to actively search and save memories during the session	Throughout the session

Hooks alone give you passive recall (memories appear at startup) and passive saving (summaries saved at exit). CLAUDE.md instructions add active mid-session behavior, Claude searches for relevant memories when encountering new topics, and saves important discoveries immediately rather than waiting for session end.

For the best experience, use both. Hooks ensure memories flow in and out automatically at session boundaries, while CLAUDE.md ensures Claude actively engages with memory tools during the session.

Authentication

The server resolves an Anthropic token using a prioritized fallback chain:

Priority	Source	Details
1	`MEM0_ANTHROPIC_TOKEN` env var	Explicit, user-controlled
2	`~/.claude/.credentials.json`	Auto-reads Claude Code's OAT token (zero-config)
3	`ANTHROPIC_API_KEY` env var	Standard pay-per-use API key
4	Disabled	Warns and disables Anthropic LLM features

In Claude Code, priority 2 always wins, the credentials file exists as long as you're logged in. This means ANTHROPIC_API_KEY (priority 3) is never reached. To override the OAT token in Claude Code, use MEM0_ANTHROPIC_TOKEN (priority 1). ANTHROPIC_API_KEY is only useful for non-Claude-Code deployments (Docker, CI, standalone).

OAT tokens (sk-ant-oat...) use your Claude subscription. The server automatically detects the token type and configures the SDK accordingly. OAT tokens are automatically refreshed before expiry: the server proactively checks the token lifetime and refreshes via the Anthropic OAuth endpoint when nearing expiry (default: 30 minutes). On authentication failures, a 3-step defensive strategy kicks in, piggybacking on Claude Code's credentials file, self-refreshing via OAuth, and wait-and-retry, so long-running sessions survive token rotation seamlessly.

API keys (sk-ant-api...) use standard pay-per-use billing.

Tools

Memory Tools (9 core)

Tool	Description
`add_memory`	Store text or conversation history as memories. Supports `enable_graph`, `infer`, `metadata`.
`search_memories`	Semantic search with optional `filters`, `threshold`, `rerank`, `enable_graph`.
`get_memories`	List/filter memories (non-search). Supports `limit` and scope filters.
`get_memory`	Fetch a single memory by UUID.
`update_memory`	Replace memory text. Re-embeds and re-indexes in Qdrant.
`delete_memory`	Delete a single memory by UUID.
`delete_all_memories`	Bulk-delete all memories in a scope.
`list_entities`	List users/agents/runs with memory counts. Uses Qdrant Facet API.
`delete_entities`	Cascade-delete an entity and all its memories.

Graph Tools

Tool	Description
`search_graph`	Search Neo4j entities by name substring. Returns entities + outgoing relationships.
`get_entity`	Get all relationships for an entity (bidirectional: incoming + outgoing).

Prompt

The server registers a memory_assistant MCP prompt that provides Claude with a quick-start guide for using the memory tools effectively.

Parameters

All tools use Pydantic Annotated[type, Field(description=...)] for self-documenting parameter schemas. Common patterns:

user_id defaults to MEM0_USER_ID env var when not provided
enable_graph overrides the default MEM0_ENABLE_GRAPH per-call
filters supports structured operators: {"key": {"eq": "value"}}, {"AND": [...]}
All responses are JSON strings via json.dumps(result, ensure_ascii=False)

Configuration

All configuration is via environment variables. Create a .env file or set them in your MCP config.

Authentication

Variable	Default	Description
`MEM0_ANTHROPIC_TOKEN`	--	Anthropic OAT or API token (priority 1)
`ANTHROPIC_API_KEY`	--	Standard Anthropic API key (priority 3)
`MEM0_OAT_HEADERS`	`auto`	OAT identity headers: `auto` or `none`
`MEM0_OAT_REFRESH_THRESHOLD_SECONDS`	`1800`	Seconds before expiry to trigger proactive OAT token refresh

LLM

Variable	Default	Description
`MEM0_PROVIDER`	`anthropic`	Top-level provider (`anthropic` or `ollama`). Cascades to `MEM0_LLM_PROVIDER` and `MEM0_GRAPH_LLM_PROVIDER` when those are not set. Does not affect `MEM0_EMBED_PROVIDER`.
`MEM0_LLM_PROVIDER`	(MEM0_PROVIDER)	Main LLM provider: `anthropic` or `ollama`. Inherits from `MEM0_PROVIDER` when not set.
`MEM0_OLLAMA_URL`	`http://localhost:11434`	Shared Ollama base URL. Cascades to `MEM0_LLM_URL`, `MEM0_EMBED_URL`, and `MEM0_GRAPH_LLM_URL` when those are not set.
`MEM0_LLM_MODEL`	(per-provider)	Model for the selected LLM provider. Defaults to `claude-opus-4-6` for Anthropic, `qwen3:14b` for Ollama
`MEM0_LLM_URL`	(cascades)	Ollama base URL for the main LLM. Cascades: `MEM0_LLM_URL` → `MEM0_OLLAMA_URL` → `http://localhost:11434`. Only used when `MEM0_LLM_PROVIDER=ollama`
`MEM0_LLM_MAX_TOKENS`	`16384`	Max tokens for LLM responses (Anthropic only)
`MEM0_GRAPH_LLM_PROVIDER`	(MEM0_PROVIDER)	Graph LLM provider (`anthropic`, `anthropic_oat`, `ollama`, `gemini`, `gemini_split`). Inherits from `MEM0_PROVIDER` when not set.
`MEM0_GRAPH_LLM_URL`	(cascades)	Ollama base URL for graph LLM. Cascades: `MEM0_GRAPH_LLM_URL` → `MEM0_LLM_URL` → `MEM0_OLLAMA_URL` → `http://localhost:11434`
`MEM0_GRAPH_LLM_MODEL`	(varies)	Graph model. Inherits `MEM0_LLM_MODEL` for anthropic/ollama; defaults to `gemini-2.5-flash-lite` for gemini/gemini_split
`GOOGLE_API_KEY`	--	Google API key (required for `gemini`/`gemini_split` graph providers)
`MEM0_GRAPH_CONTRADICTION_LLM_PROVIDER`	`anthropic`	Contradiction LLM provider in `gemini_split` mode (`anthropic`, `anthropic_oat`, `ollama`)
`MEM0_GRAPH_CONTRADICTION_LLM_MODEL`	(provider-aware)	Contradiction model in `gemini_split` mode. Defaults to `claude-opus-4-6` for `anthropic`/`anthropic_oat` providers; inherits `MEM0_LLM_MODEL` for others.
`MEM0_OLLAMA_KEEP_ALIVE`	`30m`	How long Ollama keeps the model in VRAM between calls (e.g., `1h`, `5m`). Prevents model unload during multi-call graph pipelines
`MEM0_OLLAMA_THINK`	`false`	Set to `true` to re-enable qwen3 thinking mode (disabled by default to prevent `<think>` + `format:"json"` collision)

Embedder

Variable	Default	Description
`MEM0_EMBED_PROVIDER`	`ollama`	Embedding provider (`ollama` or `openai`)
`MEM0_EMBED_MODEL`	`bge-m3`	Embedding model name
`MEM0_EMBED_URL`	(cascades)	Ollama URL for embeddings. Cascades: `MEM0_EMBED_URL` → `MEM0_OLLAMA_URL` → `http://localhost:11434`
`MEM0_EMBED_DIMS`	`1024`	Embedding vector dimensions

Vector Store (Qdrant)

Variable	Default	Description
`MEM0_QDRANT_URL`	`http://localhost:6333`	Qdrant REST API URL
`MEM0_QDRANT_API_KEY`	--	Qdrant API key (for Qdrant Cloud)
`MEM0_QDRANT_ON_DISK`	`false`	Store vectors on disk (reduces RAM, slower search)
`MEM0_QDRANT_TIMEOUT`	(client default)	Qdrant REST API timeout in seconds (e.g., `30`). Only set if you hit `ReadTimeout` during collection operations
`MEM0_COLLECTION`	`mem0_mcp_selfhosted`	Qdrant collection name

Graph Store (Neo4j)

Variable	Default	Description
`MEM0_ENABLE_GRAPH`	`false`	Enable graph memory (entity extraction to Neo4j)
`MEM0_NEO4J_URL`	`bolt://127.0.0.1:7687`	Neo4j Bolt endpoint
`MEM0_NEO4J_USER`	`neo4j`	Neo4j username
`MEM0_NEO4J_PASSWORD`	`mem0graph`	Neo4j password
`MEM0_NEO4J_DATABASE`	--	Neo4j database name (multi-database setups)
`MEM0_NEO4J_BASE_LABEL`	--	Custom Neo4j base label for node type grouping
`MEM0_GRAPH_THRESHOLD`	`0.7`	Embedding similarity threshold for node matching

Server

Variable	Default	Description
`MEM0_TRANSPORT`	`stdio`	Transport: `stdio`, `sse`, or `streamable-http`
`MEM0_HOST`	`0.0.0.0`	Host for SSE/HTTP transports
`MEM0_PORT`	`8081`	Port for SSE/HTTP transports
`MEM0_USER_ID`	`user`	Default user ID for memory scoping
`MEM0_LOG_LEVEL`	`INFO`	Logging level (`DEBUG`, `INFO`, `WARNING`, `ERROR`)
`MEM0_HISTORY_DB_PATH`	--	SQLite path for memory change history

Architecture

Claude Code
  |
  ├── MCP stdio/SSE/streamable-http
  │     |
  │     ├── env.py               ← Centralized env var readers (whitespace-safe)
  │     ├── auth.py              ← Hybrid token fallback chain + OAT self-refresh
  │     ├── llm_anthropic.py     ← Custom Anthropic LLM provider (OAT + structured outputs)
  │     ├── llm_ollama.py        ← Custom Ollama LLM provider (restored tool-calling)
  │     ├── config.py            ← Env vars → MemoryConfig dict (provider + URL cascades)
  │     ├── helpers.py           ← Error wrapper, concurrency lock, safe bulk-delete, monkey-patches
  │     ├── graph_tools.py       ← Direct Neo4j Cypher queries (lazy driver)
  │     ├── llm_router.py        ← Split-model graph LLM router (gemini_split)
  │     ├── __init__.py          ← Telemetry suppression (before any mem0 import)
  │     └── server.py            ← FastMCP orchestrator (11 tools + prompt)
  │           |
  │           ├── mem0ai Memory class
  │           │     ├── Vector: LLM fact extraction → Ollama embed → Qdrant
  │           │     └── Graph: LLM entity extraction (tool calls) → Neo4j
  │           |
  │           └── Infrastructure
  │                 ├── Qdrant          ← Vector store
  │                 ├── Ollama          ← Embeddings
  │                 ├── Neo4j           ← Knowledge graph (optional)
  │                 └── Anthropic/Ollama ← Main LLM (configurable)
  |
  └── Session Hooks (subprocess, not MCP)
        |
        └── hooks.py             ← Cross-session memory (SessionStart + Stop hooks)
              ├── context_main()   → Injects memories as additionalContext on startup/compact
              ├── stop_main()      → Saves session summary to mem0 on exit
              └── install_main()   → CLI to patch .claude/settings.json

Graph Memory & Quota

Graph memory is disabled by default (MEM0_ENABLE_GRAPH=false) to protect your Claude quota. Each add_memory with graph enabled triggers 3 additional LLM calls for entity extraction, relationship generation, and conflict resolution.

Using Ollama for Graph Operations

To eliminate Claude quota usage for graph ops, use a local Ollama model:

MEM0_ENABLE_GRAPH=true
MEM0_GRAPH_LLM_PROVIDER=ollama
MEM0_GRAPH_LLM_MODEL=qwen3:14b

Qwen3:14b has 0.971 tool-calling F1 (nearly matching GPT-4's 0.974) and runs in ~7-8GB VRAM with Q4_K_M quantization.

Using Gemini for Graph Operations

Google's Gemini 2.5 Flash Lite is the cheapest option for graph ops while maintaining strong entity extraction accuracy:

MEM0_ENABLE_GRAPH=true
MEM0_GRAPH_LLM_PROVIDER=gemini
MEM0_GRAPH_LLM_MODEL=gemini-2.5-flash-lite
GOOGLE_API_KEY=your-google-api-key

Using Split-Model for Best Accuracy

The gemini_split provider routes graph pipeline calls to different LLMs based on the operation. Entity extraction (Calls 1 & 2) goes to Gemini for speed and cost; contradiction detection (Call 3) goes to Claude for accuracy.

MEM0_ENABLE_GRAPH=true
MEM0_GRAPH_LLM_PROVIDER=gemini_split
GOOGLE_API_KEY=your-google-api-key
MEM0_GRAPH_CONTRADICTION_LLM_PROVIDER=anthropic
MEM0_GRAPH_CONTRADICTION_LLM_MODEL=claude-opus-4-6

Benchmark results across 248 test cases: Gemini scores 85.4% on entity extraction (vs Claude's 79.1%), while Claude scores 100% on contradiction detection (vs Gemini's 80%). The split-model combines the best of both.

Transport Modes

Mode	Use Case	Config
`stdio` (default)	Claude Code integration	`MEM0_TRANSPORT=stdio`
`sse`	Legacy remote clients	`MEM0_TRANSPORT=sse`
`streamable-http`	Modern remote clients	`MEM0_TRANSPORT=streamable-http`

For remote deployments, MCP SDK >= 1.23.0 enables DNS rebinding protection by default.

Development

# Install with dev dependencies
pip install -e ".[dev]"

# Run unit tests
python3 -m pytest tests/unit/ -v

# Run contract tests (validates mem0ai internal API assumptions)
python3 -m pytest tests/contract/ -v

# Run integration tests (requires live Qdrant + Neo4j + Ollama)
python3 -m pytest tests/integration/ -v

# Run all tests
python3 -m pytest tests/ -v

Test Structure

tests/unit/ -- Pure unit tests with mocked dependencies (env, auth, config, config matrix, concurrency, MCP protocol, helpers, hooks, LLM providers, graph tools, LLM router, server)
tests/contract/ -- Validates assumptions about mem0ai internals (schema detection invariant, vector_store.client access path, LlmFactory registration idempotency)
tests/integration/ -- Live infrastructure tests (memory lifecycle, graph ops, bulk operations, hooks) against real Qdrant + Neo4j + Ollama. Marked with @pytest.mark.integration.

Contract tests catch breaking changes in mem0ai upgrades before they reach production.

Telemetry

All mem0ai telemetry is suppressed. os.environ["MEM0_TELEMETRY"] = "false" is set at package import time, before any mem0 module is loaded. No PostHog events are sent.

License

MIT

Available Tools

11 tools

add_memoryA

Store a new memory. Requires at least one of user_id, agent_id, or run_id.

ParametersJSON Schema

Name	Required	Description
`text`	Yes	Text to store as a memory. Converted to messages format internally.
`messages`	No	Structured conversation history (role/content dicts). When provided, takes precedence over text.
`user_id`	No	User scope identifier. Defaults to MEM0_USER_ID.
`agent_id`	No	Agent scope identifier.
`run_id`	No	Run scope identifier.
`metadata`	No	Arbitrary metadata JSON to store alongside the memory.
`infer`	No	If true (default), LLM extracts key facts. If false, stores raw text.
`enable_graph`	No	Override default graph toggle for this call.

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.7/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries full burden but only states 'Store a new memory.' It omits behavioral traits such as whether this is a write operation, side effects, or authorization needs. The constraint on scope IDs is noted but insufficient for full transparency.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences, front-loaded with the core purpose. Every word adds value, and there is no unnecessary repetition.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (8 parameters, output schema exists), the description is adequate but incomplete. It does not clarify behavior for parameters like 'infer' or 'enable_graph,' though these are documented in the schema. Output schema mitigates need for return value explanation, but the description could provide more behavioral context.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so baseline is 3. The description adds value by stating that at least one of user_id, agent_id, or run_id is required—a cross-parameter constraint not explicit in the schema alone. This justifies a score above baseline.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'Store a new memory,' which is a specific verb+resource. It distinguishes this from sibling tools like delete_memory or get_memories, which have different purposes.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description includes a requirement ('at least one of user_id, agent_id, or run_id'), which provides context for valid invocations. However, it does not offer guidance on when to use this tool versus alternatives like search_memories or update_memory.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

delete_all_memoriesB

Bulk-delete all memories in the given scope. Requires at least one filter.

    NEVER calls memory.delete_all() — uses safe bulk-delete instead.

ParametersJSON Schema

Name	Required	Description
`user_id`	No	User scope to delete.
`agent_id`	No	Agent scope to delete.
`run_id`	No	Run scope to delete.

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

B3.3/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description must disclose behavioral traits. It mentions using a safe bulk-delete instead of memory.delete_all(), but this is vague. It fails to describe error handling, reversibility, or permission requirements, leaving significant gaps 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.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise with two sentences. The first sentence front-loads the core purpose. The second sentence includes an implementation detail ('NEVER calls memory.delete_all()...') that is somewhat extraneous and could be confusing, slightly reducing conciseness.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (3 optional parameters requiring at least one filter) and the presence of an output schema, the description does not explain what happens when no filter is provided or what the return value indicates (e.g., number of deleted memories). It is incomplete for an agent to confidently invoke the tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 100% coverage, so the descriptions of user_id, agent_id, and run_id are already clear as scope filters. The description adds the constraint that at least one filter must be provided, which adds meaning beyond the schema's default-null indicators. However, it doesn't elaborate on parameter usage beyond this.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool bulk-deletes all memories within a given scope, using specific verbs and resources. It distinguishes itself from sibling 'delete_memory' by implying a bulk operation, and the requirement of at least one filter aligns with the input schema parameters.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides a usage condition: 'Requires at least one filter.' This implies when to use the tool but does not explicitly compare it to alternatives like 'delete_memory' or provide when-not scenarios. The note about using safe bulk-delete gives behavioral context but not usage boundaries.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

delete_entitiesA

Delete an entity and cascade-delete all its memories.

    Functionally equivalent to delete_all_memories in self-hosted mode.

ParametersJSON Schema

Name	Required	Description
`user_id`	No	User entity to delete (cascades to all memories).
`agent_id`	No	Agent entity to delete.
`run_id`	No	Run entity to delete.

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.9/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the burden of disclosing behavioral traits. It clearly states the cascade-delete behavior, which is a key destructive aspect. However, it does not mention irreversibility, required permissions, or potential side effects, which would further enhance transparency.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely concise with two sentences, front-loading the main purpose. Every word is functional, and there is no unnecessary information. It efficiently communicates the core functionality.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's destructive nature and zero annotations, the description could be more complete. It does not mention return values (though output schema exists) or warn about permanent data loss. It flags the equivalence to delete_all_memories but lacks broader context like error handling or constraints.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with each parameter having a description. The description adds minimal additional meaning beyond what the schema already provides, such as the cascade effect for user_id already noted in the schema. Thus, it meets the baseline of 3 without significant enhancement.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: deleting an entity and cascade-deleting all its memories. It also distinguishes itself by noting functional equivalence to delete_all_memories in self-hosted mode, which helps differentiate from sibling tools like delete_all_memories.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides minimal guidance on when to use this tool. It only mentions functional equivalence to delete_all_memories in self-hosted mode, implying a context-dependent preference, but does not explicitly state when to use this tool versus alternatives or provide prerequisites.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

delete_memoryC

Delete a single memory.

ParametersJSON Schema

Name	Required	Description	Default
`memory_id`	Yes	Exact memory UUID to delete.

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

C2.8/5.0

Behavior1/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description must disclose behavioral traits. It only states the action without mentioning destructive nature, permissions needed, 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.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence, which is concise but under-specified for a tool with no annotations. It could include more context without being verbose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Despite having an output schema, the description does not mention return values or behavior on failure. For a destructive operation, more context is needed.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% and describes the parameter as 'Exact memory UUID to delete.' The description adds no additional meaning beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description 'Delete a single memory' clearly states the action (delete), resource (memory), and scope (single), distinguishing it from siblings like delete_all_memories and get_memory.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool versus alternatives like delete_all_memories, nor any prerequisites or disclaimers.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_memoriesA

Page through memories using filters instead of search.

ParametersJSON Schema

Name	Required	Description
`user_id`	No	User scope. Defaults to MEM0_USER_ID.
`agent_id`	No	Agent scope.
`run_id`	No	Run scope.
`limit`	No	Maximum number of memories to return.

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.5/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description must disclose behavioral traits. It mentions pagination and filtering but lacks details on read-only nature, authentication needs, rate limits, pagination mechanics (e.g., cursor, offset), or behavior when no memories match. The contrast with 'search' is vague.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, clear sentence that is front-loaded and free of unnecessary words. It is appropriately short for a simple tool, though it could benefit from a bit more detail without becoming verbose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the presence of an output schema (not shown), the description need not explain return values. The tool is straightforward, with 0 required parameters and clear schema. However, pagination behavior (e.g., default limit, ordering) is not addressed, slightly reducing completeness.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 100% description coverage, so each parameter (user_id, agent_id, run_id, limit) is already documented in the schema. The description adds no further meaning beyond what the schema provides, earning a baseline score of 3.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: 'Page through memories using filters instead of search.' It uses a specific verb ('page through'), identifies the resource ('memories'), and explicitly contrasts with 'search' (sibling tool search_memories), distinguishing it effectively.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for paginated filtering rather than search, but does not explicitly state when to use this tool vs. alternatives like search_memories. No clear prerequisites or exclusions are provided, leaving room for ambiguity.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_memoryA

Fetch a single memory by its ID.

ParametersJSON Schema

Name	Required	Description	Default
`memory_id`	Yes	Exact memory UUID to fetch.

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.8/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries full burden. 'Fetch' implies a read-only operation but does not disclose error handling (e.g., behavior when memory_id not found). For a simple retrieval, this is minimally adequate.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, concise sentence with no superfluous words. It is front-loaded and immediately understandable.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has one parameter and an output schema (assumed from context signal), the description covers the essential purpose. It lacks explicit mention of error cases or return format, but these are partially addressed by the output schema. Completeness is high for such a simple tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema already provides a clear description for memory_id ('Exact memory UUID to fetch'). The tool description adds no additional parameter information beyond the schema. With 100% schema coverage, score is at baseline 3.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description 'Fetch a single memory by its ID' clearly states the verb ('Fetch'), resource ('memory'), and scope ('single by ID'). It naturally distinguishes from sibling tools like get_memories (plural) and add_memory.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description does not provide explicit guidance on when to use this tool versus alternatives (e.g., get_memories for listing, search_memories for queries). The usage is implied by the purpose, but no direct comparison or exclusions are stated.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

list_entitiesA

List which users/agents/runs currently hold memories.

Uses Qdrant Facet API (v1.12+) for server-side aggregation, with scroll+dedupe fallback for older versions.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.2/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Discloses internal behavior (Qdrant Facet API with fallback) and implies read-only nature. Since no annotations exist, this adds valuable context beyond what structured fields provide.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, each earning its place: first states purpose, second adds technical transparency. No wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Covers purpose and internal behavior succinctly. With an output schema present, return values need not be described. Slightly lacking on when to use versus siblings.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Zero parameters with 100% schema description coverage (trivially). Description adds no parameter details but is unnecessary due to lack of parameters.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'List' and the resource 'which users/agents/runs currently hold memories'. It distinguishes from sibling tools like get_memories and search_memories by focusing on entities that hold memories.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides version-specific implementation details but no explicit guidance on when to use this tool versus alternatives like search_memories or mcp_get_entity. Usage context is implied but not stated.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_get_entityA

Get all relationships for a specific entity (bidirectional).

ParametersJSON Schema

Name	Required	Description	Default
`name`	Yes	Exact entity name to look up.

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.6/5.0

Behavior3/5

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. It indicates a read-only operation (fetches relationships) and mentions bidirectionality, which is helpful. However, it does not clarify side effects (likely none), error cases (e.g., entity not found), or performance characteristics. The description is adequate but minimal.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely concise at one sentence (9 words), front-loading the core functionality. Every word is necessary, and there is no redundancy or unnecessary information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the existence of an output schema (which presumably defines the response structure), the description does not need to explain return values. It covers the basic purpose and scope (all relationships, bidirectional). However, it could optionally mention what happens if the entity has no relationships or is not found. Still, it is largely complete for a simple lookup tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema provides full description coverage (100%) for the single parameter 'name' with clear documentation ('Exact entity name to look up'). The description adds only the 'bidirectional' scope but does not enhance parameter understanding beyond the schema. Baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool retrieves all relationships for a specific entity, with bidirectional semantics. It uses a specific verb ('Get') and resource ('relationships for a specific entity'), and distinguishes from sibling tools like list_entities (which lists entities, not relationships) and mcp_search_graph (which is for graph-wide searches).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description does not provide explicit guidance on when to use this tool versus alternatives. It lacks context about prerequisites, limitations, or when not to use it. Sibling tools like search_memories or mcp_search_graph might also retrieve relationship information, but no comparison is offered.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_search_graphA

Search entities by name/id substring matching in Neo4j knowledge graph.

ParametersJSON Schema

Name	Required	Description	Default
`query`	Yes	Entity or topic to search for (e.g., 'Python', 'TypeScript').

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Description discloses substring matching behavior, which is helpful. But no annotations exist, so description should also cover case sensitivity, pagination, limits, or what exactly 'name/id' means. It's somewhat transparent but lacks depth.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Single sentence with no wasted words. Front-loaded with action. Perfectly concise for a simple tool.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the output schema likely describes return format, the description covers the search mechanism. Missing details like case sensitivity or pagination would improve completeness, but not critical for a simple 1-param tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema provides basic description for 'query' param. Description adds context about substring matching on name/id, which goes beyond schema's generic 'Entity or topic to search for'. High schema coverage (100%) but description still adds value.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states the tool searches entities by substring matching on name/id, which is specific and distinguishes from siblings like list_entities or mcp_get_entity.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Description implies usage for substring searches but does not explicitly state when to use vs alternatives like list_entities (all entities) or mcp_get_entity (exact match). No exclusions provided.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

search_memoriesC

Semantic search across existing memories.

ParametersJSON Schema

Name	Required	Description
`query`	Yes	Natural language description of what to find.
`user_id`	No	User scope. Defaults to MEM0_USER_ID.
`agent_id`	No	Agent scope.
`run_id`	No	Run scope.
`filters`	No	Additional structured filter clauses.
`limit`	No	Maximum number of results.
`threshold`	No	Minimum relevance score (0.0-1.0).
`rerank`	No	Whether to apply reranking.
`enable_graph`	No	Override default graph toggle.

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

C2.9/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are present, so the description must disclose behavior. It only says 'semantic search' without stating that it is read-only, what the output format is (though output schema exists), or any side effects. Minimal behavioral context is provided.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely concise, consisting of only two words plus context. While it could be more informative without becoming verbose, it avoids unnecessary fluff and is clearly structured.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given 9 parameters and no annotations, the description is insufficient. It does not explain how filtering works, the role of threshold/rerank, or how this tool relates to sibling tools like get_memories or mcp_search_graph. The output schema partially compensates, but the description lacks essential context.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

All 9 parameters have descriptions in the input schema (100% coverage), so the description adds no extra information beyond the schema. The baseline of 3 is appropriate as the schema already documents parameters adequately.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it performs semantic search across memories, distinguishing it from add/get operations. However, it does not explicitly differentiate from other retrieval tools like get_memories, though 'semantic' hints at the difference.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use semantic search versus other retrieval methods (e.g., get_memories) or alternative tools like list_entities. The description lacks any context for appropriate usage.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

update_memoryA

Overwrite an existing memory's text. Re-embeds and re-indexes.

ParametersJSON Schema

Name	Required	Description	Default
`memory_id`	Yes	Exact memory UUID to update.
`text`	Yes	Replacement text for the memory.

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description provides valuable behavioral context: it re-embeds and re-indexes, which is a side effect beyond the basic operation. This aids an agent in understanding consequences, though it could be more comprehensive about error states or idempotency.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, front-loaded with the main action. Every word adds value: 'Overwrite' is specific, and the side effects are succinctly stated. No redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity and 100% schema coverage, the description is largely complete. It covers the operation and a key side effect. Missing details like return format or prerequisite that memory exists, but output schema exists (though not provided) and context is nearly sufficient.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so baseline is 3. The description adds no extra meaning beyond the schema; it mentions 'text' but not 'memory_id'. The parameter types are self-explanatory from the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool overwrites an existing memory's text, using a specific verb ('overwrite') and resource ('memory's text'). It distinguishes from siblings like add_memory (creation) and delete_memory (removal) by focusing on update.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for updating an existing memory's text, but does not explicitly state when to use it versus alternatives (e.g., when to add vs update), nor does it provide exclusions or prerequisites.

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. Dates show when Glama detected each change.

11 tool updatesv0.3.2Mar 12, 2026
- First observedadd_memory
- First observeddelete_all_memories
- First observeddelete_entities
- First observeddelete_memory
- First observedget_memories
- First observedget_memory
- First observedlist_entities
- First observedmcp_get_entity
- First observedmcp_search_graph
- First observedsearch_memories
- First observedupdate_memory

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.7/5.0

Disambiguation4/5

Most tools have distinct purposes: add, get, update, delete, search, and entity management. However, delete_all_memories and delete_entities could be confused as both are bulk deletions, and get_memories vs search_memories may cause ambiguity despite different filtering/semantic approaches.

Naming Consistency4/5

The majority follow a consistent verb_noun pattern (e.g., add_memory, delete_memory). Two tools (mcp_get_entity, mcp_search_graph) deviate with an 'mcp_' prefix, breaking the otherwise uniform style.

Tool Count5/5

With 11 tools, the server covers core memory CRUD, search, and entity operations without being excessive. This count is well-scoped for a focused memory management MCP server.

Completeness5/5

The tool surface includes creation, retrieval (by ID, pagination, semantic search), update, and multiple deletion methods, plus entity listing and graph search. This provides comprehensive lifecycle coverage for agent memory management.

Maintenance

ActivityInactive

ResponsivenessUnresponsive

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

nexsusOAuth
io.github.dbnexsus
Private persistent memory for Claude, ChatGPT & Gemini via MCP - semantic search, zero-code setup.
Knowledge & Memory RAG Systems
2
Remote Desktop CommanderOAuth
app.desktopcommander
Hosted MCP server connecting claude.ai, ChatGPT and other AI apps to your own computer
Shell Access OS Automation
214
UltraMemoryOAuth
io.github.LogicLabsAI
One memory, every AI: Claude, ChatGPT, Perplexity, Gemini, Cursor, OpenClaw, Hermes, any MCP client.
Knowledge & Memory Autonomous Agents
21
mifactory-agent-memory C
io.github.mifactory-bot
Persistent memory for AI agents across Claude, ChatGPT and any MCP client.
Knowledge & Memory Autonomous Agents Agent Orchestration
22

Related MCP Servers

mcp-server-claude
RAG Systems Knowledge & Memory
zcc-cddg-mx
A
license
Not graded
quality
D
maintenance
MCP Memory Server for Claude Code that provides persistent context across sessions using semantic search (RAG).
Updated 2 months ago (2026-06-29 19:22 UTC)
Apache 2.0
mem0-mcpofficial
Knowledge & Memory Vector Databases Search
tensakulabs
A
license
A
quality
C
maintenance
Self-hosted Mem0 MCP server integrating Qdrant, Neo4j, and Ollama for semantic memory search, graph entity relationships, and memory management via OpenMemory API.
Updated 7 months ago (2026-02-14 09:29 UTC)
6
4
MIT
mem0-local-mcp
Knowledge & Memory Vector Databases
sanchezvivi
A
license
Not graded
quality
C
maintenance
A fully local, self-hosted memory server for MCP clients (Claude Code, Cursor, etc.) that provides persistent memory storage with semantic search, using local embeddings and a local Qdrant vector store.
Updated 2 months ago (2026-06-24 19:08 UTC)
MIT
mem0-mcp
Knowledge & Memory Autonomous Agents
andresmorales07
A
license
A
quality
A
maintenance
A server that wraps a self-hosted mem0 REST API as MCP tools for Claude Desktop and Claude Code, enabling memory operations such as adding, searching, and managing memories via natural language.
Updated 2 months ago (2026-07-05 16:23 UTC)
6
1
MIT

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/elvismdev/mem0-mcp-selfhosted'

If you have feedback or need assistance with the MCP directory API, please join our Discord server

mem0-mcp-selfhosted

Prerequisites

Quick Start

Default (Anthropic)

Fully Local (Ollama)

Try It

CLAUDE.md Integration

Claude Code Hooks

Install

How it works

Entry points

Hooks + CLAUDE.md

Authentication

Tools

Memory Tools (9 core)

Graph Tools

Prompt

Parameters

Configuration

Authentication

LLM

Embedder

Vector Store (Qdrant)

Graph Store (Neo4j)

Server

Architecture

Graph Memory & Quota

Using Ollama for Graph Operations

Using Gemini for Graph Operations

Using Split-Model for Best Accuracy

Transport Modes

Development

Test Structure

Telemetry

License

Available Tools

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Tool Schema Changelog

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

mem0-mcpofficial

Latest Blog Posts

MCP directory API