Skip to main content
Glama

Mem0 MCP Logo

npm version License: MIT Node.js TypeScript MCP Mem0 Downloads GitHub Stars

@pinkpixel/mem0-mcp MCP Server ✨

A Model Context Protocol (MCP) server that integrates with Mem0.ai to provide persistent memory capabilities for LLMs. It allows AI agents to store and retrieve information across sessions.

This server uses the mem0ai Node.js SDK for its core functionality.

Features 🧠

Modernized & Advanced Tools (v0.8.0)

  • add_memory: Stores a memory from text content or structured message arrays.

    • Inputs: content (string) or messages (array of role/content objects), userId (string), runId / sessionId (string), agentId (string), appId (string), metadata (object), infer (boolean), customInstructions (string), waitForCompletion (boolean, default: true), timeoutMs (number, default: 15000)

    • Behavior: Cloud V3 additions are asynchronous. By default, this tool polls the background queue until completed. Pass waitForCompletion: false to get the eventId immediately.

  • search_memories: Searches memories using semantic and BM25 hybrid filters.

    • Inputs: query (string), userId (string), runId / sessionId (string), agentId (string), appId (string), filters (object), threshold (number), topK (number), rerank (boolean), referenceDate (string)

    • Behavior: Automatically nests scope variables inside the V3 filters block to prevent API validation errors.

  • search_memory: Backward-compatible alias for search_memories.

  • list_memories: Paginated listing of memory records scoped by identifiers.

    • Inputs: userId (string), runId / sessionId (string), agentId (string), appId (string), filters (object), page (number), pageSize (number)

  • get_memory: Retrieves a single memory record by its ID.

    • Inputs: memoryId (string)

  • update_memory: Modifies the text or metadata of an existing memory.

    • Inputs: memoryId (string), text (string), metadata (object)

  • delete_memory: Deletes a specific memory record by ID.

    • Inputs: memoryId (string)

  • get_memory_history: Retrieves the audit trail of memory revisions (cloud only).

    • Inputs: memoryId (string)

  • get_memory_capabilities: Exposes the feature matrix and support flags of the active backend storage mode.

    • Inputs: None

  • batch_update_memories: Performs bulk updates of text contents for multiple memories (cloud only).

    • Inputs: updates (array of { memoryId: string, text: string } objects)

  • batch_delete_memories: Performs bulk deletions of multiple memories.

    • Inputs: memoryIds (array of strings), confirm (boolean, must be true to execute)

  • rate_memory: Submits quality feedback evaluation for a memory record (cloud only).

    • Inputs: memoryId (string), feedback (string: positive, negative, very_negative), reason (string, optional)

  • get_memory_event: Manually retrieves details of a specific background event job (cloud only).

    • Inputs: eventId (string)

  • list_memory_events: Lists history logs of background memory processing events (cloud only).

    • Inputs: page (number), pageSize (number)

  • create_memory_export: Initiates an asynchronous memory export query job (cloud only).

    • Inputs: schema (object), filters (object, optional), exportInstructions (string, optional)

  • get_memory_export: Retrieves status and download metadata of a memory export job (cloud only).

    • Inputs: exportId (string)

Related MCP server: mindcore-memory-mcp

Prerequisites šŸ”‘

This server supports three storage modes:

  1. Cloud Storage Mode ā˜ļø (Recommended for production)

    • Requires a Mem0 API key (provided as MEM0_API_KEY environment variable)

    • Memories are persistently stored on Mem0's cloud servers

    • No local database needed

    • Full feature support with advanced filtering and search

  2. Supabase Storage Mode šŸ—„ļø (Recommended for self-hosting)

    • Requires Supabase credentials (SUPABASE_URL and SUPABASE_KEY environment variables)

    • Requires OpenAI API key (OPENAI_API_KEY environment variable) for embeddings

    • Memories are persistently stored in your Supabase database

    • Free tier available, self-hostable option

    • Requires initial database setup (SQL migrations provided below)

  3. Local Storage Mode šŸ’¾ (Development/testing only)

    • Requires an OpenAI API key (provided as OPENAI_API_KEY environment variable)

    • Memories are stored in an in-memory vector database (non-persistent by default)

    • Data is lost when the server restarts unless configured for persistent storage

Installation & Configuration āš™ļø

You can run this server in three main ways:

Installing via Smithery

To install Mem0 Memory Server for Claude Desktop automatically via Smithery:

npx -y @smithery/cli install @pinkpixel-dev/mem0-mcp-server --client claude

