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 Source Related Servers Discussions Admin

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_memoriesA

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

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 the full burden. It discloses that the tool does not call raw delete_all but uses a safe bulk-delete, implying safety. However, it omits details on destructiveness, reversibility, or auth needs, which are important for a deletion tool.

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 highly concise: two sentences that front-load the purpose and key constraint (requires filter). Every sentence earns its place with no redundancy.

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?

While the description covers purpose and filter requirement, it lacks return value information. There is no output schema to compensate, so the agent is left guessing about what the tool returns (e.g., count, confirmation). For a bulk deletion tool, this is a notable gap.

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 clear descriptions for each parameter (run_id, user_id, agent_id). The description adds no additional meaning beyond the schema, so 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 verb ('Bulk-delete') and resource ('all memories in the given scope'). It distinguishes from siblings like 'delete_memory' by specifying bulk operation and requiring a filter.

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

Usage Guidelines4/5

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

The description explicitly says 'Requires at least one filter,' providing clear usage context. It also notes the safe bulk-delete implementation, but does not explicitly mention alternatives like 'delete_memory' for single deletions or when not to use.

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.7/5.0

Behavior3/5

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

With no annotations, the description carries the full burden. It discloses cascade-deletion behavior, but does not mention irreversibility, required permissions, or error states. The description is adequate but not rich.

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 concise sentences with no fluff. The first states the core action, the second provides helpful context. Every sentence earns its place.

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?

The description and schema together cover the basic delete behavior, but they do not specify that exactly one entity identifier must be provided. Given the absence of required parameters, this is a notable gap. An output schema exists but its contents are not visible.

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 the schema already describes each parameter. The description adds 'cascade-delete all its memories' but this is implicitly clear from the schema. No additional semantic value beyond what the schema provides.

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 'delete' and resource 'entity', and specifies cascade-deletion of memories. It also distinguishes itself by noting functional equivalence to delete_all_memories, differentiating from sibling tools that delete single 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 mentions equivalence to delete_all_memories but does not explicitly guide when to use this tool versus alternatives like delete_memory or delete_all_memories. It lacks explicit when-to-use or when-not-to-use instructions.

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

delete_memoryB

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

B3.4/5.0

Behavior2/5

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

With no annotations, the description carries the full burden but only states the destructive action. No details on permissions, reversibility, or side effects are provided.

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?

Extremely concise at 4 words, front-loaded with the action, and no wasted text. Appropriate 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?

For a straightforward delete tool with one parameter and an output schema, the description covers the basic purpose. However, it lacks any additional context such as requirements or limitations.

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% for the single parameter, but the description adds no extra meaning beyond the schema's 'Exact memory UUID to delete.' Baseline 3 is appropriate as the description does not enhance parameter understanding.

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' uses a specific verb and resource, clearly distinguishing 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 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 such as delete_all_memories or delete_entities. The description lacks context for usage decisions.

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.7/5.0

Behavior2/5

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

No annotations are provided, so the description carries full burden. It implies a read operation but does not disclose pagination mechanics, ordering, rate limits, or any side effects. The behavioral disclosure is 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?

A single 8-word sentence that is front-loaded and contains no wasted words, perfectly concise.

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?

Output schema exists, so return values are covered. The description addresses the core purpose but omits details like pagination requiring multiple calls, default limits, or sorting. It is minimally complete.

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 description coverage is 100%, so the schema already documents all parameters. The description adds only the high-level hint 'using filters', providing no extra meaning. 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 'Page through memories using filters instead of search' clearly specifies the verb ('page through'), resource ('memories'), and contrasts with the sibling tool 'search_memories', making the purpose unambiguous.

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

Usage Guidelines4/5

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

The description explicitly states 'instead of search', guiding the agent to use this tool when filtering rather than full-text searching. It gives clear context but does not explicitly list when not to use or describe prerequisites.

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

get_memoryB

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

B3/5.0

Behavior2/5

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

No annotations provided, and description only says 'fetch', implying read-only but omitting behaviors like error handling, return format, or rate limits.

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?

Very concise single sentence, but it lacks necessary context; conciseness is achieved at the expense of completeness.

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 simple tool (1 parameter, output schema exists), description misses usage context and behavioral details, making it incomplete for effective agent use.

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 description 'Exact memory UUID to fetch'; description adds 'by its ID' but that's redundant, not adding value beyond 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?

