This server provides long-term memory for any MCP-compatible AI tool (Claude Code, Cursor, Windsurf, etc.), enabling persistent, searchable context across sessions and machines.
Save memories (memory_save): Persist facts, decisions, preferences, events, goals, or relationships with custom types, tags, entities, metadata, importance, and timestamps.
Hybrid search (memory_search): Perform semantic + keyword search across memories with filters (type, tags, entities, date range, score) and natural language queries.
Recall context (memory_recall): Replay recent or important memories without a query, useful for session initialization.
Retrieve by ID (memory_get): Fetch a single memory directly.
Update memories (memory_update): Patch fields (content, type, tags, entities, etc.) without duplication.
Delete memories (memory_delete): Soft-delete with 30-day recovery; no immediate hard delete.
List namespaces (memory_list_namespaces): Enumerate all namespaces with creation dates and memory counts.
Health check (memory_health): Verify local and remote Kireo service status.
Code indexing (kireo index CLI): Index local code symbols (functions, classes, methods) into a searchable namespace for AI retrieval.
Memories are organized in namespaces, shareable across projects, and pulled on-demand to prevent prompt bloat. Privacy controls allow disabling telemetry and clarify data transmission.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@@kireo/mcp-server save a memory: deployment branch is main, not master"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Long-term memory for any MCP-compatible AI tool (Claude Code, Cursor, Windsurf, Cline, Zed, Continue …).
Kireo memory MCP is a Model Context Protocol server that gives Claude Code, Cursor, Cline, Windsurf and any other MCP client long-term memory. Save a decision once; recall it in any later session, on any machine. Hybrid semantic + keyword search over LanceDB, eight MCP tools, plus local code indexing. Free beta — an API key is all you need.
One line for Claude Code, one JSON block everywhere else. Both need a free key from
https://app.kireo.app/app/api-keys (ki_sk_…).
# Claude Code — add --scope user to get it in every project
claude mcp add kireo --scope user --env KIREO_API_KEY=ki_sk_xxx -- npx -y --package=@kireo/mcp-server kireo-mcpEvery other client takes the same server entry; only the file it goes in differs:
{
"mcpServers": {
"kireo": {
"command": "npx",
"args": ["-y", "--package=@kireo/mcp-server", "kireo-mcp"],
"env": { "KIREO_API_KEY": "ki_sk_xxx" }
}
}
}Client | Where that block goes |
Claude Code |
|
Cursor |
|
Cline | MCP Servers → Configure MCP Servers ( |
Claude Desktop |
|
Windsurf |
|
Zed / Continue / any MCP host | Whatever that host calls its MCP server list — same three fields |
Restart the client afterwards. Node.js ≥ 18 must be on PATH for npx.
Eight, over MCP stdio: memory_save, memory_search, memory_recall, memory_get,
memory_update, memory_delete, memory_list_namespaces, memory_health. Every client sees the
same set. Call memory_health first to confirm the key works.
No — memory is pulled, not pushed. Nothing is injected into the system prompt. The agent calls
memory_search only when it decides prior context is worth retrieving, and gets back a bounded
ranked set (default 10 hits, hard cap 50), so tokens are spent per-query rather than per-turn.
A rules file is static text re-read in full every session and shared by nothing. Kireo memory MCP is queried on demand, is written by the agent as work happens, is searchable semantically, and is shared across projects, sessions and machines through namespaces.
Yes. npx -y -p @kireo/mcp-server kireo index ./ --repo my-app extracts functions/classes/methods
into a code-<repo> namespace that memory_search can reach. Indexing is incremental — re-runs
only send changed files, and the server dedupes identical symbols, so retrying is safe.
No. Only the content explicitly passed to memory_save (and, if you run kireo index, the symbols
it extracts) leaves your machine. Set KIREO_TELEMETRY=0 to also drop the X-Device-Id header.
Free beta. Sign up at https://app.kireo.app, create a key, done — no card.
Related MCP server: mindcore-memory-mcp
Get an API key at https://app.kireo.app/app/api-keys (ki_sk_…).
Add this MCP server to your host. Claude Code — run:
claude mcp add kireo --scope user --env KIREO_API_KEY=ki_sk_xxx -- npx -y --package=@kireo/mcp-server kireo-mcpTwo details in that line are load-bearing, both verified against claude 2.1.220 and npm 11 on 2026-08-03:
--package=@kireo/mcp-server kireo-mcp, not @kireo/mcp-server. This package ships two binaries (kireo, kireo-mcp), neither named after the package, so npx -y @kireo/mcp-server cannot pick one and fails with could not determine executable to run.
--package=, not the short -p. A bare -p after -- gets swallowed by the claude mcp add option parser, which then rejects its own flag: claude mcp add kireo --env … -- npx -y -p @kireo/mcp-server kireo-mcp errors with unknown option '--env'. The long form parses cleanly.
Drop --scope user if you only want it in the current project. Alternatively, check a project-scoped .mcp.json into your repo root with the same shape (inside JSON args the short -p is fine — it goes straight to npx and never reaches the claude parser):
// .mcp.json (project root)
{
"mcpServers": {
"kireo": {
"command": "npx",
"args": ["-y", "--package=@kireo/mcp-server", "kireo-mcp"],
"env": { "KIREO_API_KEY": "ki_sk_xxx" }
}
}
}Restart the host. You now have 8 tools available to the AI:
Tool | Purpose |
| Persist a long-term memory |
| Hybrid semantic + keyword search |
| Replay recent/important memories |
| Fetch by id |
| Patch fields |
| Soft/hard delete |
| Enumerate namespaces |
| Probe service |
Sources are merged in order: CLI args > env > ~/.kireo/config.json.
ENV / CLI | Default | Description |
| required | Bearer token ( |
|
| Override for self-host. |
|
| Per-request timeout in ms, max |
|
| 5xx/429 retries (alias: |
|
| Exponential backoff base. |
|
| Set to |
|
|
|
| none | HTTP(S) proxy. |
|
| Locale for error hints. |
Logs land in ~/.kireo/logs/ on all platforms (macOS, Linux, Windows).
Index a repository's symbols (functions / classes / methods) into a
code-<repo> namespace so the AI can recall them via memory_search:
export KIREO_API_KEY=ki_sk_xxx
npx -y -p @kireo/mcp-server kireo index ./ --repo my-appIndexing is incremental — only changed files are re-sent on subsequent runs.
Flag | Default | Description |
| directory basename | Repo name → |
|
| Symbols per upload batch ( |
|
| Per-request timeout (max |
| — | Same as the config table above; CLI flags override env. |
Run kireo --help for the full usage text. --help and --version never touch
the network or the filesystem and don't require an API key. If a batch upload
times out, re-running the same command is safe: the server dedupes identical
symbols, so retries won't create duplicates.
Set KIREO_TELEMETRY=0 to drop the X-Device-Id header. We never read your code; only the explicit content you pass to memory_save reaches the API.
AUTH_INVALID_KEY → rotate your key at https://app.kireo.app/app/api-keys.
QUOTA_EXCEEDED → upgrade or wait for next billing cycle.
Tools missing in your host → run npx @modelcontextprotocol/inspector node $(npm root -g)/@kireo/mcp-server/bin/kireo-mcp.cjs to verify locally.
MIT
Delete a memory. Defaults to a soft delete (30-day recovery window).
When to use:
The user explicitly asks to forget something ("forget that I said …").
A memory is clearly wrong AND not worth correcting.
GDPR / privacy removal request.
When NOT to use:
The memory is just outdated — prefer memory_update.
You're unsure — ask the user first.
Note: deletes are always soft — the API has no immediate hard delete. Soft-deleted memories are purged permanently after the 30-day window.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | ||
| hard | No | Accepted for compatibility, but the API only supports soft deletes — the memory is recoverable for 30 days, then purged permanently. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. Discloses soft delete behavior, 30-day recovery window, permanent purge after 30 days, and clarifies that the 'hard' parameter only emulates behavior but still performs soft delete. Could mention auth requirements or side effects, but covers key behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Very efficient: first sentence states core action and default behavior, then bullet points for usage guidelines. No wasted words, front-loaded with key information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of output schema, the description covers essential behavioral context (soft delete, recovery window) and usage scenarios. Could mention what the API returns (e.g., success/failure) but not critical for a delete operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 50% (only 'hard' has a description). The description adds minimal value for 'id' (no additional detail), but clarifies the 'hard' parameter's behavior beyond schema. Partially compensates but does not fully address missing id description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description explicitly states 'Delete a memory' with soft delete behavior. It distinguishes from siblings like memory_update by specifying when not to use (outdated memories) and when to use (explicit forget, wrong memory, GDPR).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear when-to-use and when-NOT-to-use scenarios with concrete examples, and references an alternative tool (memory_update). This offers excellent guidance for agent decision-making.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch a single memory by id.
When to use:
You already have a memory id from a previous memory_search / memory_recall / memory_save call.
The user references "that memory you saved" and you stored the id.
When NOT to use:
You only have a vague query — use memory_search or memory_recall instead.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | The memory id (looks like "mem_01HXVK..."). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description indicates a read-only operation ('Fetch'), but does not discuss error handling or auth requirements. For a simple fetch with no annotations, this is nearly sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is concise (5 lines), well-structured with bullet points, and every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema is needed for a simple fetch; the description covers purpose, usage, parameter context, and sibling differentiation completely.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers 100% of parameters, but the description adds valuable context: the id comes from previous calls and relates to user references, enhancing understanding beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states 'Fetch a single memory by id' (verb+resource) and differentiates from siblings by specifying when to use vs. not use memory_search/memory_recall.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear 'When to use' and 'When NOT to use' sections, including specific alternatives like memory_search and memory_recall, giving excellent usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Probe the Kireo service and report local + remote health.
When to use:
User reports "memory tools aren't working".
You hit unexplained errors and need to confirm the API is reachable.
First-time setup verification.
Returns: { local: { server_version, node_version, platform }, remote: { status } }.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so description carries full burden. It explains the tool probes health and returns local and remote status. No side effects mentioned, appropriate for a read-only health check.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Very concise: first sentence defines purpose, then usage guidelines, then return format. No fluff, well-organized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Complete for a simple health check tool. Explains return structure (local and remote fields). No output schema, but description covers what is returned.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, so schema coverage is trivially 100%. Baseline for 0 params is 4. Description doesn't add param info because none needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it probes Kireo service health. Distinguishes from sibling memory tools, which all involve data operations (get, save, delete, etc.).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit scenarios: user reports tools not working, unexplained errors, first-time setup. This helps decide when to call memory_health instead of other memory tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all namespaces the current user has, with per-namespace counts.
When to use:
Before deciding which namespace to save to, when the user has multiple projects.
To answer "what projects do I have memories for?".
For diagnostics.
Returns: array of { name, created_at }.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It implies read-only behavior and specifies the return structure. However, it does not mention authentication or rate limits; for a simple list tool, this is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with three clear sections: core function, usage guidance, and return type. Every sentence adds value with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description claims 'per-namespace counts' but the return structure only includes name and created_at, not counts. This inconsistency reduces completeness. Also, no mention of pagination or limits, though the input schema has no parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, so schema coverage is 100% vacuously. The description does not need to add parameter info. Baseline 4 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it lists all namespaces with per-namespace counts, using a specific verb and resource. It distinguishes from sibling tools that operate on individual memories.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit 'When to use' section with three specific scenarios (pre-save decision, answering user questions, diagnostics). Provides clear context for usage, though no explicit exclusion or alternative tools mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Replay recent or important memories from a namespace, without a query.
When to use:
At the start of a new chat — to load recent context.
The user says "what have we been working on" / "remind me".
You want a chronological feed rather than a search match.
When NOT to use:
The user has a specific question → use memory_search.
You already have the id → use memory_get.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| order | No | recency | |
| since | No | Only return memories with occurred_at >= since. | |
| cursor | No | Opaque cursor from a previous recall response, for pagination. | |
| namespace | No | default |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, description carries full burden. It mentions 'without a query' and chronological feed, but lacks details on memory boundaries, ordering behavior, pagination handling, or effect on memory state. Adequate but not deep.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Highly structured with clear headers, bullet points, and no redundant sentences. Purpose is front-loaded, and every section adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has 5 parameters and no output schema or annotations. Description covers usage context well but omits parameter details and behavioral specifics about ordering or pagination. Adequate given complexity but incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 40%. Description adds no parameter-specific guidance beyond the schema. It does not explain limit, order, since, cursor, or namespace semantics, leaving agent to infer from defaults/enums.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it replays recent/important memories from a namespace without a query. It distinguishes itself from siblings like memory_search (query-based) and memory_get (by id).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit 'When to use' and 'When NOT to use' sections with specific alternatives (memory_search, memory_get) and context cues like 'new chat' or user phrases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Persist a long-term memory for the current user.
When to use:
The user states a preference, decision, fact, plan, or goal that should outlive this chat.
You learn a stable property of the user, their project, or their tooling.
The user explicitly says "remember", "记住", "save this".
When NOT to use:
Ephemeral chat turns ("ok", "thanks").
Sensitive secrets (API keys, passwords) — refuse and warn the user.
Information you can re-derive from the codebase on demand.
Returns: { id, created_at, schema_version, embedding_status } — use memory_get for the full record.
| Name | Required | Description | Default |
|---|---|---|---|
| tags | No | ||
| type | No | "preference" = user likes/dislikes, "decision" = chosen approach, "fact" = stable truth, "event" = time-bounded happening, "goal" = intent, "insight" = derived learning, "relationship" = link between entities. | fact |
| content | Yes | The memory text to persist. Be concrete and self-contained — future-you should understand it without surrounding chat. | |
| entities | No | Named entities mentioned (people, products, repos). Helps later retrieval. | |
| metadata | No | ||
| namespace | No | Logical bucket (e.g. project name). Use "default" unless the user has multiple isolated contexts. | default |
| importance | No | 0..1 priority hint. Defaults to 0.5 server-side. | |
| occurred_at | No | ISO-8601 timestamp when the memory factually happened. Defaults to server now(). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries full behavioral burden. It discloses persistence nature and return fields, but lacks mention of deduplication, overwrite behavior, or rate limits. The advice to use memory_get for full record is helpful.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, front-loaded with purpose, and structured into clear sections. Every sentence adds value without repetition. The bullet lists are efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 8 parameters and no output schema, the description adequately explains the return structure and references sibling tools. It could elaborate on interactions with memory_update or memory_delete for completeness, but the current coverage is sufficient for most agents.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 75%, so the description compensates with extra context like 'Be concrete and self-contained' for content and detailed interpretation of type enum values. This adds value beyond the schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Persist a long-term memory for the current user,' which clearly states the action and target resource. It distinguishes itself from sibling tools like memory_get by instructing to use that tool for the full record. The purpose is specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit 'When to use' and 'When NOT to use' bullet points provide concrete scenarios, including when to store preferences, facts, etc., and when to avoid ephemeral chat or secrets. The guidance on refusing sensitive secrets adds valuable safety advice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Hybrid semantic + keyword search over the user's memories.
When to use:
The user asks "do you remember…" or "what did I say about X".
Before answering project-specific questions, search for stored preferences and decisions.
You need to ground your answer in user-supplied facts.
When NOT to use:
You already have the memory id → use memory_get.
You just want the most recent items in a namespace → use memory_recall.
Returns: ranked list of MemoryRecord with a raw RRF relevance score (typically 0.01–0.04).
| Name | Required | Description | Default |
|---|---|---|---|
| tags | No | ||
| type | No | ||
| limit | No | ||
| query | Yes | Natural language query. Hybrid (semantic + keyword) search. | |
| entities | No | ||
| min_score | No | Optional raw RRF score threshold. Typical useful values are 0.01–0.04. | |
| namespace | No | Restrict to a single namespace. Omit to search across all of the user's namespaces. | |
| occurred_to | No | ||
| occurred_from | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses the hybrid search behavior, returns a 'ranked list of MemoryRecord with a raw RRF relevance score (typically 0.01–0.04).' This is informative, though it does not cover potential edge cases like empty results 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear headings and concisely covers purpose, usage, and return format. Every sentence is justified and non-redundant.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (9 parameters, no output schema), the description effectively explains the tool's role, when to use it, and what it returns. It could be more thorough on interpreting the score, but it is sufficient for a search tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 33% (low), but the description adds some value beyond the schema, such as explaining the query as 'Natural language query. Hybrid (semantic + keyword) search' and noting typical score ranges for min_score. However, many parameters (tags, type, entities, occurred_from, occurred_to) lack additional explanation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool performs 'Hybrid semantic + keyword search over the user's memories.' It distinguishes from siblings by specifying when to use (e.g., 'do you remember…') and when not to use (use memory_get or memory_recall instead).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit 'When to use' and 'When NOT to use' sections provide clear context. It lists alternative tools (memory_get, memory_recall) and specific scenarios, offering strong guidance for an AI agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Patch an existing memory. Only the fields you provide are changed.
When to use:
The user corrects a previously stored fact ("actually, I use Tailwind v4 not v3").
You need to add tags / entities to an existing memory.
The user lowers/raises priority of a memory.
When NOT to use:
The memory is wrong AND no longer relevant → use memory_delete.
You don't have the id yet → search first.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | ||
| tags | No | ||
| type | No | ||
| content | No | ||
| entities | No | ||
| metadata | No | ||
| namespace | No | ||
| importance | No | ||
| occurred_at | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so description carries full burden. It discloses patch semantics but does not mention return value, side effects, or authentication needs. 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections, no unnecessary words, and front-loaded with the core action. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 9 parameters, no output schema, and no explanation of entities, importance scale, or return structure, the description lacks depth for an agent to use the tool confidently in complex scenarios.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% and the description does not elaborate on any parameter beyond the schema definitions. Parameters like 'metadata' or 'namespace' remain opaque, leaving the agent without additional guidance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it is for patching an existing memory with only provided fields changed. It distinguishes from sibling tools like memory_delete and memory_save by context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit 'When to use' and 'When NOT to use' sections with concrete scenarios (corrections, tag updates, priority adjustments) and alternatives (memory_delete, search first).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.2.1memory_deletememory_getmemory_healthmemory_list_namespacesmemory_recallmemory_savememory_searchmemory_updateScored across 8 tools
Each tool targets a distinct memory operation: get by ID, search by query, recall chronological feed, save new, update existing, delete, plus health check and namespace listing. Overlap between search and recall is clarified by their descriptions, making them clearly distinguishable.
All tools follow the 'memory_<verb>' pattern consistently (memory_save, memory_search, memory_delete, etc.). The verb for listing namespaces uses two words (list_namespaces) but still fits the pattern harmoniously.
8 tools is a well-scoped count for a memory management server. It covers the essential CRUD operations (save, get, search, recall, update, delete) plus auxiliary tools (health, list_namespaces) without unnecessary bloat.
The tool surface is complete for the domain: create (save), read by ID (get), search, chronological recall (recall), update, soft delete, plus namespace management and health check. No obvious gaps for typical memory workflows.
Shared, governed long-term memory for AI agents across tools and sessions via MCP and REST.
An MCP memory server. One memory your agents share — across models, devices and apps.
Persistent memory for AI agents — log and recall conversation context over MCP.
Persistent personal memory for AI assistants — save, search, and recall across every MCP client.