Install the package globally and use the mem0-mcp command:

npm install -g @pinkpixel/mem0-mcp

After global installation, you can run the server directly:

mem0-mcp

Configure your MCP client to use the global command:

Cloud Storage Configuration (Global Install)

{
  "mcpServers": {
    "mem0-mcp": {
      "command": "mem0-mcp",
      "args": [],
      "env": {
        "MEM0_API_KEY": "YOUR_MEM0_API_KEY_HERE",
        "DEFAULT_USER_ID": "user123",
        "DEFAULT_AGENT_ID": "your-agent-id",
        "DEFAULT_APP_ID": "your-app-id"
      }
    }
  }
}

Supabase Storage Configuration (Global Install)

{
  "mcpServers": {
    "mem0-mcp": {
      "command": "mem0-mcp",
      "args": [],
      "env": {
        "SUPABASE_URL": "YOUR_SUPABASE_PROJECT_URL",
        "SUPABASE_KEY": "YOUR_SUPABASE_ANON_KEY",
        "OPENAI_API_KEY": "YOUR_OPENAI_API_KEY_HERE",
        "DEFAULT_USER_ID": "user123",
        "DEFAULT_AGENT_ID": "your-agent-id",
        "DEFAULT_APP_ID": "your-app-id"
      }
    }
  }
}

Local Storage Configuration (Global Install)

{
  "mcpServers": {
    "mem0-mcp": {
      "command": "mem0-mcp",
      "args": [],
      "env": {
        "OPENAI_API_KEY": "YOUR_OPENAI_API_KEY_HERE",
        "DEFAULT_USER_ID": "user123"
      }
    }
  }
}

2. Using npx (Recommended for occasional use)

Configure your MCP client (e.g., Claude Desktop, Cursor, Cline, Roo Code, etc.) to run the server using npx:

Cloud Storage Configuration (npx)

{
  "mcpServers": {
    "mem0-mcp": {
      "command": "npx",
      "args": [
        "-y",
        "@pinkpixel/mem0-mcp"
      ],
      "env": {
        "MEM0_API_KEY": "YOUR_MEM0_API_KEY_HERE",
        "DEFAULT_USER_ID": "user123",
        "DEFAULT_AGENT_ID": "your-agent-id",
        "DEFAULT_APP_ID": "your-app-id"
      }
    }
  }
}

Supabase Storage Configuration (npx)

{
  "mcpServers": {
    "mem0-mcp": {
      "command": "npx",
      "args": [
        "-y",
        "@pinkpixel/mem0-mcp"
      ],
      "env": {
        "SUPABASE_URL": "YOUR_SUPABASE_PROJECT_URL",
        "SUPABASE_KEY": "YOUR_SUPABASE_ANON_KEY",
        "OPENAI_API_KEY": "YOUR_OPENAI_API_KEY_HERE",
        "DEFAULT_USER_ID": "user123",
        "DEFAULT_AGENT_ID": "your-agent-id",
        "DEFAULT_APP_ID": "your-app-id"
      }
    }
  }
}

Local Storage Configuration (npx)

{
  "mcpServers": {
    "mem0-mcp": {
      "command": "npx",
      "args": [
        "-y",
        "@pinkpixel/mem0-mcp"
      ],
      "env": {
        "OPENAI_API_KEY": "YOUR_OPENAI_API_KEY_HERE",
        "DEFAULT_USER_ID": "user123"
      }
    }
  }
}

3. Running from Cloned Repository

Note: This method requires you to git clone the repository first.

Clone the repository, install dependencies, and build the server:

git clone https://github.com/pinkpixel-dev/mem0-mcp
cd mem0-mcp
npm install
npm run build

Then, configure your MCP client to run the built script directly using node:

Cloud Storage Configuration (Cloned Repository)

{
  "mcpServers": {
    "mem0-mcp": {
      "command": "node",
      "args": [
        "/absolute/path/to/mem0-mcp/build/index.js"
      ],
      "env": {
        "MEM0_API_KEY": "YOUR_MEM0_API_KEY_HERE",
        "DEFAULT_USER_ID": "user123",
        "DEFAULT_AGENT_ID": "your-agent-id",
        "DEFAULT_APP_ID": "your-app-id"
      }
    }
  }
}

Supabase Storage Configuration (Cloned Repository)

