Elasticsearch Knowledge Graph for MCP

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, such as create_entities vs. update_entities or list_zones vs. zone_stats. However, some overlap exists: open_nodes and get_recent both retrieve entity details, and copy_entities vs. move_entities could be confused, though descriptions clarify differences.
Naming Consistency5/5
Tool names follow a consistent verb_noun pattern throughout, such as create_entities, delete_relations, and inspect_files. All use snake_case with clear, descriptive verbs, making the set predictable and easy to navigate.
Tool Count4/5
With 20 tools, the count is slightly high but reasonable for managing a knowledge graph with zones, entities, and relations. It covers operations like CRUD, inspection, and zone management, though it might feel heavy compared to simpler servers.
Completeness5/5
The toolset provides comprehensive coverage for a knowledge graph domain, including entity and relation CRUD, zone management (create, delete, merge, list), search capabilities, and utilities like time retrieval. No obvious gaps are present; agents can perform full lifecycle operations.
Average 3.1/5 across 20 of 20 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

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 write operation ('Add') but doesn't specify permissions needed, whether changes are reversible, rate limits, or what happens if the entity doesn't exist. This is a significant gap 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 that front-loads the core purpose without unnecessary words. Every part earns its place by clarifying the action, target, and context ('knowledge graph (memory)'), 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 mutation tool with no annotations and no output schema, the description is incomplete. It lacks critical context such as error handling, response format, or behavioral details (e.g., idempotency, side effects), which are essential for safe and effective tool invocation by an AI agent.
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 thoroughly. The description adds no additional meaning beyond what's in the schema (e.g., it doesn't explain observation format or memory zone implications), meeting the baseline for high 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 ('Add observations') and target ('to an existing entity in knowledge graph (memory)'), providing a specific verb+resource combination. However, it doesn't explicitly differentiate from sibling tools like 'update_entities' or 'mark_important', which might also modify entities, 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. It doesn't mention prerequisites (e.g., entity must exist), exclusions, or compare to siblings like 'update_entities' or 'create_entities', leaving the agent with no usage context beyond the basic purpose.
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 'optional relation handling', which hints at the 'copy_relations' parameter behavior, but fails to describe critical aspects like whether this is a read-only or destructive operation, permission requirements, rate limits, or what happens on failure. For a tool that copies entities between zones—potentially involving data mutation—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 a single, efficient sentence that front-loads the core purpose ('Copy entities between zones') and adds a key behavioral note ('with optional relation handling'). There is no wasted verbiage, making it highly concise and well-structured 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 of copying entities between zones, no annotations, and no output schema, the description is incomplete. It lacks information on return values, error conditions, side effects, and how it differs from sibling tools. For a tool with 5 parameters and potential data implications, more context 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?
Schema description coverage is 100%, so the schema fully documents all 5 parameters. The description adds minimal value by implying 'optional relation handling' corresponds to 'copy_relations', but doesn't explain parameter interactions or provide additional context beyond the schema. This meets the baseline of 3 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 action ('Copy entities') and the scope ('between zones'), which is specific and actionable. It distinguishes from siblings like 'move_entities' by specifying copying rather than moving, and from 'create_entities' by involving source/target zones. However, it doesn't fully differentiate from 'merge_zones' or other zone operations, keeping it at 4 instead of 5.
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 when to choose 'copy_entities' over 'move_entities', 'create_entities', or 'merge_zones', nor does it specify prerequisites or exclusions. This leaves the agent without contextual usage direction.
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 action without behavioral details. It doesn't disclose permissions needed, whether creation is idempotent, error handling, or rate limits, which are critical for a write operation in a knowledge graph system.
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, clearly front-loading the core action. It's appropriately sized for the tool's complexity, 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 a write operation in a knowledge graph with no annotations and no output schema, the description is incomplete. It lacks details on behavioral traits, error cases, or return values, leaving significant gaps for an agent to operate effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both parameters ('entities' and 'memory_zone') thoroughly. The description adds no additional meaning beyond the schema, such as explaining what a 'memory_zone' represents or constraints on entity creation, 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.
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 ('entities in knowledge graph (memory)'), making the purpose understandable. However, it doesn't differentiate from siblings like 'update_entities' or 'add_observations', which would require specifying this is for initial creation only.
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. For example, it doesn't mention whether to use 'update_entities' for modifying existing entities or 'add_observations' for adding observations to existing entities, leaving the agent without context for tool selection.
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 'create' which implies a mutation, but fails to detail permissions, side effects, error handling, or response format. This is inadequate for a mutation tool, as it leaves critical 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 and wastes no space, making it easy for an agent 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?
For a mutation tool with no annotations and no output schema, the description is insufficient. It lacks details on behavioral traits, error conditions, and return values, which are critical for safe and effective tool invocation. The high schema coverage does not compensate for these gaps in contextual information.
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 input schema fully documents all parameters. The description does not add any semantic details beyond what the schema provides, such as examples or usage tips. Baseline score of 3 is appropriate as the schema handles parameter documentation effectively.
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 relationships') and the resource ('between entities in knowledge graph'), which is specific and understandable. However, it does not explicitly differentiate from sibling tools like 'delete_relations' or 'update_entities', missing an opportunity to clarify its unique role in the toolset.
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 such as 'delete_relations' or 'update_entities', nor does it mention prerequisites like existing entities or zones. It lacks explicit usage context, leaving the agent to infer based on the tool 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 the full burden of behavioral disclosure. It states the tool creates a new zone but lacks details on permissions needed, whether the operation is idempotent, what happens on failure, or any rate limits. 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 that is front-loaded with the core purpose. It wastes no words and is appropriately sized for the tool's complexity.
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 is a mutation (create operation) with no annotations and no output schema, the description is incomplete. It doesn't explain what the tool returns, error conditions, or behavioral traits, leaving significant gaps for an AI agent to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents all three parameters. The description adds minimal value by noting the description is optional but doesn't provide additional meaning beyond what's in the schema, such as usage examples or constraints not covered.
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 zone'), specifying what the tool does. However, it doesn't differentiate from sibling tools like 'create_entities' or 'merge_zones', which also create resources, 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?
No guidance is provided on when to use this tool versus alternatives like 'merge_zones' or 'create_entities', nor any context on prerequisites or exclusions. The description only mentions optional parameters without 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, the description carries the full burden of behavioral disclosure. It mentions deletion but lacks details on permissions, irreversibility, side effects, or error handling. The parenthetical '(memory)' adds minimal context, leaving significant gaps 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 with zero waste. It's front-loaded with the core action 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?
For a destructive tool with no annotations and no output schema, the description is inadequate. It doesn't explain what 'delete' entails (e.g., permanent removal), return values, or error cases, leaving the agent with insufficient context for safe invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents all parameters. The description adds no additional meaning beyond what's in the schema, such as explaining 'memory_zone' or 'cascade_relations' in broader context. Baseline 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 ('Delete') and resource ('entities from knowledge graph (memory)'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'delete_relations' or 'delete_zone' beyond the resource type, 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?
No guidance is provided on when to use this tool versus alternatives like 'delete_relations' or 'delete_zone', nor does it mention prerequisites or constraints. The description only states what it does, not when it's appropriate.
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 provides minimal behavioral context. It states this is a deletion operation but doesn't mention whether deletions are permanent, reversible, require specific permissions, have side effects on connected entities, or provide confirmation of what was deleted. For a destructive operation 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 extremely concise at just 5 words plus a parenthetical clarification. Every element earns its place: 'Delete' specifies the action, 'relationships' specifies what's being deleted, 'from knowledge graph' provides context, and '(memory)' clarifies the domain. No wasted words 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 destructive operation with no annotations and no output schema, the description is inadequate. It doesn't explain what happens after deletion, whether there's confirmation, error conditions, or behavioral constraints. Given the complexity of graph operations and complete lack of structured safety information, more descriptive 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 fully documents both parameters. The description adds no additional parameter information beyond what's in the schema. The baseline score of 3 reflects adequate parameter documentation through the schema alone, with no value added by the description.
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 ('Delete') and target ('relationships from knowledge graph'), with parenthetical clarification that this refers to 'memory'. It distinguishes from siblings like 'delete_entities' by specifying relationship deletion rather than entity deletion. However, it doesn't explicitly contrast with 'delete_zone' or other deletion tools.
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. With siblings like 'delete_entities', 'delete_zone', and 'create_relations', there's no indication of when relationship deletion is appropriate versus entity deletion or zone deletion, or how this differs from other graph modification 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 the full burden of behavioral disclosure. It mentions AI-driven retrieval and token quota implications for 'include_lines', but doesn't cover critical aspects like whether this is a read-only operation, potential rate limits, authentication requirements, error handling, or what the response format looks like. The description adds some context but leaves significant gaps for a tool with 5 parameters.
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 clearly states the tool's purpose. It's appropriately sized and front-loaded with the core functionality. While it could potentially benefit from more detail given the tool's complexity, what's present is well-structured without wasted words.
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 complex AI-driven file inspection tool with 5 parameters and no output schema, the description is insufficiently complete. It doesn't explain what the tool returns, how results are structured, what 'relevant content' means operationally, or how the AI component works. With no annotations and no output schema, users need more guidance about the tool's behavior and outputs.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, 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 how parameters interact, provide examples, or clarify edge cases. With complete schema coverage, the baseline 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 tool's purpose as 'Agent driven file inspection that uses AI to retrieve relevant content from multiple files.' It specifies the verb ('inspect'), resource ('files'), and method ('uses AI to retrieve relevant content'). However, it doesn't explicitly differentiate from sibling tools like 'search_nodes' or 'inspect_knowledge_graph' which might 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. It doesn't mention sibling tools like 'search_nodes' or 'inspect_knowledge_graph' that might be relevant for similar tasks. The only implied usage is for AI-driven file content retrieval, but no explicit context or exclusions are provided.
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 that the tool 'uses AI to retrieve relevant entities and relations', implying intelligent filtering, but doesn't disclose critical behaviors such as rate limits, authentication requirements, error handling, or what 'retrieve' entails (e.g., pagination, format of results). For a query tool with 7 parameters and no output schema, 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, well-structured sentence that efficiently conveys the core purpose without redundancy. It uses clear language ('Agent driven knowledge graph inspection', 'uses AI', 'retrieve relevant entities and relations', 'based on a query') and avoids unnecessary details, making it easy to parse and understand quickly. Every word earns its place.
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 (7 parameters, no annotations, no output schema), the description is incomplete. It doesn't explain what the tool returns (e.g., structure of entities/relations, pagination), how the AI-driven retrieval works, or any limitations. Without annotations or output schema, the agent lacks sufficient context to understand the tool's full behavior and results, making this inadequate 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 the schema already documents all 7 parameters thoroughly. The description doesn't add any parameter-specific semantics beyond what's in the schema (e.g., it doesn't explain how 'information_needed' and 'keywords' interact or provide examples). With high schema coverage, the baseline score of 3 is appropriate, as the description doesn't compensate but also doesn't detract from the schema's 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: 'Agent driven knowledge graph inspection that uses AI to retrieve relevant entities and relations based on a query.' It specifies the verb ('retrieve'), resource ('entities and relations'), and mechanism ('based on a query'). However, it doesn't explicitly differentiate from sibling tools like 'search_nodes' or 'get_recent', which appear related to knowledge graph operations, leaving some ambiguity about when to choose this specific inspection tool.
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 any of the sibling tools (e.g., 'search_nodes', 'get_recent', 'open_nodes') that might overlap in functionality, nor does it specify prerequisites, exclusions, or typical use cases. The agent must infer usage from the purpose alone, which is insufficient for optimal tool selection.
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 'conflict resolution options', which hints at some complexity, but fails to describe critical behaviors such as whether the merge is destructive, what happens to data in source zones, permission requirements, or error handling. For a mutation tool with zero annotation coverage, this 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 action ('merge multiple zones') and adds a key qualifier ('with conflict resolution options'). There is no wasted verbiage or redundancy, 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?
Given the complexity of merging zones (a mutation operation) and the lack of annotations and output schema, the description is insufficient. It doesn't explain what 'zones' are, the merge semantics, potential side effects, or return values, leaving the agent with critical gaps in understanding how to use this tool effectively.
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 minimal value by implying that parameters relate to conflict resolution and merging, but doesn't provide additional context beyond what's in 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 action ('merge multiple zones') and mentions a key feature ('conflict resolution options'), which distinguishes it from sibling tools like 'create_zone' or 'delete_zone'. However, it doesn't specify what 'zones' are in this context or how the merge operation works at a high level, 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 like 'move_entities' or 'copy_entities', nor does it mention prerequisites or typical scenarios for merging zones. It lacks explicit when-to-use or when-not-to-use instructions, leaving the agent to infer usage from the tool 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 the full burden of behavioral disclosure. It reveals the 'copy + delete' implementation, which implies destructive action on the source. However, it doesn't address critical aspects like permissions needed, whether the operation is atomic/transactional, error handling, or what happens if the delete fails after copying. For a destructive operation 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 extremely concise (one sentence) and front-loaded with the core purpose. Every word earns its place—'move' specifies the action, 'entities' and 'zones' define the resources, and 'copy + delete from source' clarifies the implementation without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a destructive move operation with 5 parameters, no annotations, and no output schema, the description is incomplete. It lacks information about return values, error conditions, side effects, and how it differs from sibling tools. The agent would need to infer too much from the sparse description.
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 all parameters are documented in the schema itself. The description doesn't add any parameter-specific information beyond what's in the schema (like clarifying zone naming conventions or entity name formats). The baseline of 3 is appropriate when the schema handles parameter documentation adequately.
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 ('Move entities between zones') and specifies the implementation method ('copy + delete from source'), which distinguishes it from simple copy operations. However, it doesn't explicitly differentiate from sibling tools like 'copy_entities' or 'merge_zones' beyond the move semantics.
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 'copy_entities' (which might copy without deletion) or 'merge_zones' (which might handle zone consolidation differently). There's no mention of prerequisites, constraints, or typical use cases for moving versus other operations.
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 'Update' implying mutation but doesn't disclose behavioral traits like whether this overwrites or merges existing data, permission requirements, side effects, rate limits, or what happens on failure. For a mutation 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?
Extremely concise with a single, front-loaded sentence that wastes no words. The parenthetical '(memory)' adds brief clarification without redundancy. Every element earns its place efficiently.
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 complexity (mutation tool with 2 parameters, no annotations, no output schema), the description is incomplete. It lacks behavioral details, usage context, and output expectations, making it inadequate for safe and effective tool invocation by an AI agent.
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 implying the tool operates on 'entities' and uses 'memory_zone', which is already clear from the schema. Baseline 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 verb ('Update') and resource ('entities in knowledge graph') with parenthetical clarification ('memory'). It distinguishes from siblings like 'create_entities' (new creation) and 'delete_entities' (removal), but doesn't explicitly differentiate from 'move_entities' or 'mark_important' which might 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?
No guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., entities must exist), when to choose 'update_entities' over 'add_observations' or 'mark_important', or any constraints like memory zone requirements. The description provides only basic functional 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 the full burden of behavioral disclosure. It states the tool retrieves statistics but does not specify what types of statistics (e.g., counts, metrics), whether it's read-only, if it requires permissions, or any rate limits. 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, clear sentence that directly states the tool's purpose without any unnecessary words or fluff. It is front-loaded and efficiently conveys the core functionality, 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?
Given the complexity of statistical tools and the lack of annotations and output schema, the description is insufficient. It does not explain what statistics are returned, their format, or any behavioral nuances, making it incomplete for effective agent use without additional context.
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 'zone' parameter clearly documented as 'Zone name (omit for default zone)'. The description adds no additional parameter semantics beyond this, so it meets the baseline of 3 for adequate but not enhanced parameter 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 action ('Get statistics') and target ('for entities and relationships in a zone'), which is specific and actionable. However, it does not explicitly differentiate this tool from siblings like 'inspect_knowledge_graph' or 'get_recent', which might also provide statistical or summary information, leaving room for ambiguity in 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. It lacks context such as prerequisites, typical use cases, or comparisons to siblings like 'inspect_knowledge_graph' or 'list_zones', leaving the agent without clear usage instructions.
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 retrieving 'recently accessed entities' but doesn't specify what 'recent' means (e.g., time window, access count), whether results are sorted, or if there are rate limits or permissions required. This leaves significant gaps for a tool that interacts with a knowledge graph.
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. It directly communicates the tool's function, making it easy to parse and understand 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's moderate complexity (3 parameters, no output schema, no annotations), the description is minimal but covers the basic purpose. However, it lacks details on behavioral aspects like recency definition, sorting, or error handling, which are important for a knowledge graph query tool. The absence of an output schema increases the need for more context, but the description doesn't compensate adequately.
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 the three parameters (includeObservations, limit, memory_zone) with clear descriptions. The description adds no additional parameter semantics beyond what's in the schema, resulting in a baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the resource 'recently accessed entities from knowledge graph (memory) and their relations', which is specific and actionable. However, it doesn't explicitly distinguish this tool from sibling tools like 'search_nodes' or 'inspect_knowledge_graph', which might also retrieve graph data, 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. For example, it doesn't explain how 'get_recent' differs from 'search_nodes' or 'inspect_knowledge_graph' in terms of recency filtering or scope, 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 the full burden of behavioral disclosure. It mentions the effect on relevance scores (multiply/divide by 10) and implies mutation ('mark'), but doesn't cover permissions, rate limits, side effects (e.g., impact on other entities), or response format. For a mutation tool with zero annotation coverage, this leaves significant gaps in understanding how it behaves.
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 ('mark entity as important') and includes key behavioral detail ('boosting its relevance score'). There is zero waste or redundancy, 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 no annotations, no output schema, and a mutation tool with 4 parameters, the description is minimally adequate. It covers the purpose and basic effect but lacks details on usage context, behavioral traits, and return values. The high schema coverage helps, but for a tool that modifies data, more guidance 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?
Schema description coverage is 100%, so the schema already documents all parameters thoroughly. The description adds no parameter-specific information beyond what's in the schema (e.g., it doesn't explain 'memory_zone' or 'auto_create' further). Baseline 3 is appropriate when the schema does the heavy lifting, though no extra value is added.
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 ('mark') and resource ('entity in knowledge graph') with the specific action of 'boosting its relevance score'. It distinguishes from siblings like 'create_entities' or 'update_entities' by focusing on importance marking rather than creation or general updates. However, it doesn't explicitly differentiate from all siblings like 'merge_zones' or 'move_entities' in terms of scope.
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 'update_entities' (which might handle importance) or 'create_entities' (with auto_create parameter). It mentions the effect on relevance scores but doesn't specify use cases, prerequisites, or exclusions, leaving the agent to infer 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 of behavioral disclosure. It states the tool retrieves details about entities and relations, implying a read-only operation, but doesn't mention permissions, rate limits, error handling, or what 'details' include (e.g., properties, metadata). For a tool with zero annotation coverage, this is a significant gap in 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 a single, efficient sentence that front-loads the core purpose ('Get details about specific entities...'). There is no wasted text, and it directly communicates the tool's function without unnecessary elaboration.
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 moderate complexity (2 required parameters, no output schema, no annotations), the description is minimally adequate. It covers the basic purpose but lacks details on behavior, output format, or differentiation from siblings. With no output schema, it should ideally hint at return values, but the concise purpose statement meets a bare-minimum threshold.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both parameters ('names' and 'memory_zone') with clear descriptions. The description adds no additional meaning beyond what the schema provides, such as examples or edge cases, but the high schema coverage justifies the baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Get details') and resource ('specific entities in knowledge graph (memory) and their relations'), making the purpose understandable. However, it doesn't explicitly distinguish this tool from sibling tools like 'search_nodes' or 'get_recent', which might have overlapping functionality for retrieving graph 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 no guidance on when to use this tool versus alternatives like 'search_nodes' (which might search broadly) or 'get_recent' (which might retrieve recent entities). It lacks explicit when/when-not instructions or named alternatives, leaving usage context implied at best.
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 tool deletes a zone and all its entities/relations, which implies a destructive, irreversible operation. However, it lacks details on permissions needed, error handling (e.g., if the zone doesn't exist), side effects, or confirmation requirements beyond the 'confirm' parameter. The description adds minimal behavioral context beyond the basic action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's action and scope. It is front-loaded with the core purpose ('Delete a memory zone') and adds necessary detail ('and all its entities/relations') without redundancy. Every word earns its place, 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's destructive nature and lack of annotations or output schema, the description is minimally complete. It covers what the tool does but omits critical context like irreversible consequences, prerequisites, or error scenarios. For a deletion tool with no safety annotations, more guidance would be helpful, but the description meets a basic threshold.
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 100%, so the schema fully documents both parameters ('name' and 'confirm'). The description adds no additional parameter semantics, but with high schema coverage, the baseline is 3. Since there are only 2 parameters and the schema is comprehensive, a score of 4 reflects that the description doesn't need to compensate and the tool's purpose is straightforward.
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 ('Delete') and resource ('a memory zone and all its entities/relations'), making the purpose specific and unambiguous. It distinguishes from sibling tools like 'delete_entities' and 'delete_relations' by specifying that it deletes the entire zone along with its contents, not just individual components.
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 prerequisites (e.g., whether the zone must exist or be empty), exclusions (e.g., cannot delete the 'default' zone, though this is hinted in the schema), or comparisons to siblings like 'merge_zones' or 'list_zones' for verification. Usage context is implied but not explicit.
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 lists zones with metadata and can filter/prioritize based on a reason, which adds context beyond basic listing. However, it lacks details on behavioral traits such as pagination, rate limits, authentication needs, or what happens if no zones exist. The description doesn't contradict any annotations (since none exist).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core purpose and followed by an explanation of the optional parameter's effect. Every sentence earns its place by adding useful information without redundancy or fluff, making it efficient 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's low complexity (1 optional parameter, no output schema, no annotations), the description is somewhat complete but has gaps. It covers the purpose and parameter usage but lacks details on output format, error handling, or how metadata is structured. For a list tool with no output schema, more information on 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 1 parameter with 100% description coverage, providing a clear explanation of the 'reason' parameter. The description adds value by explaining that the reason is used to 'filter and prioritize relevant zones,' which gives semantic context beyond the schema's description. However, it doesn't elaborate on how filtering or prioritization works, keeping the baseline at 3 due to 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 tool's purpose: 'List all available memory zones with metadata.' It specifies the verb ('List') and resource ('memory zones'), and mentions metadata inclusion. However, it doesn't explicitly differentiate from sibling tools like 'zone_stats' or 'search_nodes' in terms of scope or output format.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by stating that zones can be filtered and prioritized when a reason is provided, suggesting this tool is for retrieving zones with optional relevance-based filtering. However, it doesn't explicitly state when to use this tool versus alternatives like 'search_nodes' or 'zone_stats', nor does it provide exclusions 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.
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 effectively describes the search syntax and zone isolation, but misses key behavioral traits: it doesn't mention whether this is a read-only operation (implied but not stated), potential rate limits, error handling, or the format of results (especially since there's no output schema). The syntax examples are helpful but not comprehensive for 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 appropriately sized and front-loaded with the core purpose and syntax details. Every sentence adds value: the first states the action and syntax, the second lists supported operators, the third gives examples, and the fourth mentions zone isolation. There's no wasted text, though it could be slightly more structured (e.g., bullet points for operators).
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 (8 parameters, 4 required, no annotations, no output schema), the description is incomplete. It covers the search syntax and zone isolation well, but lacks details on result format, pagination, error cases, or performance considerations. Without an output schema, the description should ideally hint at what to expect (e.g., 'returns a list of matching entities'), but it doesn't, leaving gaps for the agent.
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 8 parameters thoroughly. The description adds no parameter-specific information beyond what's in the schema (e.g., it doesn't clarify 'query' beyond stating it uses ElasticSearch syntax, which the schema already notes). Thus, it meets the baseline of 3 without adding extra semantic value.
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 ('Search entities using ElasticSearch query syntax') and resource ('entities'), distinguishing it from sibling tools like 'get_recent' (which likely retrieves recent items without search) or 'open_nodes' (which might open specific nodes). The mention of 'zone isolation' further differentiates it from tools like 'list_zones' or 'zone_stats'.
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 (searching entities with ElasticSearch syntax) and implies when not to use it (e.g., for non-search operations like creating or deleting entities, covered by sibling tools). However, it lacks explicit alternatives (e.g., 'get_recent' for recent items without querying) or exclusions (e.g., when to use 'inspect_knowledge_graph' instead).
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 the output format, which is a key behavioral trait. However, it does not mention other aspects like whether it's a read-only operation, if it has side effects, or any rate limits. The description is accurate but lacks comprehensive behavioral details.
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, clear sentence that directly states the tool's purpose and output format without any unnecessary words. It is front-loaded and efficiently conveys all necessary information in minimal text.
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 low complexity (no parameters, simple time retrieval) and lack of annotations or output schema, the description is complete enough for basic use. It specifies the exact format, which is crucial. However, it could be more complete by mentioning that it returns a string or any potential errors, but for this simple tool, it is largely adequate.
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% (as there are no parameters to describe). The description does not need to add parameter semantics, so it meets the baseline of 4 for tools with no parameters, as per the rules.
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 ('Get') and resource ('current UTC time'), including the exact format ('YYYY-MM-DD hh:mm:ss'). It distinguishes itself from all sibling tools, which involve entity manipulation, file inspection, or zone operations, by being the only time-retrieval tool.
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 implies usage context (when you need the current UTC time in a specific format), but does not explicitly state when not to use it or name alternatives. Given the sibling tools are unrelated (e.g., 'add_observations', 'create_entities'), the distinction is clear by purpose, but no explicit guidance on alternatives is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

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

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

Card Badge

Copy to your README.md:

[![mcp-brain-tools MCP server](https://glama.ai/mcp/servers/j3k0/mcp-brain-tools/badges/card.svg)](https://glama.ai/mcp/servers/j3k0/mcp-brain-tools)

Score Badge

Copy to your README.md:

[![mcp-brain-tools MCP server](https://glama.ai/mcp/servers/j3k0/mcp-brain-tools/badges/score.svg)](https://glama.ai/mcp/servers/j3k0/mcp-brain-tools)

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/j3k0/mcp-brain-tools'

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