Description clearly states the verb 'fetch', resource 'a single memory', and method 'by its ID', distinguishing it from siblings like get_memories and search_memories.

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 search_memories or when not to use it; usage is only implied.

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

list_entitiesB

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

B3.2/5.0

Behavior3/5

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

With no annotations, the description provides some behavioral context: it uses server-side aggregation with fallback for older versions. However, it doesn't disclose read-only nature, performance implications, or what 'holds memories' entails.

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 (two sentences) and front-loads the primary purpose. The technical detail about Qdrant is somewhat jargon-heavy but not excessive. No wasted sentences.

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 no parameters and an output schema exists, the description is adequate but lacks context about what 'holds memories' means, the scope of the list, or any constraints. It could be more complete for a tool with many siblings.

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 schema has no parameters and 100% coverage trivially, so baseline is 3. The description adds no parameter information beyond the schema, which is acceptable since there are no parameters.

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 the tool lists which users/agents/runs hold memories. It uses a specific verb and resource, but doesn't explicitly differentiate from sibling list tools like get_memories or search_memories.

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. The description mentions implementation details (Qdrant API) but doesn't help the agent decide when to invoke list_entities over other list/search tools.

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.7/5.0

Behavior3/5

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

With no annotations, the description must disclose behavioral traits. It mentions 'bidirectional', which is useful, but does not clarify if the operation is read-only, requires authentication, has limits, or how the result is structured. Basic transparency but incomplete.

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 sentence that is front-loaded and purposeful. While very concise, it could be slightly expanded with minimal additional detail without sacrificing structure.

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 (from context signals), the description does not need to detail return values. For a one-parameter tool with simple behavior, the description adequately covers the functionality, though some users might want more detail about the bidirectional aspect.

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 the schema already describes the 'name' parameter as 'Exact entity name to look up.' The description adds no additional semantic value beyond what the schema provides, so baseline score of 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's function: 'Get all relationships for a specific entity (bidirectional).' It uses a specific verb ('Get') and resource ('relationships for a specific entity'), and highlights bidirectional behavior, distinguishing it from sibling tools like mcp_search_graph.

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 when needing all relationships of an entity, but does not explicitly state when to use this tool versus alternatives (e.g., mcp_search_graph) or 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.

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

A3.5/5.0

Behavior2/5

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

No annotations are provided, so the description bears full responsibility for behavioral disclosure. It mentions 'substring matching' but omits critical details like case sensitivity, scope of search (e.g., nodes/relationships), and whether the tool is read-only. This leaves the agent uncertain about behavior.

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 sentence with no redundant words. It is front-loaded and efficient, earning its place with specific verb and resource.

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?

The tool is simple (one parameter, output schema exists), but the description does not clarify the substring matching behavior or what entity types are searched. The output schema exists but the agent might benefit from knowing the matching semantics. Overall adequate but has gaps.

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% for the single parameter 'query', and the description adds minimal extra meaning beyond the schema's description. It does not provide format, length limits, or examples 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 searches entities by name/id substring matching in a Neo4j knowledge graph. It uses a specific verb ('search') and resource ('entities'), and distinguishes from siblings like 'search_memories' (searches memories) and 'mcp_get_entity' (likely gets a specific 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?

The description provides no explicit when-to-use or when-not-to-use guidance. It neither mentions alternatives nor exclusions. Usage is implied (searching entities), but no differentiation from similar tools like 'list_entities' or 'search_memories' is given.

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

A3.6/5.0

Behavior3/5

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

Discloses that the operation re-embeds and re-indexes, adding value beyond the basic update. However, given no annotations, more behavioral details (e.g., error cases, idempotency) would be beneficial.

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 short sentences with no wasted words, efficiently conveying the core action and key side effect.

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?

For a simple two-parameter tool, the description is fairly complete. It could mention return value behavior but output schema exists to cover that.

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 parameter descriptions are clear. The description adds no extra meaning beyond what the schema provides, meeting the 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?

Clearly states the action: 'Overwrite an existing memory's text' with specific verb and resource, distinguishing it from siblings like add_memory and delete_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 explicit guidance on when to use this tool versus alternatives such as get_memory or delete_memory. Usage context is only implied.

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.

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

Deploy Server

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A3.7/5.0

Scored 2026-05-01 01:50 across 11 tools

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

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
219
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 3 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
D
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 3 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

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

Related MCP Connectors

Related MCP Servers

mem0-mcpofficial