mcp-super-memory

by donggyun112

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.4.4
Disambiguation5/5
Each tool has a distinct role in the memory lifecycle: creation (remember, remember_batch), retrieval (recall, list_memories, get_conversation), update (correct), deletion (forget), exploration (related), and maintenance (cleanup_expired, memory_stats). The overlap between remember and remember_batch is clearly explained as single vs batch.
Naming Consistency5/5
Names are consistently lowercase snake_case with clear verbs (recall, remember, correct, forget) and noun-prefixed operations (get_conversation, list_memories, memory_stats). No mixed conventions like camelCase or inconsistent verb styles.
Tool Count5/5
Ten tools provide comprehensive coverage without redundancy. Each tool earns its place, covering CRUD, batch operations, exploration, and system maintenance.
Completeness4/5
The set covers the full memory lifecycle: save, search, list, update, delete, link exploration, batch save, and maintenance. A minor gap is the lack of a direct 'get memory by ID' tool, though recall and related can surface memory content.
Average 4.2/5 across 10 of 10 tools scored. Lowest: 3.6/5.
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

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states that it loads raw turns, offering no information about side effects, error behavior, data volume, or whether the operation is read-only. This is minimal and leaves important behavioral aspects undisclosed.
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, front-loaded with the primary purpose, and contains no filler. Every sentence contributes to understanding the tool's purpose and usage context, making it highly concise and well-structured.
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 description gives a clear purpose and usage context, and the output schema covers return values. However, it does not fully explain the parameters, especially 'turn', and lacks details about potential edge cases. For a simple retrieval tool this is adequate but has clear gaps in parameter semantics.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It hints at 'session_id' via 'past session' but does not explain the 'turn' parameter at all. The description adds only marginal meaning beyond the schema, leaving the optional 'turn' parameter ambiguous.
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 action ('Load') and the resource ('raw conversation turns from a past session'), which is specific and distinct from sibling tools like recall or remember. It also differentiates itself by referencing 'raw' context, implying it provides more detail than recalled memories.
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 explicit guidance on when to use the tool: 'Use when a recalled memory lacks detail and you need the original context.' This implies when the recall tool is insufficient and gives clear context, though it does not explicitly name the alternative or state exclusion conditions.
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. It clearly implies a read-only operation ('get counts') and discloses no side effects, but it does not elaborate on what exactly is included (e.g., expired memories, links across all namespaces) or the return format beyond what the output schema likely provides. This is adequate for a simple stats tool but not rich.
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 a single, concise sentence that immediately states the tool's purpose. Every word earns its place, and the structure is ideal for quick comprehension.
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 with no parameters and an output schema that presumably documents return values. The description sufficiently communicates the scope ('counts of keys, memories, and links') without needing further detail. It could mention that it's a read-only stats endpoint, but the verb 'get' already implies this.
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?
There are zero parameters, so the baseline is 4. The description adds no parameter-level detail because none is needed. The schema-driven coverage is effectively perfect, and the description's mention of keys, memories, and links aligns with the tool's purpose.
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: retrieving counts of keys, memories, and links. This is a specific verb+resource combination that distinguishes it from sibling tools like recall or list_memories, which deal with individual items rather than aggregate statistics.
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 about when to use this tool versus alternatives. The description does not mention that it should be used for aggregate overviews instead of listing memories, nor does it mention any exclusions or trade-offs. The context is implied but not stated.
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 responsibility. It discloses that the tool saves memories and returns a list of saved IDs. It also outlines the item structure (content, keys, etc.), which is useful. However, it omits important behavioral aspects such as partial failure handling, whether the operation is atomic, or any validation or permission requirements.
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 long, front-loads the main purpose, and includes no redundant information. Every sentence adds value: the first explains the core action, the second details the item schema and return value.
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 an output schema present, the return values are likely covered, so the description's mention of returning saved IDs is a bonus. The tool is a batch operation with potential complexity (e.g., partial failures, limits), but the description does not address these. It is adequate for basic usage but not fully 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 input schema provides no descriptions and has a coverage of 0%, so the description must compensate. It lists the expected fields for each item (content, keys, key_types?, namespace?, ttl_seconds?, related_to?), which adds meaning beyond the empty schema. However, it does not explain what each field means, which are required, or any constraints, leaving gaps for the agent.
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: 'Save multiple memories in one call.' It identifies the resource (memories) and the batch nature. It also distinguishes itself from the sibling tool remember() by stating it is 'More efficient than multiple remember() calls,' 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 Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly names the alternative tool (remember()) and positions remember_batch as the more efficient choice for batch saving. This gives the agent clear guidance on when to prefer this tool over the singular variant.
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 takes full responsibility for behavioral disclosure. It reveals a key non-obvious behavior: 'Old version is preserved but weakened — never lost,' which is critical for understanding side effects. It also notes that 'omit keys to keep the same search terms,' adding practical behavior detail, though it doesn't cover every edge case.
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 three sentences, front-loaded with the primary purpose. Every sentence earns its place: purpose, usage, and behavioral notes. There is no fluff or redundant information.
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?
Despite having 5 parameters and no annotations, the description covers purpose, usage, key behavior, and some param semantics. Because an output schema exists, the description needn't explain return values. The only notable gap is the 'key_types' parameter, but overall it provides enough context for effective tool 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?
The schema description coverage is 0%, yet the description adds meaning for some parameters: it explains 'keys' ('Omit keys to keep the same search terms') and 'related_to' ('links the updated memory to other memory IDs'). 'memory_id' and 'content' are implicit from the tool's purpose, but 'key_types' is left completely unexplained, leaving a coverage gap.
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+resource: 'Update outdated information,' clearly stating the tool's purpose. It distinguishes itself from siblings like 'remember' (for new info) and 'forget' (for deletion) by focusing on corrections. Examples like 'moved cities, changed job' further clarify its scope.
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: 'Use when user corrects you or info changes,' providing clear context for invocation. However, it doesn't explicitly mention when not to use it or name alternative tools, so it earns a 4 rather than a 5.
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 present, so the description carries the transparency burden. It does disclose important behaviors like ttl_seconds expiry, permanent when None, and related_to for graph traversal. Yet it doesn't mention potential side effects like overwriting existing memories, permissions, or persistence guarantees, leaving room for ambiguity.
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 remarkably concise: four sentences cover the main purpose and all key parameters without unnecessary detail. The first sentence frontloads the action, and the subsequent parameter explanations are telegraphic but highly informative.
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 is largely complete for a write operation: it explains key selection, namespaces, TTL, and relations, and the output schema covers return values. The main gaps are key_types semantics and any guidance about using remember_batch for bulk writes, which would have made it fully complete.
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 description adds significant meaning for keys (search terms, 3-6 diverse), namespace (project/context), ttl_seconds (with example and permanent default), and related_to (graph traversal). However, key_types is not explained at all, and schema coverage is 0%, so the description only partially compensates for the missing schema descriptions.
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 'Save important information to memory', clearly stating the action and resource. The verb 'save' distinguishes it from retrieval, deletion, and batch siblings, and the parameter explanations reinforce its write-purpose.
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 practical guidance on key selection ('think what would I search to find this later?'), namespace usage with examples, and TTL vs permanent storage, which implies when to set expiry. However, it doesn't explicitly mention when to use alternatives like recall or remember_batch, so it lacks explicit exclusions.
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 full burden. It discloses the permanent (irreversible) nature of the deletion, which is the key behavioral trait. The contrast with correct() also implies that forget does not preserve history. However, it does not mention authorization requirements or potential side effects, which would strengthen transparency.
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, each earning its place. The first states the core purpose concisely, and the second provides essential usage guidance and an alternative. No filler or redundant information.
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 delete operation with one parameter and an output schema, the description covers the key aspects: what it does, when to use it, and the alternative. It lacks explicit error handling or idempotency details, but these are less critical given the simplicity and the presence of an output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has no parameter descriptions (0% coverage). The description does not explain 'memory_id', its format, or how to obtain it. While the name is fairly self-explanatory, the description adds no semantic meaning beyond the schema, and with low coverage it fails to compensate.
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.' It distinguishes itself from the sibling tool 'correct' by pointing out that correct preserves history, 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 Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use the tool ('Only use for completely wrong information') and when not to use it, directing users to an alternative ('For outdated info, use correct() instead — it preserves history'). This provides clear guidance relative to sibling tools.
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 full burden and discloses a key behavior: 'Expired memories are excluded.' It implies that omitting namespace lists all memories, but doesn't mention pagination or authentication, leaving some gaps.
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, each earning its place: the action, the parameter behavior, and the alternative guidance. Front-loaded and free of redundant 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 one-param tool with an output schema, the description covers purpose, param semantics, an exclusion behavior, and an alternative. It could mention ordering or pagination, but the given detail is adequate for this tool's complexity.
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 has no descriptions for the namespace parameter, so the description's statement that it 'filters by project/context' adds crucial meaning. However, it doesn't explain the default behavior when namespace is null, so compensation is partial.
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 stored memories,' which is a specific verb+resource statement. It also distinguishes from siblings by noting 'Prefer recall() for normal retrieval,' making it clear this is for bulk listing rather than targeted retrieval.
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 provides an alternative: 'Prefer recall() for normal retrieval,' which tells the agent when not to use this tool. It also clarifies the namespace parameter usage, giving context for project/context filtering.
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?
The description discloses the destructive action ('Delete all memories past their ttl') and the return behavior ('Returns count of deleted memories'). It also indicates intended frequency ('Call periodically'). No annotations are present, but the key behaviors are disclosed. It doesn't discuss irreversibility, but deletion semantics are implied.
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 three short sentences, each with a distinct purpose: action, return value, and usage recommendation. No wasted 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?
With no parameters and an output schema present, the description covers the core operation, return, and usage cadence. It's complete for a simple cleanup 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 schema coverage is moot. Per the rubric, 0 params earns a baseline of 4.
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 ('Delete'), identifies the resource ('memories'), and specifies the scope ('past their ttl'), clearly distinguishing this from sibling tools like 'forget' or 'list_memories'.
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 says 'Call periodically to keep memory clean,' providing a clear usage context. It doesn't mention alternatives or exclusions, but the periodic maintenance context is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It reveals important behaviors: memory ranking by relevance, hop=1 vs hop=2, and that 'Memories get stronger each time they're recalled.' This gives the agent a clear picture of side effects and retrieval semantics beyond the schema.
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 a single dense paragraph but every sentence contributes value—the imperative call order, the core purpose, parameter nuances, output mechanics, and memory strengthening effect. It is front-loaded with the most critical usage instruction.
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 has four parameters and no annotations, but the description covers the key concepts: namespace, expansion, hop levels, and relevance ranking. An output schema exists, so return value details are not needed. Minor gaps include lack of mention of empty results or error behavior, but overall it is well-rounded.
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 has 0% description coverage, so the description must compensate. It explains namespace ('filters to a specific project/context'), expand ('returns up to 2x results'), and implies query semantics through 'search by concept.' top_k is not explicitly explained, but ranking by relevance with a default value makes it self-explanatory.
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: 'Search long-term memory by concept.' It explicitly instructs to call it first before every response, distinguishing it from sibling tools like remember or list_memories. The namespace and expand parameters are also described with specific behavior.
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 strong when-to-use guidance: 'CALL THIS FIRST before every first response' and suggests expand=True 'when initial results feel insufficient.' However, it does not explicitly mention when not to use it or name alternatives like list_memories or related, so it falls short of full alternative differentiation.
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 behavioral disclosure burden. It reveals the connection logic ('shared keys OR explicit links (both directions)') and that results are returned. It does not mention error cases or edge behaviors, but for a simple query tool this is adequate transparency, though not exhaustive, so a 4 is appropriate.
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, front-loaded with the primary action and immediately followed by usage context. Every sentence contributes value: the first defines the operation, the second explains the connection criteria and provides a usage workflow. No redundant wording.
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, no annotations, and an output schema that describes return values), the description is complete. It covers what the tool does, how to use it, and what to expect in terms of results. No critical missing information 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.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one parameter (memory_id) with 0% schema description coverage. The description compensates by referencing 'a specific memory' and the pattern 'pick ID', which clearly indicates the parameter identifies the starting memory. This adds semantic context beyond the raw schema field title, though it could be more explicit about the parameter name.
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: 'Explore connections from a specific memory.' This is a specific verb+resource pair that distinguishes it from siblings like recall (which retrieves a single memory) and list_memories (which lists all memories). The mention of returning connected memories by shared keys or explicit links further differentiates its role.
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?
Provides explicit usage guidance: 'Use after recall() to drill down: recall → pick ID → related → pick ID → related → ...' This tells the agent exactly when to use this tool (after recall) and how to chain it, effectively distinguishing it from alternatives.
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:

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

Score Badge

Copy to your README.md:

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

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/donggyun112/mcp-super-memory'

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