Click on "Install 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., "@Mnemonic remember that I prefer direct answers"
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 memory management for Claude and other AI assistants. Give your AI a brain that remembers.
Born from the Claude Memory Architecture research project.
# Using uvx (recommended)
uvx mnemonic-memory
# Or pip
pip install mnemonic-memoryRelated MCP server: SAE4U Memory
Add to your Claude Code MCP config (~/.claude.json or project .claude/settings.json):
{
"mcpServers": {
"mnemonic": {
"command": "uvx",
"args": ["mnemonic-memory"]
}
}
}Or with pip-installed version:
{
"mcpServers": {
"mnemonic": {
"command": "mnemonic"
}
}
}Tool | Description |
| Create a new memory with tags and triggers |
| Retrieve a memory by ID |
| Update an existing memory |
| Permanently delete a memory |
| Full-text search with tag filtering |
| List all memories with sorting |
| Pin important memories |
| Export all memories to JSON |
| Import from a previous export |
| View memory statistics |
Semantic Search: Find memories by meaning, not just keywords
Auto-Decay: Memories fade based on access patterns
Consolidation: Automatically merge similar memories
Maintenance: Clean up stale data
mnemonic_create({
"title": "Bash's communication preferences",
"content": "Direct and concise. Lead with conclusions (Minto Pyramid). No fluff.",
"tags": ["preferences", "communication"],
"triggers": ["how should I respond to bash"]
})# Full-text search
mnemonic_search({"query": "communication preferences"})
# Filter by tags
mnemonic_search({"tags": ["preferences"]})
# Combined
mnemonic_search({"query": "direct", "tags": ["communication"]})mnemonic_pin({"id": "abc-123", "pinned": true})Memories are stored in ~/.mnemonic/memories.db (SQLite).
Override with MNEMONIC_DATA_DIR environment variable:
export MNEMONIC_DATA_DIR="/custom/path"memories
├── id (TEXT, UUID)
├── type (TEXT, default 'memory')
├── title (TEXT)
├── content (TEXT)
├── weight (REAL, 0.1-1.0)
├── pinned (BOOLEAN)
├── emotional_flag (BOOLEAN)
├── created_at (TEXT, ISO timestamp)
├── updated_at (TEXT)
├── last_accessed_at (TEXT)
├── access_count (INTEGER)
├── status (TEXT: active, archived)
└── metadata (JSON)
tags
├── id (INTEGER)
└── name (TEXT, unique)
memory_tags (many-to-many)
triggers
├── id (INTEGER)
├── memory_id (TEXT)
└── phrase (TEXT)This project implements the Claude Memory Architecture research:
Weighted memories: Not all memories are equal (0.1-1.0 weight)
Memory decay: Unused things fade (premium feature)
Depth on demand: Load summaries, expand when needed
Trigger-based recall: Phrases that surface relevant memories
# Clone
git clone https://github.com/bashoh/mnemonic-memory
cd mnemonic-memory
# Install with dev dependencies
pip install -e ".[dev]"
# Run locally
python -m mnemonicMIT
Built by Bash @ Wishly Group
"Current AI assistants have Alzheimer's. Let's fix that."
Create a new memory.
Use this to store important information that should persist across sessions. Memories can be tagged for organization and have trigger phrases that surface them when relevant topics come up.
Example: - Title: "Bash's communication style" - Content: "Direct, concise, no fluff. Lead with conclusions." - Tags: ["preferences", "user-profile"] - Triggers: ["how does bash like responses"]
| Name | Required | Description | Default |
|---|---|---|---|
| params | Yes | Input for creating a new memory. |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It adds useful context about persistence ('persist across sessions') and trigger-based surfacing ('surface them when relevant topics come up'). However, it does not disclose any side effects, permissions, or error behaviors, though for a create operation this is minimal. The description does not contradict any structured data.
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 tight and front-loaded, starting with the core purpose. The example is well-structured and earns its place by concretely demonstrating usage. Every sentence contributes meaning, with 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 output schema exists and the input schema covers all parameters, the description is sufficiently complete. It covers the core use-case, provides an illustrative example, and explains memory behaviors like persistence and triggering. It might not mention edge cases or limitations, but the schema and output schema handle the rest, so nothing critical is missing.
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 schema provides 100% parameter descriptions, so the baseline is 3. The description adds value by presenting a complete example with realistic values for title, content, tags, and triggers, illustrating how to use the parameters in practice. It also conceptually explains how tags and triggers work, which enriches understanding beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Create a new memory,' which is a specific verb and resource, clearly distinguishing it from sibling tools like mnemonic_update or mnemonic_delete. The example further confirms the agent's understanding of what 'create' entails, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description says 'Use this to store important information that should persist across sessions,' providing clear context on when to invoke the tool. It does not explicitly mention alternatives or when not to use it, but the 'create' operation is self-evident versus siblings. This matches 'clear context, no exclusions'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Permanently delete a memory.
This cannot be undone. Consider setting status to 'archived' instead if you might need the memory later.
| Name | Required | Description | Default |
|---|---|---|---|
| params | Yes | Input for deleting a memory. |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility for disclosing behavioral traits. It states 'This cannot be undone,' which is the most critical behavior for a delete operation. It also implies permanence, though it does not cover other aspects like permissions or side effects. Overall, it provides key transparency for a destructive action.
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 short sentences that front-load the core purpose ('Permanently delete a memory') and provide critical caveats. No extraneous 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?
For a simple one-parameter delete tool, the description fully covers the nature of the operation, its irreversibility, and a suggested alternative. The presence of an output schema means return values are handled elsewhere, so nothing is missing here.
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 schema already provides full coverage for the single parameter (id) with description 'Memory UUID to delete.' The tool description does not add any additional meaning about the parameter beyond what the schema states, 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 with a specific verb and resource: 'Permanently delete a memory.' This distinguishes it from sibling tools like mnemonic_update or mnemonic_pin, which imply modification or categorization rather than deletion.
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 says when to consider an alternative: 'Consider setting status to \'archived\' instead if you might need the memory later.' This gives clear usage guidance and an alternative tool/approach, which is more than minimal.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Export all active memories to JSON.
Returns a complete export that can be imported later or backed up. Useful for:
Backing up memories
Transferring to another system
Debugging
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It states the export covers 'all active memories' and is 'complete', implying a read-only operation without side effects, but does not explicitly state non-destructiveness, authentication requirements, or potential limitations like size. This is adequate but not thorough.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, front-loaded with the main purpose, and uses a clear bullet list for use cases. Every sentence adds value without 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's simplicity (no parameters), the presence of an output schema, and a clear description of purpose and when to use it, the description is fairly complete. The main gap is the lack of safety/behavioral details, but since it is a simple export operation, the provided information is sufficient for most use cases.
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 tool has zero parameters and the schema coverage is 100%, so there are no parameter semantics to explain. Baseline 4 is appropriate; the description adds value by clarifying what the export contains (all active memories) rather than focusing on parameters.
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 exports all active memories to JSON, using a specific verb ('Export') and resource ('all active memories'). It distinguishes from siblings by specifying the export format and scope, making it distinct from mnemonic_list or mnemonic_get.
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 use cases: backing up memories, transferring to another system, and debugging. This gives clear context for when to use the tool, though it does not explicitly mention when not to use it or name alternative tools as exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a single memory by its ID.
Returns the full memory including content, tags, triggers, and metadata. Also records that the memory was accessed (updates access count and timestamp).
| Name | Required | Description | Default |
|---|---|---|---|
| params | Yes | Input for getting a memory by ID. |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It explicitly discloses the side effect of recording access (updates access count and timestamp) and enumerates the returned fields (content, tags, triggers, metadata). This goes beyond a simple read verb and provides valuable behavioral context, though it does not mention error handling or security prerequisites.
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 with no filler: the first states the primary action, the second adds return contents and side effect. It is front-loaded and 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?
Given the tool's simplicity (one parameter, output schema present), the description sufficiently covers the operation, return data, and side effect. No annotations exist, but the description compensates with relevant behavioral detail. There is nothing materially missing for an agent to select and 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 coverage is 100%: the 'id' parameter is already described as 'Memory UUID'. The description adds no additional meaning or formatting details beyond the schema, 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?
The description states 'Get a single memory by its ID' – a specific verb and resource, and clarifies it returns the full memory. This clearly distinguishes it from sibling tools like mnemonic_list or mnemonic_search, which have broader scopes.
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 clearly implies use when you have a specific memory ID and need the complete memory, but it does not explicitly mention alternatives or exclusions. Since the sibling tools provide context, the usage intent is clear without explicit 'when not to use' guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Import memories from a previous export.
The data must be in the export format with a 'memories' array.
Options:
overwrite: If true, updates existing memories with matching IDs If false, skips memories that already exist
Returns statistics about the import operation.
| Name | Required | Description | Default |
|---|---|---|---|
| params | Yes | Input for importing memories. |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It explains the overwrite behavior (update vs. skip) and that statistics are returned, but it does not explicitly state that new memories (with non-matching IDs) are added to the store. This leaves a gap about the core import action for new entries.
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 tightly written, with a clear opening purpose, a short format note, bullet-style options, and a return-value statement. Every line is useful and contributes to understanding without 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?
The description covers the input format, the overwrite behavior, and the return type, and the presence of an output schema reduces the need to detail return values. It lacks an explicit statement about adding new memories that don't already exist, but this is largely implied by the word 'import' and the overwrite semantics.
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 schema already describes both parameters (data, overwrite), and the description adds value by expanding on the overwrite behavior, including what happens when overwrite is false. It also specifies that data must contain a 'memories' array, reinforcing the schema's description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Import memories from a previous export' with a specific verb and resource, distinguishing it from sibling tools like create, export, and search. The format requirement and overwrite option further clarify its unique role.
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 context for when to use the tool: when importing from a previous export, with the requirement that data must be in the export format. It does not explicitly spell out alternatives or exclusions, but the context is strong enough for correct selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all memories with optional filtering and sorting.
Use this for browsing memories rather than searching. Returns paginated results with metadata.
| Name | Required | Description | Default |
|---|---|---|---|
| params | Yes | Input for listing memories. |
| Name | Required | Description |
|---|---|---|
| result | Yes |
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 pagination behavior ('Returns paginated results with metadata'), which is valuable. However, it does not mention read-only nature, any auth requirements, or how pagination cursors/offsets work—though the output schema may cover some of this.
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 sentences, front-loaded with the core purpose, then key usage guidance and return behavior. No redundant or filler content.
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 list tool with a nested param schema, full schema coverage, and an output schema, the description is appropriately sized. It covers purpose, browse-vs-search distinction, and pagination metadata, which together are sufficient for an agent to select and invoke the tool 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?
Input schema coverage is 100%, with each parameter (limit, status, sort_by) having its own description. The description adds only a high-level mention of 'optional filtering and sorting,' which does not go beyond the schema. Baseline 3 is appropriate because the schema already documents the parameters well.
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 'List all memories with optional filtering and sorting', which clearly states the verb, resource, and scope. It also distinguishes the tool from the sibling search tool by stating it is for browsing rather than searching.
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 frames usage: 'Use this for browsing memories rather than searching.' This gives a clear when-to-use and when-not-to-use signal, directly contrasting with the sibling mnemonic_search tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Pin or unpin a memory.
Pinned memories:
Won't decay in weight over time (premium feature)
Are prioritized in search results
Useful for critical information like user preferences
| Name | Required | Description | Default |
|---|---|---|---|
| params | Yes | Input for pinning/unpinning a memory. |
| Name | Required | Description |
|---|---|---|
| result | Yes |
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 behavioral consequences of pinning (no decay, search prioritization, premium feature), which adds value beyond the schema. It doesn't detail return values or errors, but the operation is simple and reversible.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, front-loaded with the action, and uses bullet points to convey additional consequences without unnecessary wording. 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?
Given the simple toggle operation and presence of an output schema, the description covers the core purpose and behavioral implications. It could mention side effects like reversibility or authentication, but these are implied by 'pin or unpin'.
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 both `id` and `pinned` described clearly. The description doesn't add parameter-specific meaning beyond what the schema already states, so 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?
The description clearly states 'Pin or unpin a memory' with a specific verb and resource, and the bullet points explain the effects of pinning (decay prevention, search priority). This distinguishes it from sibling tools like update or delete.
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 context for when pinning is useful (critical information, user preferences) and implies the action of toggling. It doesn't explicitly mention when not to use or reference alternatives, but the use case is well defined enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search memories using full-text search and/or tag filtering.
The query searches both title and content using SQLite FTS5. Results are ranked by relevance and weight.
Examples: - query: "wishly deals" # Find memories about Wishly deals - tags: ["project"] # All memories tagged 'project' - query: "API", tags: ["technical"] # Combine search and filtering
| Name | Required | Description | Default |
|---|---|---|---|
| params | Yes | Input for searching memories. |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since no annotations are provided, the description bears the full burden of behavioral disclosure. It states that the query searches both title and content via SQLite FTS5 and that results are ranked by relevance and weight, which goes beyond the schema. It could mention edge cases like empty queries, but the core behavior is well 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 concise and front-loaded: the first sentence states the primary purpose, followed by two sentences of technical detail and examples. Every sentence earns its place, with no fluff or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is comprehensive for a search tool of this complexity. It covers the search scope, ranking behavior, and provides practical examples. The output schema exists, so the description need not explain return values. The schema covers parameter details, making the combination 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?
The schema description coverage is 100%, and the schema already provides detailed descriptions for all parameters (tags, limit, query). The description adds examples but no new parameter semantics, so the baseline 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 purpose: 'Search memories using full-text search and/or tag filtering.' It specifies the verb (search), the resource (memories), and the mechanism (full-text and tag filtering), distinguishing it from sibling tools like list, get, and create.
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 context on how to use the tool with examples covering different modes (query-only, tags-only, combined). While it doesn't explicitly state when not to use it (e.g., vs. mnemonic_list), the search-focused language and examples imply the appropriate scenario.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get memory statistics.
Returns:
Total memory count by status
Weight distribution
Most used tags
Pinned/emotional counts
Useful for understanding your memory landscape.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the burden of behavioral disclosure. It uses 'Get' which implies a read-only operation and lists expected returns, but it does not explicitly state that it has no side effects, requires no special permissions, or any other behavioral traits such as performance considerations. For a straightforward stats tool this is adequate but not fully 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?
The description is highly concise: one opening line, a neat bullet list of return values, and a single closing sentence. Every element earns its place, and the most important information ('Get memory statistics') is 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 the tool's simplicity (zero parameters, no nested objects, output schema present) the description is nearly complete. It covers the core purpose and return categories. It does not explicitly address when to prefer it over similar tools or confirm read-only behavior, but those gaps are minor for this low-complexity 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?
The tool has zero parameters, so the baseline is 4. The schema already covers everything (empty object) and the description need not add parameter details. No additional semantics are required or provided, but none are needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Get memory statistics' with a specific verb and resource, and the bullet list of return values (total count, weight distribution, tags, pinned/emotional counts) clearly distinguishes it from sibling CRUD/list/search tools. It is unambiguous and 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?
The phrase 'Useful for understanding your memory landscape' provides a clear context for when to use this tool, implying it is for high-level aggregate insights rather than individual record retrieval. However, it does not explicitly name alternatives or state when not to use it, which would warrant a 5.
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.
Only specified fields will be updated. Tags and triggers are replaced entirely if provided (not merged).
Example: - id: "abc-123" - weight: 0.95 # Increase importance - tags: ["high-priority"] # Replace existing tags
| Name | Required | Description | Default |
|---|---|---|---|
| params | Yes | Input for updating an existing memory. |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden for disclosing behavioral traits. It clearly states partial-update behavior and the destructive replacement of tags and triggers, which is critical for a mutating operation. It does not cover potential error conditions or idempotency, but the key traits are well-explained.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: a one-sentence purpose, a key behavioral note, and a compact example. Every sentence contributes meaning, with no redundant filler or overly verbose explanations.
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 presence of an output schema and a detailed input schema, the description adequately covers essential semantics like partial updates and replacement behavior. It does not explain return values, which is acceptable since an output schema exists. It lacks mention of prerequisites like existence of the memory, but overall it is sufficiently complete for a tool of this complexity.
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 already provides descriptions for all parameters, so the baseline is 3. The description adds value with a concrete example showing how to use weight and tags, and clarifies that unspecified fields remain unchanged, which is not obvious from the schema alone. This enrichment pushes it above 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's function: 'Update an existing memory.' It uses a specific verb (update) and resource (memory), and distinguishes it from sibling tools like mnemonic_create, mnemonic_get, and mnemonic_delete. The additional note 'Only specified fields will be updated' further clarifies the scope.
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 by stating 'Update an existing memory,' but it does not explicitly mention when to use this tool versus alternatives like mnemonic_create or mnemonic_get. It provides no exclusions or comparisons to sibling tools, so usage guidance 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.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.1.0mnemonic_createmnemonic_deletemnemonic_exportmnemonic_getmnemonic_importmnemonic_listmnemonic_pinmnemonic_searchmnemonic_statsmnemonic_updateEach tool targets a distinct operation: create, get, update, delete, search, list, pin, export, import, stats. Search and list are differentiated by intent (query-based vs. browsing), and all other actions are unambiguous.
All tools follow a consistent 'mnemonic_<verb>' pattern (e.g., mnemonic_create, mnemonic_get, mnemonic_update). The verb is clear and the naming is uniform.
10 tools is well-scoped for a memory management server. It covers all core CRUD operations plus search, organization (pin), data portability (export/import), and analytics (stats) without bloat.
The tool set provides complete lifecycle coverage for memories: create, read, update, delete, search, list, plus additional features like pinning, export/import, and statistics. No significant gaps are apparent.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Persistent memory for AI agents across Claude, ChatGPT and any MCP client.
Persistent AI memory shared across Claude, ChatGPT, coding agents, and compatible MCP clients.
Private persistent memory for Claude, ChatGPT & Gemini via MCP - semantic search, zero-code setup.
Persistent memory for AI agents: add, search, update, and delete long-term memories.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/bacharyehya/claude-memory-architecture'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
