Mnemex

Overview Schema Related Servers Score Discussions

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation5/5
Each tool has a clearly distinct purpose with no significant overlap. For example, cluster_memories groups similar memories, consolidate_memories merges them, create_relation links memories, and touch_memory reinforces a single memory. The descriptions clearly differentiate each tool's function, making misselection unlikely.
Naming Consistency4/5
The naming follows a consistent verb_noun pattern throughout (e.g., cluster_memories, create_relation, promote_memory), with all tools using snake_case. The only minor deviation is 'gc' (garbage collection), which is an acronym rather than a descriptive verb_noun, but it's a common term in this context and doesn't break overall consistency.
Tool Count5/5
With 11 tools, the count is well-scoped for a memory management system. Each tool serves a specific purpose in the lifecycle of memories (e.g., save, search, reinforce, promote, garbage collect), and none feel redundant or unnecessary for the domain.
Completeness4/5
The toolset provides comprehensive coverage for memory management, including creation (save_memory), retrieval (open_memories, search_memory, search_unified), reinforcement (touch_memory), organization (cluster_memories, create_relation), promotion (promote_memory), and cleanup (gc). The only minor gap is that consolidate_memories is noted as 'NOT YET IMPLEMENTED', but this is explicitly documented, and other tools cover related functionality.
Average 3.7/5 across 11 of 11 tools scored. Lowest: 2.9/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
- Last stable release on November 19, 2025
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is failing
This repository is licensed under AGPL 3.0.
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 full burden for behavioral disclosure. While it mentions optional filters and scoring, it doesn't describe important behavioral aspects like whether this is a read-only operation, what permissions are required, how results are sorted, or what happens with null parameters. The mention of 'decay score threshold' hints at some scoring mechanism but doesn't explain it.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections for Args and Returns. It's appropriately sized for a 6-parameter tool, though the opening sentence could be more specific about what type of search this performs (semantic vs keyword).
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?
Given 6 parameters with no schema descriptions and no annotations, the description provides basic parameter semantics and return format. However, for a search tool with complex filtering options and sibling alternatives, it lacks sufficient context about behavioral characteristics, performance considerations, and differentiation from other search tools on the server.
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?
With 0% schema description coverage, the description provides basic semantic information for all 6 parameters in the Args section, explaining what each parameter controls. However, it doesn't provide deeper context about parameter interactions, default behaviors, or practical examples of how to use them effectively together.
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 states the tool searches for memories with optional filters and scoring, providing a specific verb (search) and resource (memories). However, it doesn't differentiate from sibling tools like 'search_unified' or 'open_memories', which appear to be related search operations.
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?
The description provides no guidance on when to use this tool versus alternatives like 'search_unified' or 'open_memories'. It mentions optional filters but gives no context about appropriate use cases or when other tools might be more suitable.
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 provided, the description carries the full burden. It discloses key behavioral traits: the tool is not yet implemented (returns placeholder), uses LLM-driven merging, and resolves conflicts. However, it doesn't cover important aspects like permissions needed, rate limits, or error handling, leaving gaps for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and appropriately sized. It front-loads the purpose, includes implementation status, and lists parameters clearly. Every sentence adds value, though the placeholder note could be slightly more 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?
Given the tool has an output schema (returns are documented elsewhere) and 2 parameters with 0% schema coverage, the description is moderately complete. It covers purpose, status, and parameters but lacks details on behavioral aspects like permissions or error handling, which are important for a mutation tool with no annotations.
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 0%, so the description must compensate. It explains 'cluster_id' as 'Cluster ID to consolidate' and 'mode' with options 'dry_run' or 'apply,' adding meaningful context beyond the bare schema. However, it doesn't detail what a 'Cluster ID' represents or the implications of each mode, leaving some ambiguity.
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 states the tool's purpose: 'Consolidate similar memories using LLM-driven merging.' It specifies the verb (consolidate), resource (memories), and method (LLM-driven merging). However, it doesn't explicitly differentiate from sibling tools like 'cluster_memories' or 'promote_memory,' which prevents a perfect score.
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?
The description provides minimal usage guidance. It mentions the tool is 'NOT YET IMPLEMENTED' and currently returns a placeholder, which is useful context. However, it lacks explicit guidance on when to use this tool versus alternatives like 'cluster_memories' or 'promote_memory,' and doesn't specify prerequisites or exclusions.
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 burden. It mentions 'unified ranking' but doesn't explain what this means operationally, how results are combined, or any behavioral traits like performance characteristics, error conditions, or limitations. The description is minimal beyond basic functionality.
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 efficiently structured with a clear purpose statement followed by organized parameter and return sections. Every sentence earns its place, and the information is front-loaded with the core functionality stated first.
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?
Given the tool's complexity (7 parameters, no annotations) but with an output schema present, the description covers parameters adequately but lacks behavioral context. It doesn't explain how STM and LTM differ, what 'unified ranking' entails, or provide usage examples. The output schema handles return values, but more operational guidance would be helpful.
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?
With 0% schema description coverage, the description compensates well by listing all 7 parameters with brief explanations. It clarifies what each parameter controls (e.g., 'Weight multiplier for STM results', 'Only include STM memories from last N days'), adding meaningful context beyond the schema's type information.
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 states the tool searches across STM and LTM with unified ranking, providing a specific verb ('search') and resources ('STM and LTM'). However, it doesn't explicitly differentiate from sibling tools like 'search_memory' or 'open_memories', which appear related to memory operations.
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 provided on when to use this tool versus alternatives like 'search_memory' or 'open_memories'. The description only states what the tool does, not when it's appropriate or what distinguishes it from similar tools in the sibling list.
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. It discloses that the tool retrieves memories and returns detailed information with optional relations and scores, which covers basic behavior. However, it lacks details on potential side effects (e.g., whether this is a read-only operation), error handling, or performance aspects like rate limits. The description doesn't contradict annotations, but it's not comprehensive for a tool with no annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded, starting with the core purpose. The sentences are efficient, with no wasted words, and it includes a structured 'Args' and 'Returns' section for clarity. However, the reference to 'open_nodes functionality' could be considered slightly extraneous if not widely understood.
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 has an output schema (which handles return values), no annotations, and 3 parameters with 0% schema coverage, the description does a good job of covering the basics. It explains the purpose, parameters, and return intent, making it largely complete for a retrieval tool. Minor gaps include lack of sibling differentiation and deeper behavioral context.
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 beyond the input schema, which has 0% description coverage. It explains that 'memory_ids' can be a single ID or list, 'include_relations' adds relations from/to memories, and 'include_scores' includes decay scores and age. This compensates well for the schema's lack of descriptions, though it doesn't fully detail all parameter nuances (e.g., format of IDs).
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 states the tool's purpose as 'Retrieve specific memories by their IDs' and 'Returns detailed information about the requested memories including their relations to other memories.' This specifies the verb (retrieve) and resource (memories) with scope (by IDs, with relations). However, it doesn't explicitly differentiate from sibling tools like 'read_graph' or 'search_memory' which might also retrieve memory information.
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?
The description provides minimal usage guidance. It mentions 'Similar to the reference MCP memory server's open_nodes functionality,' which offers some context but is vague. There's no explicit guidance on when to use this tool versus alternatives like 'search_memory' or 'read_graph,' nor any mention of prerequisites or exclusions for usage.
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 provided, the description carries the full burden. It discloses that promotion makes memories 'permanent' and mentions a 'dry_run' option for previewing, which adds behavioral context. However, it doesn't cover critical aspects like permissions needed, rate limits, error handling, or what 'permanent' entails operationally (e.g., irreversible changes).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a purpose statement, elaboration, and clear sections for Args and Returns. It's appropriately sized with no redundant sentences, though the elaboration could be slightly more concise. Every sentence adds value, and it's front-loaded with the core purpose.
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 5 parameters with 0% schema coverage and no annotations, the description does a good job explaining parameter semantics and the tool's purpose. The presence of an output schema means the description doesn't need to detail return values, which it correctly omits. However, for a tool that makes memories 'permanent', more behavioral context (e.g., side effects, prerequisites) would enhance completeness.
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?
Schema description coverage is 0%, so the description must compensate. It provides meaningful semantics for all 5 parameters: 'memory_id' for specific promotion, 'auto_detect' for automatic candidate detection, 'dry_run' for previewing, 'target' for destination (default 'obsidian'), and 'force' to override criteria. This adds substantial value beyond the bare schema, though it doesn't detail parameter interactions (e.g., 'memory_id' vs 'auto_detect').
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 states the tool's purpose: 'Promote high-value memories to long-term storage' with specific criteria (high scores or frequent usage) and destination (Obsidian vault or other storage). It distinguishes from siblings like 'save_memory' or 'consolidate_memories' by focusing on promotion to permanent storage, though it doesn't explicitly contrast with them.
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 when memories have high scores or frequent usage, but doesn't explicitly state when to use this tool versus alternatives like 'save_memory' or 'consolidate_memories'. It mentions 'auto_detect' for automatic candidate detection, providing some contextual guidance, but lacks clear exclusions or prerequisites.
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 burden. It states the tool creates a relation and returns an ID and confirmation, which covers basic behavior. However, it lacks details on permissions needed, whether the operation is idempotent, error conditions (e.g., invalid memory IDs), or side effects (e.g., updating memory graphs). For a mutation tool with zero annotation coverage, this is insufficient.
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 efficiently structured: a concise purpose statement, a brief elaboration with examples, and a well-organized Args/Returns section. Every sentence adds value without redundancy, and information is front-loaded with the core purpose stated first.
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?
Given the tool's complexity (mutation with 5 parameters) and the presence of an output schema (which covers return values), the description is partially complete. It explains parameters well but lacks behavioral context (e.g., error handling, idempotency) and usage guidelines. With no annotations, it should do more to guide safe and effective use.
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?
Schema description coverage is 0%, so the description must compensate. It provides clear semantic explanations for all 5 parameters (e.g., 'Source memory ID', 'Type of relation', 'Strength of the relation (0.0-1.0)'), adding meaningful context beyond the schema's titles. However, it does not elaborate on relation_type examples beyond the parenthetical list or metadata structure.
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 specific action ('Create an explicit relation') and resource ('between two memories'), with a parenthetical list of example relation types. It distinguishes this from sibling tools like 'cluster_memories' or 'read_graph' by focusing on explicit pairwise linking rather than grouping, analyzing, or retrieving existing relations.
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 when linking two specific memories with a typed relationship, but does not explicitly state when to use this tool versus alternatives like 'cluster_memories' (for grouping) or 'read_graph' (for viewing existing relations). No guidance on prerequisites, exclusions, or common scenarios is provided.
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 of behavioral disclosure. It effectively describes key behavioral traits: the memory is stored in 'short-term storage' with 'temporal decay,' may be 'forgotten if not used regularly,' and 'frequently accessed memories may be promoted to long-term storage automatically.' This provides important context about persistence, lifecycle, and automatic promotion that isn't obvious from the tool name alone.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized with three sentences followed by a structured parameter list. The first sentence states the core purpose, the next two explain behavioral context, and the Args section efficiently documents parameters. There's minimal waste, though the parameter explanations could be slightly more detailed without losing conciseness.
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 complexity (6 parameters, behavioral nuances) and the absence of annotations, the description does a reasonably complete job. It explains the tool's purpose, behavioral characteristics (decay, promotion), and documents all parameters. Since there's an output schema (mentioned in context signals), the description doesn't need to explain return values. The main gap is lack of explicit guidance on when to use versus sibling tools.
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 description includes an 'Args:' section that lists all 6 parameters with brief explanations, adding meaning beyond the input schema which has 0% description coverage. However, the explanations are minimal (e.g., 'Tags for categorization') and don't provide detailed semantics like format examples, constraints, or relationships between parameters. Since schema coverage is 0%, the description compensates somewhat but not fully.
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 states the action ('Save a new memory') and resource ('to short-term storage'), providing a specific verb+resource combination. It distinguishes this from sibling tools like 'promote_memory' or 'touch_memory' by focusing on initial creation rather than manipulation of existing memories. However, it doesn't explicitly contrast with 'create_relation' which might also create new data.
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 context through phrases like 'temporal decay applied' and 'forgotten if not used regularly,' suggesting this is for transient storage. However, it doesn't explicitly state when to use this tool versus alternatives like 'promote_memory' (for long-term storage) or 'cluster_memories' (for grouping). No explicit when-not-to-use guidance or named alternatives are provided.
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 provided, the description carries the full burden. It discloses that the tool reads data (implying non-destructive) and returns a complete graph, but lacks details on permissions, rate limits, or error handling. It adds some context about what's included (decay scores, statistics) but is incomplete for behavioral 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 well-structured and front-loaded with the core purpose, followed by parameter and return details. Every sentence adds value without redundancy, making it efficient and easy to parse for an agent.
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 moderate complexity (3 parameters, no annotations, but with an output schema), the description is fairly complete. It covers purpose, parameters, and return values, and the output schema reduces the need to explain returns in detail. However, it lacks usage guidelines and some behavioral context, slightly impacting completeness.
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 description coverage is 0%, so the description must compensate. It explains all three parameters: status filters memories by specific values, include_scores adds decay scores and age, and limit sets a maximum return count. This adds meaningful semantics beyond the bare schema, though it could elaborate on default behaviors or constraints.
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 'Read' and the resource 'entire knowledge graph of memories and relations', specifying it returns the complete graph structure including memories with decay scores, relations, and statistics. This distinguishes it from siblings like search_memory or cluster_memories by emphasizing comprehensive retrieval rather than filtering or processing.
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?
The description provides no guidance on when to use this tool versus alternatives. It does not mention scenarios where this is preferred over search_memory or open_memories, nor does it specify prerequisites or exclusions, leaving the agent to infer usage from the purpose alone.
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 of behavioral disclosure. It effectively describes the tool's effects ('resets temporal decay', 'increases resistance to being forgotten', 'optionally boost base strength') and the return value ('updated memory statistics including old and new scores'). It doesn't cover potential side effects, rate limits, or error conditions, but provides solid operational context.
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 well-structured and front-loaded with the core purpose in the first sentence. Each subsequent sentence adds value: explaining effects, documenting parameters, and describing returns. There's no wasted text, and it efficiently communicates essential information in four concise sentences.
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 has an output schema (which handles return values), no annotations, and moderate complexity with 2 parameters, the description is reasonably complete. It covers purpose, effects, parameters, and returns at a high level. However, it lacks details on error cases, side effects, or specific usage scenarios that would be helpful for a mutation 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 schema description coverage is 0%, so the description must compensate. It adds meaningful context for both parameters: 'memory_id' is explained as 'ID of the memory to reinforce', and 'boost_strength' as 'Whether to boost the base strength' with the optional nature clarified. This goes beyond the schema's basic type information, though it could provide more detail on what boosting entails.
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 with specific verbs ('reinforce', 'updating', 'resets', 'increases') and identifies the resource ('memory'). It distinguishes this from siblings like 'promote_memory' or 'save_memory' by focusing on temporal reinforcement rather than creation or promotion.
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 context through phrases like 'resets the temporal decay' and 'increases resistance to being forgotten', suggesting it's for maintaining memory relevance. However, it doesn't explicitly state when to use this tool versus alternatives like 'promote_memory' or 'consolidate_memories', nor does it mention prerequisites or 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 provided, the description carries the full burden. It discloses behavioral traits such as clustering based on semantic similarity (if embeddings enabled) and returning clusters or duplicate pairs with scores and suggested actions. However, it lacks details on permissions, rate limits, or side effects (e.g., whether clustering modifies 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 appropriately sized and front-loaded, starting with the core purpose, followed by implementation details, and ending with parameter and return explanations. Every sentence earns its place without redundancy, and the structure (purpose → behavior → args → returns) is logical and efficient.
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 moderate complexity (5 parameters, no annotations, but with output schema), the description is largely complete. It covers purpose, behavior, parameters, and return values. However, it lacks explicit guidance on when to choose clustering vs. duplicate finding, and the output schema existence means return details are not strictly needed, but some behavioral context (e.g., side effects) could be enhanced.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds significant meaning beyond the input schema, which has 0% description coverage. It explains all 5 parameters with clear semantics: 'strategy' as clustering strategy, 'threshold' for similarity linking, 'max_cluster_size' for cluster limits, 'find_duplicates' toggles between clustering and duplicate finding, and 'duplicate_threshold' for duplicate detection. This fully compensates for the schema's lack of 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 clearly states the tool's purpose with specific verbs ('cluster similar memories', 'find duplicates') and resources ('memories'), distinguishing it from siblings like 'consolidate_memories' (which likely acts on clusters) and 'search_memory' (which finds individual memories). It explicitly mentions two distinct use cases: clustering for consolidation and finding duplicates.
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 ('useful for identifying redundant memories'), but does not explicitly state when not to use it or name alternatives among siblings. It implies usage for consolidation or duplicate detection without specifying prerequisites or comparing to tools like 'consolidate_memories'.
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 provided, the description carries the full burden of behavioral disclosure. It explains that the tool 'Removes or archives memories' based on decay scores, which clarifies it's a destructive operation (though with safe options like dry_run and archive_instead). However, it doesn't mention potential side effects, rate limits, or authentication requirements, leaving some behavioral aspects unclear.
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 well-structured and appropriately sized. It starts with the core purpose, explains the rationale, lists parameters with clear explanations, and states the return value. Every sentence earns its place with no wasted words, and information is front-loaded effectively.
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 complexity (destructive operation with 3 parameters) and the presence of an output schema (which covers return values), the description is mostly complete. It explains the tool's purpose, parameters, and behavior adequately. The main gap is lack of explicit warnings about destructive nature or prerequisites, though the dry_run parameter provides some safety context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds significant semantic value beyond the input schema, which has 0% description coverage. It explains each parameter's purpose: 'dry_run: Preview what would be removed without actually removing,' 'archive_instead: Archive memories instead of deleting,' and 'limit: Maximum number of memories to process.' This fully compensates for the schema's lack of 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 clearly states the tool's purpose: 'Perform garbage collection on low-scoring memories' with specific verb ('Perform garbage collection') and resource ('low-scoring memories'). It distinguishes from siblings like 'cluster_memories' or 'consolidate_memories' by focusing on removal/archiving based on decay scores.
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 this tool: when memories have 'fallen below the forget threshold' to 'prevent the database from growing indefinitely with unused memories.' However, it doesn't explicitly state when NOT to use it or mention alternatives among siblings, though the purpose implies it's for cleanup rather than other memory operations.
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:

[![cortexgraph MCP server](https://glama.ai/mcp/servers/prefrontal-systems/cortexgraph/badges/card.svg)](https://glama.ai/mcp/servers/prefrontal-systems/cortexgraph)

Score Badge

Copy to your README.md:

[![cortexgraph MCP server](https://glama.ai/mcp/servers/prefrontal-systems/cortexgraph/badges/score.svg)](https://glama.ai/mcp/servers/prefrontal-systems/cortexgraph)

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/prefrontal-systems/cortexgraph'

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