Memanto MCP Server provides persistent semantic memory for MCP-compatible AI agents, enabling long-term knowledge storage and retrieval across sessions.
Store single or batch memories (facts, preferences, goals, etc.) with type, confidence, provenance, tags, and source.
Search semantically via natural language queries, with optional type and similarity filters.
Retrieve recent memories, point-in-time snapshots, or differential updates since a timestamp.
Answer questions with LLM-grounded responses (RAG) using only stored memories, with source references and optional kiosk/temperature settings.
Admin (optional): Create, list, inspect, and delete agent memory namespaces by enabling MEMANTO_EXPOSE_ADMIN=true.
Transport: Supports stdio, Server-Sent Events, and Streamable HTTP for local or remote clients.
Integration: Works with Claude Desktop, Cursor, Windsurf, Cline, and more; configurable via environment variables and JSON snippets.
Provides persistent semantic memory for Windsurf (a Codeium product), enabling long-term memory for the AI coding assistant within the IDE.
Persistent semantic memory for any MCP-compatible agent.
This package exposes Memanto's memory primitives —
remember, recall, answer, and friends — as
Model Context Protocol (MCP) tools so any
MCP client (Claude Desktop, Cursor, Windsurf, Cline, Continue, Goose,
custom agents, …) can plug into long-term memory in a single config line.
One Moorcheh API key → typed semantic memory across every agent that shares the namespace, with sub-90 ms retrieval, conflict detection, and zero ingestion latency.
pip install memanto-mcpRequires Python 3.10+, memanto>=0.2.13, mcp>=1.2,<2, and a
Moorcheh API key
(free tier: 100K ops/month).
Related MCP server: Mem0 Memory MCP Server
Get a Moorcheh API key from the console.
Edit claude_desktop_config.json (Settings → Developer → Edit Config):
{
"mcpServers": {
"memanto": {
"command": "memanto-mcp",
"env": {
"MOORCHEH_API_KEY": "mch_xxxxxxxxxxxxxxxxxx",
"MEMANTO_DEFAULT_AGENT_ID": "my-assistant"
}
}
}
}Restart Claude Desktop. Ask it to "remember that I prefer concise answers" — then in a brand-new chat tomorrow ask "what do I prefer?".
The first call auto-creates the my-assistant agent and namespace; every
subsequent call reuses the same persistent memory.
Most clients consume a config file in the standard MCP shape. The same JSON snippet works almost verbatim:
{
"mcpServers": {
"memanto": {
"command": "memanto-mcp",
"env": {
"MOORCHEH_API_KEY": "mch_xxxxxxxxxxxxxxxxxx",
"MEMANTO_DEFAULT_AGENT_ID": "cursor-workspace"
}
}
}
}Client | Config path |
Claude Desktop |
|
Cursor |
|
Windsurf |
|
Cline (VS Code) |
|
Continue |
|
Goose |
|
The server registers 7 memory tools by default. Set
MEMANTO_EXPOSE_ADMIN=true to also expose 4 agent-management tools.
Tool | When the agent should call it |
| Persist a single new fact/preference/decision/goal/instruction. |
| Persist up to 100 memories in one call (e.g. extracted from a document). |
| Semantic search — always check here before asking the user to repeat stable info. |
| "What did we just decide?" — newest-first, no query needed. |
| Point-in-time recall — "what did we know on 2025-11-01?" |
| Differential — "what's new since I last checked?" |
| RAG: grounded LLM answer synthesized over the agent's memories. |
Enabled when MEMANTO_EXPOSE_ADMIN=true:
Tool | Purpose |
| Create a new memory namespace. |
| List every agent the API key can see. |
| Look up an agent's metadata. |
| Remove an agent's local metadata. |
Memory types accepted by remember / batch_remember:
fact, preference, goal, decision, artifact, learning, event,
instruction, relationship, context, observation, commitment,
error.
Provenance values: explicit_statement, inferred, corrected,
validated, observed, imported.
source names who wrote a memory, so recall can be attributed and filtered
per writer. It is open: user, agent, tool, system, or a specific
writer such as cursor, codex, claude_code, mem0. Labels are limited to
64 letters, digits, ., _, or - so that #source:<value> stays a usable
filter.
When a tool call omits source, the server attributes the write to the
connected MCP client from the initialize handshake (cursor, codex,
claude-ai, …), falling back to mcp-agent when the client sends no name.
Two editors sharing one agent therefore stay distinguishable in recall without
any extra configuration.
All config is via environment variables (load order: process env →
.env file in the working directory).
Variable | Required | Default | Description |
| yes | — | Moorcheh API key. |
| recommended | none | Default agent. When set, tool calls may omit |
| no |
| Pattern ( |
| no |
| Create the default agent on first use if missing. Explicit non-default agents must already exist. |
| no | server default (6) | Session lifetime in hours. |
| no |
| Register the 4 agent-management tools. |
| no |
|
|
| no |
| Bind host for sse/http transports. |
| no |
| Bind port for sse/http transports. |
| no |
| Log level (logs are always sent to stderr). |
CLI flags (memanto-mcp --transport sse --port 9000) override env vars.
For remote clients or multi-process setups, run the server over a network transport:
# Streamable HTTP (recommended modern transport)
memanto-mcp --transport streamable-http --host 0.0.0.0 --port 8765
# Server-Sent Events (older, still widely supported)
memanto-mcp --transport sse --host 0.0.0.0 --port 8765Then point your client at http://your-host:8765/mcp (or whatever path the
chosen transport advertises). Pair with a reverse proxy + auth for
production deployments — the server itself authenticates upstream to
Moorcheh using your API key but does not authenticate inbound MCP
clients.
┌──────────────┐ MCP/stdio ┌──────────────────┐ Moorcheh API ┌─────────────┐
│ Claude / IDE │ ──────────────► │ memanto-mcp │ ────────────────► │ Moorcheh │
│ (client) │ ◄────────────── │ (this package) │ ◄──────────────── │ Service │
└──────────────┘ tool calls └──────────────────┘ HTTPS+API key └─────────────┘
│
└─ uses memanto.cli.client.SdkClient
(same client the Memanto CLI uses)On startup, settings are validated; the API key is verified lazily on first tool call.
On the first memory tool invocation for a given agent, the server ensures the agent exists (auto-creates if needed) and activates a JWT session. Sessions auto-renew before expiry, so long-running MCP connections never hit a session-expired error mid-conversation.
The server intentionally keeps the session alive on shutdown: JWT sessions are TTL-bound and other Memanto clients (CLI, REST) may want to share them.
If you're building a custom MCP host or wiring this server into a larger process, you can construct the FastMCP instance yourself:
from memanto_mcp import MCPServerSettings, build_server
settings = MCPServerSettings() # reads env / .env
mcp = build_server(settings)
# Add your own tools alongside Memanto's, then run.
mcp.run(transport="stdio")Symptom | Fix |
| Set the env var in your MCP client config's |
| Either re-enable auto-create or call |
Tools never appear in the client | Confirm the client supports MCP and the config path matches. Look at the client's MCP log: the server's stderr lines (prefixed |
Garbled output in stdio mode | Something on your side is writing to stdout — that channel is reserved for JSON-RPC. Move logs to stderr. The server itself only writes to stderr. |
Slow first call | Cold-start cost: SDK import + first session activation. Subsequent calls reuse the live session. |
MIT — same as the Memanto project. See LICENSE.
Ask a natural-language question and get an LLM-generated answer grounded ONLY in the agent's stored memories (RAG). Prefer this over recall when you need a synthesized answer rather than a ranked list. Returns the answer text plus the supporting memory sources.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Number of context memories to retrieve. Defaults to server config. | |
| agent_id | No | Memanto agent identifier the memory belongs to (required: no MEMANTO_DEFAULT_AGENT_ID is configured). | |
| question | Yes | The question to answer. | |
| kiosk_mode | No | If true, refuses to answer when no memory clears the similarity threshold (useful for strictly grounded applications). Defaults to the server config value. | |
| temperature | No | LLM temperature. Defaults to server config. |
| Name | Required | Description |
|---|---|---|
| answer | No | |
| status | Yes | |
| message | No | |
| sources | No | |
| agent_id | Yes | |
| question | Yes | |
| namespace | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses that the answer is LLM-generated, grounded only in stored memories (RAG), and returns answer text plus supporting sources. This is strong context, though it could also mention behavior when no memories are found or the effects of kiosk_mode; however, those are partially captured in the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two clearly structured sentences: first states purpose and grounding, second gives selection guidance and return value. Every sentence adds value, with no filler or repetition of schema details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (5 parameters, output schema), the description covers purpose, usage guidance, grounding behavior, and return contents. It doesn't explicitly discuss failure modes such as no memory found, but that is addressed by the kiosk_mode parameter and output schema, making the description adequately complete for an agent.
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 100%: every parameter has a clear description. The tool description adds no parameter-specific meaning beyond what the schema provides, so the baseline score of 3 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 the tool's function: 'Ask a natural-language question and get an LLM-generated answer grounded ONLY in the agent's stored memories (RAG).' It also explicitly contrasts with a sibling tool ('Prefer this over `recall`'), distinguishing a synthesized answer from a ranked list.
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 direct usage guidance: 'Prefer this over `recall` when you need a synthesized answer rather than a ranked list.' This tells the agent exactly when to choose this tool over a close alternative, and the rest of the description implies when not to use it (e.g., when a ranked list is desired).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Store many memories at once (up to 100). Use this when you have a list of independent facts to persist - e.g. extracting structured data from a document. For a single item, prefer remember.
| Name | Required | Description | Default |
|---|---|---|---|
| agent_id | No | Memanto agent identifier the memory belongs to (required: no MEMANTO_DEFAULT_AGENT_ID is configured). | |
| memories | Yes | List of memory dicts. Each item supports the same fields as `remember` (content [required], type, title, confidence, tags, source, provenance) with the same allowed values; an item without a source is attributed to the calling client. Max 100 items. |
| Name | Required | Description |
|---|---|---|
| failed | No | |
| status | Yes | |
| message | No | |
| results | No | |
| agent_id | Yes | |
| namespace | No | |
| successful | No | |
| total_submitted | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden for behavioral disclosure. It adds useful context beyond the schema, such as the 'item without a source is attributed to the calling client' and the emphasis on 'independent facts.' However, it does not mention potential partial failures, idempotency, or other side effects, which would be richer context.
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 extremely concise, consisting of two front-loaded sentences that convey purpose, usage context, and an alternative. Every word adds value, and it avoids redundancy with the schema.
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 rich schema and presence of an output schema, the description covers purpose, usage, and distinctions effectively. It lacks an explicit note on error handling or atomicity, which might be relevant for a batch operation, but overall it is sufficiently complete for agent decision-making.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the schema itself already explains the `memories` parameter, including field details, limits, and source attribution. The tool description does not add new parameter semantics beyond what the schema provides, so the baseline score of 3 applies.
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's function with a specific verb and resource: 'Store many memories at once (up to 100).' It also distinguishes itself from the sibling tool `remember` by explicitly saying 'For a single item, prefer `remember`.'
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit when-to-use guidance: 'Use this when you have a list of independent facts to persist - e.g. extracting structured data from a document.' It also gives an exclusion by directing single-item use to `remember`, which clarifies the appropriate context for each tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search the agent's memories by semantic similarity. Returns the top-N most relevant items. Use this FIRST before asking the user to repeat information - the agent may already remember it. The query should be natural language ('what does the user prefer for code style?'), not keywords.
| Name | Required | Description | Default |
|---|---|---|---|
| type | No | Optional type filter - e.g. ['preference'] to only retrieve user preferences. | |
| limit | No | Max number of memories to return (1-100). | |
| query | Yes | Natural-language search query. | |
| agent_id | No | Memanto agent identifier the memory belongs to (required: no MEMANTO_DEFAULT_AGENT_ID is configured). | |
| min_similarity | No | Minimum similarity score 0-1. Applied by the search backend, so the top-N is filled with results that pass the threshold. Defaults to the server config value. |
| Name | Required | Description |
|---|---|---|
| mode | No | semantic | recent | as_of | changed_since |
| count | No | |
| query | No | |
| status | Yes | |
| message | No | |
| agent_id | Yes | |
| memories | No |
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 it performs a semantic search and returns top-N items, which implies a non-destructive read operation. However, it does not explicitly state that it is read-only, describe behavior when no memories match, or mention any auth or rate-limit considerations. The query-style guidance adds useful context but more behavioral disclosure would be needed for a higher score.
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 compact, consisting of four short sentences that each deliver distinct value: what the tool does, the result format, when to use it, and query guidance. There is no filler or repetition, and the embedded example is illustrative without adding bulk. This is a model of efficient writing.
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 full schema coverage and the presence of an output schema, the description needn't explain return values. It provides essential usage context: the tool's purpose, a priority use case (before asking the user), and query formulation advice. It does not discuss edge cases or exclusions, but for a straightforward search tool, this is sufficiently complete.
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 100% with descriptions for all 5 parameters, so the baseline is 3. The description adds semantic value specifically for the 'query' parameter by clarifying that it expects natural language rather than keywords, with a concrete example. No additional insight is given for type, limit, agent_id, or min_similarity beyond the schema, but this meaningful addition for the most important parameter justifies a 4.
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 searches memories via semantic similarity and returns top-N relevant items. The verb 'search' and resource 'memories' are specific, and 'semantic similarity' implies a distinction from time-based recall siblings. However, it does not explicitly name alternatives like recall_recent or recall_as_of, so it stops short of full differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly instructs to use this tool FIRST before asking the user to repeat information, establishing a clear priority. It also provides query formatting guidance (natural language vs keywords) with an example. It does not explicitly state when not to use it or mention alternative sibling tools, but the 'FIRST' directive is strong context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Point-in-time recall: return only memories that were known before the given timestamp. Use this when the user asks historical questions like 'what did we know on 2025-11-01?' or to reconstruct context at a previous moment.
| Name | Required | Description | Default |
|---|---|---|---|
| type | No | Optional type filter. | |
| as_of | Yes | Cutoff timestamp. Accepts YYYY-MM-DD (interpreted as end of that day) or full ISO 8601 e.g. 2025-11-01T14:30:00Z. | |
| limit | No | ||
| agent_id | No | Memanto agent identifier the memory belongs to (required: no MEMANTO_DEFAULT_AGENT_ID is configured). |
| Name | Required | Description |
|---|---|---|
| mode | No | semantic | recent | as_of | changed_since |
| count | No | |
| query | No | |
| status | Yes | |
| message | No | |
| agent_id | Yes | |
| memories | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It explains the core behavior: returning memories known before a given timestamp. The parameter descriptions (notably for 'as_of') provide additional detail on timestamp interpretation. No contradictions or omissions about side effects (it is read-only). The description is adequate for understanding the tool's behavior.
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 two sentences, front-loading the purpose ('Point-in-time recall') followed by immediate usage guidance. Every word serves a purpose; no filler or repetition. Excellent conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's 4 parameters and existence of an output schema, the description covers the essential information: purpose, when to use, and key behavior. It does not detail return structure or parameter limits, but those are covered by the schema and output schema. The description is sufficient for an agent to make correct selection and invocation decisions.
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 75% (3 of 4 parameters have descriptions in the schema). The tool description adds value by contextualizing the 'as_of' parameter with usage examples, but does not describe 'type', 'limit', or 'agent_id' beyond what the schema already provides. For a high-coverage schema, a baseline of 3 is appropriate, with slight bonus for the usage context on 'as_of'.
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's purpose: 'return only memories that were known before the given timestamp.' It explicitly contrasts with siblings by focusing on point-in-time recall, and provides concrete examples of when to use it (historical questions, reconstructing context). This distinguishes it from other recall tools like 'recall' (current memories) or 'recall_recent' (recent 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?
The description provides explicit when-to-use guidance: 'Use this when the user asks historical questions... or to reconstruct context at a previous moment.' It does not explicitly mention when not to use it or name alternative tools, but the context is clear enough for an agent to infer that non-historical queries should use other recall tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Differential retrieval: return memories created or updated after the given timestamp. Use this for 'what's new since X?' or to catch up on activity between sessions.
| Name | Required | Description | Default |
|---|---|---|---|
| type | No | Optional type filter. | |
| limit | No | ||
| since | Yes | Lower-bound timestamp. Accepts YYYY-MM-DD (start of day) or full ISO 8601 e.g. 2025-11-01T00:00:00Z. | |
| agent_id | No | Memanto agent identifier the memory belongs to (required: no MEMANTO_DEFAULT_AGENT_ID is configured). |
| Name | Required | Description |
|---|---|---|
| mode | No | semantic | recent | as_of | changed_since |
| count | No | |
| query | No | |
| status | Yes | |
| message | No | |
| agent_id | Yes | |
| memories | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It states it returns memories created or updated after the timestamp, but doesn't mention pagination, ordering, or agent filtering behavior. Some behavioral aspects are implied but not fully disclosed.
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 two sentences, front-loading the purpose and then providing usage guidance. Every word contributes value, with no redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 4 parameters and an output schema, the description is somewhat complete but lacks details on limit behavior, ordering, and required agent_id condition. It covers purpose and usage adequately but leaves gaps in operational details.
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 75%, so baseline is 3. The description adds context for the 'since' parameter but doesn't elaborate on 'type' or 'limit' beyond schema defaults. No new semantic value 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 clearly states the tool performs differential retrieval of memories created or updated after a given timestamp, using specific verbs and resource. It explicitly distinguishes from siblings by using 'differential retrieval' and providing use cases like 'what's new since X?'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit usage guidance: 'Use this for "what's new since X?" or to catch up on activity between sessions.' This tells the agent when to apply the tool, though it doesn't explicitly mention when not to use it or name alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return the most recently stored memories (newest first). Use this to surface fresh context - e.g. 'what did we just decide?' - when you don't have a specific search query.
| Name | Required | Description | Default |
|---|---|---|---|
| type | No | Optional type filter. | |
| limit | No | Max number of memories to return. | |
| agent_id | No | Memanto agent identifier the memory belongs to (required: no MEMANTO_DEFAULT_AGENT_ID is configured). |
| Name | Required | Description |
|---|---|---|
| mode | No | semantic | recent | as_of | changed_since |
| count | No | |
| query | No | |
| status | Yes | |
| message | No | |
| agent_id | Yes | |
| memories | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states the tool returns data newest-first but does not mention scoping (e.g., agent-specific), response format, or any potential side effects. For a read-only tool, the description is adequate but minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence with a usage example. Every part is purposeful, no redundancy, and the key action is upfront.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (3 optional params, no required ones, output schema present), the description covers its core functionality and use case. It could mention ordering details or the limit default, but those are in the schema. Slightly above adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the input schema already documents all three parameters (type, limit, agent_id). The tool description does not add 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.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns recently stored memories in reverse chronological order, using a specific verb ('Return') and resource ('memories'). It distinguishes itself from siblings like 'recall' (likely search-based) and 'recall_as_of' by focusing on recency without a specific query.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly advises using this tool to surface fresh context when lacking a specific query, e.g., 'what did we just decide?'. While it implies alternatives for specific recalls, it does not name them explicitly. The sibling list provides additional context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Store a single piece of information in the agent's long-term memory. Use this whenever the user shares a stable fact, preference, decision, goal, or instruction you should recall in a future conversation. Memory is typed (13 categories) and carries confidence + provenance so later retrievals can rank and filter intelligently. Content is capped at 10000 chars - store atomic, self-contained statements.
| Name | Required | Description | Default |
|---|---|---|---|
| tags | No | Optional lowercase tag list for later filtering. | |
| type | No | Semantic memory type. Use 'preference' for likes/styles, 'fact' for stable factual claims, 'decision' for choices the user has made, 'goal' for objectives, 'instruction' for explicit how-to directives, 'event' for things that happened, 'observation' for inferred behavior. | fact |
| title | No | Short label (<= 100 chars). If omitted, derived from content. | |
| source | No | Who wrote this memory. Defaults to the connected MCP client (e.g. 'cursor', 'codex', 'claude-ai'), falling back to 'mcp-agent'. Up to 64 letters, digits, '.', '_', or '-'. | |
| content | Yes | The memory itself - one atomic statement. Max 10000 characters. | |
| agent_id | No | Memanto agent identifier the memory belongs to (required: no MEMANTO_DEFAULT_AGENT_ID is configured). | |
| confidence | No | How sure you are this is true (0.0-1.0). Use 1.0 only for things the user stated explicitly. 0.6-0.8 is a sensible default for inferred information. | |
| provenance | No | How this memory was obtained. 'explicit_statement' means the user said it; 'inferred' means you deduced it; 'observed' means you saw it during a tool call; 'corrected' means it overrides an earlier wrong memory. | explicit_statement |
| Name | Required | Description |
|---|---|---|
| status | Yes | 'ok' on success, 'error' otherwise. |
| message | No | Human-readable detail. |
| agent_id | Yes | Agent the memory belongs to. |
| memory_id | No | Memanto-assigned ID. |
| namespace | No | Underlying namespace. |
| confidence | No | Confidence stored. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses useful behavioral traits: memory is typed, carries confidence/provenance, and content is capped at 10000 characters. However, it does not mention behavior on duplicate storage, overwrite semantics, or what happens on failure, which are relevant for a persistence tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is four sentences, front-loaded with the primary purpose. Every sentence contributes: purpose, usage trigger, behavioral features, and content length constraint. No unnecessary filler.
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 (8 params, enums, output schema), the description covers purpose, usage, and key constraints well. The output schema exists, so return values need not be described. It lacks explicit handling of duplicates/overwrites, but this is a minor gap for a store operation with optional tags and provenance.
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 100%, so the baseline is 3. The description adds value by explaining why parameters like type, confidence, and provenance exist ('so later retrievals can rank and filter intelligently') and emphasizes the atomicity expected in content ('store atomic, self-contained statements'), enriching beyond the schema's individual 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 'Store a single piece of information in the agent's long-term memory,' which clearly identifies the verb (store), resource (long-term memory), and scope (single piece). It distinguishes from siblings like recall (retrieval) and batch_remember (batch storage) through the explicit 'single piece' phrasing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear guidance on when to use the tool: 'Use this whenever the user shares a stable fact, preference, decision, goal, or instruction you should recall in a future conversation.' It does not explicitly name alternatives or state when not to use it, but the context strongly implies it is for single-item storage versus retrieval or batch, which is sufficient.
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.8answer4 fields changedInput schema / properties / kiosk_mode / anyOfAdded value: +[
+ {
+ "type": "boolean"
+ },
+ {
+ "type": "null"
+ }
+]Input schema / properties / kiosk_mode / defaultPrevious value: -falseNew value: +nullInput schema / properties / kiosk_mode / descriptionPrevious value: -"If true, refuses to answer when no memory clears the similarity threshold (useful for strictly grounded applications)."New value: +"If true, refuses to answer when no memory clears the similarity threshold (useful for strictly grounded applications). Defaults to the server config value."Input schema / properties / kiosk_mode / typeRemoved value: -"boolean"batch_remember3 fields changedInput schema / properties / memories / descriptionPrevious value: -"List of memory dicts. Each item supports the same fields as `remember` (content [required], type, title, confidence, tags, source, provenance). Max 100 items."New value: +"List of memory dicts. Each item supports the same fields as `remember` (content [required], type, title, confidence, tags, source, provenance) with the same allowed values; an item without a source is attributed to the calling client. Max 100 items."Output schema / $defs / BatchRememberItemResult / descriptionAdded value: +"Result for one item in a batch memory write."Output schema / descriptionAdded value: +"Response returned by the batch_remember MCP tool."recall1 field changedInput schema / properties / min_similarity / descriptionPrevious value: -"Minimum similarity score 0-1."New value: +"Minimum similarity score 0-1. Applied by the search backend, so the top-N is filled with results that pass the threshold. Defaults to the server config value."remember4 fields changedInput schema / properties / source / anyOfAdded value: +[
+ {
+ "maxLength": 64,
+ "pattern": "^[A-Za-z0-9._-]+$",
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+]Input schema / properties / source / defaultPrevious value: -"mcp-agent"New value: +nullInput schema / properties / source / descriptionPrevious value: -"Free-form label for the source of this memory (e.g. 'user', 'web', 'tool-call', or your agent name)."New value: +"Who wrote this memory. Defaults to the connected MCP client (e.g. 'cursor', 'codex', 'claude-ai'), falling back to 'mcp-agent'. Up to 64 letters, digits, '.', '_', or '-'."Input schema / properties / source / typeRemoved value: -"string"v0.1.0answerbatch_rememberrecallrecall_as_ofrecall_changed_sincerecall_recentrememberScored across 7 tools
Each tool serves a clearly distinct purpose: remember for single storage, batch_remember for bulk storage, and the recall variants cover different retrieval modes (semantic, recent, point-in-time, changed-since). The 'answer' tool adds a synthesis layer that is distinct from raw retrieval. No two tools appear to do the same thing.
All tool names are lowercase with underscores, following a consistent verb-first convention. The recall_* family is uniformly prefixed, and remember/batch_remember are clearly related. The naming is predictable and intuitive.
Seven tools is well-scoped for a memory server, covering storage and retrieval without bloat. Each tool earns its place, and the count sits comfortably in the ideal 3-15 range.
The tool surface covers creating and reading memories thoroughly, but lacks update and delete operations. Agents cannot correct a wrong memory or remove outdated information, which is a notable gap for a memory system. The absence of these lifecycle operations may cause dead ends in real use.
Universal memory for AI agents and tools. Save, organize and search context anywhere.
Persistent memory for AI agents. EU-hosted, privacy-first, hybrid recall, contradiction detection.
Persistent memory for AI agents to retain, retrieve, and recall conversation context through MCP.
Persistent memory and knowledge graphs for AI agents. Hybrid search, context checkpoints, and more.
