AGI MCP Server

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation4/5
Most tools have distinct purposes, with clear separation between memory creation, retrieval, search, and management operations. However, some overlap exists between the three search tools (search_memories_advanced, search_memories_similarity, search_memories_text), which could cause confusion about which to use for different query types.
Naming Consistency5/5
All tools follow a consistent verb_noun naming pattern with clear, descriptive names. The naming convention is uniform throughout, using snake_case consistently without any mixing of styles or ambiguous verbs.
Tool Count3/5
With 24 tools, the count feels heavy for a memory management system. While the domain is complex, the number of tools may overwhelm agents and suggests potential for consolidation, particularly in the search and retrieval categories.
Completeness5/5
The tool set provides comprehensive coverage for memory management, including full CRUD operations (create, get, update via relationships, delete via prune), search capabilities, analytics, and system health monitoring. No obvious gaps exist for the apparent domain of AGI memory systems.
Average 2.9/5 across 24 of 24 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
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?
No annotations are provided, so the description carries full burden for behavioral disclosure. It only states the action without detailing traits like read/write nature, permissions, rate limits, or output format. This is inadequate for a tool that likely involves data retrieval or analysis.
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 a single, efficient sentence with no wasted words, making it easy to parse. However, it lacks front-loaded critical information (e.g., distinguishing from siblings), which slightly reduces its effectiveness despite the brevity.
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?
Given the complexity implied by sibling tools (e.g., memory and cluster management), no annotations, and no output schema, the description is incomplete. It doesn't explain what 'clusters' are, how similarity is measured, or what the output entails, leaving significant gaps for agent understanding.
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%, with clear documentation for both parameters ('cluster_id' as UUID, 'threshold' as number with default 0.7). The description adds no additional meaning beyond the schema, such as explaining what 'similar' means or how the threshold is applied, so it meets the baseline for high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool's purpose as 'Find clusters similar to a given cluster', which is clear but vague. It specifies the verb ('Find') and resource ('clusters'), but doesn't distinguish it from sibling tools like 'search_memories_similarity' or 'find_related_memories', leaving ambiguity about what makes this tool unique.
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. With siblings like 'search_memories_similarity' and 'find_related_memories', it fails to specify contexts, prerequisites, or exclusions, leaving the agent to guess based on tool names alone.
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 provided, the description carries full burden for behavioral disclosure. It mentions ordering by 'importance/activity', which adds some context beyond a basic retrieval, but fails to address critical aspects like whether this is a read-only operation, potential rate limits, authentication needs, or what the output format looks like. For a tool with zero annotation coverage, this leaves significant behavioral gaps.
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 a single, efficient sentence that front-loads the core action ('retrieve memory clusters') and adds a key detail ('ordered by importance/activity'). There is no wasted text, making it appropriately concise for a simple retrieval tool.
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?
Given the lack of annotations and output schema, the description is incomplete. It doesn't explain what memory clusters are, how they relate to sibling tools, or what the return values include (e.g., cluster details, ordering criteria). For a tool in a complex memory management context with many alternatives, more contextual information is needed to guide effective use.
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 has 100% description coverage for its single parameter 'limit', so the schema fully documents it. The description adds no additional parameter information beyond what the schema provides, such as typical values or constraints on 'importance/activity' ordering. This meets the baseline of 3 when schema coverage is high.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the verb 'retrieve' and resource 'memory clusters', which clarifies the basic action. However, it doesn't specify what memory clusters are or how they differ from related resources like 'memories' or 'working memories' mentioned in sibling tools, leaving the purpose somewhat vague compared to alternatives like get_memory or get_working_memories.
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 such as get_memory, get_working_memories, or find_similar_clusters. The description mentions ordering by 'importance/activity', but this doesn't explicitly indicate when this ordering is preferred over other retrieval methods, offering minimal usage context.
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 provided, the description carries full burden for behavioral disclosure. It mentions 'advanced' and 'multiple criteria' but fails to describe key traits: whether this is a read-only operation, what permissions are needed, how results are returned (e.g., pagination, sorting), or any rate limits. For a search tool with complex nested parameters, this leaves significant gaps in understanding its 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 extremely concise with a single sentence that efficiently conveys the core idea. It's front-loaded with the main purpose ('Advanced memory search') and adds a qualifier ('with multiple criteria') without unnecessary elaboration. Every word earns its place, making it structurally sound for quick comprehension.
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?
Given the complexity (1 nested parameter with 6 sub-properties), no annotations, and no output schema, the description is incomplete. It doesn't explain the tool's behavior, parameter usage, or return values, which are critical for an 'advanced' search operation. The lack of output schema means the description should ideally hint at result format, but it doesn't, leaving the agent under-informed.
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%, meaning all parameter details are undocumented in the schema. The description only vaguely references 'multiple criteria', without explaining what those criteria are, how they interact, or their semantics. It doesn't compensate for the schema gap by detailing parameters like 'criteria' object, 'embedding', 'memory_types', etc., leaving the agent with insufficient guidance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Advanced memory search with multiple criteria' states the general purpose (searching memories) and hints at capability ('advanced', 'multiple criteria'), but it's vague about what makes it 'advanced' and doesn't clearly differentiate from sibling tools like 'search_memories_similarity' or 'search_memories_text'. It provides a basic verb+resource but lacks specificity about scope or unique features.
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 offers no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'search_memories_similarity' or 'search_memories_text', nor does it provide context about when 'advanced' search is appropriate versus simpler methods. There's no explicit when/when-not advice or prerequisites stated.
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 but provides minimal behavioral insight. It mentions 'graph traversal' but doesn't disclose key traits: whether it's read-only or mutative, performance implications (e.g., depth limits), error handling, or output format. For a tool with graph operations and no annotations, this leaves significant gaps in understanding its 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 a single, efficient sentence with no wasted words. It's front-loaded and directly states the tool's function. Every part earns its place, making it highly concise and well-structured for its brevity.
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?
Given the complexity of graph traversal, no annotations, and no output schema, the description is incomplete. It doesn't cover behavioral aspects like safety, performance, or return values, leaving the agent with insufficient context to use the tool effectively. The high schema coverage helps but doesn't compensate for missing output and behavioral details.
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 parameters are fully documented in the schema. The description adds no additional meaning beyond the schema's details for 'memory_id', 'max_depth', or 'min_strength'. It doesn't explain how these parameters interact (e.g., how strength affects traversal) or provide usage examples, meeting the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool finds memories through graph traversal, which gives a general purpose but lacks specificity. It doesn't clarify what 'related' means (e.g., by relationship type, similarity, or temporal proximity) or distinguish it from sibling tools like 'find_similar_clusters' or 'search_memories_similarity'. The verb 'find' is generic, and 'graph traversal' is technical but vague without context.
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. It doesn't mention prerequisites (e.g., needing an existing memory ID), exclusions, or compare to siblings like 'get_memory_relationships' or 'search_memories_advanced'. The description implies a graph-based approach but offers no practical usage context.
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 the full burden. It states 'retrieve' implying a read-only operation, but doesn't disclose behavioral traits such as permissions needed, rate limits, pagination, or what 'current' means in practice (e.g., time-based or state-based). This leaves gaps for safe and effective use.
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, efficient sentence with no wasted words. It's front-loaded with the core purpose, making it easy to scan and understand quickly. Every word earns its place, adhering to best practices for concise tool descriptions.
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?
Given the lack of annotations and output schema, the description is incomplete for a retrieval tool. It doesn't explain what 'working memories' are, what data is returned, or how 'current' is defined, which could lead to misuse. For a tool in a memory system with many siblings, more context is needed to ensure proper selection and 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%, with the parameter 'include_expired' fully documented in the schema. The description doesn't add any meaning beyond the schema, as it doesn't mention parameters at all. With high schema coverage, the baseline score of 3 is appropriate since the schema handles the parameter documentation adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Retrieve current working memories' clearly states the action (retrieve) and target resource (working memories), but it's somewhat vague about what constitutes 'current' versus other states. It doesn't differentiate from siblings like get_memory, get_memory_history, or search_memories_advanced, which might retrieve similar data with different filters or scopes.
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. With many sibling tools like get_memory (singular), get_memory_history, and search_memories_advanced, the description lacks context on whether this is for bulk retrieval, real-time data, or specific use cases, leaving the agent to guess based on the name alone.
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 the full burden of behavioral disclosure. It mentions activation and retrieval of memories, but doesn't describe what 'activate' means (e.g., does it change state, require permissions, have side effects?), the format or scope of returned memories, potential errors, or rate limits. For a tool with no annotation coverage, this leaves significant gaps in understanding its behavior.
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 a single, efficient sentence that front-loads the core action and outcome. It avoids redundancy and wastes no words, making it easy to parse quickly. However, it could be slightly more structured by separating purpose from usage hints, but this is minor.
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?
Given the complexity (activation operation with no annotations and no output schema), the description is incomplete. It doesn't explain what 'activate' entails, the nature of returned memories, error conditions, or how it differs from read-only siblings. Without annotations or output schema, more detail is needed to fully understand the tool's behavior and use cases.
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 fully documents both parameters ('cluster_id' as UUID, 'context' as optional description). The description doesn't add any meaning beyond this, such as explaining how 'context' influences activation or providing examples. With high schema coverage, the baseline is 3, as the description doesn't compensate but also doesn't detract.
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 ('activate') and resource ('a memory cluster'), and mentions the outcome ('get its associated memories'). It distinguishes from siblings like 'get_memory_clusters' (which likely lists clusters) and 'create_memory_cluster' (which creates new ones), though it doesn't explicitly name alternatives. The purpose is specific but could be more precise about what 'activate' entails operationally.
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. It doesn't specify prerequisites (e.g., whether the cluster must exist or be inactive), exclusions, or compare to siblings like 'get_memory_clusters' or 'find_similar_clusters'. The description implies usage for retrieving memories from a cluster, but lacks context on appropriate scenarios or limitations.
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 the full burden of behavioral disclosure. It states the action ('archive') but doesn't explain what 'archive' entails—e.g., whether it's reversible, destructive, or requires specific permissions. For a mutation tool with zero annotation coverage, this lack of detail is a significant gap, leaving key behavioral traits unspecified.
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, efficient sentence that directly states the tool's purpose without unnecessary words. It is front-loaded with the core action and criteria, making it easy to parse quickly. Every part of the sentence contributes to understanding the tool's function, demonstrating excellent conciseness and structure.
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?
Given the tool's complexity as a mutation operation with no annotations and no output schema, the description is incomplete. It lacks details on behavioral aspects (e.g., effects of archiving), usage context compared to siblings, and output expectations. For a tool that modifies data, this minimal description fails to provide sufficient context for safe and effective use.
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 mentions 'age and importance criteria', which aligns with the parameters 'days_old' and 'importance_threshold'. However, the input schema has 100% description coverage, with clear defaults and meanings for both parameters. The description adds minimal value beyond what the schema already provides, so it meets the baseline score for high schema coverage without enhancing parameter understanding.
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 verb ('archive') and resource ('old memories'), specifying the action and target. It also mentions criteria ('based on age and importance criteria'), which adds specificity. However, it doesn't explicitly distinguish this tool from sibling tools like 'prune_memories' or 'cleanup_expired_working_memory', which might have overlapping functions, so it falls short of 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 no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, exclusions, or compare it to sibling tools such as 'prune_memories' or 'cleanup_expired_working_memory'. Without this context, users must infer usage from the tool name and parameters alone, which is insufficient for clear decision-making.
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 but only states the action without behavioral details. It doesn't disclose if this is destructive (e.g., permanent deletion), requires specific permissions, has side effects, or how it handles errors. This is inadequate for a mutation tool with zero 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words. It's appropriately sized and front-loaded, making it easy to scan and understand quickly.
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?
Given the tool likely performs a mutation (cleaning up implies change), the lack of annotations and output schema means the description should provide more context. It doesn't explain what 'expired' means, the cleanup process, or expected outcomes, making it incomplete for safe agent 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?
There are 0 parameters, and schema description coverage is 100%, so no parameter documentation is needed. The description doesn't add param info, but that's acceptable here. Baseline is 4 for zero parameters, as it avoids unnecessary detail.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Clean up expired working memories' states a clear verb ('clean up') and resource ('expired working memories'), but it's somewhat vague about what 'clean up' entails (e.g., deletion, archiving, marking). It doesn't distinguish from siblings like 'archive_old_memories' or 'prune_memories', which might have overlapping functions.
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 'archive_old_memories' or 'prune_memories'. The description implies it's for expired items, but it doesn't specify context, triggers, or exclusions, leaving usage unclear relative to siblings.
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 consolidates memories but doesn't disclose critical behavioral traits: whether this is a destructive operation (what happens to the original working memories), what permissions or authentication might be required, rate limits, or what the output looks like (since no output schema exists).
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, efficient sentence that directly states the tool's purpose with zero wasted words. It's appropriately sized and front-loaded with the core functionality.
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?
Given the complexity of a memory consolidation operation with no annotations and no output schema, the description is insufficient. It doesn't explain what happens to the original working memories, what the resulting semantic memory contains, or any prerequisites or side effects, leaving significant gaps for an AI agent to understand the tool's behavior.
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 all three parameters with clear descriptions. The description adds no additional meaning about parameters beyond what's in the schema, such as format expectations for UUIDs, content guidelines, or embedding specifications.
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 ('consolidate') and resources ('multiple working memories into a single semantic memory'), providing a specific verb+resource combination. However, it doesn't explicitly distinguish this tool from sibling tools like 'create_memory' or 'prune_memories', which might also involve memory transformation or management.
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. With sibling tools like 'create_memory', 'prune_memories', and 'archive_old_memories' available, there's no indication of when consolidation is appropriate versus creation, deletion, or archiving of memories.
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 the full burden of behavioral disclosure. While it states this is a creation operation, it doesn't mention whether this requires specific permissions, what happens on success/failure, whether duplicates are allowed, or any rate limits. For a mutation tool with zero annotation coverage, this leaves significant behavioral gaps for an AI agent.
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, efficient sentence that gets straight to the point. It's appropriately sized for the tool's complexity and front-loads the essential information. There's no wasted language or unnecessary elaboration.
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?
For a mutation tool with 5 parameters, no annotations, and no output schema, the description is insufficiently complete. It doesn't address behavioral aspects like error conditions, permission requirements, or what the tool returns. While the schema covers parameters well, the description fails to provide the broader operational context needed for effective tool use.
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 all 5 parameters thoroughly. The description adds minimal value beyond what's in the schema - it mentions 'optional type-specific metadata' which aligns with the schema's metadata parameter description. No additional semantic context is provided about how parameters interact or their practical significance.
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 ('create a new memory') and resource ('memory'), making the purpose immediately understandable. It distinguishes this from sibling tools like 'create_memory_cluster' or 'create_working_memory' by focusing on individual memory creation rather than clusters or working memory. However, it doesn't explicitly differentiate from 'create_memory_relationship', which might create some ambiguity.
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. With sibling tools like 'create_memory_cluster', 'create_working_memory', and 'create_memory_relationship', there's no indication of which tool to choose for different scenarios. The mention of 'optional type-specific metadata' hints at some context but doesn't constitute usage guidelines.
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 provided, the description carries full burden for behavioral disclosure. 'Create' implies a write/mutation operation, but the description doesn't address important behavioral aspects: whether this requires specific permissions, what happens on success/failure, whether clusters are immediately usable, or any side effects. For a creation tool with zero annotation coverage, this represents a significant transparency gap.
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 maximally concise - a single clear sentence that states the core purpose without any unnecessary words. It's front-loaded with the essential information and contains zero waste or 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?
For a creation tool with no annotations and no output schema, the description is insufficiently complete. It doesn't explain what a memory cluster is, how it differs from regular memories, what happens after creation, or what the tool returns. Given the complexity implied by the parameter schema (including cluster_type enum with 6 options) and the absence of structured behavioral information, more context is needed.
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 all parameters thoroughly. The description adds no parameter information beyond what's in the schema - it doesn't explain the significance of cluster_type choices, how names are validated, or how keywords affect cluster behavior. With complete schema coverage, 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 states the action ('create') and resource ('new memory cluster'), making the purpose immediately understandable. However, it doesn't differentiate this tool from sibling tools like 'create_memory' or 'create_memory_relationship', which would require more specific context about what distinguishes a memory cluster from other memory-related entities.
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. With multiple sibling tools for creating memory-related entities (create_memory, create_memory_relationship, create_working_memory), there's no indication of when a memory cluster is appropriate versus other memory creation tools, nor any mention of prerequisites or typical use cases.
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 provided, the description carries full burden for behavioral disclosure. 'Create' implies a write/mutation operation, but the description doesn't mention permissions needed, whether this is reversible, what happens on conflict, or what the response looks like. For a creation tool with zero annotation coverage, this leaves significant behavioral questions unanswered.
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, efficient sentence that states the core purpose without unnecessary words. It's appropriately sized for a tool with good schema documentation and gets straight to the point with zero waste.
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?
For a creation tool with no annotations and no output schema, the description is insufficient. It doesn't explain what gets created, what the relationship means operationally, whether there are constraints on relationship creation, or what the tool returns. Given the complexity of memory relationships and lack of structured behavioral information, more context is needed.
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 all parameters thoroughly. The description doesn't add any meaningful parameter semantics beyond what's in the schema - it doesn't explain relationship types, what 'properties' might contain, or how the relationship affects the memories. Baseline 3 is appropriate when the schema does the heavy lifting.
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 verb 'create' and the resource 'relationship between two memories', making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'get_memory_relationships' or explain what distinguishes this creation from other 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 about when to use this tool versus alternatives like 'create_memory_cluster' or 'find_related_memories'. The description lacks context about prerequisites, typical use cases, or when this operation is appropriate versus other memory manipulation tools.
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 provided, the description carries full burden. It discloses the temporary/expiring nature (useful behavioral context), but doesn't mention permissions needed, rate limits, whether it's idempotent, what happens on failure, or the response format. For a creation tool with zero annotation coverage, this leaves significant gaps in understanding its 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 a single, efficient sentence that front-loads the core purpose. Every word earns its place—'temporary' and 'with expiration' add important qualifiers without redundancy. No wasted words or unnecessary elaboration.
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?
For a creation tool with 3 parameters, no annotations, and no output schema, the description is insufficient. It doesn't explain what a 'working memory' is in this system, how it differs from regular memories, what happens after creation, or error conditions. The agent would need to guess about many aspects of tool behavior.
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 67% (2 of 3 parameters have descriptions). The description doesn't add any parameter-specific information beyond what's in the schema. It mentions 'expiration' which relates to the 'ttl' parameter, but doesn't explain the relationship between content and embedding, or provide context for the nested 'context' object. Baseline 3 is appropriate given moderate schema coverage.
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 ('Create') and resource ('temporary working memory'), specifying it has expiration. It distinguishes from siblings like 'create_memory' by emphasizing the temporary nature, but doesn't explicitly contrast with other creation tools like 'create_memory_cluster' or 'create_memory_relationship'.
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 'create_memory' (which might be permanent) or 'create_memory_cluster'. It mentions expiration but doesn't specify scenarios where temporary vs. permanent storage is appropriate, nor prerequisites for use.
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 the full burden. It mentions 'recently activated' and implies a time-based filter, but doesn't disclose behavioral traits such as whether this is a read-only operation, if it requires authentication, rate limits, or what the output format looks like (e.g., list of themes). This leaves significant gaps for an agent to understand how to handle 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?
The description is a single, efficient sentence that directly states the tool's purpose without any wasted words. It's appropriately sized and front-loaded, making it easy to parse quickly.
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?
Given the complexity of memory-related tools and no annotations or output schema, the description is incomplete. It doesn't explain what 'themes and patterns' entail, how results are returned, or any behavioral constraints, leaving the agent with insufficient context for effective use.
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 has 100% description coverage, with the 'days' parameter well-documented. The description adds minimal value beyond the schema by implying a time-based filter ('recently activated'), but doesn't provide additional semantics like default behavior or usage context. This meets the baseline for high schema coverage.
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 verb ('Get') and resource ('recently activated memory themes and patterns'), making the purpose understandable. However, it doesn't explicitly differentiate from sibling tools like 'get_memory_clusters' or 'get_memory_history', which might also retrieve memory-related data, so it misses full sibling distinction.
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. With many sibling tools like 'get_memory_clusters' or 'search_memories_advanced', there's no indication of context, prerequisites, or exclusions for selecting this specific tool.
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 provided, the description carries full burden for behavioral disclosure. It implies a read-only operation ('Get') but doesn't specify whether it requires authentication, has rate limits, returns structured data, or involves side effects. For a tool that presumably returns analytics data, this lack of behavioral context is a significant gap.
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, efficient sentence that front-loads the core purpose without unnecessary words. Every word earns its place: 'Get' (action), 'detailed analytics' (output type), 'for a memory cluster' (target). There's no redundancy or fluff.
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?
For a tool with no annotations, no output schema, and a single parameter, the description is incomplete. It doesn't explain what 'detailed analytics' includes (e.g., metrics, timestamps, visualizations), how results are structured, or error conditions. Given the complexity implied by 'analytics' and lack of structured fields, more context is needed for effective use.
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%, with the single parameter 'cluster_id' documented as a UUID. The description adds no additional parameter semantics beyond what the schema provides—it doesn't clarify format examples, valid UUID ranges, or how to obtain cluster IDs. Given the high schema coverage, 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 states the action ('Get detailed analytics') and target resource ('for a memory cluster'), making the purpose immediately understandable. It distinguishes from siblings like 'get_memory_clusters' (which likely lists clusters) and 'get_memory_health' (which might provide health metrics rather than analytics). However, it doesn't specify what 'detailed analytics' includes, leaving some ambiguity.
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 'get_memory_clusters' or 'get_memory_health'. It doesn't mention prerequisites (e.g., needing an existing cluster) or contextual cues (e.g., use when analyzing cluster performance). The agent must infer usage from the name and sibling tools alone.
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 provided, the description carries full burden for behavioral disclosure. While 'Get change history' implies a read operation, it doesn't specify what constitutes 'change history' (edits, metadata changes, access logs), whether there are permission requirements, pagination behavior, or rate limits. The description is too minimal for a tool that presumably returns historical 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 a single, efficient sentence that gets straight to the point with zero wasted words. It's appropriately sized for a simple retrieval tool and front-loads the essential information.
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?
For a tool that retrieves historical data with no annotations and no output schema, the description is insufficient. It doesn't explain what 'change history' includes, the format of returned data, whether it's paginated, or any constraints on historical data availability. Given the complexity implied by 'change history' and lack of structured metadata, more context is needed.
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 has 100% description coverage with 'memory_id' clearly documented as a UUID. The description doesn't add any parameter semantics beyond what the schema provides, but with complete schema coverage, the baseline score of 3 is appropriate as the schema does the heavy lifting.
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 ('Get change history') and resource ('for a specific memory'), making the purpose immediately understandable. It doesn't explicitly differentiate from sibling tools like 'get_memory' or 'get_memory_relationships', but the focus on 'change history' provides reasonable distinction.
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. With sibling tools like 'get_memory', 'get_memory_relationships', and various search functions available, there's no indication of when change history retrieval is appropriate versus retrieving current memory state or other related data.
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 the full burden of behavioral disclosure. It states the action but doesn't describe what 'relationships' entail (e.g., structure, format), whether it's a read-only operation, potential rate limits, or error conditions. This leaves significant gaps for an agent to understand the tool's 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 a single, efficient sentence that directly states the tool's purpose without unnecessary words. It's appropriately sized and front-loaded, making it easy to parse quickly.
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?
Given the lack of annotations and output schema, the description is incomplete. It doesn't explain what 'relationships' are returned, their format, or any behavioral traits like pagination or error handling. For a retrieval tool with three parameters, this minimal description leaves too much undefined for effective agent use.
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 has 100% description coverage, providing clear documentation for all three parameters. The description adds no additional semantic context beyond implying that 'memory_id' identifies the target memory, which is already covered by the schema. This meets the baseline for high schema coverage.
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 verb ('Get') and resource ('relationships for a specific memory'), making the purpose understandable. However, it doesn't distinguish this tool from sibling tools like 'find_related_memories' or 'create_memory_relationship', which appear to handle related functionality but with different 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. With sibling tools like 'find_related_memories' and 'search_memories_advanced' available, there's no indication of context, prerequisites, or exclusions for selecting this specific retrieval tool.
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 provided, the description carries the full burden of behavioral disclosure. It mentions retrieval but doesn't specify if this is a read-only operation, requires authentication, has rate limits, or what the output format might be. This leaves significant gaps in understanding the tool's behavior and constraints.
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, efficient sentence that directly states the tool's function without any fluff or repetition. It is front-loaded with the core action ('retrieve') and resource, making it easy to parse quickly.
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?
Given the lack of annotations and output schema, the description is incomplete for a tool that likely returns complex data (worldview primitives and beliefs). It doesn't explain what the output contains, how it's structured, or any behavioral aspects like side effects, making it inadequate for full contextual understanding.
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 input schema has 100% description coverage (though empty). The description doesn't need to add parameter details, so it appropriately focuses on the tool's purpose without redundancy. A baseline of 4 is given as it avoids unnecessary parameter explanation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool retrieves 'current worldview primitives and beliefs', which provides a general purpose but lacks specificity about what these primitives and beliefs entail or how they differ from related tools like 'get_identity_core' or 'get_active_themes'. It uses a clear verb ('retrieve') but doesn't distinguish itself from siblings beyond the resource name.
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 such as 'get_identity_core' or 'get_active_themes'. The description implies it's for retrieving worldview data but offers no context on prerequisites, timing, or exclusions, leaving the agent to infer usage from the name alone.
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 provided, the description carries full burden. It discloses the destructive nature ('permanently delete') but lacks critical behavioral details: what permissions are required, whether deletions are reversible, rate limits, or what happens to related data. The description is insufficient for a destructive 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 a single, efficient sentence that front-loads the key information ('permanently delete memories'). There's no wasted verbiage or redundant information.
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?
For a destructive tool with no annotations and no output schema, the description is inadequate. It doesn't explain what 'memories' are in this context, what happens after deletion, error conditions, or return values. The description leaves too many open questions for safe usage.
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 mentions 'criteria' but doesn't explain what criteria are available or their semantics. With 0% schema description coverage (schema has no top-level description), the description adds minimal value. However, since there's only 1 parameter (a nested object), the baseline is 3 as the schema documents the nested properties well.
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 ('permanently delete') and resource ('memories'), making the purpose unambiguous. However, it doesn't differentiate from sibling tools like 'archive_old_memories' or 'cleanup_expired_working_memory', which likely have overlapping functionality.
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 'archive_old_memories' or 'cleanup_expired_working_memory'. It mentions criteria-based deletion but doesn't specify scenarios or prerequisites for usage.
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 provided, the description carries full burden but only states the basic operation. It lacks details on behavioral traits such as performance characteristics, rate limits, authentication needs, error handling, or what constitutes a 'memory' in this 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 a single, efficient sentence with zero wasted words. It's front-loaded with the core purpose and uses precise terminology ('vector similarity'), 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.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a search tool with 3 parameters, no annotations, and no output schema, the description is insufficient. It doesn't cover return format, result structure, pagination, or error cases. Given the complexity of vector similarity searches, more context is needed for effective use.
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 parameters are well-documented in the schema. The description adds no additional meaning beyond implying vector similarity is used, but doesn't explain embedding format, similarity metrics, or result ordering. Baseline 3 is appropriate as the schema handles parameter documentation.
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 ('Search') and resource ('memories'), with the specific method 'by vector similarity' distinguishing it from text-based search. However, it doesn't explicitly differentiate from sibling 'search_memories_advanced' or 'find_related_memories', which might also involve similarity searches.
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_memories_text' or 'search_memories_advanced'. The description implies it's for vector-based similarity searches but doesn't specify use cases, 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 states the search method ('full-text search') but lacks details on permissions, rate limits, result format, pagination, or error handling. For a search tool with zero annotation coverage, this is a significant gap in behavioral disclosure.
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, efficient sentence with zero waste. It is appropriately sized and front-loaded, clearly stating the tool's purpose without unnecessary elaboration.
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?
Given no annotations and no output schema, the description is incomplete. It lacks details on behavioral traits, return values, and usage context, which are essential for a search tool. The high schema coverage does not compensate for these missing elements.
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%, with both parameters ('query' and 'limit') well-documented in the schema. The description adds no additional parameter semantics beyond implying text-based search, so it meets the baseline of 3 without compensating for any schema gaps.
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 ('search') and target resource ('memories by text content'), specifying the method ('full-text search'). It distinguishes from some siblings like 'get_memory' (retrieval) and 'find_related_memories' (relation-based), though not explicitly from 'search_memories_advanced' or 'search_memories_similarity'.
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. It does not mention when to prefer it over 'search_memories_advanced' or 'search_memories_similarity', nor does it specify prerequisites or exclusions, leaving usage context unclear.
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 the full burden. It states 'retrieve' implying a read operation, but doesn't disclose behavioral traits such as whether it requires authentication, has rate limits, returns structured data, or if it's idempotent. For a tool with zero annotation coverage, this leaves significant gaps in understanding its 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 a single, efficient sentence that directly states the tool's purpose without any fluff or redundant information. It is appropriately sized and front-loaded, making it easy to parse quickly.
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 no parameters, no output schema, and no annotations, the description adequately covers the basic purpose. However, it lacks details on return format, error conditions, or how the retrieved data integrates with sibling tools, which could be important for an AI agent to use it effectively in 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 tool has 0 parameters, and schema description coverage is 100% (though empty). The description doesn't need to add parameter semantics, so it meets the baseline of 4 for zero-parameter tools. No additional parameter context is required or provided.
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 verb 'retrieve' and specifies the resources: 'current identity model and core memory clusters'. It distinguishes from siblings like 'get_memory_clusters' (which retrieves clusters generally) by focusing on identity-related core clusters. However, it doesn't explicitly differentiate from 'get_worldview' (which might overlap with identity model).
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. With siblings like 'get_memory_clusters', 'get_active_themes', and 'get_worldview', there's no indication of when this specific retrieval is appropriate, what context it serves, or any prerequisites for invocation.
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 provided, the description carries full burden for behavioral disclosure. While 'Get' implies a read-only operation, it doesn't specify whether this requires special permissions, what format the statistics are returned in, whether there are rate limits, or if the operation has any side effects. For a diagnostic tool with zero annotation coverage, this leaves significant behavioral questions unanswered.
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 perfectly concise - a single sentence that directly states the tool's purpose without any unnecessary words. It's front-loaded with the core functionality and doesn't include any extraneous information. Every word earns its place in this minimal but complete statement.
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 simplicity (no parameters, no output schema), the description is adequate but minimal. For a diagnostic/health-check tool, it could benefit from mentioning what specific statistics are included or the format of the response. However, with no complex parameters and no output schema to document, the description meets minimum viable standards.
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% (though trivial since there are no parameters). The description appropriately doesn't waste space discussing parameters that don't exist. A baseline of 4 is appropriate for zero-parameter tools when the description focuses on what the tool does rather than parameter documentation.
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 with a specific verb ('Get') and resource ('overall statistics about memory system health'), making it immediately understandable. However, it doesn't differentiate this tool from sibling tools like 'get_cluster_insights' or 'get_active_themes' that also retrieve health/status information, 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 no guidance on when to use this tool versus alternatives. With many sibling tools that retrieve various types of memory information (clusters, relationships, history, etc.), there's no indication of when 'memory system health' statistics are appropriate versus other diagnostic or informational tools.
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 a behavioral trait ('mark it as accessed') that indicates a side effect beyond simple retrieval, which is useful. However, it lacks details on permissions, rate limits, or error handling, leaving gaps in behavioral understanding.
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, efficient sentence that front-loads the core action ('Retrieve a specific memory by ID') and includes a key behavioral note ('mark it as accessed'). There is no wasted wording, 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?
Given the tool has one parameter with full schema coverage and no output schema, the description is minimally adequate. It covers the basic action and a side effect, but for a tool that modifies state (marking as accessed), more context on implications or return values would improve 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 input schema has 100% description coverage, with the parameter 'memory_id' documented as a UUID. The description adds no additional meaning beyond this, such as format examples or constraints, so it meets the baseline score without compensating further.
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 verb ('Retrieve') and resource ('a specific memory by ID'), making the purpose understandable. However, it doesn't explicitly differentiate this tool from sibling tools like 'get_memory_history' or 'get_memory_relationships', which might also retrieve memory-related data, so it doesn't reach the highest 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 no guidance on when to use this tool versus alternatives like 'search_memories_advanced' or 'find_related_memories'. It mentions marking the memory as accessed, but this doesn't clarify usage context or exclusions, leaving the agent with minimal direction.
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:

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

Score Badge

Copy to your README.md:

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

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/QuixiAI/agi-mcp-server'

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