{
  "mcpServers": {
    "mem0-mcp": {
      "command": "node",
      "args": [
        "/absolute/path/to/mem0-mcp/build/index.js"
      ],
      "env": {
        "SUPABASE_URL": "YOUR_SUPABASE_PROJECT_URL",
        "SUPABASE_KEY": "YOUR_SUPABASE_ANON_KEY",
        "OPENAI_API_KEY": "YOUR_OPENAI_API_KEY_HERE",
        "DEFAULT_USER_ID": "user123",
        "DEFAULT_AGENT_ID": "your-agent-id",
        "DEFAULT_APP_ID": "your-app-id"
      }
    }
  }
}

Local Storage Configuration (Cloned Repository)

{
  "mcpServers": {
    "mem0-mcp": {
      "command": "node",
      "args": [
        "/absolute/path/to/mem0-mcp/build/index.js"
      ],
      "env": {
        "OPENAI_API_KEY": "YOUR_OPENAI_API_KEY_HERE",
        "DEFAULT_USER_ID": "user123"
      },
      "disabled": false,
      "alwaysAllow": [
        "add_memory",
        "search_memory",
        "delete_memory"
      ]
    }
  }
}

Important Notes:

  1. Replace /absolute/path/to/mem0-mcp/ with the actual absolute path to your cloned repository

  2. Use the build/index.js file, not the src/index.ts file

  3. The MCP server requires clean stdout for protocol communication - any libraries or code that writes to stdout may interfere with the protocol

Supabase Setup šŸ—„ļø

If you choose to use Supabase storage mode, you'll need to set up your Supabase database with the required table.

1. Create a Supabase Project

  1. Go to supabase.com and create a new project

  2. Note your project URL and anon key from the project settings

2. Run SQL Migrations

Run these SQL commands in your Supabase SQL Editor:

-- Enable the vector extension
create extension if not exists vector;

-- Create the memories table
create table if not exists memories (
  id text primary key,
  embedding vector(1536),
  metadata jsonb,
  created_at timestamp with time zone default timezone('utc', now()),
  updated_at timestamp with time zone default timezone('utc', now())
);

-- Create the vector similarity search function
create or replace function match_vectors(
  query_embedding vector(1536),
  match_count int,
  filter jsonb default '{}'::jsonb
)
returns table (
  id text,
  similarity float,
  metadata jsonb
)
language plpgsql
as $$
begin
  return query
  select
    t.id::text,
    1 - (t.embedding <=> query_embedding) as similarity,
    t.metadata
  from memories t
  where case
    when filter::text = '{}'::text then true
    else t.metadata @> filter
  end
  order by t.embedding <=> query_embedding
  limit match_count;
end;
$$;

-- Create the memory_history table for history tracking
create table if not exists memory_history (
  id text primary key,
  memory_id text not null,
  previous_value text,
  new_value text,
  action text not null,
  created_at timestamp with time zone default timezone('utc', now()),
  updated_at timestamp with time zone,
  is_deleted integer default 0
);

3. Set Environment Variables

