Allows using Google Gemini embedding models for semantic memory search and storage.
Supports reranking memory search results using Hugging Face's Text Embeddings Inference (TEI) models.
Enables local embedding generation using Ollama models for offline semantic memory operations.
Allows using OpenAI's embedding models (e.g., text-embedding-3-small) for semantic memory storage and retrieval.
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., "@memory-lancedb-mcp remember my preferred terminal theme"
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.
Persistent, intelligent long-term memory for any MCP-compatible AI agent.
English | 繁體中文
Without memory, every session starts from zero. With memory-lancedb-mcp, your agent accumulates knowledge across sessions — automatically.
Before — agent has no context:
User: "Use the same animation style as last time"
Agent: "I don't have any context about previous animations. Could you describe what you'd like?"After — agent recalls past decisions:
<memories>
1. Remotion spring animation: use duration >= 20, damping 12-15 for smooth easing
2. Video export preset: 1080p, 30fps for social, 60fps for demo
</memories>
<refs>#1=6352a7d2 #2=bed148f0</refs>Store responses are minimal — no noise, just confirmation:
Stored. [topic: remotion]Related MCP server: Memsolus MCP Server
npm install -g @cablate/memory-lancedb-mcpAdd to your MCP client settings (e.g. Claude Desktop claude_desktop_config.json):
{
"mcpServers": {
"memory": {
"command": "npx",
"args": ["-y", "@cablate/memory-lancedb-mcp"],
"env": {
"EMBEDDING_API_KEY": "your-api-key",
"EMBEDDING_MODEL": "text-embedding-3-small"
}
}
}
}{
"mcpServers": {
"memory": {
"command": "npx",
"args": ["-y", "@cablate/memory-lancedb-mcp"],
"env": {
"MEMORY_LANCEDB_CONFIG": "/path/to/config.json"
}
}
}
}See config.example.json for all options.
store recall
│ │
┌────────▼────────┐ ┌────────▼────────┐
│ Filter junk │ │ Search by meaning │
│ Save + embed │ │ AND keywords │
│ Link related │ │ Re-rank results │
│ Flag conflicts │ │ Fade stale ones │
│ Tag topic │ │ Pull in related │
└────────┬────────┘ │ Merge duplicates │
│ └────────┬────────┘
▼ ▼
┌─────────────────────────────────────────────┐
│ LanceDB (local, zero-config) │
└─────────────────────────────────────────────┘Every memory_store saves to a local database, automatically links related memories, flags contradictions, and assigns topic labels — no extra API calls needed. Every memory_recall searches by both meaning and keywords, pulls in related memories the main search might miss, and includes maintenance hints so the agent can keep its own knowledge base clean.
Finds the right memory even when you use different words — searches by meaning and exact keywords simultaneously, then combines the best of both
More precise results, not just surface matches — an optional second pass re-ranks results by actual relevance (6 providers supported)
Search multiple topics at once — pass a queries array to search several keywords in one call; results are deduplicated and memories that match multiple queries rank higher
Finding A automatically surfaces related B — when a memory is found, its linked neighbors are pulled in too, even if they use completely different words
Minimal token overhead — responses use compact XML tags (<memories>, <hints>, <refs>) with short IDs, no category/scope noise
Related memories link themselves — when you store something new, it automatically creates bidirectional links to similar existing memories
Conflicts get flagged — if a new memory contradicts an existing one, you get a warning so nothing silently overwrites
Topics assigned automatically — each memory gets a topic label inferred from its content and neighbors; you can also set it explicitly
Junk gets filtered out — greetings, refusals, and meta-questions are rejected before they waste storage
Frequently used memories stay sharp, stale ones fade — a decay model balances how recent, how often accessed, and how important each memory is
Memories earn their keep — three tiers (Peripheral → Working → Core); the more a memory gets used, the faster it promotes
Full version history — when you update a memory, the old version is preserved in a chain you can trace with memory_history
The agent maintains itself — recall results include inline hints about duplicates, dormant memories, and contradictions
Health checks on demand — memory_lint finds orphaned memories, stale entries, and missing links, then fixes what it can
Merge duplicates — memory_merge combines two redundant memories into one; originals are marked as superseded
See your memory space — memory_visualize generates an interactive HTML graph you can open in any browser
Run memory_visualize to generate an interactive knowledge graph of your memory space:
Automatic clustering — related memories group together visually
Similarity edges, duplicate detection, importance sizing
Time filter, growth animation, cluster view
Self-contained HTML — open in any browser
Query → embedQuery() ─┐
├─→ RRF Fusion → Rerank → Lifecycle Decay → Length Norm → Filter
Query → BM25 FTS ─────┘Stage | Effect |
RRF Fusion | Combines semantic and exact-match recall |
Cross-Encoder Rerank | Promotes semantically precise hits |
Lifecycle Decay | Weibull freshness + access frequency + importance |
Length Normalization | Prevents long entries from dominating (anchor: 500 chars) |
Hard Min Score | Removes irrelevant results (default: 0.35) |
MMR Diversity | Cosine similarity > 0.85 → demoted |
Variable | Required | Description |
| Yes | API key for embedding provider |
| No | Model name (default: |
| No | Custom base URL for non-OpenAI providers |
| No | LanceDB storage directory |
| No | Path to JSON config file |
{
"embedding": {
"apiKey": "${EMBEDDING_API_KEY}",
"model": "jina-embeddings-v5-text-small",
"baseURL": "https://api.jina.ai/v1",
"dimensions": 1024,
"taskQuery": "retrieval.query",
"taskPassage": "retrieval.passage",
"normalized": true
},
"dbPath": "./memory-data",
"retrieval": {
"mode": "hybrid",
"vectorWeight": 0.7,
"bm25Weight": 0.3,
"minScore": 0.3,
"rerank": "cross-encoder",
"rerankApiKey": "${JINA_API_KEY}",
"rerankModel": "jina-reranker-v3",
"rerankEndpoint": "https://api.jina.ai/v1/rerank",
"rerankProvider": "jina",
"candidatePoolSize": 20,
"hardMinScore": 0.35,
"filterNoise": true
},
"enableManagementTools": true,
"enableSelfImprovementTools": false,
"enableVisualizationTools": true,
"scopes": {
"default": "global",
"definitions": {
"global": { "description": "Shared knowledge" },
"agent:my-bot": { "description": "Private to my-bot" }
},
"agentAccess": {
"my-bot": ["global", "agent:my-bot"]
}
},
"decay": {
"recencyHalfLifeDays": 30,
"frequencyWeight": 0.3,
"intrinsicWeight": 0.3
}
}Works with any OpenAI-compatible embedding API:
Provider | Model | Base URL | Dimensions |
OpenAI |
|
| 1536 |
Jina |
|
| 1024 |
DeepInfra |
|
| 1024 |
Google Gemini |
|
| 3072 |
Ollama (local) |
|
| varies |
Provider |
| Endpoint | Example Model |
Jina |
|
|
|
Hugging Face TEI |
|
|
|
SiliconFlow |
|
|
|
Voyage AI |
|
|
|
Pinecone |
|
|
|
DashScope |
|
|
|
Tool | Description |
| Search memories — supports batch queries, relation expansion, topic filtering, and inline maintenance hints |
| Save a memory — auto-links related ones, flags contradictions, infers topic, filters junk |
| Delete by ID or search query |
| Update a memory; the old version is preserved in a version chain |
| Merge two memories into one |
| Trace version history through update/merge chains |
Tool | Description |
| Usage statistics by scope and category |
| List recent memories with filtering |
| Health checks + auto-fix missing relations |
Enable: "enableManagementTools": true
Tool | Description |
| Log structured learning/error entries |
| Create skill scaffolds from learnings |
| Summarize governance backlog |
Enable: "enableSelfImprovementTools": true
Tool | Description |
| Generate interactive HTML memory graph |
Params: output_path, scope, threshold (default: 0.65), max_neighbors (default: 4)
Disable: "enableVisualizationTools": false
LanceDB table memories:
Field | Type | Description |
| string (UUID) | Primary key |
| string | Memory text (FTS indexed) |
| float[] | Embedding vector |
| string |
|
| string | Scope identifier |
| float | Importance score 0-1 |
| int64 | Creation timestamp (ms) |
| string (JSON) | Extended metadata (tier, access_count, relations, topic, etc.) |
git clone https://github.com/cablate/memory-lancedb-mcp.git
cd memory-lancedb-mcp
npm install
npm testRun locally:
EMBEDDING_API_KEY=your-key npx tsx server.tsBuilt on CortexReach/memory-lancedb-pro — original work by win4r and contributors.
MIT — see LICENSE for details.
Delete specific memories. Supports both search-based and direct ID-based deletion.
| Name | Required | Description | Default |
|---|---|---|---|
| query | No | Search query to find memory to delete | |
| scope | No | Scope to search/delete from (optional) | |
| memoryId | No | Specific memory ID to delete |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are supplied, so the description carries the full behavioral burden for what is clearly a destructive operation. It says 'delete' but omits whether deletion is permanent/reversible, what permissions are needed, what happens to related memories, or what a successful result looks like.
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 short sentences with no filler, and the core purpose is front-loaded before the mode detail. Every clause earns its place.
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?
For a destructive tool with zero annotations and no output schema, the description should disclose reversibility, side effects, and the relationship between the two deletion modes. All of those are absent, leaving the agent under-informed about consequences.
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 each parameter is already documented, establishing a baseline of 3. The description adds marginal value by grouping query/scope into a search mode and memoryId into a direct mode, but does not clarify mutual exclusivity or format expectations.
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?
States a specific verb and resource ('Delete specific memories') and clarifies that two deletion modes exist. It does not distinguish itself from sibling mutators like memory_update or memory_merge, so an agent must infer the boundary from the name alone.
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 two-mode statement implicitly tells the agent that either a query or a memoryId drives the operation, which is useful context. However, it never says when to prefer search-based versus ID-based deletion, nor when to use this tool instead of memory_update or memory_merge.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Trace the version history of a memory through its supersede/merge chain. Shows how a memory evolved over time.
| Name | Required | Description | Default |
|---|---|---|---|
| scope | No | Scope filter (optional) | |
| memoryId | Yes | ID of any memory in the chain (full UUID or 8+ char prefix) | |
| direction | No | Traversal direction (default: "both") |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears the full disclosure burden. 'Trace' and 'Shows how a memory evolved' strongly imply a non-mutating read, but it never states cost, permissions, pagination, or what happens if the ID is not part of a chain.
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 short sentences, front-loaded with the core action ('Trace the version history...') and no filler. Every sentence adds distinct 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?
With only three fully documented parameters and no output schema, the description covers what the tool is for and what it conceptually returns (an evolution view). It is nearly complete, missing only invocation constraints such as what happens on an unresolved ID.
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 memoryId (full UUID or 8+ prefix), scope, and the direction enum are already fully documented in the schema. The description adds no meaning beyond the structured fields, so the baseline 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?
Specific verb ('trace') plus a precise resource ('version history of a memory through its supersede/merge chain'), which makes its scope distinct from the flat recall siblings. It does not name an alternative tool explicitly, but the chain/evolution framing clearly separates it from memory_recall and memory_merge.
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?
Usage is implied rather than stated: an agent can infer 'use when you need a memory's lineage,' and the mention of supersede/merge hints at its relation to memory_merge. There is no explicit when-to-use vs. alternative guidance or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Merge two related memories into one. Creates a new merged memory and invalidates both originals. Use when duplicate or fragmented memories cover the same topic.
| Name | Required | Description | Default |
|---|---|---|---|
| scope | No | Scope filter (optional) | |
| primaryId | Yes | ID of the primary memory (text used as base if mergedText is not provided) | |
| importance | No | Override importance (default: max of both) | |
| mergedText | No | Explicit merged text. If omitted, both texts are concatenated. | |
| secondaryId | Yes | ID of the secondary memory to absorb |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden and does disclose the critical side effect: a new memory is created and both originals are invalidated, which is the key consequence an agent must know before calling. It omits reversibility (can a merge be undone via memory_history?), permission requirements, and error behavior for nonexistent IDs.
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?
Three short, front-loaded sentences with zero padding: purpose, side effect, then usage trigger. Every sentence earns its place.
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?
All five parameters are documented and the core mutation semantics are explained. Since there is no output schema, the description could say what the caller receives (e.g., the new memory's ID) or how missing IDs are handled, but it is otherwise sufficient for correct invocation.
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 every parameter including the primary/secondary roles, importance default, and mergedText fallback is already documented in the schema. The description adds no parameter-level detail beyond that baseline, so a 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?
States a specific verb (merge) and resource (two memories), and distinguishes itself from siblings like memory_store and memory_update by describing the compound effect: a new merged memory is created and both originals are invalidated. An agent can tell exactly what this does without opening the schema.
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?
Explicitly names the triggering condition: 'Use when duplicate or fragmented memories cover the same topic.' That is a clear when-to-use statement, but it does not name alternatives (e.g., memory_update for single-record edits) or state when not to merge.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search through long-term memories using hybrid retrieval (vector + keyword search). Use when you need context about user preferences, past decisions, or previously discussed topics.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max results to return (default: 5, max: 20) | |
| query | Yes | Search query for finding relevant memories | |
| scope | No | Specific memory scope to search in (optional) | |
| since | No | Time range filter. Use shorthand like "3d" (3 days), "1w" (1 week), "2h" (2 hours), or ISO timestamp. | |
| topic | No | Filter by topic label (e.g. "remotion", "invoice"). Only returns memories tagged with this topic. | |
| queries | No | Multiple search queries in one call. Results are merged and deduplicated. Memories matching multiple queries rank higher. Use instead of calling memory_recall multiple times. | |
| summary | No | When true, returns a topic-grouped overview (topic name, count, latest date, preview) instead of individual memories. Use a broad query like "project decisions" or "recent work" to scan your memory space, then follow up with a normal recall on a specific topic to drill in. | |
| category | No | Filter by category |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It discloses the retrieval method (hybrid vector + keyword), which is useful, but says nothing about read-only/non-destructive nature, result ordering, or limits beyond what the schema states. Read-only is only implied by 'Search'.
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 concise sentences with no waste, front-loading the retrieval mechanism before the usage trigger. Appropriately sized for the tool's complexity.
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 eight parameters and no output schema, the description is somewhat thin. It does not describe the return shape, and while the schema richly documents individual parameters (including the summary overview mode), the description itself adds limited context for such a feature-rich recall 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 100%, so the schema already documents all eight parameters in detail. The description adds no additional parameter semantics beyond the schema. Baseline 3 applies when structured fields do the heavy lifting.
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?
States a specific verb (Search) and resource (long-term memories) plus the retrieval mechanism (hybrid vector + keyword). It is clearly distinct from siblings like memory_store, memory_forget, and memory_update, though it does not name them explicitly.
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?
Gives concrete trigger conditions: user preferences, past decisions, or previously discussed topics. It lacks explicit when-not guidance or direct routing to siblings such as memory_history, but the context of use is unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Save important information in long-term memory. Use for preferences, facts, decisions, and other notable information.
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | Information to remember | |
| scope | No | Memory scope (optional, defaults to default scope) | |
| topic | No | Topic label for grouping related memories (e.g. "remotion", "invoice"). Auto-inferred from similar memories if omitted. | |
| category | No | Memory category | |
| importance | No | Importance score 0-1 (default: 0.7) | |
| lesson_rule | No | For category="lesson": the derived rule to follow (e.g. "check for syntax errors before assuming cache issues") | |
| lesson_trigger | No | For category="lesson": what situation triggers this lesson (e.g. "when editing CSS layout") | |
| lesson_principle | No | For category="lesson": the universal principle (e.g. "verify assumptions with evidence before acting") |
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 doesn't disclose whether the operation is permanent, how deduplication works, what happens when a similar memory exists, or any return behavior. Only mutation is implied by 'Save'.
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 concise sentences, front-loaded with the core purpose, with no wasted words. Very 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?
With 8 parameters, no annotations, and no output schema, the description is too sparse. It doesn't cover important behavioral aspects (e.g., overwriting, deduplication, scope defaults, importance defaults) that an agent needs to invoke the tool correctly, especially given the rich schema.
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 schema already documents all parameters in detail. The description adds a list of example use cases but no parameter semantics beyond what the schema provides. Baseline 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?
States a specific verb+resource ('Save important information in long-term memory') and gives examples of what qualifies. It's clear what the tool does, though it doesn't differentiate from sibling tools like memory_update or memory_merge.
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 lists when to use it ('for preferences, facts, decisions') but doesn't explicitly say when to use alternatives like memory_update (for changing existing memories) or memory_merge. Implied usage only.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update an existing memory. For preferences/entities, changing text creates a new version (supersede) to preserve history. Metadata-only changes (importance, category) update in-place.
| Name | Required | Description | Default |
|---|---|---|---|
| text | No | New text content (triggers re-embedding) | |
| category | No | New category | |
| memoryId | Yes | ID of the memory to update (full UUID or 8+ char prefix) | |
| importance | No | New importance score 0-1 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and delivers the key non-obvious trait: text changes on preferences/entities create a superseding version (history preserved), while metadata-only changes update in-place. This is exactly the behavioral context an agent needs to predict side effects.
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?
Three tight sentences with the core semantics (versioning vs in-place) front-loaded immediately after the purpose. Zero waste.
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 enough for a 4-param mutation tool with no output schema: purpose, required param, and the versioning side effect are covered. Missing only explicit when-to-use routing against siblings like memory_merge.
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% and the schema already documents all four params (text triggers re-embedding, memoryId accepts UUID/prefix, importance 0-1, category enum). The description adds no parameter-level detail beyond the schema, so baseline 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?
States a specific verb+resource ('Update an existing memory') and distinguishes behavior by category type. An agent can tell it apart from memory_store (create) and memory_merge without opening schemas.
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?
Implies usage by describing what updating does in two cases, but never states when to use this vs memory_store or memory_merge, nor any prerequisites. Context is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate an interactive HTML visualization of the memory graph. Shows semantic clusters, similarity edges, duplicate detection, importance distribution, and growth timeline. Returns the HTML as text or writes it to a file path.
| Name | Required | Description | Default |
|---|---|---|---|
| scope | No | Scope to visualize (default: all accessible scopes) | |
| threshold | No | Cosine similarity threshold for drawing edges between memories (0.0-1.0, default: 0.65) | |
| output_path | No | File path to write the HTML output. If omitted, returns the HTML content directly. | |
| max_neighbors | No | Maximum edges per node (default: 4) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations, so the description carries the full burden. It usefully discloses the two output modes (returns HTML text vs. writes to output_path) and the visualized content, which is real behavioral value, but says nothing about read-only safety, whether it mutates state, or performance cost on large graphs.
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?
Three tight sentences: purpose, content list, output behavior. Front-loaded and free of filler, though the content enumeration is somewhat list-heavy.
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 no output schema, the description correctly covers return semantics (HTML text or file). All four parameters are documented in the schema, and the tool's rendering scope is described, so an agent has what it needs to invoke it correctly.
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 schema already documents scope, threshold, output_path, and max_neighbors. The description restates the output_path behavior ('returns the HTML as text or writes it to a file path') but adds no format, default, or constraint detail 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?
States a specific verb (Generate) and resource (interactive HTML visualization of the memory graph) and enumerates what it renders (clusters, similarity edges, duplicates, importance, timeline). It is clearly distinct from the CRUD siblings, though it never explicitly contrasts itself with them.
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?
Usage is implied by the nature of the tool (inspect/visualize the memory graph), but there is no explicit when-to-use, when-not-to-use, or alternative routing. With siblings all being memory mutations, an agent can infer this is the inspection path, but the description does not say so.
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.
v2.0.33memory_forgetmemory_historymemory_mergememory_recallmemory_storememory_updatememory_visualizeScored across 7 tools
Each tool maps to a distinct memory operation: search, store, delete, update, merge, history, and visualize. Boundaries are clear, with well-differentiated pairs like update vs merge and recall vs history.
All tools follow a consistent memory_<verb> snake_case pattern with predictable verbs. No mixing of conventions or ambiguous naming.
Seven tools is well-scoped for a long-term memory management server. Each tool earns its place without redundancy.
The surface covers create, read, update, delete, merge, history, and visualization. However, there is no explicit list-all or get-by-ID tool, though recall search can work around this minor gap.
Persistent memory and knowledge management for AI agents with semantic search and 50+ tools.
Persistent memory for AI agents. Search, store, and recall across sessions.
Persistent memory for AI agents: add, search, update, and delete long-term memories.
Memory system for AI agents with semantic search. Store and recall memories with ease.
