mnemonic-mcp

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation3/5
Most tools target distinct actions, but save_memory, auto_save, and save_to_section overlap in purpose, and read_memory/search_memory/list_sections have fuzzy boundaries without clear parameter detail. Descriptions reduce but do not eliminate confusion.
Naming Consistency4/5
The dominant pattern is verb_noun: read_memory, save_memory, update_memory, delete_memory, search_memory, list_sections. auto_save breaks the pattern slightly, and save_to_section/replace_section use prepositions, but the overall naming style is recognizable and consistent enough.
Tool Count5/5
Ten tools is a reasonable size for a memory management server. Each tool covers a distinct facet of reading, writing, organizing, searching, or maintaining persistent memory without feeling padded.
Completeness4/5
The memory domain is well covered with CRUD operations, search, section management, and maintenance. Minor gaps include no explicit 'list all memory at once' tool and no dedicated 'delete section' operation, but these can be worked around.
Average 3.8/5 across 10 of 10 tools scored. Lowest: 2.9/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 8 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

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility for behavioral disclosure. It communicates exact-match behavior but does not state what happens if no match is found, whether all occurrences are replaced, whether replacing is reversible, or that omitting replace deletes the memory.
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?
Two short sentences with no filler. The core action is front-loaded and the key matching instruction is included without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is a mutation with no annotations, no output schema, and several overlapping sibling tools. The description covers the basic action but omits important decision context such as when to prefer this over related tools and how edge cases like missing finds or empty replacements behave.
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 description coverage is 100%, so the schema already documents both parameters adequately. The description's 'exact text' phrasing adds mild emphasis on matching but does not materially extend what the schema already states.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the operation as 'Find and replace existing memory' and adds the key requirement to pass exact text. It is distinguishable from delete_memory and save_memory, though it does not explicitly differentiate from the similarly named replace_section sibling.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use update_memory versus save_memory, delete_memory, or replace_section. The only instruction is 'Pass exact text to find,' which is more of a usage detail than a decision rule.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden for disclosing behavior, but it only states the destructive intent and repeats the parameter hint. It does not clarify whether deletion is permanent, what happens if multiple entries match, or whether a failure to find the fragment results in an error or no-op.
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 short sentences with no filler, front-loading the operation and then the key usage requirement. Every word contributes to the core message, making it appropriately concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one required parameter and a fully documented schema, so minimal description is acceptable. However, since no annotations or output schema exist, the description omits useful context about side effects, matching behavior, and how to locate the fragment, leaving some room for agent uncertainty.
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%, so the baseline is 3. The description adds the word 'unique' beyond the schema's 'distinctive part,' slightly strengthening the matching requirement, but it does not provide substantial new meaning beyond what the schema already offers.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb and resource ('Delete something from memory') and the unique-fragment requirement distinguishes it from sibling operations like read, save, or update. It is somewhat vague about what 'memory' contains, but the action and target are unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance is given for when to use delete_memory versus alternatives such as update_memory or tidy_memory. The instruction to provide a unique fragment is a how-to hint rather than a when-to-use explanation, leaving the agent to infer the appropriate scenario.
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 behavioral burden. It does disclose one useful side effect: 'Creates it if needed.' However, it does not clarify whether content is appended, overwritten, or how existing content in the section is affected, leaving meaningful ambiguity for a write operation.
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 short sentences with no filler. The core action is front-loaded, and the auto-create behavior is stated immediately after, making it easy to scan and understand.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter tool, the description covers the essential action and an important edge case (auto-creation). However, because there is no output schema and no annotations, the absence of append-versus-replace semantics and return-value behavior leaves the description merely adequate rather than 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?
Schema description coverage is 100%, so the parameters are already documented. The description adds only light context by calling the target a 'categorized section' and the content 'info,' but it does not enrich parameter semantics beyond the schema. This matches the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb plus resource: 'Add info to a categorized section' and adds the auto-create behavior. It clearly distinguishes itself from a generic save operation, but does not explicitly differentiate itself from siblings like save_memory or update_memory.
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 usage context is implied: use this when adding info to a section, creating it if it doesn't exist. However, the description provides no explicit exclusions or mention of alternatives, so an agent must infer when to choose this over save_memory, update_memory, or replace_section.
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 behavior disclosure. It adds one useful behavioral detail—automatic categorization into an appropriate section—but does not disclose potential side effects, duplicate handling, or failure behavior. It does not contradict any annotations.
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 short sentences with no filler. The primary action and trigger are front-loaded, and the second sentence adds a distinct behavioral trait, so 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?
For a simple one-parameter tool with no output schema, the description covers the core purpose, the trigger condition, and a key behavioral aspect. It could briefly mention what the agent should expect after saving, but that is a minor omission for such a straightforward operation.
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?
There is only one parameter, 'fact', and the schema already describes it fully at 100% coverage. The description references the fact but adds no meaning beyond what the schema provides, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the action ('save a fact to memory') and adds a specific scoping condition ('when asked directly'). It distinguishes the tool from auto_save through the explicit vs automatic distinction, though it doesn't name sibling tools or fully delineate the boundary with save_to_section.
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 phrase 'when asked directly' provides an explicit trigger condition for using the tool. However, it does not say when not to use this tool or mention alternatives such as auto_save or save_to_section, leaving the agent to infer those boundaries.
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 accurately describes the operation as a read with no implied mutation, but it does not describe behavior for missing sections, full-memory reads, or potential size limits. For a simple read tool this is adequate but minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two crisp sentences, front-loading the primary action and then giving a useful pointer to list_sections. There is no wasted wording.
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?
For a simple tool with one optional parameter and no output schema, the description gives enough context for an agent to use it correctly, including a fallback workflow. It could briefly mention that omitting 'section' reads all memory, but that is already covered by the parameter schema.
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 description coverage is 100%, so the schema already documents the optional 'section' parameter and the 'Omit for full memory' behavior. The description adds workflow context but no additional parameter-level meaning beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the action ('Read') and the resource ('persistent memory'), making the core purpose obvious. It does not explicitly differentiate from search_memory, but the direct read vs. search distinction is reasonably implicit.
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 explicitly tells the agent to use list_sections first if unsure where information is stored, then read the section directly. This is clear practical guidance for at least one important alternative, though it does not mention other read-like siblings such as search_memory.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility for disclosing behavior. It explains that entries are organized into sections, but does not clarify whether this moves, edits, merges, or removes content, whether it is reversible, or whether it modifies the file destructively.
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?
Two concise sentences: one defines the action and one gives the usage trigger. No filler, and the most important information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no parameters, the invocation is simple, and the description covers what and when. However, with no output schema and no annotations, it omits what the caller should expect afterward — e.g., whether a summary is returned or whether existing content is rewritten — leaving some uncertainty for an AI agent.
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 effectively 100%. The description adds context about the target content of the operation, which is appropriate even though no parameter-level documentation is 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 clearly identifies a specific verb and resource: organizing standalone dated entries into sections. This distinguishes it from sibling tools like save_memory, search_memory, or delete_memory, none of which perform reorganization.
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?
It explicitly states when to use the tool: when memory.md has many orphaned entries that could be categorized. It does not explicitly mention when not to use it or name alternatives, but the trigger condition is clear and actionable.
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 the burden of disclosing behavior. 'Replace ALL content' clearly communicates that this is a destructive overwrite operation. It does not explain behavior for nonexistent sections or return values, but the destructive nature is explicitly 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?
A single clear sentence, 'Replace ALL content in a named section,' conveys the core behavior with no wasted words. The destructive scope is front-loaded with 'ALL.'
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 tool is simple: two fully described parameters and a clear action. The description plus schema sufficiently instructs an agent on what to provide. It could be improved by noting what happens if the section does not exist or whether the operation can be undone, but these are not blockers for correct invocation.
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 description coverage is 100%, so both parameters are already documented. The description adds little beyond the schema, merely restating 'named section' and 'ALL content' without additional nuance.
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 uses a specific verb ('Replace') and a clear resource ('ALL content in a named section'). The uppercase 'ALL' clearly communicates full overwrite, distinguishing it from sibling tools like save_to_section or update_memory that suggest partial or different behavior.
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 when to use the tool: when the entire content of a section should be replaced. However, it does not explicitly mention alternatives or conditions, such as 'use save_to_section to append' or 'use update_memory for partial edits.'
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 the burden; it openly discloses keyword matching and the all-entry scope, so the agent understands this is a lookup operation, though it stops short of detailing result format or matching nuances.
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?
Two tight, front-loaded sentences with no redundancy; every word contributes.
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?
Adequate for a single-parameter search tool: behavior is stated, the query parameter is fully documented, and the scope is clear. Missing return-shape detail and explicit usage boundaries keep it just below top completeness.
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 fully documents query as 'Keywords to search for' (100% coverage), and the description adds the keyword-matching behavior but no extra parameter details, so baseline 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?
States a specific verb (search), resource (memory), and method (keyword matching across all entries), which distinguishes it from read_memory and other memory-management siblings.
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?
Implies use when locating specific info by keyword, but doesn't explicitly name alternatives or exclusion conditions; an agent must infer 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of disclosing behavior. It does so by specifying that the save should be silent, proactive, and not announced unless asked. This is meaningful behavioral context beyond the generic 'save' action, though it does not detail storage semantics such as deduplication or overwrite behavior.
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 concise sentences with no redundant phrasing. The core behavior and trigger conditions are front-loaded, and the instruction about not announcing is placed exactly where it matters.
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?
For a simple one-parameter tool, the description provides sufficient guidance on when and how to invoke it. It gives trigger conditions, scope of content, and interaction guidance. It does not explain what response to expect or how it compares to closely related memory siblings, but the tool's simplicity limits the impact of that gap.
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 coverage is 100% and describes 'fact' as 'The fact to remember.' The description adds meaning by specifying what counts as worth remembering: preferences, facts, corrections, and project state, and clarifies that the fact should be about the user and long-term.
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 verb 'save' and the resource: information about the user worth remembering long-term. It also differentiates this tool from siblings by emphasizing 'silently' and 'proactively during conversations,' which distinguishes it from a manual save_memory operation.
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 gives explicit trigger conditions: call when the user reveals preferences, facts, corrections, or project state during conversations. It also says not to announce the action unless asked, but it does not explicitly state when to prefer save_memory or update_memory instead, so it lacks full alternative discrimination.
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 the transparency burden. It clearly states that the tool enumerates all named sections, which is self-evidently a read-only operation. It does not describe whether empty or unnamed sections are included, but the risk of misunderstanding is low given the simplicity of the tool.
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?
Two short sentences, front-loaded with the core action, and every word earns its place. The usage guidance is packed into the second sentence without 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?
The tool is simple, has no parameters, and no output schema. The description explains what the tool does and when to use it, which covers the essential context. A minor gap is that it doesn't describe the return format, but for a list-all-sections tool the return is reasonably inferable.
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 schema description coverage is 100%, so the schema already documents everything. Per the rubric, a zero-parameter tool earns a baseline of 4; there is nothing else the description needs to add.
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 uses a specific verb ('List') and resource ('all named sections in memory'), clearly distinguishing this from siblings that read, write, or search memory content. The title reinforces the purpose without being vague.
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 gives an explicit use case: 'Use this when you're unsure where info might be stored.' It does not explicitly name alternatives like search_memory or read_memory, but the stated context is sufficient for an agent to recognize when this tool is the right starting point.
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:

[![mnemonic-mcp MCP server](https://glama.ai/mcp/servers/c1hucktay4lors/mnemonic-mcp/badges/card.svg)](https://glama.ai/mcp/servers/c1hucktay4lors/mnemonic-mcp)

Score Badge

Copy to your README.md:

[![mnemonic-mcp MCP server](https://glama.ai/mcp/servers/c1hucktay4lors/mnemonic-mcp/badges/score.svg)](https://glama.ai/mcp/servers/c1hucktay4lors/mnemonic-mcp)

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/c1hucktay4lors/mnemonic-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server