Add these to your MCP configuration:

  • SUPABASE_URL: Your Supabase project URL (e.g., https://your-project.supabase.co)

  • SUPABASE_KEY: Your Supabase anon key

  • OPENAI_API_KEY: Your OpenAI API key (for embeddings)

Benefits of Supabase Mode

āœ… Persistent Storage - Data survives server restarts āœ… Free Tier Available - Generous free tier for development āœ… Self-Hostable - Can run your own Supabase instance āœ… Scalable - Grows with your needs āœ… SQL Access - Direct database access for advanced queries āœ… Real-time Features - Built-in real-time subscriptions

Parameter Configuration šŸŽÆ

Understanding Mem0 Parameters

The server uses four key parameters to organize and scope memories:

  1. userId - Identifies the user (required)

  2. agentId - Identifies the LLM/agent making the tool call (optional)

  3. appId - Identifies the user's project/application - this controls project scope! (optional)

  4. sessionId - Identifies the conversation session (maps to run_id in Mem0) (optional)

Environment Variable Fallbacks šŸ”„

The MCP server supports environment variable fallbacks for user identification and project settings:

  • DEFAULT_USER_ID: Fallback user ID when not provided in tool calls

  • DEFAULT_AGENT_ID: Fallback agent ID for identifying the LLM/agent

  • DEFAULT_APP_ID: Fallback app ID for project scoping

Priority Order (Important!)

  1. Tool Parameters (highest priority) - Values provided by the LLM in tool calls

  2. Environment Variables (fallback) - Values from your MCP configuration

Example Behavior:

// Your MCP config
"env": {
  "DEFAULT_USER_ID": "john-doe",
  "DEFAULT_AGENT_ID": "my-assistant",
  "DEFAULT_APP_ID": "my-project"
}

If LLM provides parameters:

{
  "tool": "add_memory",
  "arguments": {
    "content": "Remember this",
    "userId": "session-123",        // ← Overrides DEFAULT_USER_ID
    "agentId": "different-agent",   // ← Overrides DEFAULT_AGENT_ID
    "appId": "special-project"      // ← Overrides DEFAULT_APP_ID
    // sessionId omitted           // ← No fallback, will be undefined
  }
}

Result: Uses session-123, different-agent, and special-project

If LLM omits parameters:

{
  "tool": "add_memory",
  "arguments": {
    "content": "Remember this"
    // All IDs omitted - uses environment variables
  }
}

Result: Uses john-doe, my-assistant, and my-project

Controlling LLM Behavior

To ensure your environment variables are used, instruct your LLM:

  • "Use the default user ID configured in the environment"

  • "Don't specify userId, agentId, or appId parameters"

  • "Let the server use the configured defaults"

System Prompt Recommendation

For best results, include instructions in your system prompt like:

When creating memories, use:
- agentId: "my-assistant"
- appId: "my-project"
- sessionId: "current-conversation-id"

Example configuration using DEFAULT_USER_ID:

{
  "mcpServers": {
    "mem0-mcp": {
      "command": "npx",
      "args": [
        "-y",
        "@pinkpixel/mem0-mcp"
      ],
      "env": {
        "MEM0_API_KEY": "YOUR_MEM0_API_KEY_HERE",
        "DEFAULT_USER_ID": "user123",
        "ORG_ID": "your-org-id",
        "PROJECT_ID": "your-project-id"
      }
    }
  }
}

Or when running directly with node:

git clone https://github.com/pinkpixel-dev/mem0-mcp
cd mem0-mcp
npm install
npm run build
{
  "mcpServers": {
    "mem0-mcp": {
      "command": "node",
      "args": [
        "path/to/mem0-mcp/build/index.js"
      ],
      "env": {
        "OPENAI_API_KEY": "YOUR_OPENAI_API_KEY_HERE",
        "DEFAULT_USER_ID": "user123"
      }
    }
  }
}

Storage Mode Comparison šŸ”„

Cloud Storage (Mem0 API) ā˜ļø

  • Persistent by default - Your memories remain available across sessions and server restarts

  • No local database required - All data is stored on Mem0's servers

  • Higher retrieval quality - Uses Mem0's optimized search algorithms

  • Additional fields - Supports agent_id and threshold parameters

  • Fully managed - No setup or maintenance required

  • Requires - A Mem0 API key

Supabase Storage šŸ—„ļø

  • Persistent storage - Data is stored in your Supabase PostgreSQL database

  • Free tier available - Generous free tier for development and small projects

  • Self-hostable - Can run your own Supabase instance for complete control

  • SQL access - Direct database access for advanced queries and analytics

  • Scalable - Grows with your needs, from free tier to enterprise

  • Vector search - Uses pgvector extension for efficient similarity search

  • Real-time features - Built-in real-time subscriptions and webhooks

  • Requires - Supabase project setup and OpenAI API key for embeddings

Local Storage (OpenAI API) šŸ’¾

  • In-memory by default - Data is stored only in RAM and is not persistent long-term. While some caching may occur, you should not rely on this for permanent storage.

  • Data loss risk - Memory data will be lost on server restart, system reboot, or if the process is terminated

  • Recommended for - Development, testing, or temporary use only

  • For persistent storage - Use the Cloud Storage or Supabase options if you need reliable long-term memory

  • Uses OpenAI embeddings - For vector search functionality

  • Self-contained - All data stays on your machine

  • Requires - An OpenAI API key

Development šŸ’»

Clone the repository and install dependencies:

git clone https://github.com/pinkpixel-dev/mem0-mcp
cd mem0-mcp
npm install

Build the server:

npm run build

For development with auto-rebuild on file changes:

npm run watch

Debugging šŸž

Since MCP servers communicate over stdio, debugging can be challenging. Here are some approaches:

  1. Use the MCP Inspector: This tool can monitor the MCP protocol communication:

npm run inspector
  1. Console Logging: When adding console logs, always use console.error() instead of console.log() to avoid interfering with the MCP protocol

  2. Environment Files: Use a .env file for local development to simplify setting API keys and other configuration options

Technical Implementation Notes šŸ”§

1. Platform V3 Async Additions & Polling

Mem0 Cloud V3 addition is an asynchronous background task. When calling add_memory, the server submits the request to /v3/memories/add/ and receives an eventId.

  • Synchronous Polling (Default): The server polls the event status endpoint (/v1/event/{id}/) every 500ms for up to timeoutMs (default 15000ms) until the status becomes SUCCEEDED or FAILED. Once resolved, it returns the final outcome.

  • Asynchronous Execution: Pass "waitForCompletion": false to bypass polling. The server will immediately return the eventId and a PENDING status.

2. Nested V3 Filter Normalization

The Mem0 Cloud V3 search and list endpoints reject top-level scope IDs (user_id, agent_id, app_id, run_id) and return an HTTP 400 error. V3 requires these fields inside the nested filters object. To prevent breaking client configurations, this server automatically normalizes top-level scope variables (userId, agentId, appId, runId/sessionId) and merges them into the nested filters object under the hood before sending the API request.

3. Capability Gating

Different backends support different feature sets. Call get_memory_capabilities to get a structured capability matrix of the active backend.

  • Cloud Mode: Fully supports all features (apiVersion: "v3", async events, listing, audit histories, logical queries).

  • Supabase / Local Modes: Standard V1 vector interfaces. Unsupported cloud-specific tools (like get_memory_history or list_memories) will fail gracefully with clear feature-unavailable messages.

4. Logging & Protocol Stability

MCP servers communicate using JSON-RPC over stdout. Any unexpected library logs printed to stdout will corrupt the protocol channel and cause clients to crash. This server overrides the default console output methods (such as console.log) to redirect/mute standard logging, ensuring clean stdio communication.


Made with šŸ’– by Pink Pixel

Available Tools

3 tools
add_memoryC

Stores a piece of text as a memory in Mem0.

ParametersJSON Schema
NameRequiredDescriptionDefault
agentIdNoOptional agent ID to associate with the memory (for cloud API).
contentYesThe text content to store as memory.
metadataNoOptional key-value metadata.
sessionIdNoOptional session ID to associate with the memory.
userIdYesUser ID to associate with the memory.

TDQS

C2.9/5.0
Behavior2/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool stores text as memory but doesn't mention whether this is a write operation (implied), what permissions are needed, how the memory is persisted, rate limits, or what happens on success/failure. This is inadequate for a mutation tool with zero annotation coverage.

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

Conciseness5/5

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

The description is a single, efficient sentence that gets straight to the point with zero wasted words. It's appropriately sized and front-loaded, making it easy for an agent to parse quickly.

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

Completeness2/5

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

For a mutation tool with no annotations and no output schema, the description is insufficient. It doesn't explain what the tool returns, error conditions, or behavioral nuances like idempotency. Given the complexity (5 parameters including nested objects) and lack of structured coverage, more context is needed.

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

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 fully documents all 5 parameters. The description doesn't add any parameter-specific details beyond what's in the schema (e.g., it doesn't explain format constraints or usage examples). Baseline 3 is appropriate when the schema does the heavy lifting.

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

Purpose4/5

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

The description clearly states the action ('Stores') and resource ('a piece of text as a memory in Mem0'), making the purpose immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'delete_memory' or 'search_memory' beyond the obvious verb difference, which prevents a perfect score.

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

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus alternatives like 'search_memory' or 'delete_memory'. It doesn't mention prerequisites, typical use cases, or exclusions, leaving the agent to infer usage from the tool name alone.

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

delete_memoryC

Deletes a specific memory from Mem0 by ID.

ParametersJSON Schema
NameRequiredDescriptionDefault
agentIdNoOptional agent ID associated with the memory (for cloud API).
memoryIdYesThe unique ID of the memory to delete.
sessionIdNoOptional session ID associated with the memory.
userIdYesUser ID associated with the memory.

TDQS

C2.9/5.0
Behavior2/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool deletes a memory, implying a destructive operation, but doesn't cover critical aspects like permissions needed, whether deletion is permanent or reversible, rate limits, or error handling. This leaves significant gaps for a mutation tool.

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

Conciseness5/5

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

The description is a single, clear sentence with zero waste—it directly states the tool's function without unnecessary words. It's appropriately sized and front-loaded, making it highly efficient.

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

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 (a destructive operation with 4 parameters) and lack of annotations and output schema, the description is insufficient. It doesn't explain behavioral traits, return values, or usage context, leaving the agent with incomplete information for safe and effective invocation.

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

Parameters3/5

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

The schema description coverage is 100%, so all parameters are documented in the input schema. The description mentions 'by ID', which aligns with the 'memoryId' parameter but doesn't add meaningful semantic context beyond what the schema already provides. Baseline 3 is appropriate when the schema does the heavy lifting.

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

Purpose4/5

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

The description clearly states the action ('Deletes') and resource ('a specific memory from Mem0 by ID'), making the purpose unambiguous. However, it doesn't explicitly differentiate from sibling tools like 'add_memory' or 'search_memory' beyond the obvious verb difference, which is why it doesn't reach a 5.

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

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus alternatives like 'search_memory' or 'add_memory', nor does it mention prerequisites or exclusions. It's a straightforward statement of function without contextual usage advice.

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

search_memoryC

Searches stored memories in Mem0 based on a query.

ParametersJSON Schema
NameRequiredDescriptionDefault
agentIdNoOptional agent ID to filter search (for cloud API).
filtersNoOptional key-value filters for metadata.
queryYesThe search query.
sessionIdNoOptional session ID to filter search.
thresholdNoOptional similarity threshold for results (for cloud API).
userIdYesUser ID to filter search.

TDQS

C2.9/5.0
Behavior2/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It only states the basic action of searching without detailing aspects like whether it's read-only (implied but not explicit), potential side effects, rate limits, authentication needs, or what the search returns. This leaves significant gaps for a tool with multiple parameters and no output schema.

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

Conciseness5/5

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

The description is a single, efficient sentence that directly states the tool's purpose without any fluff or redundancy. It's appropriately sized and front-loaded, making it easy to parse quickly.

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

Completeness2/5

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

Given the complexity (6 parameters, no output schema, and no annotations), the description is insufficient. It lacks details on behavioral traits, return values, or how to interpret results, leaving the agent with incomplete information to use the tool effectively in context with its siblings.

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

Parameters3/5

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

The description mentions 'based on a query,' which aligns with the 'query' parameter, but adds no additional meaning beyond what the schema provides. With 100% schema description coverage, the baseline is 3, as the schema already documents all parameters well, and the description doesn't compensate with extra context or examples.

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

Purpose4/5

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

The description clearly states the action ('searches') and resource ('stored memories in Mem0'), making the purpose understandable. However, it doesn't differentiate from sibling tools like 'add_memory' or 'delete_memory' beyond the basic verb difference, missing specific scope or functional distinctions that would warrant a 5.

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

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus alternatives, such as how it differs from 'add_memory' or 'delete_memory' in practice, nor does it mention any prerequisites or exclusions. It's a generic statement that offers no contextual usage advice.

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

TDQS

B3.3/5.0
Disambiguation5/5

Each tool has a clearly distinct purpose: add_memory stores new data, delete_memory removes by ID, and search_memory retrieves based on queries. There is no overlap or ambiguity between these three core operations.

Naming Consistency5/5

All tools follow a consistent verb_noun pattern (add_memory, delete_memory, search_memory) with snake_case throughout. The naming is predictable and uniform across the set.

Tool Count3/5

With only 3 tools, the set feels minimal for a memory system. While it covers basic CRUD operations (create, delete, read), it lacks update functionality and other potential features like listing or managing memory collections, making it borderline thin for the domain.

Completeness4/5

The tools provide essential CRUD coverage (add, delete, search) for a memory system, but there are minor gaps such as no update_memory tool to modify existing memories and no way to list all memories without a query. Agents can work around this by deleting and re-adding, but it's not ideal.

Maintenance

ActivityStale
ResponsivenessSyncing

Related MCP Connectors

Related MCP Servers

  • A
    license
    Not graded
    quality
    C
    maintenance
    An MCP-native, local-first memory server that gives AI agents persistent, structured memory across sessions and tools, enabling them to maintain identity and context without reconfiguration.
    3
    MIT
  • A
    license
    A
    quality
    A
    maintenance
    A production-grade long-term memory MCP server that enables AI agents to persist and recall memories across sessions with importance weighting, confidence calibration, and efficient context window management.
    9
    1
    MIT
  • A
    license
    Not graded
    quality
    D
    maintenance
    An MCP server that provides persistent memory capabilities for AI agents using Mem0, enabling storage, search, and management of contextual information across conversations with support for multiple backends and LLM providers.
    MIT

Latest Blog Posts

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/pinkpixel-dev/mem0-mcp'

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