Mnemonic

by bacharyehya

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.0
Disambiguation5/5
Each 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.
Naming Consistency5/5
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.
Tool Count5/5
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.
Completeness5/5
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.
Average 4.3/5 across 10 of 10 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![claude-memory-architecture MCP server](https://glama.ai/mcp/servers/bacharyehya/claude-memory-architecture/badges/card.svg)](https://glama.ai/mcp/servers/bacharyehya/claude-memory-architecture)

Score Badge

Copy to your README.md:

[![claude-memory-architecture MCP server](https://glama.ai/mcp/servers/bacharyehya/claude-memory-architecture/badges/score.svg)](https://glama.ai/mcp/servers/bacharyehya/claude-memory-architecture)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

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