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., "@claude-crowed search for previous research on the payment integration"
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.
A persistent semantic memory system for Claude Code, built as an MCP server. Replaces Claude Code's built-in flat-file memories with a structured, searchable, versioned document store.
Semantic search via sentence-transformers (nomic-embed-text-v1.5) + sqlite-vec
Versioned memories with full history (update creates a new version, old versions preserved)
Soft-delete with rate limiting (5 per session) and undo
Dynamic "see also" via embedding nearest-neighbor lookup (no manual linking needed)
Duplicate detection with adjustable similarity threshold
Timeline browsing with cursor-based pagination
Export/import for backup and portability
Migration tool to import existing CLAUDE.md and auto-memory files
Hot-reload dev mode via stdio proxy that watches for git commits
Web visualizer — force-directed graph of memories with search, detail browsing, and CRUD
Related MCP server: MemoVault
uv syncclaude mcp add --scope user claude-crowed -- uv run --directory /path/to/claude-crowed claude-crowedThen add the memory directive to your ~/.claude/CLAUDE.md so Claude knows to use it.
The core principle is that crowed is a memoization layer for Claude Code. Every piece of knowledge, research, implementation detail, design decision, open question, or idea should flow through crowed so that future sessions can skip the work entirely. Before you think, search. Before you conclude, store. If a prior session already figured something out, reuse it — don't re-derive it.
## Memory System (claude-crowed)
You have access to a persistent memory system via MCP tools (server: claude-crowed).
**This is your memoization layer.** The whole point is to avoid repetitive work and
thinking across sessions. Every piece of knowledge, research, implementation detail,
design decision, open question, or idea that you produce should flow through crowed
so that future sessions can skip the work entirely.
Think of crowed as a cache: before you think, search. Before you conclude, store.
If a prior session already figured something out, reuse it — don't re-derive it.
### Search Discipline
- At the **START** of every task, call `memory_recall` (or `memory_search`) with relevant keywords.
Do not skip this step — you have no passive context from crowed without it.
- **Mid-task**: whenever you encounter unfamiliar code, patterns, or errors, search again.
Don't only search at the beginning — search whenever you hit something you might have seen before.
- **Before expensive work**: always search before launching an Explore agent, doing
multi-file Grep/Glob sweeps, or calling WebSearch/WebFetch. A prior session may have
already answered the question — skip the work if it has.
- **Before forming a plan**: search for prior plans, design decisions, or rejected
approaches. Don't re-propose something that was already tried and failed.
- Use `memory_recall` to combine search + read in one call (fewer round trips).
Use `memory_search` + `memory_read` when you need finer control.
### When to Store
Store **anything** a future session might need. If you thought about it, researched it,
or figured it out, it belongs in crowed. Specific triggers:
- **After diagnosing a root cause**: "The problem was X because Y" is always worth storing.
- **When you discover a gotcha or workaround**: non-obvious behavior, API quirks,
config footguns — things that would cost a future session time to rediscover.
- **After codebase exploration**: when you map out how a module, feature, or subsystem works,
store the finding. Frame it as the question a future session would ask.
- **After web research**: store the *actionable conclusion* — not the URL.
- **After a user correction**: store it immediately — prevents the same wrong suggestion next time.
- **After every git commit**: store novel decisions, patterns, or architecture.
- **When you form an implementation plan**: store the plan, the alternatives considered,
and why you chose this approach. Future sessions shouldn't re-derive the same plan.
- **When you have an open question or idea**: store it so it's not lost between sessions.
- **When you read and understand a complex code path**: store the summary. Reading code
is expensive — don't make the next session re-read and re-understand the same thing.
- **Don't batch**: store as you go, not at the end. Mid-task insights are the most valuable
and the easiest to forget.
### Storage Rules
- Title (max 150 chars): Must be a complete thought, not a label. Another instance of you
should judge relevance from the title alone.
- Content (max 1500 chars): One insight per memory. Split larger ideas into multiple memories.
- Prefer creating NEW memories over updating existing ones unless refining the same idea.
### Do NOT
- Accumulate knowledge in this file or in auto-memory files. Crowed is the single source of truth.
- Fetch all search results — be selective (usually 1-5).
- Delegate memory_store to a subagent.
- Re-derive something that crowed already knows. Search first, always.Tool | Purpose |
| Semantic search, returns titles only |
| Fetch full content of a memory |
| Search + read top results in one call (fewer round trips) |
| Store a new memory (with dedup check) |
| Create a new version of a memory |
| Soft-delete (rate-limited, reversible) |
| Restore a deleted memory |
| View all versions of a memory |
| Browse chronologically with pagination |
| Find semantically similar memories (dynamic nearest-neighbor) |
| Export all data to JSON |
| Import from JSON export |
| Discover and split existing memory files for migration |
| View/adjust duplicate similarity threshold |
| Summary statistics |
# Start MCP server (default, stdio transport)
claude-crowed serve
# Development mode with hot-reload on git commits
claude-crowed dev
# Export/import
claude-crowed export [--output path]
claude-crowed import <path> [--overwrite]
# Restore from backup
claude-crowed restore <backup-path>
# Rebuild embedding index
claude-crowed rebuild-embeddings
# Show stats
claude-crowed stats
# Launch web visualizer (opens browser)
claude-crowed visualize [--port 4242] [--no-browser]The web visualizer shows all memories as a force-directed graph. Nodes are colored by age (blue = recent, gold = older). Similarity edges connect semantically related memories via dynamic nearest-neighbor lookup.
uv sync --extra visualizer
uv run claude-crowed visualizeThe frontend is built automatically on launch if visualizer/dist/ is missing or
stale (requires npm). It skips the build if the dist is already up to date.
Features:
Force-directed graph with age coloring and similarity-based clustering
Labels appear progressively as you zoom in
Semantic search (press / to focus)
Click any node to browse its content and metadata
Delete/restore memories from the detail panel
SQLite with WAL mode for the memory store
sqlite-vec for vector similarity search (vec0 virtual tables)
sentence-transformers with nomic-embed-text-v1.5 (768-dim, CPU by default)
Background model loading — embedding model loads in a thread during MCP handshake (~1s startup)
Two-phase retrieval — search returns titles/metadata, read fetches full content
Embedding prefixes — search_document: for storage, search_query: for retrieval
All data is stored in ~/.local/share/claude-crowed/:
crowed.db — SQLite database
backups/ — rolling backups (max 30, created on each server start)
exports/ — JSON exports
uv run pytestSoft-delete a memory. Always confirm with the user before deleting. Deletions are reversible with memory_undelete, but limited to 5 per session as a safety measure.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes |
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 soft-delete nature, reversibility, session limit, and the need for user confirmation. This is highly transparent.
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-load the key action and safety notes. Every sentence adds essential information 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?
For a simple tool with one parameter and no output schema, the description covers purpose, behavior, safety, limits, and reversibility. It is fully complete for effective use.
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 sole parameter 'id' is not described in the description. The schema's title 'Id' provides some clarity, but the description adds no additional meaning. A baseline of 3 is appropriate given the parameter is straightforward.
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 action ('Soft-delete a memory') and distinguishes from sibling tools like memory_undelete by noting reversibility. The verb 'delete' and resource 'memory' are specific.
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 guidance: always confirm with user before deleting, and notes the per-session limit of 5 reversible deletions. This helps the agent decide when to use this tool vs. memory_undelete.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve all versions of a logical memory. Pass any version ID in the chain.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Only states it retrieves versions, but lacks details on whether it requires authentication, rate limits, pagination, or any side effects. Minimal transparency for a retrieval operation.
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 sentences, no fluff. Information is front-loaded: first sentence states purpose, second gives usage hint. 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?
Having an output schema reduces burden, but description still lacks details like required permissions, error cases (invalid ID), or behavior for empty chains. Adequate for a simple tool but could be more robust.
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% with no parameter descriptions in the input schema. Description adds meaning: 'Pass any version ID in the chain' clarifies that 'id' should be a version ID from a logical memory chain, not just any memory ID.
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 'Retrieve all versions of a logical memory', which is a specific verb+resource. Combined with the sibling tool names, it effectively distinguishes from tools like memory_read (single version) and memory_timeline (chronological order).
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 a usage hint 'Pass any version ID in the chain', but no explicit when-to-use or alternatives. Agent must infer context from sibling names without guidance on when to prefer this over memory_read or memory_timeline.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Discover and read memory files (CLAUDE.md, auto-memory) for migration into crowed.
Returns file sections split by markdown headers. Review each section and decide whether it contains KNOWLEDGE (store with memory_store) or INSTRUCTIONS (skip).
With no path: discovers all migratable files (~/.claude/CLAUDE.md and auto-memory) and returns their sections.
With a path: reads and splits that specific file.
This tool does NOT store anything. You review the sections and call memory_store for each piece of knowledge you want to keep. Skip pure instructions.
| Name | Required | Description | Default |
|---|---|---|---|
| path | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Transparently discloses behavior: discovers files, splits by markdown headers, returns sections, and explicitly states it does NOT store anything. Also mentions file locations and return format.
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, three short paragraphs each adding value. Front-loaded with purpose, then usage details, then explicit non-store disclaimer. No redundant sentences.
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 single optional parameter and no output schema, the description is complete. Explains input behavior, output format (sections split by headers), and follow-up actions. Addresses complexity adequately.
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?
Input schema has no description for the sole parameter (0% coverage). Description adds significant meaning: explains behavior with no path (discover all) vs with a path (read specific file). This compensates fully.
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 the tool discovers and reads memory files (CLAUDE.md, auto-memory) for migration, and distinguishes from siblings like memory_store by explicitly stating it does not store. The verb 'discover and read' is specific.
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 tells when to use (migration context) and when not to (skip instructions). Provides clear instructions: review sections, call memory_store for knowledge. Includes path vs no-path distinction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch the full content of a specific memory. This is the only tool that returns content. Each read is tracked in the memory_accesses table.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description discloses one behavioral trait (each read is tracked in memory_accesses table), but does not mention other aspects like idempotency, authorization needs, 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 extremely concise with two sentences, each adding value. No fluff or 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?
Given the simple tool (one param, no output schema, no annotations), the description covers the core purpose and a side effect, but lacks parameter guidance and usage boundaries.
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?
The input schema has 0% description coverage and the tool description does not explain the 'id' parameter beyond the schema. It adds no meaning to what is already in 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 verb 'Fetch' and the resource 'specific memory', and explicitly distinguishes it from siblings by saying it is the only tool that returns content.
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 context that this tool is for fetching content and is unique among siblings for returning content, but it does not explicitly state when not to use it or name alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search memory and return full content for the top results in a single call. Use this instead of memory_search + memory_read to reduce round trips.
Returns two lists:
memories: full content for the top read_k results (default 5)
also_matched: titles only for remaining results (for follow-up reads if needed)
Call this at the START of every task AND whenever you hit unfamiliar territory mid-task.
| Name | Required | Description | Default |
|---|---|---|---|
| k | No | ||
| query | Yes | ||
| read_k | No | ||
| include_deleted | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description discloses return structure (two lists), default read_k=5, and suggests usage pattern. It adds behavioral context beyond what schema provides, though some aspects like permissions or side effects are not covered.
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?
Every sentence serves a purpose: purpose, benefit over alternatives, return format, usage timing. No superfluous content. Well-structured and front-loaded.
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 4 params, no output schema, and no annotations, the description covers usage pattern, return structure, and key defaults. Missing explanation for k and include_deleted, but overall fairly complete 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 coverage is 0%, so description must compensate. It explains read_k (top results) and default 5, but does not explain k (likely number of search results) or include_deleted. Partial compensation.
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 verb 'Search memory' and specifies the resource 'memory', returning full content for top results. It distinguishes from siblings by explicitly mentioning it replaces memory_search + memory_read.
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 guidance on when to use: 'instead of memory_search + memory_read' and 'at the START of every task and whenever you hit unfamiliar territory'. No explicit when-not-to-use, but the positive guidance is strong and clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Store a new memory. Call this whenever you learn something worth remembering across sessions -- novel insights, decisions, findings, patterns, or debugging solutions. Title (max 150 chars) must be a complete, descriptive thought, not a label. Another instance of you should judge relevance from the title alone. Content max 1500 chars; split larger ideas into multiple memories. Source: manual, conversation, or auto.
Rejects near-duplicates by default (threshold adjustable via claude-crowed threshold CLI).
Set force=True to skip the duplicate check entirely.
| Name | Required | Description | Default |
|---|---|---|---|
| force | No | ||
| title | Yes | ||
| source | No | manual | |
| content | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations so description carries full burden. It reveals duplicate rejection behavior and force flag. Does not disclose side effects like overwriting, but as a create operation it's non-destructive. Sufficient for understanding.
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 informative without excess. First sentence states core purpose. Follow-up sentences add essential details. Could be slightly tighter but no wasted words.
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 9 sibling tools and absence of output schema, description covers purpose, usage, parameter semantics, and behavioral quirks (duplicates). Return value not described, but acceptable without output schema. Complete for 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 coverage is 0%, but description fully explains each parameter: title (max 150 chars, descriptive), content (max 1500 chars, split ideas), source (manual default with three options implied), force (skip duplicate check). Adds meaning beyond schema names.
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 'Store a new memory' and specifies context: learn something worth remembering across sessions. It distinguishes from sibling tools like memory_read, memory_update, etc., by focusing on creation.
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 says when to call: novel insights, decisions, etc. Provides constraints on title and content length, source options, and duplicate handling. Lacks explicit when-not-to-use, but siblings cover alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Browse memories chronologically with cursor-based pagination. Returns titles and metadata only.
| Name | Required | Description | Default |
|---|---|---|---|
| k | No | ||
| after | No | ||
| before | No | ||
| cursor | No | ||
| include_deleted | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description discloses key behavior: it is a read-only browsing tool with cursor-based pagination and limited return fields. It does not mention side effects, auth requirements, or rate limits, but these are implied by the read-only nature.
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 with two sentences, front-loading the action and pagination method, then the return type. No unnecessary words.
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 no annotations and no output schema, the description covers core purpose and return format but lacks details on pagination mechanics, parameter interactions, and output structure, leaving some gaps for agent understanding.
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?
The input schema has 5 parameters with 0% description coverage, and the description does not explain any parameter beyond hinting at cursor-based pagination. Parameter names are somewhat self-explanatory, but the tool fails to add meaningful semantics 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 verb 'browse', the resource 'memories', and distinguishes from siblings by specifying chronological order and cursor-based pagination. It also indicates what is returned (titles and metadata only).
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 implies usage for browsing memories in order, but does not provide explicit guidance on when to use this tool versus alternatives like memory_read or memory_recall, or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Restore a soft-deleted memory.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description only states the action without disclosing side effects, permissions, or error conditions (e.g., what happens if the memory was not soft-deleted).
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 sentence with no redundancy, but it could include more detail without losing conciseness, such as specifying that the ID is required.
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 simple undo operation with one parameter, the description is adequate but lacks details on return format or failure modes. No output schema, so behavior is not fully specified.
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 the 'id' parameter. While the tool name implies the ID of the memory, no additional meaning is provided 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 verb 'Restore' and the resource 'soft-deleted memory', accurately reflecting the tool's function and distinguishing it from siblings like memory_delete and memory_update.
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?
No guidance on when to use this tool versus alternatives (e.g., after memory_delete) or prerequisites. The description lacks context for proper invocation.
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, creating a new version. The old version is preserved but removed from the search index. Returns the new version's ID.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | ||
| title | No | ||
| content | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond a simple 'update', the description reveals versioning behavior, preservation of old version, removal from search index, and return of new version ID. This adds significant transparency not covered by annotations.
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 sentences with no filler. Front-loaded with purpose and key behavioral notes. 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?
Despite good behavioral detail, the description omits parameter explanations and usage context. With 3 parameters and no output schema, it should provide more field-level guidance.
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?
The input schema has 0% description coverage, yet the description does not explain any parameter semantics. It fails to describe the role of 'id', 'title', or 'content' beyond basic schema types.
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 updates an existing memory, creating a new version, and distinguishes from siblings like memory_store or memory_delete. It uses a specific verb and resource.
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?
No explicit guidance on when to use this tool vs alternatives such as memory_store or memory_delete. The description implies updating, but lacks context or exclusion criteria.
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.1.0memory_deletememory_historymemory_migratememory_readmemory_recallmemory_relatedmemory_storememory_timelinememory_undeletememory_updateScored across 10 tools
Each tool has a clearly distinct purpose: read by ID, search+read combined, store, update, delete, undelete, version history, chronological browsing, semantic relatedness, and migration from external files. No two tools perform overlapping functions.
All tools follow a consistent 'memory_verb' pattern in snake_case, with verbs like read, recall, store, update, delete, undelete, history, timeline, related, migrate. The naming is predictable and uniform.
10 tools is well-scoped for a memory management server, covering creation, retrieval, search, update, deletion (with undo), version history, chronological browsing, semantic relatedness, and migration. No tool is redundant.
The set covers full CRUD lifecycle (store, read/recall, update, delete/undelete), plus additional features like version history, timeline browsing, semantic relatedness, and migration from external formats. No obvious gaps for the stated domain of persistent memory management.
Persistent, governed institutional memory for Claude Code — specs, decisions, learnings.
Persistent memory for Claude Code and Cursor. Stop re-explaining your project every session.
Persistent cross-session memory shared by Codex, Claude Code, ChatGPT, and other AI agents.
Shared memory for coding agents. Stop re-explaining your codebase every session.
