aion-mcp

by draygen

Overview Schema Related Servers Score Discussions

TypeScript

Local

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation2/5
Several tools have overlapping purposes, notably memory_get_facts and aion_memory_browse both retrieve facts with category filters, and multiple query tools (aion_query, aion_api_chat, ollama_query, openai_query) send prompts to different backends but could confuse an agent. Most other tools are distinct, but this ambiguity is significant.
Naming Consistency3/5
Tool names generally follow a [domain]_[action] pattern with snake_case, but there are inconsistencies: memory_get_facts vs aion_memory_browse, aion_admin_profile_rebuild vs aion_admin_users, and some names are nouns (system_status) while others are verbs (fleet_run). The prefixes help but the pattern isn't uniform.
Tool Count2/5
45 tools is far above the typical 3-15 range, making the server unwieldy. While it covers many subdomains, the tool count is excessive and would benefit from splitting into focused servers.
Completeness3/5
The server covers a broad range of operations for AION memory, conversations, system health, and various services, but there are notable gaps such as no memory update, no conversation delete, and limited SonChat operations beyond invites. Core workflows are present, but the surface is uneven.
Average 3.9/5 across 45 of 45 tools scored. Lowest: 3.1/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 4 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 the full burden. It does disclose the return type ('port/service info') and the execution environment, but omits potential behavioral aspects like scan duration, network impact, permission requirements, or side effects. It doesn't state whether the scan is safe or read-only beyond the implicit nature of nmap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, concise sentence that is front-loaded with the verb and resource, and includes the return type. No redundant information or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter tool with no output schema, the description is minimally sufficient to understand the operation. It tells what it does and what it returns, but lacks usage context, limitations, or examples. It would benefit from mentioning that flags are optional and how they affect behavior, but the schema already documents flags.
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 covers both parameters with descriptions ('target' and 'flags'), giving 100% coverage. The description adds no extra meaning beyond the schema, so the baseline of 3 applies.
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?
Description clearly states the specific action: 'Run an nmap scan inside the Kali Docker container on Draydev' and mentions the output type ('port/service info'). It is a specific verb+resource, though it doesn't explicitly distinguish from sibling tools like kali_web_scan or kali_dir_enum beyond the nmap reference.
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 such as kali_web_scan or kali_dir_enum. It doesn't mention prerequisites, scope limitations, or when not to use nmap. The description provides no exclusions or alternatives.
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 disclosure. It mentions the admin token requirement but does not disclose potential side effects (e.g., network traffic, scanning behavior), output handling, or whether the operation is reversible. This is a security-sensitive arbitrary command execution tool, so the lack of behavioral detail 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 two concise sentences, front-loaded with the main action and followed by the key prerequisite. There is no redundant phrasing or unnecessary detail.
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?
This is an arbitrary command execution tool with no output schema, yet the description is extremely sparse. It does not explain the return format, execution behavior, timeouts, error modes, or any limitations. The presence of many similar sibling tools makes this incompleteness more problematic, as the agent cannot confidently predict the tool's full 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 coverage is 100% with clear parameter descriptions for both 'command' and 'target'. The description adds minor context (mentions nmap/nikto) but does not substantially enhance understanding beyond the schema, so the baseline of 3 is appropriate.
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 a verb ('Run') and a resource ('network intelligence command via Aion's admin panel'), and the Aion admin panel context distinguishes it from sibling tools like kali_exec. The examples (nmap, nikto) further clarify the tool's 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?
No guidance is provided on when to use this tool versus alternatives; the only additional information is a prerequisite (admin token). There is no comparison to siblings or indication of preferred use cases, so the agent is left without clear selection criteria.
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 discloses the core action (Nikto scan) but does not mention potential side effects like network intrusion, expected runtime, dependencies on the Kali container being running, or output format. This is minimal information for a security scanning 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 concise sentence that front-loads the action and target. Every word adds meaning; there is no filler or redundant content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter tool with complete schema coverage, the description is minimally viable. However, it lacks operational context such as scan duration, whether the target must be reachable, or what the output represents. As a security scan tool, a bit more context 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 schema description covers the only param 'url' fully with an example, so schema coverage is 100%. The tool description adds no additional parameter semantics beyond restating that a URL is the target. Baseline 3 is appropriate since the schema handles the parameter documentation.
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 a specific verb ('Run') and a specific resource ('Nikto web vulnerability scan against a URL using the Kali container'). This distinguishes it from sibling tools like kali_nmap or kali_dir_enum, which target different scanning activities.
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, exclusions, or when another Kali tool would be more appropriate. The only implied context is that it is for Nikto scanning.
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 present, so the description must carry the burden of disclosing behavioral traits. It only restates the function without mentioning that this is a network-querying operation, whether it is read-only, or what output format to expect. This leaves the agent without important safety or performance 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, clear, and efficient sentence. It states the core action and target without any repetitive or extraneous language, making it easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool, the description adequately states the function, but it lacks behavioral notes, usage context, or output expectations. Given the absence of annotations and an output schema, a bit more detail would help the agent understand what to expect from the tool.
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 already fully describes the sole parameter 'target' as 'Domain or IP to look up', providing 100% coverage. The description adds no additional semantic detail beyond repeating the target type, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Run a whois lookup') and the target ('domain or IP address'), with the scope ('via Kali'). This distinguishes it from sibling tools like kali_nmap and kali_web_scan, which serve different security-scanning purposes.
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 use cases, prerequisites, or exclusions. For example, an agent is not told whether this is appropriate for passive reconnaissance or if other Kali tools should be preferred for active scanning.
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 discloses the admin key requirement, which is useful, but does not specify side effects (e.g., that it creates a persistent invite), return value, or whether it can revoke existing invites. The description is largely an action statement.
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 sentence with two clauses, front-loaded with the action and followed by the auth requirement. Every word earns its place, with no fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with only 3 parameters and a comprehensive schema, but the description omits the return value (the invite token/link) and any relationship to sibling tools (e.g., that the invite appears in sonchat_invites). Given no annotations and no output schema, this is a notable gap, but the core function is clear.
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 each parameter (label, max_uses, expires_in_days) described including defaults and optionality. The description itself adds no parameter semantics, but the schema already covers them, so this is at baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Create' and names the resource 'SonChat invite token/link', clearly distinguishing it from siblings like sonchat_invites (listing) and sonchat_revoke_invite (revocation). It also includes a required auth note, adding 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 explicit guidance is given on when to use this tool versus alternatives. The auth requirement hints at appropriate conditions, but there are no when-to-use or when-not-to-use statements, and no mention of sibling tools like sonchat_revoke_invite.
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 discloses an authentication requirement, but omits behavioral details such as whether the deployment is asynchronous, what happens on success/failure, cost implications, or how to verify the new instance. This is a significant gap for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence with no wasted words. It front-loads the core purpose and includes the critical prerequisite 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?
As a deployment tool with no output schema and no annotations, the description should provide more context—such as how to obtain an offer_id, what happens after deployment, and how to monitor the instance. The current description only covers the action and authentication, leaving users under-informed for a consequential operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both 'image' and 'offer_id' already described in the input schema. The tool description adds no parameter-level information beyond what the schema provides, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Deploy a new Vast.ai GPU instance') with a specific verb and resource. It distinguishes itself from sibling tools like aion_vast_instances (list) and aion_vast_stop (stop) by focusing on deployment.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool (to deploy an instance) and includes a prerequisite (AION_SESSION_TOKEN with vast/admin access), but it does not explicitly mention alternatives or when not to use it. With multiple Vast-related siblings, a brief note directing users to aion_vast_offers for finding offers would improve guidance.
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 the auth requirement (AION_SESSION_TOKEN), which is useful. However, it does not clarify what 'active users' means, whether the result is a list or count, or any potential side effects or limitations.
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 succinct sentences, immediately stating the action and the key requirement. Every word earns its place with no unnecessary detail.
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 simple one-parameter nature of the tool, the description is functionally adequate. However, with no output schema, it lacks information about the return format or semantics of 'active users', which could leave the agent uncertain about how to interpret the result.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with the 'channel' parameter described as 'Channel name'. The description reinforces this with 'specific Aion channel' but adds no additional meaning beyond the schema.
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 active users in a specific Aion channel.' This is a precise verb+resource combination that distinguishes it from sibling tools like aion_channel_history (message history) and aion_channels (list channels).
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 only mentions a prerequisite (AION_SESSION_TOKEN), but does not specify scenarios for selecting this tool or exclude cases where another tool would be more 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 responsibility for behavioral disclosure. It mentions the admin requirement and the re-summarising action, but does not disclose potential side effects, whether existing cached data is overwritten, if the operation is asynchronous, or whether it returns a result.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences, with the primary action front-loaded and a necessary prerequisite in the second sentence. Every word adds value with no repetition or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple zero-parameter tool with no output schema, the description is reasonably complete: it explains what happens (rebuild/re-summarise) and the access condition. However, it could usefully note that the rebuild overwrites the existing profile or whether a confirmation is returned, but the core intent is clear.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline score is 4 per the rubric. The description adds no parameter-specific information, but none is needed given the empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb ('Trigger a rebuild') and a specific resource ('Aion's cached system prompt profile'). It also explains the underlying action ('re-summarises facts with GPT-4o'), which distinguishes it from sibling read/profile 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?
The description does not provide explicit usage guidelines such as when to use this tool versus alternatives, nor does it mention any exclusions or alternative tools. The only stipulation is an admin session requirement, which is a prerequisite rather than a usage scenario.
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 what is returned (titles, tool types, summaries) but does not state whether the operation is read-only, how 'recent' is defined, or any side effects. For a simple list tool this is minimal, and it does not disclose ordering or pagination behavior beyond the schema's limit parameter.
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, front-loaded sentence that efficiently states the purpose and key output details. There is no redundancy or fluff, and every word contributes to understanding the tool's function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a straightforward list tool with two optional parameters and no output schema, the description provides sufficient context: it specifies the resource, the recency qualifier, and the output contents. It could elaborate on the return structure or edge cases, but given the low complexity and schema coverage, it is nearly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both parameters (tool and limit) already documented in the schema. The description adds no extra semantic meaning about the parameters; the mention of tool types in the output is tangential to the tool filter parameter. Baseline of 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'List' and identifies the resource 'recent AION conversations', with concrete output details (titles, tool types, auto-generated summaries). This clearly distinguishes it from siblings like conversation_get (which likely retrieves one) and conversation_search (which likely searches).
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 states what the tool does, implying it's for listing recent conversations, but provides no explicit guidance on when to use it over alternatives like conversation_search or conversation_get. There are no exclusions or named alternatives, so the usage context is only implicitly derived from the tool's 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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions using gobuster with the common wordlist, but does not explain what the tool actually does (e.g., sends HTTP requests), what the output looks like, or potential side effects such as being intrusive. This is a significant gap for a security scanning 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 one short sentence that is front-loaded with the action and purpose. Every word contributes to meaning, with no filler or repetition.
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?
With no output schema and no annotations, the description must explain what the tool returns or how results are presented. It does not do this. The tool is relatively simple, but the absence of return-value information and behavioral caveats makes it incomplete for an 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 coverage is 100%, with both url and wordlist described in the input schema. The description adds minimal value by mentioning 'common wordlist', which is already reflected in the schema's default. Therefore, the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool enumerates directories/files on a web server using gobuster, which is a specific verb+resource. This distinguishes it from sibling tools like kali_nmap (network scanning) and kali_web_scan (broader web scanning).
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 conveys a clear context: use this when you need to enumerate directories/files on a web server. It does not explicitly list alternatives or when-not-to-use, but the context is unambiguous enough for an agent to select it appropriately.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the burden of behavioral disclosure. It explains what facts are and that filtering is possible, but it does not describe the return format, pagination behavior, or handling of limits/errors, leaving significant behavioral traits undisclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences front-load the core purpose and provide a compact list of fact categories. Every word earns its place with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with two optional parameters and full schema coverage, the description provides sufficient context about fact types and filtering. The absence of an output schema is offset by the straightforward nature of the tool, though it could mention default behavior more explicitly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds minimal value beyond the schema, mainly reinforcing that category filtering is optional. The category list in the description mirrors the enum, but does not deepen 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 tool retrieves user facts from long-term memory, listing specific examples of fact types. It does not explicitly differentiate from sibling tools like memory_search, so it falls short of a 5.
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 this is the tool for fetching stored facts and mentions optional category filtering, but it does not provide explicit when-to-use or when-not-to-use guidance compared to sibling tools like memory_search or memory_get_context.
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 burden. It adds the requirement for AION_SESSION_TOKEN and lists valid categories. However, it doesn't disclose the return format or behavior when no category is specified, which leaves gaps for a browse 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?
Two sentences (plus category list) efficiently convey purpose, auth requirement, and valid inputs. No waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple 1-param read tool, the description covers purpose, auth, and category options. It doesn't describe the return payload, but with no output schema, a brief statement about returned facts would improve completeness; still, it's mostly 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 schema already documents 'category' as an optional filter, so baseline is 3. The description adds enumerated category values (preferences, family, work, etc.), giving semantics beyond the schema's generic 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?
Description states 'Browse Aion's fact memory' with a clear verb and resource, and mentions optional category filtering. It doesn't explicitly distinguish from sibling memory_get_facts, but the purpose is unambiguous.
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?
Usage is implied (to browse facts, use this tool) and it mentions the auth prerequisite, but no explicit guidance on when to choose this over sibling memory tools like memory_search or memory_get_facts.
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 present, so the description carries the full burden of behavioral disclosure. While it notes the required token, it does not disclose whether the stop action is reversible, what happens to the instance's billing/resources, or what kind of response the agent can expect. For a state-changing operation, this is a notable 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, compact sentence that conveys both the action and the authorization requirement. There is no redundant information or unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool, the description is functional but incomplete. There is no output schema, so the description should clarify what happens after a successful stop (e.g., whether it is synchronous, idempotent, or affects billing). The absence of this information leaves the agent with uncertainties.
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 already provides a complete description for the sole parameter (instance_id: 'Vast.ai instance ID to stop') with 100% coverage. The tool description adds no extra semantics beyond the action itself, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'stop' and names the resource 'Vast.ai GPU instance', which clearly distinguishes it from sibling tools like aion_vast_deploy and aion_vast_instances. The action and scope are unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use the tool: to stop a running Vast.ai instance. It also states an important prerequisite (AION_SESSION_TOKEN with vast/admin access). It does not explicitly mention alternatives or exclusions, but for a simple lifecycle operation the context is sufficient.
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. For a tool that executes arbitrary shell commands, it fails to mention safety implications, environment specifics, whether the container is ephemeral, or what the output/return behavior is. The description only states the environment (Kali Docker container) without addressing the potentially destructive nature of running arbitrary commands.
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 exceptionally concise: two sentences with no redundant words. The first sentence states the action and target, the second provides usage guidance. Every word earns its place, and the structure is well front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has one parameter and no output schema, so the description is reasonably complete for a straightforward execution tool. However, it omits any mention of what the command's output looks like or whether it returns results, which is a meaningful gap for a shell execution tool. The behavioral transparency deficit also affects 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%, with the single 'command' parameter already having a clear description and example. The tool description itself adds no additional parameter semantics beyond what the schema provides, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool runs an arbitrary shell command inside the Kali Docker container on Draydev, which is a specific verb+resource combination. It also distinguishes itself from sibling tools by explicitly saying 'Use for tools not covered by other kali_* tools', making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives a clear usage guideline: use it for tools not covered by other kali_* tools, implying that specialized sibling tools should be preferred when they apply. It doesn't explicitly state exclusions for specific tools, but the context of sibling tools like kali_nmap and kali_web_scan makes the intended use clear.
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 burden. It discloses the token requirement and the 'Get' (read) nature, but does not mention rate limits, side effects, or pagination behavior. Minimal but some useful context is added.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with purpose and examples, followed by the auth requirement. No filler or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-parameter list tool, the description adequately covers purpose, event types, and auth. The word 'recent' implies temporal ordering. It does not describe output format, but the absence of an output schema reduces the need for that.
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 covers 100% of the single parameter 'limit' with a description (default: 50). The description adds no additional parameter details, so the baseline of 3 is appropriate.
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 'Get', the resource 'Aion', and the scope 'audit/activity events' with concrete examples (joins, messages, logins). This distinguishes it from sibling tools like sonchat_activity by specifying 'from Aion' and the audit/activity focus.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when needing recent Aion activity events and notes the AION_SESSION_TOKEN requirement, but does not explicitly contrast with alternatives such as aion_channel_history or aion_query. No clear when-not-to-use guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full transparency burden. It discloses the API endpoint (port 3003), the injection of full memory context, and the automatic fallback to a direct Ollama query without memory if offline. This is valuable behavioral context, though it does not describe the exact response format.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the primary action and followed by the fallback behavior. Every sentence adds necessary information with no redundancy or irrelevant details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool without an output schema, the description covers the essential context: what it does, the memory injection, and the fallback. It does not detail the response structure beyond the memory hint, but given the simplicity, it is reasonably complete. A brief note on response format would elevate it.
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 already fully describes the single 'message' parameter. The description's phrase 'send a message' reiterates the schema but adds no additional parameter constraints or formatting details. Since schema coverage is 100%, 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 sends a message to AION via its public REST API on port 3003, with specific mention of memory context injection. It does not explicitly differentiate from sibling tools like aion_api_chat or ollama_query, but the fallback behavior and memory context provide implicit distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when one desires AION with memory context and mentions automatic fallback if offline. However, it does not explicitly state when to use this tool instead of alternatives like ollama_query, nor does it provide exclusions or prerequisites. Usage context is present but not fully 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?
With no annotations, the description carries the burden of behavioral disclosure. It does disclose that the response includes the full history of all user and assistant turns, which is helpful. However, it does not mention read-only semantics, potential ordering, pagination, or error behavior for invalid IDs. This is adequate but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that is front-loaded with the primary action and includes relevant scope details. No wasted words or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple retrieval tool with one parameter and no output schema, the description provides sufficient context: it states exactly what the tool returns (full message history with all user and assistant turns). It lacks detail on return format or pagination, but given the low complexity, the completeness is good.
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 for conversation_id is 100% descriptive ('The integer ID of the conversation (from conversation_list)'), so the schema already carries the meaning. The tool description adds no additional parameter semantics beyond reinforcing the 'specific conversation' aspect. Baseline 3 is appropriate.
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 'Get', the resource 'full message history of a specific AION conversation', and the scope 'including all user and assistant turns.' This distinguishes it from sibling tools like conversation_list (which lists conversations) and conversation_search (which searches conversations).
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 after obtaining a conversation_id, but it does not explicitly mention when to use this tool versus alternatives. It lacks exclusions or references to sibling tools such as conversation_list for obtaining IDs. The context is clear but not fully 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?
With no annotations provided, the description must convey safety and behavior. It does disclose that search targets titles and summaries, adding useful context beyond just 'search'. However, it lacks details about result ordering, matching behavior, or the return format, limiting 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 concise sentence that front-loads the action and target. Every word earns its place, and there is no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple search tool with full schema coverage and no output schema, the description provides adequate context. It clearly states the search scope and parameter semantics are covered. The only minor gap is absence of result format details, but this is not critical for a straightforward search.
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 already fully describes both parameters with 100% coverage (query and limit). The description adds no new param semantics beyond what the schema provides, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb ('Search') and resource ('AION conversation titles and summaries') and indicates the search is by keyword. This distinguishes it from sibling tools like conversation_list (listing) and conversation_get (single retrieval).
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 for searching conversation content, but it does not explicitly state when to use this tool over alternatives like memory_search or conversation_list. No exclusions or alternative guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It uses 'Get' which implies a read-only operation, but does not explicitly state safety, permissions, return format, or behavior on invalid categories. The reference to 'AION's Jenn memory database' adds some context, but overall transparency is basic.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the main purpose and includes the optional filter. Every word earns its place, with no redundancy or unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple: one optional parameter, no output schema. The description tells the agent what the tool does and how to filter. It lacks information about return structure, but given the simplicity, the description is adequate. No annotations exist to supplement, so this is complete enough for a basic retrieval tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with the category parameter fully described in the schema. The description repeats the category list ('biography, relationship, family, interests, life_events') without adding new meaning beyond the schema. While 'Optionally filter' clarifies optionality, the schema already indicates it is not required.
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 function: 'Get memories about Jenn from AION's Jenn memory database.' This is a specific verb+resource pair. It does not explicitly differentiate from sibling tools like memory_get_facts or memory_search, but the focus on 'Jenn' and 'memories' makes the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use the tool: to retrieve memories about Jenn. It does not explicitly mention alternatives or when not to use it, but the specificity of 'Jenn memory database' implies the appropriate use case. No exclusions or alternative recommendations are given.
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 burden. It discloses the required admin key and the type of events returned, implying a read-only operation. However, it does not mention behaviors like pagination, error responses, or whether the operation has side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences, front-loaded with the core action, and contains no filler or repetition. Every phrase adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one optional parameter, the description covers the essential context: what it does, what events it includes, and the auth requirement. The absence of return format details is a minor gap, but the tool's simplicity makes the description largely sufficient.
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 covers the single 'limit' parameter fully, including default and max values. The description adds no additional parameter detail, so it neither enhances nor detracts from the schema's semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Get SonChat activity log' with specific event types 'join/leave/message events.' This distinguishes it from sibling tools like sonchat_health and sonchat_invites, which serve different purposes.
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 notes the required SONCHAT_ADMIN_KEY, giving a clear precondition for use. However, it does not explicitly say when to choose this tool over alternatives or provide exclusions compared to sibling tools like sonchat_health or conversation_list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the destructive nature (revoke/delete) and admin key requirement, but does not explain idempotency or behavior with invalid tokens.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, zero waste. Action is front-loaded and the prerequisite is clearly stated.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter mutation tool, it covers purpose, prerequisite, and parameter. Does not explain return values or error cases, but acceptable given the tool's simplicity.
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%, and the token parameter is self-explanatory. The description adds minimal extra meaning beyond the schema.
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?
Clearly states the specific action (revoke/delete) and resource (SonChat invite token). Distinguishes from siblings like sonchat_create_invite and sonchat_invites.
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?
Indicates a prerequisite (requires admin key) but does not explicitly compare to alternatives or state when to use it vs other invite tools. Usage is implied by the tool's purpose and name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It states the admin key requirement, which is a useful authentication context, and 'List' implies a read-only operation. However, it does not describe the return format, error behaviors, or any rate limits, leaving gaps for an 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, front-loaded sentence that conveys the tool's purpose and a key requirement without any filler. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with no output schema, the description provides the core purpose and a prerequisite, but it lacks detail about what the response includes (e.g., token format, metadata) or any edge cases. It is minimally sufficient but not fully comprehensive.
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 input schema is empty (0 parameters), so the baseline is 4. The description adds no parameter details because there are none to describe, which is acceptable and consistent.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'List all active invite tokens for SonChat.' It uses a specific verb ('List') and resource ('active invite tokens'), and the scope ('for SonChat') distinguishes it from sibling tools like sonchat_create_invite and sonchat_revoke_invite.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool (when needing to list invite tokens) and notes a prerequisite (requires SONCHAT_ADMIN_KEY), but it does not explicitly name alternatives or exclusions. The usage context is clear but not fully 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?
With no annotations, the description carries the behavioral burden. It discloses auth, endpoint, and that the response includes full memory context, but it does not state side effects (e.g., whether messages are stored), error behavior, or return structure. More detail would improve transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the action and endpoint, and every clause adds value. No redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers endpoint, auth, and response context, which is substantial for a simple two-parameter tool. Since there is no output schema, a note on return format would be helpful, but the current information is sufficient for selection and basic 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%, and both parameters (message, channel) have descriptions. The tool description adds no additional parameter meaning beyond what the schema already provides, so a baseline score is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool sends a message to Aion via a specific endpoint (/api/service/chat), identifies the auth mechanism, and clarifies that no user session is required. This distinguishes it from sibling tools like aion_query by exposing its service-level scope and response behavior.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context for when to use the tool: it uses AION_SERVICE_TOKEN and requires no user session, implying service-to-service scenarios. However, it does not explicitly mention alternatives or when not to use it, leaving a small gap.
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 an authentication requirement (AION_SESSION_TOKEN), which is useful behavioral context. However, it does not mention the read-only nature (though implied), error conditions, or pagination behavior, leaving room for more transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences: the first states the core purpose, the second notes the authentication requirement. It is front-loaded, concise, and every word contributes value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with two parameters and no output schema, the description adequately covers the essential context: what it does and what is required. It does not over-explain, but for the tool's simplicity, it is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the schema descriptions already explain both parameters (channel name and limit with default). The description adds no additional parameter-specific meaning, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (fetch message history) and the specific resource (a specific Aion channel), which distinguishes it from sibling tools like aion_channels (listing channels) and aion_activity. The verb and scope are precise and unambiguous.
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 (retrieving message history for a single channel) and includes a prerequisite (requires AION_SESSION_TOKEN). However, it does not explicitly name alternatives or exclusion criteria, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. 'Browse' implies a read-only, safe operation, and the auth requirement is disclosed. However, it does not describe return value format, pagination, or any side effects beyond browsing, leaving some behavioral ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description consists of two short sentences that immediately state the purpose and the key prerequisite. There is no fluff or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple browse tool with one optional parameter and no output schema, the description provides the core purpose and access requirements. It does not describe the response format, but given the low complexity, this is acceptable. Slightly more detail on output would make it complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description for max_price is fully self-explanatory: 'Max price per hour in USD (optional filter).' The tool description adds no extra parameter context, but schema coverage is 100%, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Browse available Vast.ai GPU offers.' This is a specific verb and resource, and it distinguishes itself from sibling tools like aion_vast_deploy or aion_vast_instances by focusing on discovery rather than deployment 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides clear context by stating the requirement: 'Requires AION_SESSION_TOKEN with vast/admin access.' This tells the agent when it can be used (with proper authorization) but does not explicitly mention when not to use it or offer alternative 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?
No annotations are provided, so the description must carry the behavioral disclosure burden. It reveals the check scope (headless/authenticated on each machine) and implies a read-only nature via 'Health-check', but it does not explicitly state that it makes no changes, whether it performs network calls, or how it handles unreachable machines. It could be more transparent about side effects or failure modes.
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, focused sentence that front-loads the core action and resource. It avoids redundant phrasing and includes necessary detail about the check scope and optional filters, with no wasted words.
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 simplicity (2 optional parameters, no nested objects, no output schema), the description covers the essential purpose and usage. It lacks details about return format or error behavior, but for a status-checking tool, the core functionality is adequately conveyed. A 5 would require more context about output or failure handling.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%: both parameters have enum constraints and descriptions ('Limit to one agent/machine'). The description's phrase 'Optionally narrow with machine/agent' merely reinforces the schema without adding new semantic meaning. Baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb ('Health-check') and resource ('the fleet', defined as agent CLIs on machines). It names the exact CLIs (claude/codex/agy) and machines (wsl/draydev/ec2), which distinguishes it from sibling tools like fleet_run or system_status.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context: use to confirm each agent is headless and authenticated on each machine, with optional narrowing by machine/agent. It does not explicitly name alternatives or exclusions (e.g., 'for detailed command execution use fleet_run'), but the purpose is specific enough to imply 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.
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 behavioral disclosure burden. 'Get' implies a read-only operation, and the data source is specified, but the description does not explicitly state that it has no side effects, requires no permissions, or what the response contains. This is minimal but not misleading.
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, front-loaded sentence with no filler. Every word contributes to identifying the tool's purpose and source.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter read-only getter with no output schema, the description is reasonably complete: it states the target subject, what is retrieved, and the source database. It does not elaborate on what 'profile data' includes, but given the tool's low complexity, this is sufficient for selection and invocation.
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 input schema has zero parameters, so the baseline is 4. There are no parameter semantics to document, and the description does not need to compensate for any schema gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get'), a clear resource ('profile data about Jenn'), and a source ('AION's Jenn memory database'). It clearly distinguishes this from sibling tools like jenn_get_memories by focusing on profile data specifically.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool—whenever Jenn's profile data is needed—but it does not explicitly state alternatives or exclusions. Sibling tools like memory_get_facts or jenn_get_memories are not mentioned, so guidance is indirect.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses a key behavior: bypassing AION's persona and memory, which is significant. However, it does not mention other behavioral aspects such as whether it is a read-only operation, any rate limits, or the response format. For a simple query tool, this is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise—two sentences with zero filler. It front-loads the core action and then provides contextual use cases. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 4 parameters, no annotations, and no output schema, the description does a good job explaining purpose and usage. It does not explicitly state what the return value is, but that is largely implied for a query tool. It could benefit from mentioning that the output is the model's response, but overall it is complete enough for an AI agent to select and invoke 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 all four parameters are already well-documented in the schema. The description adds minimal semantic value beyond reinforcing the 'raw prompt' aspect, which aligns with the prompt parameter. There is no additional explanation of model, system, or temperature, so the baseline of 3 is appropriate.
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 function: 'Send a raw prompt directly to Ollama'. It specifies the verb (send), resource (Ollama), and scope (raw prompt bypassing persona/memory). This distinguishes it from sibling tools like aion_query (which presumably uses persona/memory) and openai_query (different model provider).
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 use cases: 'Useful for model testing, one-off queries, or comparing model outputs.' It also implies when not to use by noting it bypasses AION's persona and memory, suggesting that contextual queries should go elsewhere. However, it does not explicitly name alternative tools like aion_query, so it falls short of full explicitness.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the return data (status, version, subsystem health) and the verb 'check' implies read-only behavior, but it does not explicitly state that it is a safe read operation or mention any potential side effects, auth requirements, or failure 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, front-loaded sentence that efficiently communicates the action, resource, and return information. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (no params, no output schema), and the description provides a reasonable overview of what it returns. However, the vague phrase 'any reported subsystem health' leaves the response format somewhat undefined, which could be improved given the absence of an output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema is fully covered by the empty parameter list. Per the guidelines, a 0-parameter tool receives a baseline of 4; the description adds no parameter-specific details, which is acceptable.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Check') and a specific resource ('SyncForge (MFT) portal'), and it names the tech stack (Spring Boot, Nginx, port 8888). This clearly distinguishes it from sibling tools like system_status or portal_nginx_check.
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 for portal health checks but does not explicitly state when to choose this tool over alternatives such as system_status, sonchat_health, or portal_nginx_check. No exclusions or edge cases are mentioned.
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 burden of explaining behavior. It states that the tool returns status and basic service info, which implies a side-effect-free read operation. However, it does not disclose what fields constitute 'status' or 'basic service info', nor any potential error or latency 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 concise sentence that front-loads the action and clearly indicates the return value. There is no wasted wording or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple zero-parameter health check, the description is mostly sufficient. It does not have an output schema, and 'basic service info' is somewhat vague, but the tool's simplicity means the description covers the core use case adequately.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema is empty, so there are no parameter semantics to document. The description adds no parameter-related ambiguity, and the baseline of 4 for zero-parameter tools applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Check' and names the resource 'SonChat', clearly conveying a health-check purpose. It distinguishes itself from sibling tools like sonchat_activity and sonchat_invites by focusing on online status rather than activity or invites.
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 the tool is for verifying SonChat availability, but it does not explicitly state when to use it over other health-related tools like portal_health or system_status. There are no exclusions or alternative tool references, so guidance is only implied.
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 burden. It discloses that the tool lists models with sizes and compatibility info, but does not explicitly state that it is read-only or describe any side effects, permissions, or failure behaviors. For a listing tool this is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, front-loaded with the primary action ('List all locally available Ollama models with their sizes'), and no wasted words. Every sentence contributes value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with no parameters and no output schema. The description covers the main return content (models, sizes, compatibility) and is sufficient for the agent to understand the tool's output. It could mention the format of the compatibility flags, but is otherwise complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With zero parameters, the baseline is 4. The description adds meaning beyond the empty schema by specifying the output includes sizes and AION/Nebula compatibility, giving context to what the tool returns.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists all locally available Ollama models with their sizes, and adds the specific purpose of showing compatibility with AION and Nebula. This is a specific verb-resource pairing that distinguishes it from query tools like ollama_query.
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 implication is to use this for checking model availability and AION/Nebula compatibility, but there is no explicit guidance on when to use this tool versus alternatives or any exclusion criteria. The utility is implied, not stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility. 'List' implies a read-only, non-destructive operation, and the admin session requirement is disclosed. However, it does not describe behavior when authentication fails, the response format, or any potential performance implications for large user lists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences with no filler. The purpose is stated first, followed by a critical prerequisite. Every word earns its place, and the structure is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, read-only listing tool, the description covers the operation and the auth requirement adequately. It lacks details on return shape or error conditions, but the tool's simplicity and lack of output schema mean the description is nearly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, making the description's job trivial. Since there are no parameters to explain, the baseline of 4 applies. The description neither adds nor omits parameter-related information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'List' and identifies the resource as 'all users registered in Aion', making the tool's purpose unambiguous. It clearly distinguishes this from sibling admin tools like aion_admin_profile_rebuild or aion_admin_network_run, which concern different resources.
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 clearly states the prerequisite of an admin session (AION_SESSION_TOKEN), which is essential usage context. However, it does not explicitly mention alternatives or when not to use the tool, though no direct competing sibling exists.
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?
Since no annotations are provided, the description carries the full burden of behavioral disclosure. It reveals a credential requirement (AION_SESSION_TOKEN with vast/admin access) and implies a read-only operation via 'List'. However, it does not detail return format, pagination, or failure behaviors. For a simple zero-parameter list, this is minimal but adequate, though it misses some behavioral 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 two short sentences, front-loaded with the main action and resource. It conveys purpose and auth requirement without waste, making it appropriately concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter list tool with no output schema or annotations, the description covers the core purpose and a critical prerequisite (token). It does not explain return details, but that is not strictly necessary given the simplicity. The tool is adequately specified, though additional info about what fields are returned could be helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so the description cannot add parameter-specific semantics. Given 0 params, the baseline is 4. The description does not introduce any param-related confusion or omissions, so it meets the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action ('List') and its resource ('current Vast.ai GPU instances managed by Aion'). It distinguishes itself from sibling tools like aion_vast_deploy and aion_vast_stop by focusing on listing, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context: it is for viewing current instances, which is distinct from managing or stopping them. However, it does not explicitly mention alternatives or when not to use it, though the verb 'List' and naming convention make this clear. It is adequate but lacks explicit comparison to sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses key behaviors: parallel execution, side-by-side response formatting, and default agents (codex + agy). While it doesn't discuss error handling or costs, these are not essential for selecting this tool for its intended review use case.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loads the action, and contains no redundant words. Every phrase advances understanding: the behavior, use cases, and defaults are all packed efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with a simple signature and fully described schema, the description delivers purpose, usage guidance, and defaults, which is sufficient. The output format is summarized as 'side by side,' and no output schema exists, so no further detail is required. It is complete enough for an agent to decide when and how to use it.
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?
Input schema covers all 4 parameters with descriptions and defaults (100% coverage), so baseline is 3. The description adds minimal extra meaning—reiterating defaults and providing example prompts—but does not significantly enrich parameter understanding beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource: 'Fan out the same prompt... to multiple agents in parallel and return all responses side by side.' It clearly differentiates from siblings like fleet_run and fleet_status by focusing on parallel agent review, making the tool's purpose unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit use cases: 'Use for consensus code review or to get diverse model perspectives before deciding.' It gives clear context but stops short of specifying when not to use it or naming alternative tools explicitly, so it earns a 4 rather than a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/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 key behavioral traits: submits the job, polls until complete with a 5-minute timeout, and returns the image URL/path. This gives the agent a clear model of the async behavior and time cost. It does not mention error handling or failure outcomes, but the core behavior is well covered.
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 concise and front-loaded: the first sentence states the purpose, and the second explains the workflow. Every sentence earns its place, and there is no redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 5 parameters and no annotations or output schema, the description provides a solid overview: what it does, how it works (submission and polling), and what it returns. It could also mention potential failure modes or prerequisites (e.g., local service running), but the combination of schema descriptions and this overview makes the tool reasonably complete for 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 covers 100% of the parameters with descriptive text, including enums and defaults. The description itself adds no additional parameter semantics beyond what the schema already provides. Therefore, 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Generate an image using Fooocus (Stable Diffusion XL) running locally.' The verb 'Generate' plus the resource 'image' is specific and unambiguous. It also distinguishes from all sibling tools, which are focused on memory, conversation, system, or security tasks, making this the only image generation 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 does not explicitly state when to use this tool versus alternatives, but the sibling list contains no similar image generation tools, so the usage context is implicitly clear. It also provides useful behavioral expectations (submit and poll) that help the agent decide when to invoke it appropriately.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It reveals that the tool makes a direct call to OpenAI, uses GPT-4o by default, and bypasses AION's persona and memory—an important behavioral distinction. However, it does not mention potential costs, rate limits, or what the response contains, but for a simple query tool this is reasonably transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences: the first states the core action and default behavior, the second provides usage guidance. No fluff, and it is front-loaded with the most critical information. Excellent structure for an AI agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no output schema and no annotations, the description covers the essential facts: what it does, the default model, and when to use it. It omits return-value details and cost implications, but these are secondary for a straightforward query tool. Overall, it is adequately complete for the tool's simplicity.
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 all four parameters (prompt, model, system, temperature) already described in the schema. The description adds no additional parameter semantics beyond the schema; it only reiterates the default model. Since the schema is fully self-explanatory, 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Send a raw prompt directly to OpenAI (GPT-4o by default)'. It uses a specific verb ('send') and resource ('prompt to OpenAI'), and distinguishes from siblings by noting it bypasses AION's persona and memory, which differentiates it from aion_query and other AION-context tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage scenarios: 'Useful for one-off queries, comparing model outputs, or when Ollama is unavailable.' It gives clear context for when to use the tool but does not explicitly name an alternative tool like aion_query, though the 'bypassing AION' phrase implies when not to use it. This is strong but not fully explicit about alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It does so by stating that the fact is injected into every future AION conversation, a significant side effect. This is valuable context for an agent deciding whether to use the tool. It does not mention other behaviors like overwriting, but for a simple add operation this is acceptable.
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 with no wasted words. It front-loads the primary action and adds a single, relevant consequence. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter tool with no output schema, the description explains the action and its most important side effect. The input schema fully covers the parameters, so nothing critical is missing for an agent to select and invoke the tool 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%, with both 'fact' and 'category' fully described, including examples and an enum. The description itself adds no parameter information beyond what the schema already provides, so a baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Add' and identifies the resource 'AION's long-term memory'. It also states the consequence (injected into every future conversation), which clearly differentiates it from sibling tools like memory_get_facts, memory_delete_fact, and memory_search.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use the tool: when adding a fact to long-term memory. The note about future conversation injection helps the agent judge appropriateness. It does not explicitly mention alternatives or exclusions, but the purpose is unambiguous given sibling 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?
No annotations are provided, so the description carries the full burden. It states the fact is deleted but does not explicitly mention permanence or irreversibility, which is a significant behavioral trait for a destructive operation. The context about long-term memory is helpful, but the description could be more transparent about consequences.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the action and resource, and every word earns its place. No fluff or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter delete tool with no output schema, the description is complete. It includes the essential prerequisite (memory_get_facts) and does not need to explain return values for such a straightforward operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with the id parameter fully described as 'The integer ID of the fact to delete.' The description does not add extra meaning beyond the schema, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool deletes a fact from AION's long-term memory by ID, using a specific verb and resource. It distinguishes itself from sibling tools like memory_add_fact and memory_get_facts by focusing on removal.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly instructs to use memory_get_facts first to find the ID, providing clear sequential guidance and implying that this tool is for deletion after retrieval. This is more than generic context—it tells the agent exactly when and how to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It clearly states the tool performs a search (read-only) and describes the return value ('matching facts and conversation metadata'). It does not mention limitations or edge cases, but for a simple search tool this is sufficient.
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 main action and scope, with no wasted words. Every word contributes to understanding the tool's purpose and behavior.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (one parameter, no output schema), and the description covers the essential purpose, scope, and return type. It is complete enough for an agent to decide when to use it and what outcome to expect.
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 already provides a description for the only parameter (query: 'Keyword or phrase to search for') with 100% coverage. The tool description reinforces the notion of 'keyword' but adds no additional semantic detail beyond the schema, so a baseline score of 3 is appropriate.
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 states a specific verb ('Search') and resource ('AION's memory'), and further defines the scope ('across both user facts and conversation summaries'). This distinguishes it from sibling tools like memory_get_facts (which likely retrieves facts) and conversation_search (which likely searches only conversations).
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 clearly indicates the tool is for searching across both user facts and conversation summaries, which implies when it should be used over more specific siblings. However, it does not explicitly name alternatives or state exclusions, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It describes a 'quick connectivity probe', implying a non-invasive read-only operation, but does not disclose what happens on failure, return format, or whether any permissions are needed. This is acceptable but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences, efficiently stating the tool's purpose and supplementary context without any unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameter-less, simple check tool, the description fully conveys what it does and why it matters. It lacks output schema details, but the purpose implies a straightforward status response, making it complete enough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so no parameter explanations are needed. The baseline for no parameters is 4, and the description appropriately omits any parameter details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Check') and resource ('Nginx on port 8888'), clearly distinguishing it from broader tools like portal_health. It also adds context that this is the public gateway for all Drayhub services.
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 when to use this tool (when checking if the public gateway/Nginx is responding) and provides context about its importance. However, it does not explicitly mention when not to use it or name alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses the specific services checked, including ports, and states the return value (online/offline status and latency). It does not mention potential errors or rate limits, but for a read-only health check, this is adequate.
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 front-loads the main verb and resource. Every service is listed concisely with port details, and the output is clearly stated. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (0 params, no output schema), the description fully covers the intended function and output. All services are enumerated, and the return format is specified. Nothing critical is missing for an agent to select and invoke this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has no parameters, and the schema coverage is 100% (empty object). The description does not need to add parameter details. It implicitly covers the scope of the check, which serves as the only relevant semantic.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Check the health of all Drayhub services' with a specific verb and resource. It enumerates all services (Ollama, Aion Flask API, SonChat, SyncForge/Portal, Fooocus) and distinguishes itself from narrower sibling health checks like sonchat_health or portal_health.
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 the tool is for a comprehensive health overview, but it does not explicitly state when to use it versus individual service health tools (e.g., sonchat_health, portal_health). No exclusions or alternatives are mentioned, so the guidance is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that the tool returns the agent's response, mentions headless execution, and warns that codex/agy can edit files and run commands. It does not cover error/timeout behavior, but the key safety and output traits are addressed.
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 compact, front-loaded with the main purpose, and each sentence earns its place. It avoids redundancy while packing essential details into four short sentences.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is complete for a tool of this complexity, covering purpose, use cases, machine mapping, agent capabilities, and output. It could mention timeout/default behavior or return format specifics, but these are partially covered by the schema and not critical for invocation.
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 coverage is 100%, yet the description adds value by mapping machine enum values to human-readable meanings (wsl=local, draydev=dev VM, ec2=prod) and describing agent CLI capabilities. This goes beyond the schema's generic descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the action ('Delegate a single prompt to another agent CLI'), the resource (claude, codex, or agy), and the environment (fleet machines). It explicitly states the return value and gives use cases, distinguishing it from sibling tools like fleet_review and fleet_status.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit use cases: 'Use to farm a subtask to a different model, or to run work on a remote box.' It also includes a warning about codex/agy capabilities and advises scoping prompts, but it does not name alternative tools for exclusion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It discloses the authentication requirement (AION_SESSION_TOKEN), which is a useful behavioral trait. It doesn't detail error handling or return format, but for a simple listing tool, this is acceptable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, front-loaded with the purpose, zero wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the zero-parameter schema and simple listing purpose, the description provides the essential information: what it lists and the auth requirement. It's complete for an agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema already fully documents them. The description adds no parameter information, but none is needed. Baseline 4 is appropriate.
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 'List all Aion chat channels' with a specific verb and resource, distinguishing it from sibling tools like aion_channel_history and aion_channel_presence.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides the prerequisite that AION_SESSION_TOKEN must be set, giving clear context for when the tool can be used. However, it does not explicitly compare with alternatives, so it doesn't fully meet the 'explicit alternatives' criterion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, but the description itself transparently indicates a read-only connectivity check and enumerates the returned data. It does not discuss failure behavior or permissions, but for a simple status probe this is sufficient.
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?
One sentence, front-loaded with the action and subject, with no redundant wording. Every word adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the trivial input schema and the fact that the description identifies both the purpose and the return payload, the tool is adequately described. No output schema exists, but the stated return values (version/inventory) cover the core needs.
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 100% schema coverage, so the baseline is 4. There are no parameter semantics for the description to clarify.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Check') and resource ('Kali Docker container'), and specifies the return content (version/tool inventory). This clearly distinguishes it from sibling tools like kali_nmap or kali_exec, which perform actions, and from other health checks like portal_health.
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 clearly implies use when you need to verify Kali container connectivity and inventory. It does not explicitly mention alternatives or exclusion criteria, but the context of a status check is unmistakable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses precisely what the tool returns (last 10 conversation summaries, all user facts, exact formatted view) and implies a read-only operation via the verb 'Get' and purpose of auditing. However, it doesn't explicitly state safety or side effects, but for a getter this is sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loads the action and content, and the second sentence provides practical value without redundancy. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter tool with no annotations and no output schema, the description fully explains what the tool does, what it returns, and when it's useful. It covers the necessary behavioral and usage details, making it complete for an agent to select and invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so the baseline is 4. The description adds no parameter-specific information because there are none; it correctly focuses on the tool's output and purpose.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the function: 'Get the full memory context that AION injects into its system prompt,' with concrete details about content (last 10 conversation summaries, all user facts) and format ('formatted exactly as AION sees them'). It distinguishes from siblings like memory_get_facts by specifying the full context, making it clearly separate.
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 a clear use case: 'Useful for auditing what AION knows.' This implies when to use it, but it doesn't explicitly mention alternatives or exclusions relative to memory_get_facts or memory_search. Thus it has clear context but no explicit when-not-to-use.
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:

[![mcpbuilder MCP server](https://glama.ai/mcp/servers/draygen/mcpbuilder/badges/card.svg)](https://glama.ai/mcp/servers/draygen/mcpbuilder)

Score Badge

Copy to your README.md:

[![mcpbuilder MCP server](https://glama.ai/mcp/servers/draygen/mcpbuilder/badges/score.svg)](https://glama.ai/mcp/servers/draygen/mcpbuilder)

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/draygen/mcpbuilder'

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