GoClaw MCP Server

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation4/5
Tools are well-organized by resource categories (agent, config, cron, custom_tool, etc.) with clear CRUD operations, making most tools distinct. However, some overlap exists within categories like goclaw_agent_files_set and goclaw_agent_files_create/update are implied but not explicitly separate, and goclaw_health vs goclaw_status might cause minor confusion as both relate to system status.
Naming Consistency5/5
Naming follows a highly consistent pattern throughout: all tools use snake_case with the prefix 'goclaw_', followed by resource name (e.g., agent, config), and then action verb (e.g., create, list, get, update, delete). This uniformity makes the tool set predictable and easy to navigate.
Tool Count2/5
With 66 tools, the count is excessive for an MCP server, likely overwhelming for agents and indicating poor scoping. While the domain (GoClaw gateway management) is broad, this many tools suggests fragmentation rather than a cohesive set, making it difficult to manage and use effectively.
Completeness5/5
The tool set provides comprehensive coverage for managing a GoClaw gateway, including agents, channels, config, cron jobs, custom tools, MCP servers, memory, models, providers, sessions, skills, teams, and traces. Each category has full CRUD operations and additional utilities, leaving no obvious gaps for the inferred domain.
Average 3/5 across 66 of 66 tools scored. Lowest: 1.9/5.
See the Tool Scores section below for per-tool breakdowns.
- 0 of 1 community issues answered or closed in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior1/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 but fails completely. It doesn't indicate whether this is a read or write operation, what permissions are required, whether it has side effects, what happens on errors, or what the typical response looks like. 'Invoke' suggests execution but gives no insight into the nature or consequences of that execution.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at just 6 words, which is efficient. However, this conciseness comes at the cost of meaningful information - it's under-specified rather than optimally concise. The single sentence structure is clear but lacks the necessary content to be truly helpful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool that executes arbitrary custom functionality with no annotations and no output schema, this description is completely inadequate. It doesn't explain what 'custom tools' are in this system, what they can do, how to discover available tools, what authentication they require, or what format results return. The agent has insufficient information to use this tool safely or effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both parameters thoroughly. The description adds no additional meaning beyond what's in the schema - it mentions 'arguments' but doesn't clarify what types of custom tools accept what argument structures, or provide examples of valid IDs or argument patterns.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Invoke a custom tool directly with arguments' is a tautology that essentially restates the tool name 'goclaw_custom_tool_invoke'. It doesn't specify what 'custom tool' means in this context, what types of tools can be invoked, or what 'invoke' entails. While it mentions 'with arguments', this adds minimal value beyond the name itself.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/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. There are multiple sibling tools for managing custom tools (create, delete, get, list, update), but the description doesn't explain when direct invocation is appropriate versus using those management tools. No prerequisites, constraints, or typical use cases are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but offers minimal behavioral insight. 'Update' implies a mutation, but it doesn't disclose required permissions, whether updates are partial or complete, if changes are reversible, error conditions, or what happens to unspecified fields. It lacks crucial context 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, efficient sentence with zero wasted words. It's appropriately sized for a simple action, though its brevity contributes to gaps in other dimensions.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with 5 parameters (4 undocumented), no annotations, and no output schema, the description is inadequate. It doesn't explain the update behavior, parameter roles, or expected outcomes, leaving the agent with significant uncertainty about how to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is low (20%), with only the 'id' parameter documented. The description doesn't compensate by explaining what 'name', 'expression', 'agent_id', or 'message' represent, their formats, constraints, or which are optional. It adds no meaning beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Update a cron job's settings' clearly states the verb (update) and resource (cron job), but it's vague about what 'settings' encompasses. It distinguishes from obvious siblings like 'goclaw_cron_create' and 'goclaw_cron_delete', but doesn't specify how it differs from 'goclaw_cron_toggle' or what aspects of a cron job can be updated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing an existing cron job ID), when to choose update over delete+create, or how it relates to sibling tools like 'goclaw_cron_toggle' for enabling/disabling jobs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. While 'Update' implies a mutation operation, it doesn't describe what happens on success/failure, whether changes are reversible, if it requires specific permissions, or any rate limits/constraints. This leaves significant gaps for a tool that modifies provider configurations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that gets straight to the point without unnecessary words. However, it could be slightly more specific (e.g., 'Update configuration fields for an existing LLM provider') to better distinguish from create operations.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with 6 parameters, no annotations, and no output schema, the description is insufficient. It doesn't explain what 'configuration' entails, what happens when fields are omitted, or what the tool returns. Given the complexity and lack of structured metadata, more context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all 6 parameters thoroughly. The description adds no additional parameter semantics beyond implying these are configuration fields that can be updated. This meets the baseline expectation when schema coverage is high.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Update an LLM provider's configuration' clearly states the action (update) and target (LLM provider configuration), which is better than a tautology. However, it doesn't specify what aspects of configuration can be updated or differentiate this from sibling tools like goclaw_provider_create or goclaw_provider_delete beyond the basic verb.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing an existing provider ID), when to choose update over create/delete, or any constraints like which fields are optional vs. required beyond the schema's 'id' requirement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states 'update' implying a mutation, but doesn't cover permissions, side effects, error handling, or response format. For a mutation tool with zero annotation coverage, this is insufficient—it lacks critical behavioral details like whether changes are reversible or what authentication is needed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words. It's front-loaded and to the point, though it could benefit from more detail given the lack of annotations. It earns its place but is borderline under-specified rather than concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a mutation tool with no annotations and no output schema, the description is incomplete. It doesn't explain what happens on success or failure, what 'metadata' encompasses beyond the schema, or how it relates to sibling tools. For a tool that modifies data, this leaves significant gaps in understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, so the schema already documents all parameters (id, name, description, enabled) with clear descriptions. The description adds no additional meaning beyond implying 'metadata' includes these fields, but it doesn't clarify semantics like format constraints or interactions. Baseline 3 is appropriate as the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Update a skill's metadata' clearly states the verb ('update') and resource ('skill's metadata'), making the purpose understandable. However, it doesn't differentiate from sibling tools like 'goclaw_skill_get' or 'goclaw_skill_list', nor does it specify what 'metadata' entails beyond the schema fields. It's adequate but lacks sibling distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. There are no mentions of prerequisites, conditions, or comparisons to siblings like 'goclaw_skill_get' for reading or 'goclaw_skill_list' for listing. It's a basic statement with no usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states 'update' which implies a mutation, but doesn't disclose behavioral traits like required permissions, whether updates are partial or full, if changes are reversible, rate limits, or error conditions. This leaves significant gaps for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste. It's appropriately sized and front-loaded, though its brevity contributes to gaps in other dimensions.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with 4 parameters, low schema coverage (25%), no annotations, and no output schema, the description is inadequate. It doesn't explain what 'settings' includes, how updates work, or what to expect in return. More detail is needed given the complexity and lack of structured information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is low (25%, only the 'id' parameter has a description). The description mentions 'settings' but doesn't specify which settings correspond to the parameters (name, description, member_agent_ids). It adds minimal meaning beyond the schema, failing to compensate for the coverage gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Update a team's settings' clearly states the action (update) and resource (team), but it's vague about what 'settings' encompasses. It distinguishes from obvious siblings like 'team_create' and 'team_delete' by specifying update rather than create/delete, but doesn't differentiate from other update tools like 'agent_update' or 'skill_update' beyond the resource type.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing an existing team ID), when not to use it, or how it relates to sibling tools like 'team_create' or 'team_get'. The agent must infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. 'Delete a team' implies a destructive, irreversible mutation, but it doesn't disclose any behavioral traits such as required permissions, whether deletion is permanent or recoverable, side effects (e.g., cascading deletions), rate limits, or error conditions. This is inadequate for a destructive operation with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with zero waste—just three words. It's front-loaded and gets straight to the point, though this brevity contributes to gaps in other dimensions. Every word earns its place by stating the core action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given this is a destructive mutation tool with no annotations and no output schema, the description is incomplete. It lacks critical context: what 'delete' entails (permanent? reversible?), prerequisites, side effects, and what the tool returns. For a tool that could have significant impact, this minimal description is insufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 1 parameter with 100% description coverage ('Team ID'), so the schema already documents it fully. The description adds no meaning beyond what the schema provides—it doesn't explain where to find the ID, format requirements, or validation rules. Baseline 3 is appropriate when schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Delete a team' clearly states the action (delete) and resource (team), but it's overly simplistic and doesn't differentiate from sibling tools like 'goclaw_agent_delete' or 'goclaw_session_delete' beyond the resource type. It lacks specificity about what 'team' means in this context compared to other deletion tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. There's no mention of prerequisites (e.g., needing team ID), consequences (e.g., what happens to associated agents or data), or when not to use it (e.g., if team has active sessions). The description offers only the basic function without context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. 'Get team details' implies a read-only operation, but it doesn't specify authentication requirements, rate limits, error conditions, or what 'details' include (e.g., members, settings). For a tool with zero annotation coverage, this leaves significant gaps in understanding its behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at three words, with no wasted language. It's front-loaded and directly states the tool's function without unnecessary elaboration, making it efficient for quick understanding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description is incomplete. It doesn't explain what 'details' include in the response, potential errors, or usage context relative to siblings. For a read operation with no structured output documentation, more detail is needed to guide effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with the 'id' parameter documented as 'Team ID'. The description doesn't add any meaning beyond this, such as format examples or where to find the ID. With high schema coverage, the baseline score of 3 is appropriate, as the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get team details' clearly states the action (Get) and resource (team details), making the purpose understandable. However, it doesn't differentiate from sibling tools like 'goclaw_team_list' (which likely lists multiple teams) or 'goclaw_team_update' (which modifies teams), leaving ambiguity about when to use this specific retrieval tool versus alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. With siblings like 'goclaw_team_list' (likely for listing teams) and 'goclaw_team_get' (for retrieving a specific team), the description doesn't specify that this is for fetching details of a single team by ID, nor does it mention prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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. While 'Update' implies a mutation, it doesn't specify whether this requires specific permissions, what happens to unspecified fields (partial vs. full updates), or if there are side effects like validation or error handling. This leaves significant gaps for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It's appropriately sized and front-loaded, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a mutation tool with 5 parameters, low schema coverage (20%), and no output schema or annotations, the description is inadequate. It doesn't explain what the update entails, how parameters interact, or what the tool returns, leaving the agent with insufficient context for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is low at 20%, with only the 'id' parameter documented. The description adds no information about the other four parameters (name, description, command, timeout_seconds), such as their purposes, formats, or constraints. This fails to compensate for the schema's lack of detail.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Update') and the resource ('a custom tool's definition'), which provides a specific verb+resource combination. However, it doesn't explicitly distinguish this tool from its sibling 'goclaw_custom_tool_create' or 'goclaw_custom_tool_get', which would be needed for a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'goclaw_custom_tool_create' or 'goclaw_custom_tool_get'. There's no mention of prerequisites (e.g., needing an existing custom tool ID) or context for updates, leaving the agent with minimal usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states this is an update operation, implying mutation, but doesn't disclose critical behavioral traits such as required permissions, whether changes are reversible, potential side effects, or error conditions. For a mutation tool with zero annotation coverage, this represents a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is perfectly concise - a single sentence that directly states the tool's purpose with no wasted words. It's front-loaded with the essential information and contains no unnecessary elaboration. This is an example of efficient communication that respects the agent's need for quick comprehension.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with 7 parameters, low schema coverage (29%), no annotations, and no output schema, the description is inadequate. It doesn't explain what configuration aspects can be updated, what the expected behavior is, what permissions are required, or what the tool returns. The agent would struggle to use this tool correctly given the sparse contextual information provided.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With low schema description coverage (29%), the description must compensate by explaining parameter meanings, but it provides no parameter information whatsoever. The schema documents only the 'id' parameter (29% coverage), leaving six parameters (name, transport, command, args, url, enabled) completely undocumented in both schema and description. The description adds zero value beyond what the sparse schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Update') and the resource ('a registered MCP server's configuration'), making the purpose immediately understandable. It distinguishes this tool from sibling tools like 'goclaw_mcp_server_create' and 'goclaw_mcp_server_delete' by focusing on modification rather than creation or deletion. However, it doesn't specify what aspects of configuration can be updated, which prevents a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing an existing server ID), when not to use it, or how it differs from similar tools like 'goclaw_mcp_server_create' or 'goclaw_config_patch'. This leaves the agent without context for making informed decisions about tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states this is a creation operation but provides no information about permissions required, whether this is idempotent, what happens on duplicate agent_key, rate limits, or what the response contains. For a mutation tool with zero annotation coverage, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that states the core purpose without unnecessary words. It's appropriately sized and front-loaded with the essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a creation tool with 8 parameters, no annotations, and no output schema, the description is inadequate. It doesn't explain what happens after creation, what permissions are needed, how to verify success, or how this tool relates to other agent management tools. The agent creation process has significant complexity that isn't addressed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all 8 parameters thoroughly. The description adds no additional parameter information beyond what's in the schema. This meets the baseline of 3 when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Create') and resource ('new agent in GoClaw gateway'), making the purpose immediately understandable. However, it doesn't differentiate this tool from its sibling 'goclaw_agent_update' or explain what distinguishes creation from updating an existing agent.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives like 'goclaw_agent_update' or 'goclaw_agent_get'. The description doesn't mention prerequisites, constraints, or typical use cases for agent creation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It mentions 'soft delete' which implies the agent isn't permanently removed and might be recoverable, but doesn't explain what 'soft delete' entails (e.g., marking as inactive, retention period, recovery options). It also doesn't cover permissions needed, side effects, or error conditions for this mutation operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at just four words, front-loading the key information ('Delete an agent') and adding a critical qualifier ('soft delete'). There's zero wasted language, making it easy to parse while conveying essential behavioral context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a deletion tool with no annotations and no output schema, the description is insufficient. It doesn't explain what 'soft delete' means operationally, what the tool returns (success confirmation, error messages), or how this differs from other agent operations. The context signals show a simple parameter structure, but the behavioral aspects are under-specified for a mutation 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 description coverage is 100%, with the single parameter 'id' clearly documented as 'Agent ID'. The description doesn't add any parameter-specific information beyond what the schema provides, such as format examples or where to obtain the ID. With high schema coverage, the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Delete') and resource ('an agent'), and specifies it's a 'soft delete' which distinguishes it from permanent deletion. However, it doesn't explicitly differentiate from sibling tools like goclaw_agent_files_delete or goclaw_agent_links_remove, which handle different resource types.
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. There's no mention of prerequisites (e.g., needing the agent ID), when soft deletion is appropriate versus other operations, or what happens after deletion. Sibling tools like goclaw_agent_update or goclaw_agent_get aren't referenced for context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. While 'Delete' implies a destructive operation, it doesn't specify whether deletion is permanent or reversible, what happens on success/failure, or any permissions/rate limits required. For a mutation tool with zero annotation coverage, this is a significant gap in safety and operational context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It's front-loaded with the core action and resource, making it easy to parse quickly. Every word earns its place with zero waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given this is a destructive operation with no annotations and no output schema, the description is incomplete. It doesn't cover behavioral aspects like irreversibility, error conditions, or return values, which are critical for safe tool invocation. The high schema coverage helps with parameters, but overall context for a delete operation is lacking.
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 ('agent_id' and 'path') clearly documented in the schema. The description doesn't add any meaning beyond what the schema provides (e.g., clarifying path format or agent ID sourcing). With high schema coverage, the baseline score of 3 is appropriate as the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Delete') and target ('a context file from an agent'), providing a specific verb+resource combination. However, it doesn't explicitly distinguish this tool from sibling deletion tools like 'goclaw_agent_delete' or 'goclaw_agent_files_set' (which might handle file updates), leaving some ambiguity about its unique scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., file must exist), exclusions (e.g., cannot delete system files), or compare it to related tools like 'goclaw_agent_files_list' for checking files first. This leaves the agent without context for proper selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states 'Read' implying a read-only operation, but doesn't disclose behavioral traits such as error handling (e.g., what happens if the file doesn't exist), permissions required, rate limits, or the format of the returned data. This leaves gaps in understanding how the tool behaves in practice.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no wasted words. It's front-loaded with the core action and target, making it easy to grasp quickly. Every part of the sentence contributes directly to understanding the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a read operation with no annotations and no output schema, the description is incomplete. It doesn't explain what the tool returns (e.g., file content, metadata), error conditions, or how it fits into the broader agent file management context. This leaves the agent with insufficient information to use the tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with clear descriptions for 'agent_id' and 'path' (including examples like 'SOUL.md, IDENTITY.md'). The description adds minimal value beyond the schema, as it doesn't explain parameter interactions or constraints. Baseline 3 is appropriate given the high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Read') and target ('a specific context file for an agent'), which is specific and distinguishes it from siblings like 'goclaw_agent_files_list' (list files) and 'goclaw_agent_files_set' (write file). However, it doesn't explicitly mention what type of content is read (e.g., configuration, metadata) or the format, keeping it from a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. For example, it doesn't clarify if this is for retrieving agent configuration files, metadata, or other contexts, or how it differs from 'goclaw_agent_get' (which might get agent details). The description lacks context on prerequisites or typical use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the action but fails to explain key traits: whether this operation overwrites existing files, requires specific permissions, has rate limits, or what happens on success/failure. This leaves the agent with insufficient behavioral context for safe invocation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence that directly states the tool's purpose without any wasted words. It is front-loaded and efficiently conveys the core action, making it easy to parse and understand quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a file creation/update operation, no annotations, and no output schema, the description is incomplete. It lacks details on behavioral traits, error handling, and output expectations, which are crucial for an agent to use this tool effectively in context with its siblings.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, so the schema already documents all three parameters (agent_id, path, content) with basic descriptions. The description adds no additional meaning beyond implying the tool handles context files, which is minimal value. This meets the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('create or update') and the resource ('a context file for an agent'), which is specific and actionable. However, it doesn't distinguish this tool from its sibling 'goclaw_agent_files_delete' or 'goclaw_agent_files_get' beyond the basic verb difference, missing explicit differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 'goclaw_agent_files_delete' or 'goclaw_agent_files_get'. The description lacks context about prerequisites, such as whether the agent must exist or if the file path has specific constraints, leaving usage unclear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool 'Get[s] detailed information,' implying a read-only operation, but does not specify what 'detailed information' includes, potential permissions required, error conditions, or response format. This leaves significant gaps for a tool with no annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It is appropriately sized and front-loaded, with zero waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description is incomplete. It does not explain what 'detailed information' includes, potential return values, or behavioral aspects like error handling. For a tool with no structured data beyond the input schema, more context is needed to guide effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with the parameter 'id' documented as 'Agent ID or agent_key.' The description does not add any additional meaning beyond this, such as format examples or validation rules. With high schema coverage, the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get detailed information about a specific agent.' It uses a specific verb ('Get') and resource ('agent'), but does not explicitly differentiate from its sibling 'goclaw_agent_list' which likely lists multiple agents. The description is clear but lacks sibling differentiation.
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 sibling tools like 'goclaw_agent_list' for listing agents or 'goclaw_agent_update' for modifying agents. There are no explicit when/when-not instructions or prerequisites stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. 'Remove' implies a destructive mutation, but the description doesn't specify whether this operation is reversible, what permissions are required, whether it affects agent functionality, or what happens on success/failure. This is inadequate for a mutation tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that states the core purpose without unnecessary words. It's appropriately sized for a simple operation and front-loads the essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive mutation tool with no annotations and no output schema, the description is insufficient. It doesn't explain what 'delegation link' means in this context, what the consequences of removal are, whether the operation is idempotent, or what response to expect. Given the complexity of agent relationships, more context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so parameters are fully documented in the schema. The description doesn't add any parameter-specific information beyond what's already in the schema (agent_id as source, target_agent_id as target to unlink). This meets the baseline when schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Remove') and resource ('delegation link between agents'), making the purpose immediately understandable. However, it doesn't differentiate this tool from its sibling 'goclaw_agent_links_set' (which presumably creates links) or explain what a 'delegation link' entails in this system.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., an existing link must exist), error conditions, or when to choose this over other agent management tools like 'goclaw_agent_delete' or 'goclaw_agent_update'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the action ('Create or update') but doesn't clarify whether this is idempotent, what permissions are required, whether it's destructive, or what happens on success/failure. For a mutation tool with zero annotation coverage, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that states the core purpose without any wasted words. It's appropriately sized for a tool with three parameters and no complex behavioral nuances to explain.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, the description is insufficient. It doesn't explain what a 'delegation link' entails in this system, what the response looks like, error conditions, or side effects. Given the complexity implied by sibling tools and lack of structured data, more context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all three parameters adequately. The description doesn't add any additional semantic context about the parameters beyond what's in the schema (e.g., format of agent IDs, examples of descriptions). This meets the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Create or update') and resource ('delegation link between agents'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'goclaw_agent_links_remove' or 'goclaw_agent_links_list' beyond the verb difference, which prevents a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'goclaw_agent_links_remove' or 'goclaw_agent_links_list'. It doesn't mention prerequisites, consequences, or typical use cases, leaving the agent with minimal context for decision-making.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the action ('Share') but doesn't explain what sharing entails—whether it grants permissions, sends notifications, affects existing shares, or has side effects like rate limits or authentication requirements. This leaves significant gaps for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence with zero wasted words. It's front-loaded with the core action and resource, making it highly efficient and easy to parse at a glance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a sharing operation (a mutation with potential side effects), no annotations, and no output schema, the description is incomplete. It lacks details on behavior, permissions, return values, or error conditions, leaving the agent with insufficient context to use the tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with clear parameter names and descriptions ('Agent ID', 'User ID to share with'). The description adds no additional semantic context beyond what the schema provides, such as format examples or constraints. With high schema coverage, the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Share') and resource ('an agent') with a target ('with a user'), making the purpose immediately understandable. It distinguishes itself from siblings like 'goclaw_agent_get' or 'goclaw_agent_update' by focusing on sharing, though it doesn't explicitly differentiate from other sharing-related tools like 'goclaw_mcp_server_grant_agent' or 'goclaw_skill_grant_user'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing an existing agent or user), exclusions (e.g., not for teams or groups), or related tools like 'goclaw_team_create' for broader sharing. Usage is implied but not explicitly defined.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states this is an update operation, implying mutation, but doesn't describe permissions needed, whether changes are reversible, error conditions, or what happens to unspecified settings. This is inadequate for a mutation tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It's appropriately sized and front-loaded, with zero wasted content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with 7 parameters and no annotations or output schema, the description is insufficient. It doesn't explain what 'settings' encompass, how partial updates work, what the response contains, or error handling. The agent must rely entirely on the parameter schema without broader context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, with all 7 parameters clearly documented in the input schema. The description doesn't add any parameter-specific information beyond what's already in the schema (e.g., format constraints, dependencies between parameters), so it meets the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Update') and resource ('an existing agent's settings'), providing a specific verb+resource combination. It distinguishes this from creation and deletion tools, though it doesn't explicitly differentiate from other agent-related tools like 'goclaw_agent_share' or 'goclaw_agent_get'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'goclaw_agent_create' or 'goclaw_agent_get'. It doesn't mention prerequisites (e.g., needing an existing agent ID) or contextual constraints, leaving the agent to infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the action but doesn't cover important aspects like required permissions, whether the change is reversible, potential side effects (e.g., impact on active conversations), or error conditions. This leaves significant gaps for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It's front-loaded and wastes no space, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that this is a mutation tool with no annotations and no output schema, the description is incomplete. It lacks details on behavioral traits, error handling, and what happens upon success or failure. For a tool that modifies system state, this leaves the agent under-informed about critical operational aspects.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description doesn't add any parameter semantics beyond what's already in the input schema, which has 100% coverage with clear descriptions for 'channel' and 'enabled'. Since schema coverage is high, the baseline score of 3 is appropriate, as the description doesn't compensate but also doesn't detract.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Enable or disable') and resource ('a messaging channel'), providing a specific verb+resource combination. However, it doesn't differentiate from sibling tools like 'goclaw_channel_list' or other channel-related operations that might exist, which prevents a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. There's no mention of prerequisites, context for enabling/disabling channels, or comparison to sibling tools like 'goclaw_channel_list' for checking channel status, leaving the agent with minimal usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states 'Patch specific fields' and 'merged into current config', which hints at a non-destructive merge behavior. However, it lacks critical details: whether this requires admin permissions, if it's idempotent, what happens on invalid fields, rate limits, or error responses. For a configuration mutation tool, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core action and resource. It avoids redundancy and wastes no words, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of patching a gateway configuration (a mutation operation with no annotations and no output schema), the description is incomplete. It doesn't explain the format of 'patches', expected return values, error conditions, or security implications. This leaves significant gaps for an AI agent to use the tool safely and effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the parameter 'patches' documented as 'Configuration fields to patch (merged into current config)'. The description adds no additional parameter details beyond what the schema provides, so it meets the baseline of 3 for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Patch') and resource ('GoClaw gateway configuration'), specifying it operates on 'specific fields'. It distinguishes itself from sibling tools like 'goclaw_config_get' (read) and 'goclaw_config_apply' (full apply), but doesn't explicitly contrast with them in the description text.
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 like 'goclaw_config_apply' (which likely applies a full config) or 'goclaw_config_get' (which reads config). The description implies partial updates but doesn't specify scenarios, prerequisites, or exclusions for usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. 'Create a new cron job' implies a write/mutation operation but reveals nothing about permissions required, whether creation is idempotent, what happens on duplicate names, rate limits, or what the response contains. For a mutation tool with zero annotation coverage, this is inadequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero wasted words. It's front-loaded with the essential action and resource, making it immediately scannable. Every word earns its place in this minimal but complete statement of purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, the description is insufficient. It doesn't explain what happens after creation (e.g., does it return the created job ID?), error conditions, or system behavior. The agent lacks crucial context about how this tool actually operates in the system.
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 parameters clearly documented in the schema itself. The description adds no additional parameter context beyond what's already in the structured schema. According to scoring rules, when schema coverage is high (>80%), the baseline is 3 even with no param info in the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Create a new cron job' clearly states the action (create) and resource (cron job), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like goclaw_cron_update or goclaw_custom_tool_create, which also involve creation operations but for 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 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. There's no mention of prerequisites (e.g., needing an existing agent), comparison to goclaw_cron_update for modifications, or when cron jobs are appropriate versus other scheduling methods. The agent must infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. While 'Delete' implies a destructive operation, the description doesn't specify whether this action is reversible, what permissions are required, whether it affects related resources, or what happens upon success/failure. This leaves significant gaps for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with zero wasted words. It's front-loaded with the essential action and resource, making it immediately scannable and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive operation with no annotations and no output schema, the description is incomplete. It doesn't explain what 'delete' entails behaviorally, what the expected outcome is, or how to verify success. Given the complexity of a delete operation in a system with many sibling tools, more context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% (the 'id' parameter is documented as 'Cron job ID'), so the baseline is 3. The description doesn't add any parameter information beyond what the schema provides, such as format examples or where to find the ID, but it doesn't need to compensate for gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Delete') and resource ('a cron job'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like goclaw_cron_toggle or goclaw_cron_update, which also modify cron jobs, nor does it specify what 'delete' entails compared to other destructive operations in the system.
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. There are multiple sibling tools for managing cron jobs (create, list, run, toggle, update), but the description doesn't indicate when deletion is appropriate versus updating or toggling, nor does it mention prerequisites like needing an existing cron job ID.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states the tool triggers a cron job immediately, implying a write/mutation action, but doesn't disclose behavioral traits such as required permissions, whether it's idempotent, potential side effects (e.g., if the job runs in background), error handling, or rate limits. This leaves significant gaps for an agent to understand how to use it safely and effectively.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with zero wasted words. It front-loads the key action ('trigger a cron job') and specifies the timing ('immediately'), making it easy to parse quickly. Every part of the sentence earns its place by conveying essential information efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (triggering a cron job is a mutation with potential side effects), lack of annotations, and no output schema, the description is incomplete. It doesn't cover behavioral aspects like permissions, idempotency, or what happens after triggering (e.g., does it return job status?). For a mutation tool with no structured safety or output information, more context is needed to guide an agent effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with the single parameter 'id' documented as 'Cron job ID'. The description adds no additional meaning beyond this, such as format examples or where to obtain the ID. With high schema coverage, the baseline score of 3 is appropriate as the schema already provides adequate parameter information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('trigger') and resource ('cron job') with the specific timing constraint 'immediately'. It distinguishes this tool from siblings like goclaw_cron_create, goclaw_cron_list, etc., by focusing on execution rather than management, though it doesn't explicitly contrast with goclaw_cron_toggle which might also affect job execution.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing an existing cron job ID), exclusions, or how it differs from siblings like goclaw_cron_toggle (which might enable/disable jobs) or goclaw_custom_tool_invoke (which runs custom tools). Usage is implied but not explicitly defined.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the action ('Enable or disable') but fails to describe critical traits: whether this is a mutating operation (implied but not explicit), what permissions are required, if changes are reversible, potential side effects (e.g., affecting scheduled runs), or error conditions. For a tool that modifies system state, this omission is significant and reduces transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's function without unnecessary words. It is front-loaded with the core action and resource, making it immediately scannable. Every word earns its place, achieving ideal conciseness for a simple tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (a state-changing operation with no annotations and no output schema), the description is incomplete. It lacks behavioral details (e.g., mutation effects, error handling), usage context, and output expectations. While the schema covers parameters well, the overall context for safe and effective use is insufficient, especially for a tool that alters cron job states.
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 ('id' and 'enabled') clearly documented in the schema. The description adds no additional semantic context beyond what the schema provides (e.g., format of 'id', implications of toggling). This meets the baseline score of 3, as the schema adequately covers parameter meaning without requiring description supplementation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Enable or disable') and the resource ('a cron job'), making the purpose immediately understandable. It distinguishes itself from sibling tools like 'goclaw_cron_create', 'goclaw_cron_delete', and 'goclaw_cron_run' by focusing on toggling status rather than creation, deletion, or execution. However, it doesn't explicitly differentiate from 'goclaw_cron_update', which might also handle status changes, preventing a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing an existing cron job ID), exclusions, or comparisons to sibling tools like 'goclaw_cron_update' or 'goclaw_cron_list'. This lack of context leaves the agent to infer usage from the tool name alone, which is insufficient for optimal selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. While 'Create' implies a write operation, it doesn't specify permissions needed, whether the tool is idempotent, potential side effects (e.g., overwriting existing tools), or error handling. This is a significant gap for a mutation tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that states the core purpose without any fluff. It's front-loaded and wastes no words, making it easy for an agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool that creates custom tools with 6 parameters and no annotations or output schema, the description is inadequate. It doesn't explain what a 'custom tool' entails in GoClaw, how the created tool integrates with the system, or what happens post-creation (e.g., success response or error cases). This leaves critical gaps for an agent to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all 6 parameters thoroughly. The description adds no additional meaning beyond what's in the schema (e.g., it doesn't explain relationships between parameters like 'parameters' and 'command'). Baseline 3 is appropriate when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Create') and resource ('new custom tool in GoClaw'), making the purpose immediately understandable. However, it doesn't differentiate this tool from sibling tools like 'goclaw_custom_tool_update' or 'goclaw_custom_tool_invoke', which would require more specific context about when to create versus update or invoke.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With siblings like 'goclaw_custom_tool_update' and 'goclaw_custom_tool_invoke', there's no indication of prerequisites (e.g., tool must not exist), appropriate contexts, or exclusions, leaving the agent to guess based on tool names alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only states the action ('Delete') without behavioral details. It doesn't disclose whether deletion is permanent/reversible, requires specific permissions, has side effects (e.g., affecting associated agents), or returns confirmation data. For a destructive operation, this leaves critical gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero wasted words. It's front-loaded with the core action and resource, making it immediately scannable and appropriately sized for its purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive tool with no annotations and no output schema, the description is insufficient. It doesn't explain behavioral implications (e.g., permanence, permissions), return values, or error conditions. Given the complexity of deletion operations and lack of structured data, more context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100% (parameter 'id' is documented as 'Custom tool ID'), so the baseline is 3. The description adds no additional parameter context beyond what the schema provides, such as where to obtain the ID or format requirements.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Delete') and resource ('a custom tool from GoClaw'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'goclaw_custom_tool_get' or 'goclaw_custom_tool_update', which would require specifying this is specifically for removal operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. There's no mention of prerequisites (e.g., needing the tool ID from a list operation), when not to use it (e.g., if the tool is in use), or comparison to siblings like 'goclaw_custom_tool_update' for modifications instead of deletion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states 'Get details' but doesn't disclose behavioral traits such as whether this is a read-only operation, if it requires authentication, potential error conditions (e.g., invalid ID), or rate limits. The description is minimal and lacks essential context for safe and effective use.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with zero waste—it directly states the tool's purpose without fluff. It's appropriately sized for a simple retrieval tool and front-loaded with the essential action, making it efficient for an agent to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description is incomplete. It doesn't explain what details are returned (e.g., tool configuration, metadata), error handling, or dependencies. For a tool with no structured output documentation, this leaves significant gaps in understanding its behavior and results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the single parameter 'id' documented as 'Custom tool ID'. The description doesn't add meaning beyond this, such as format examples or where to obtain the ID. Since the schema does the heavy lifting, the baseline score of 3 is appropriate, but no extra value is provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get details') and resource ('a custom tool'), which is specific and informative. However, it doesn't differentiate from sibling tools like 'goclaw_custom_tool_list' or 'goclaw_custom_tool_invoke', which would require mentioning it retrieves details for a specific ID rather than listing all tools or invoking one.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing a custom tool ID), contrast with 'goclaw_custom_tool_list' for listing all tools, or specify use cases like retrieving metadata before invocation. This leaves the agent to infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It only states what the tool does ('List custom tools') without mentioning whether this is a read-only operation, what permissions are required, whether results are paginated, or what format the output takes. This leaves significant behavioral questions unanswered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that states exactly what the tool does without any wasted words. It's appropriately sized for a simple listing tool and is front-loaded with the essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a listing tool with no annotations and no output schema, the description is insufficiently complete. It doesn't describe the return format, whether results are filtered/paginated, what permissions are required, or how it differs from sibling tools. Given the lack of structured data elsewhere, the description should provide more context about the tool's behavior and output.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already fully documents the single optional parameter. The description doesn't add any parameter information beyond what's in the schema, which is acceptable given the high schema coverage. The 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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('List') and resource ('custom tools defined in GoClaw'), providing a specific verb+resource combination. However, it doesn't differentiate from sibling tools like 'goclaw_custom_tool_get' or 'goclaw_custom_tool_invoke', which would require more specific scope information.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. There are multiple sibling tools related to custom tools (create, delete, get, invoke, update), but the description doesn't indicate when listing is appropriate versus getting a specific tool or invoking one.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only states the action ('Remove') without disclosing behavioral traits. It doesn't mention if this is destructive, requires specific permissions, has side effects, or what happens on success/failure, which is critical for a deletion 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, direct sentence with zero wasted words, clearly front-loading the core action. It's appropriately sized for a simple tool, making it easy to parse quickly without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's destructive nature (implied by 'Remove'), lack of annotations, and no output schema, the description is incomplete. It doesn't address behavioral risks, success indicators, or error conditions, leaving gaps that could hinder safe and effective agent invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the input schema fully documents the 'id' parameter. The description adds no additional meaning beyond what the schema provides, such as format examples or source hints, but meets the baseline since the schema handles parameter documentation adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Remove') and target ('a registered MCP server from GoClaw'), making the purpose evident. However, it doesn't explicitly differentiate from sibling tools like 'goclaw_mcp_server_delete' vs 'goclaw_mcp_server_update' or 'goclaw_mcp_server_grant_agent', leaving room for ambiguity in sibling context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing an existing server ID), exclusions, or comparisons to related tools like 'goclaw_mcp_server_list' for verification, leaving the agent without context for appropriate selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. While 'grant access' implies a permission change, the description doesn't specify what type of access is granted, whether this is reversible, what permissions are required to execute this operation, or what happens on success/failure. This is inadequate for a permission-modifying tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that states the core purpose without unnecessary words. It's front-loaded with the essential information and wastes no space on redundant details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool that modifies permissions (a potentially sensitive operation), the description is insufficient. With no annotations and no output schema, the description should provide more behavioral context about what 'grant access' entails, what permissions are required, and what the expected outcome is. The current description leaves too many important questions unanswered.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, with both parameters clearly documented in the schema itself. The description doesn't add any additional semantic context about the parameters beyond what's already in the schema, so it meets the baseline expectation when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('grant access') and the target resource ('an MCP server'), making the purpose immediately understandable. However, it doesn't differentiate this tool from its sibling 'goclaw_mcp_server_grant_user', which appears to perform a similar function for users rather than agents.
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. There's no mention of prerequisites (like needing existing server and agent IDs), when this operation is appropriate, or how it differs from the similar 'goclaw_mcp_server_grant_user' tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden but provides minimal behavioral context. It states it's a grant operation (implying a write/mutation), but doesn't disclose required permissions, whether changes are reversible, error conditions, or what happens on success. For a permission-modifying tool, this leaves critical gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose with zero wasted words. It's appropriately front-loaded and doesn't contain unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a permission-granting tool with no annotations and no output schema, the description is insufficient. It doesn't explain what 'access' entails, the response format, error handling, or security implications. Given the complexity of access control operations, more context is needed for safe use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both parameters clearly documented in the schema. The description doesn't add any meaning beyond what the schema provides (e.g., format of IDs, where to find them, or validation rules). Baseline 3 is appropriate when schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Grant') and resource ('access to an MCP server'), specifying it's for a user. It distinguishes from sibling 'goclaw_mcp_server_grant_agent' by targeting users instead of agents, but doesn't explicitly differentiate from other permission-related tools like 'goclaw_skill_grant_user'.
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 is provided. The description doesn't mention prerequisites (e.g., server must exist, user must be valid), nor does it clarify what type of access is granted or how this differs from similar tools like 'goclaw_skill_grant_user' or 'goclaw_agent_share'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states 'Store a new memory document' which implies a write/mutation operation, but doesn't disclose behavioral traits like whether it overwrites existing documents, requires specific permissions, returns an ID or confirmation, or has side effects. For a mutation tool with zero annotation coverage, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without fluff. It's front-loaded and wastes no words, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given this is a mutation tool (implied by 'Store') with no annotations and no output schema, the description is incomplete. It doesn't cover what happens on success/failure, return values, or error conditions. For a tool that creates persistent data, more context is needed to use it effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all three parameters (agent_id, path, content). The description doesn't add any meaning beyond what the schema provides—it doesn't explain what a 'memory document' is, how 'path' is structured, or constraints on 'content'. Baseline 3 is appropriate when schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Store') and the resource ('a new memory document for an agent'), making the purpose evident. It distinguishes this tool from siblings like goclaw_memory_get or goclaw_memory_delete by specifying it's for creation/storage, not retrieval or deletion. However, it doesn't explicitly differentiate from other 'create' tools like goclaw_agent_create, so it's not a perfect 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., agent must exist), exclusions, or compare it to similar tools like goclaw_agent_files_set. Without any usage context, the agent must infer from the name and schema alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. While 'Delete' implies a destructive mutation, the description doesn't specify whether this action is reversible, requires specific permissions, has side effects (e.g., on related data), or provides confirmation of deletion. For a mutation tool with zero annotation coverage, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence with no wasted words. It front-loads the key action ('Delete') and resource ('a memory document'), making it immediately scannable and efficient. Every word earns its place by conveying essential information without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's destructive nature and lack of annotations or output schema, the description is incomplete. It doesn't address critical aspects like success/failure responses, error conditions, or behavioral nuances (e.g., idempotency). For a deletion tool with no structured safety hints, more context is needed to ensure safe and correct usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, with the single parameter 'id' clearly documented as 'Memory document ID'. The description doesn't add any semantic details beyond what the schema provides, such as format examples or sourcing instructions. With high schema coverage, the baseline score of 3 is appropriate, as the schema adequately handles parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Delete') and resource ('a memory document'), making the purpose immediately understandable. It distinguishes from sibling tools like goclaw_memory_create, goclaw_memory_get, and goclaw_memory_list by specifying deletion rather than creation, retrieval, or listing. However, it doesn't specify what constitutes a 'memory document' in this context, leaving some ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing an existing memory document ID), exclusions, or comparisons to other memory-related tools like goclaw_memory_get or goclaw_memory_list. This lack of context could lead to misuse, such as attempting deletion without proper identification.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. 'Add' implies a write/mutation operation, but the description doesn't disclose important traits: whether this requires authentication/permissions, if it's idempotent, what happens on success/failure, or any rate limits. For a creation tool with zero annotation coverage, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that states the core purpose without unnecessary words. It's appropriately sized for a creation tool and front-loads the essential information. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a creation tool with 5 parameters, no annotations, and no output schema, the description is incomplete. It doesn't explain what happens after creation (e.g., returns a provider ID), error conditions, or system-wide implications. The agent lacks sufficient context to use this tool effectively beyond the basic parameter schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all 5 parameters with clear descriptions. The description adds no additional parameter context beyond what's in the schema (e.g., format examples for 'type', validation rules, or how 'models' interacts with provider capabilities). Baseline 3 is appropriate when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Add') and resource ('a new LLM provider to GoClaw'), making the purpose immediately understandable. However, it doesn't differentiate from sibling provider tools like goclaw_provider_update or goclaw_provider_delete, which would require mentioning this is specifically for creation/initial addition.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing admin access), when to choose this over goclaw_provider_update, or what happens if a provider with the same name already exists. This leaves the agent with insufficient context for appropriate tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only states the action ('Remove') without disclosing behavioral traits. It doesn't indicate if this is destructive (likely yes, but not confirmed), requires specific permissions, has side effects (e.g., affecting dependent agents), or what happens on success/failure. This is inadequate for a mutation tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero wasted words. It's front-loaded with the core action and resource, making it easy to parse quickly. Every word earns its place, achieving optimal conciseness for such a simple tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (a deletion operation with no annotations and no output schema), the description is incomplete. It lacks crucial context: behavioral details (destructiveness, permissions), usage guidelines (when to use, alternatives), and expected outcomes. For a mutation tool, this leaves significant gaps that could hinder correct agent invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds no parameter semantics beyond what the input schema provides. The schema has 100% coverage with a clear 'id' parameter description ('Provider ID'), so the baseline is 3. The description doesn't elaborate on format, sourcing (e.g., from 'goclaw_provider_list'), or validation rules, but the schema suffices for basic 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 action ('Remove') and resource ('an LLM provider from GoClaw'), making the purpose specific and understandable. However, it doesn't explicitly differentiate from sibling tools like 'goclaw_provider_delete' vs 'goclaw_provider_update' or 'goclaw_provider_get', which would require mentioning it's a deletion operation specifically.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing the provider ID), consequences (e.g., irreversible deletion), or related tools like 'goclaw_provider_list' to find IDs or 'goclaw_provider_create' for alternatives. This leaves the agent without context for appropriate usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions 'preview' and 'recent messages,' which implies a read-only operation, but doesn't specify permissions, rate limits, whether it's safe or destructive, or what the output format looks like. This leaves significant gaps for an AI agent to understand the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without any unnecessary words. It's appropriately sized and front-loaded, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description is incomplete. It doesn't explain what 'preview' entails (e.g., format, pagination, or error handling) or provide context for usage. For a tool with no structured behavioral data, more detail is needed to help an AI agent use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the input schema already documents both parameters ('session_key' and 'limit') adequately. The description doesn't add any meaning beyond what the schema provides, such as explaining what a 'session key' represents or how 'recent' is defined. This meets the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb ('preview') and resource ('recent messages in a chat session'), making it easy to understand what the tool does. However, it doesn't explicitly differentiate from sibling tools like 'goclaw_session_list' or 'goclaw_session_get', which might also involve session data retrieval.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With sibling tools like 'goclaw_session_list' and 'goclaw_session_get' available, there's no indication of when this preview tool is preferred or what distinguishes it from other session-related tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states this is a 'grant' operation which implies a write/mutation, but doesn't disclose behavioral traits like required permissions, whether this is idempotent, what happens on failure, or if there are rate limits. For a mutation tool with zero annotation coverage, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with zero wasted words. It's perfectly front-loaded, immediately conveying the core purpose without unnecessary elaboration. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, the description is incomplete. It doesn't explain what 'grant access' entails (e.g., what permissions are granted), what the return value might be, or potential side effects. Given the complexity of access control operations, more context is needed for the agent to use this tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both parameters clearly documented in the schema. The description doesn't add any additional meaning about the parameters beyond what the schema provides (skill_id and user_id). This meets the baseline expectation when schema coverage is complete.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Grant') and the resource ('access to a skill'), making the purpose immediately understandable. It distinguishes from sibling tools like 'goclaw_skill_grant_agent' by specifying 'user' rather than 'agent', but doesn't explicitly differentiate from other grant-like operations in the sibling list.
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 description doesn't mention prerequisites (e.g., existing skill/user), when not to use it, or what happens after granting access. With many sibling tools available, this lack of context leaves the agent guessing about appropriate usage scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. 'Create a new agent team' implies a write/mutation operation, but it doesn't specify required permissions, whether the operation is idempotent, what happens on duplicate names, or what the response contains (e.g., team ID). For a mutation tool with zero annotation coverage, this is a significant gap in transparency about how the tool behaves beyond basic functionality.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that states the core functionality without unnecessary words. It's appropriately sized for a straightforward creation tool and front-loads the essential information. Every word earns its place, making it easy for an agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given this is a mutation tool (create) with no annotations and no output schema, the description is insufficiently complete. It doesn't explain what happens after creation (e.g., returns a team object/ID), error conditions, or behavioral nuances. For a tool that modifies system state, more context about outcomes and constraints would help the agent use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with all parameters (name, description, member_agent_ids) having clear descriptions in the schema. The tool description adds no additional parameter information beyond what the schema provides. According to scoring rules, when schema_description_coverage is high (>80%), the baseline is 3 even with no param info in the description, which applies here.
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 'Create a new agent team' clearly states the action (create) and resource (agent team), making the purpose immediately understandable. It distinguishes from sibling tools like goclaw_team_get, goclaw_team_list, goclaw_team_update, and goclaw_team_delete by specifying creation rather than retrieval, listing, modification, or deletion. However, it doesn't explicitly differentiate from other creation tools like goclaw_agent_create or goclaw_memory_create beyond the resource type.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., existing agents for member_agent_ids), when creation is appropriate versus updating existing teams, or how it relates to sibling tools like goclaw_team_update for modifications. The agent must infer usage from the tool name and schema alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states this is a list operation, implying it's likely read-only and non-destructive, but doesn't confirm this explicitly. It doesn't describe what the output looks like (e.g., format, structure, pagination), error conditions, or any rate limits or permissions required. For a tool with zero annotation coverage, this leaves significant gaps in understanding its behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose ('List context files') and includes helpful examples ('SOUL.md, IDENTITY.md, etc.'). There's zero waste—every word contributes to understanding the tool's function without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (one parameter, no nested objects) and high schema coverage, the description is minimally adequate. However, with no annotations and no output schema, it fails to address key behavioral aspects like output format or safety. It provides enough to identify the tool's purpose but leaves the agent guessing about practical usage and results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, with the single parameter 'agent_id' fully documented in the schema. The description doesn't add any parameter-specific details beyond what's in the schema (e.g., format examples, where to find agent IDs, or constraints). Since the schema does the heavy lifting, the baseline score of 3 is appropriate, as the description doesn't compensate but also doesn't detract.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('List') and resource ('context files for an agent'), with specific examples of file types (SOUL.md, IDENTITY.md). It distinguishes this tool from other agent file operations like 'get', 'set', and 'delete' by focusing on listing rather than individual file manipulation. However, it doesn't explicitly differentiate from other list operations like goclaw_agent_list or goclaw_agent_links_list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (like needing an existing agent), compare it to sibling tools (like goclaw_agent_files_get for retrieving specific files), or indicate scenarios where listing files is appropriate versus other operations. The agent must infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool lists delegation links, implying a read-only operation, but doesn't specify whether it requires authentication, returns paginated results, has rate limits, or what format the output takes (e.g., list of agent IDs or detailed objects). For a tool with zero annotation coverage, this leaves significant gaps in understanding its behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It is front-loaded with the core action ('List delegation links') and includes clarifying information ('which agents it can delegate to') that adds value. There is zero waste 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?
Given the tool's low complexity (one required parameter) and high schema coverage (100%), the description is minimally adequate. However, with no annotations and no output schema, it fails to address behavioral aspects like authentication needs, output format, or error handling. For a read operation, this is a moderate gap, but the simplicity of the tool keeps it from being severely incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with the single parameter 'agent_id' documented as 'Agent ID'. The description adds no additional semantic context about this parameter (e.g., where to find the agent ID, format requirements, or validation rules). Since the schema already fully describes the parameter, the baseline score of 3 is appropriate, as the description doesn't compensate but also doesn't detract.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('List delegation links') and the target resource ('for an agent'), with additional clarification about what delegation links represent ('which agents it can delegate to'). It distinguishes from siblings like 'goclaw_agent_links_remove' and 'goclaw_agent_links_set' by focusing on listing rather than modifying. However, it doesn't explicitly differentiate from 'goclaw_agent_list' or other list tools, which slightly reduces specificity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing an existing agent ID), exclusions, or comparisons to sibling tools like 'goclaw_agent_list' (which might list agents themselves) or 'goclaw_agent_get' (which might retrieve agent details). Usage is implied from the name and description but not explicitly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. While 'List all agents' implies a read-only operation, it doesn't address important aspects like whether this requires authentication, returns paginated results, includes rate limits, or what format the output takes. The description provides minimal behavioral context beyond the basic action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that states the core purpose without any unnecessary words. It's appropriately sized for a simple list operation and front-loads the essential information. 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 operation with one optional parameter and no output schema, the description is minimally adequate. However, with no annotations and multiple sibling tools, it lacks important context about authentication requirements, output format, pagination, and differentiation from similar tools. The description covers the basic 'what' but not the 'how' or 'when'.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 100% description coverage, with the single parameter 'include_deleted' clearly documented in the schema itself. The description doesn't mention this parameter at all, so it adds no semantic value beyond what the structured schema already provides. This meets the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('List all agents') and resource ('configured in GoClaw gateway'), providing a specific verb+resource combination. However, it doesn't explicitly differentiate from sibling tools like 'goclaw_agent_get' (which likely retrieves a single agent) or 'goclaw_agent_files_list' (which lists agent files rather than agents themselves).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With multiple sibling tools like 'goclaw_agent_get' (for single agent retrieval) and 'goclaw_agent_files_list' (for agent files), the agent receives no explicit or implicit direction about appropriate use cases or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool is for getting configuration, implying a read-only operation, but doesn't specify permissions required, rate limits, error conditions, or what the output looks like (e.g., format, structure). This leaves significant gaps for an agent to understand how to use it effectively.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose ('Get current GoClaw gateway configuration') and adds optional functionality ('or a specific section') without unnecessary words. It's appropriately sized for a simple tool with one optional parameter.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (one optional parameter, no output schema, no annotations), the description is minimally adequate. It covers the basic purpose but lacks details on usage context, behavioral traits, and output expectations. For a read operation with no annotations, more information on permissions or response format 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 description adds minimal semantics beyond the input schema. It mentions 'a specific section' which aligns with the 'section' parameter in the schema, but the schema already has 100% description coverage (e.g., 'Config section (e.g. gateway, agents, tools, channels)'). The description doesn't provide additional details like default behavior when no section is specified or examples of valid sections beyond what's implied.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get current GoClaw gateway configuration (or a specific section)'. It specifies the verb ('Get') and resource ('GoClaw gateway configuration'), making the action clear. However, it doesn't explicitly differentiate from sibling tools like 'goclaw_config_apply' or 'goclaw_config_patch', which are write operations, though the 'Get' verb implies read-only distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It mentions retrieving 'a specific section' but doesn't clarify when to use this versus other config-related tools (e.g., 'goclaw_config_apply' for applying changes) or other read tools (e.g., 'goclaw_status' for status checks). No prerequisites or exclusions are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states it's a list operation, implying read-only behavior, but doesn't disclose any behavioral traits like whether it requires authentication, returns paginated results, includes inactive jobs, or has rate limits. The description is minimal and lacks necessary context for safe invocation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without any fluff. It's appropriately sized for a simple list operation with no parameters.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and a simple list operation, the description is incomplete. It doesn't explain what the return format looks like (e.g., array of cron job objects), whether it includes metadata, or any error conditions. For a tool with zero structured support, more context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters with 100% schema description coverage (empty schema). The description doesn't need to add parameter semantics since there are none, so it appropriately doesn't mention any. A baseline of 4 is justified as the description doesn't mislead about parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('List') and resource ('all cron jobs in GoClaw'), making the purpose immediately understandable. However, it doesn't differentiate from sibling cron tools like 'goclaw_cron_create' or 'goclaw_cron_delete' beyond the basic list vs. create/delete distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives. While the name implies it's for listing cron jobs, there's no mention of prerequisites, when it's appropriate versus other cron operations, or any contextual constraints.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only states what the tool does, not how it behaves. It doesn't disclose whether this is a read-only operation, what authentication is needed, what the output format might be, or any rate limits or side effects. The description is minimal and lacks 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 a single, efficient sentence with no wasted words. It's front-loaded with the core purpose and doesn't include unnecessary elaboration, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a health-check tool with no annotations and no output schema, the description is insufficient. It doesn't explain what 'health status' means, what metrics or indicators are returned, or how to interpret results. Given the complexity of health monitoring and lack of structured data, more context is needed for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters with 100% schema description coverage (empty schema), so no parameter documentation is needed. The description appropriately doesn't discuss parameters, which aligns with the schema. A baseline of 4 is applied since the schema fully covers the parameter situation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Check') and target ('GoClaw gateway health status'), making the purpose immediately understandable. It doesn't differentiate from siblings like 'goclaw_status' which might have overlapping functionality, but the verb+resource combination is specific enough for basic understanding.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'goclaw_status' or other health-checking tools. There's no mention of prerequisites, timing considerations, or comparative context with sibling tools, leaving the agent to infer usage scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. 'Register' implies a write/mutation operation, but the description doesn't mention permissions required, whether this is idempotent, what happens on duplicate names, or what the response contains. For a creation tool with zero annotation coverage, this is a significant gap in 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 a single, efficient sentence with zero waste. It's appropriately sized for a tool with comprehensive schema documentation and gets straight to the point without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a creation tool with 9 parameters, no annotations, and no output schema, the description is minimal but functional. The 100% schema coverage helps compensate, but the description itself doesn't provide context about what 'registration' entails, what happens after creation, or how this fits into the broader MCP server lifecycle. It's adequate but leaves gaps in understanding the tool's role and behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all 9 parameters thoroughly. The description adds no additional parameter semantics beyond what's in the schema. The baseline score of 3 is appropriate when the schema does the heavy lifting for parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Register') and resource ('new MCP server in GoClaw'), providing specific verb+resource pairing. However, it doesn't differentiate from sibling tools like goclaw_mcp_server_update or goclaw_mcp_server_list, which would require mentioning this is specifically for creation/registration.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like goclaw_mcp_server_update or goclaw_mcp_server_list. There's no mention of prerequisites, typical use cases, or when this specific creation tool is appropriate versus other MCP server operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states 'Get details' which implies a read-only operation, but doesn't disclose behavioral traits like authentication requirements, rate limits, error conditions, or what 'details' include. For a tool with no annotations, this leaves significant gaps in understanding how it behaves.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with zero wasted words. It's front-loaded with the core purpose and appropriately sized for a simple retrieval tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (single required parameter) and 100% schema coverage, the description is minimally adequate. However, with no annotations and no output schema, it should ideally provide more context about what 'details' are returned or any behavioral constraints. It meets basic needs but leaves room for improvement.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with the single parameter 'id' documented as 'MCP server ID'. The description doesn't add any meaning beyond this, such as format examples or where to find the ID. With high schema coverage, the baseline score of 3 is appropriate as the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get details') and resource ('registered MCP server'), making the purpose immediately understandable. However, it doesn't distinguish this tool from its sibling 'goclaw_mcp_server_list' which likely lists servers rather than getting details of a specific one, so it misses full sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (like needing a server ID), when not to use it, or how it differs from similar tools like 'goclaw_mcp_server_list' or 'goclaw_mcp_server_get' vs 'goclaw_mcp_server_update'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool is for reading, implying it's non-destructive, but doesn't clarify if it requires specific permissions, has rate limits, returns structured data or raw content, or handles errors. For a read operation with zero annotation coverage, this leaves significant gaps in understanding how the tool behaves.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no wasted words. It front-loads the key action ('Read') and resource ('memory document's content'), making it immediately understandable. Every part of the sentence contributes directly to the tool's purpose, achieving optimal conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, 100% schema coverage, no output schema), the description is minimally adequate. It covers the basic action but lacks details on behavioral aspects like permissions, error handling, or return format. Without annotations or an output schema, the description should ideally provide more context about what 'content' entails and any usage constraints, but it's sufficient for a straightforward read 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?
The input schema has 100% description coverage, with the 'id' parameter documented as 'Memory document ID'. The description adds no additional semantic context beyond implying the ID is used to fetch content. Since the schema already provides adequate parameter documentation, the baseline score of 3 is appropriate, as the description doesn't enhance or detract from the schema's information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Read') and resource ('a memory document's content'), making the purpose immediately understandable. It distinguishes itself from siblings like goclaw_memory_create, goclaw_memory_delete, and goclaw_memory_list by focusing on reading content rather than creating, deleting, or listing. However, it doesn't specify what constitutes 'content' (e.g., text, metadata), which keeps it from a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing a valid memory document ID), exclusions, or comparisons to siblings like goclaw_memory_list for browsing or goclaw_memory_delete for removal. This lack of context leaves the agent to infer usage based on the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. It states it 'lists' documents, implying a read-only operation, but doesn't clarify if it's safe (non-destructive), requires authentication, has rate limits, or returns paginated results. For a list operation with zero annotation coverage, this leaves significant gaps in understanding how the tool behaves beyond its basic function.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence that efficiently conveys the tool's purpose without unnecessary words. It's front-loaded with the core action and resource, making it easy to parse. Every part of the sentence earns its place by specifying what is listed and for whom.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (list operation with 2 parameters) and high schema coverage (100%), the description is minimally adequate. However, with no annotations and no output schema, it lacks details on behavioral traits (e.g., safety, pagination) and return values. For a basic list tool, it meets the minimum but doesn't provide a complete picture for an agent to use it confidently without additional context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents both parameters (agent_id as required, user_id as optional filter). The description adds no parameter-specific information beyond implying the tool lists documents 'for an agent' (aligning with agent_id). Since the schema does the heavy lifting, the baseline score of 3 is appropriate, as the description doesn't enhance parameter understanding but doesn't detract either.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('List') and resource ('memory documents stored for an agent'), making the purpose immediately understandable. It distinguishes itself from sibling tools like goclaw_memory_create, goclaw_memory_delete, and goclaw_memory_get by focusing on listing rather than creating, deleting, or retrieving individual documents. However, it doesn't specify scope (e.g., all documents vs. filtered) or differentiate from other list tools like goclaw_agent_list or goclaw_session_list beyond the resource type.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing an existing agent), exclusions (e.g., not for modifying documents), or comparisons to sibling tools like goclaw_memory_get (for single documents) or goclaw_agent_files_list (for files vs. memory). Usage is implied by the name and purpose but not explicitly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states it 'Get details', implying a read-only operation, but doesn't specify if it requires authentication, rate limits, error conditions, or what 'details' include (e.g., configuration, status). For a read tool with zero annotation coverage, this leaves significant gaps in understanding its behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with zero waste—it directly states the tool's purpose without unnecessary words. It's appropriately sized and front-loaded, making it easy for an agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (single parameter, no output schema, no annotations), the description is minimally adequate. It states what the tool does but lacks details on usage, behavior, and output. For a simple read operation, this might suffice, but it doesn't provide complete context for reliable agent invocation without additional inference.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage (the 'id' parameter is described as 'Provider ID'), so the schema already documents the parameter adequately. The description doesn't add any extra meaning about the parameter (e.g., format, where to find the ID, examples). Baseline 3 is appropriate when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose as 'Get details of a specific LLM provider', which is a specific verb ('Get') and resource ('LLM provider'). It distinguishes from sibling tools like 'goclaw_provider_list' (which lists providers) and 'goclaw_provider_create' (which creates providers), but doesn't explicitly differentiate from 'goclaw_provider_get' vs other 'get' tools (e.g., 'goclaw_agent_get'), so it's not a perfect 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing a provider ID), when to use it over 'goclaw_provider_list', or any exclusions. The agent must infer usage from the tool name and context alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the destructive nature ('permanently'), which is critical. However, it lacks other behavioral details such as authentication requirements, error conditions (e.g., invalid session key), side effects, or confirmation prompts. For a deletion tool, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the key action ('Delete') and includes essential qualifiers ('permanently'). There is no wasted verbiage, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's destructive nature and lack of annotations or output schema, the description is minimally adequate. It covers the core action and permanence but omits important context like error handling, return values, or safety warnings. For a deletion tool, more completeness would be beneficial.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with 'session_key' clearly documented. The description adds no additional parameter semantics beyond what the schema provides. According to the rules, with high schema coverage (>80%), the baseline score is 3 even without param info in the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Delete') and target ('a chat session'), and specifies the permanence ('permanently'). It distinguishes from sibling tools like 'goclaw_session_reset' (which likely resets without deletion) and 'goclaw_session_list' (which lists sessions). However, it doesn't explicitly contrast with these siblings in the text.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing a valid session key), exclusions (e.g., not for active sessions), or refer to sibling tools like 'goclaw_session_reset' for non-destructive operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states 'Set a label/title', implying a write/mutation operation, but doesn't disclose behavioral traits like permissions needed, whether it overwrites existing labels, error conditions, or side effects. This leaves significant gaps for a tool that modifies session data.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with zero wasted words, making it front-loaded and efficient. It directly communicates the tool's purpose without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description is minimal but covers the basic action. However, for a mutation tool with two parameters, it lacks details on behavior, error handling, or return values, making it incomplete for safe and effective use by an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both parameters ('session_key' and 'label') documented in the schema. The description adds no additional meaning beyond the schema, such as format examples or constraints, so it meets the baseline of 3 where the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Set') and the target ('a label/title for a chat session'), making the purpose specific and understandable. However, it doesn't distinguish this tool from its sibling 'goclaw_session_list' or 'goclaw_session_delete' in terms of functionality, which prevents a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, such as when labeling is appropriate compared to other session operations like deletion or listing. There's no mention of prerequisites, context, or exclusions, leaving usage entirely implied.
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 filtering but doesn't describe key behaviors like pagination (implied by 'limit' parameter), sorting, error handling, or whether this is a read-only operation. For a list tool with zero annotation coverage, this leaves significant gaps in understanding how the tool behaves.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose ('List chat sessions') and adds a qualifying clause ('optionally filtered by agent'). There is no wasted language, and it's appropriately sized for a simple list tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (list operation with two optional parameters) and 100% schema coverage, the description is minimally adequate. However, with no annotations and no output schema, it lacks details on behavioral traits (e.g., pagination, read-only nature) and return format. It meets basic needs but could be more informative 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 description coverage is 100%, so the schema already documents both parameters ('agent_id' for filtering and 'limit' with default). The description adds minimal value by mentioning 'optionally filtered by agent', which aligns with 'agent_id', but doesn't provide additional context like filter syntax or usage examples. Baseline 3 is appropriate when the schema handles most documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('List chat sessions') and resource ('chat sessions'), making the purpose immediately understandable. It also mentions optional filtering ('optionally filtered by agent'), which adds specificity. However, it doesn't explicitly differentiate from sibling tools like 'goclaw_session_preview' or 'goclaw_session_delete', which would require more precise scope definition.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, compare with similar tools (e.g., 'goclaw_session_preview' for detailed views or 'goclaw_session_delete' for removal), or specify scenarios where filtering by agent is appropriate. Usage is implied but not explicitly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool resets a session by clearing message history, but doesn't mention whether this action is reversible, requires specific permissions, affects other session data, or has side effects like rate limits. This leaves significant gaps for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the purpose ('Reset a chat session') and adds clarifying detail ('clear message history') without any wasted words. It's appropriately sized for a simple tool.
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 mutation tool with no annotations and no output schema, the description is minimal but covers the basic action. It lacks details on behavioral traits, usage context, and output expectations, making it adequate but with clear gaps given the tool's potential complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with 'session_key' clearly documented. The description doesn't add any parameter details beyond what the schema provides, such as format examples or constraints. Baseline 3 is appropriate since the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Reset a chat session') and the effect ('clear message history'), which is specific and unambiguous. However, it doesn't differentiate from sibling tools like 'goclaw_session_delete' or 'goclaw_session_label', which might have overlapping or related purposes in session management.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as 'goclaw_session_delete' (which might permanently remove a session) or 'goclaw_session_label' (which might modify session metadata). The description lacks context on prerequisites, timing, or exclusions for usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states this is a 'Get' operation, implying it's read-only, but doesn't confirm safety aspects like whether it requires authentication, has rate limits, or what happens on errors (e.g., if the skill ID is invalid). This leaves significant gaps for an agent to understand its behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence that efficiently conveys the core purpose without any unnecessary words. It's front-loaded and wastes no space, making it easy for an agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (one required parameter, no output schema, no annotations), the description is minimally adequate but incomplete. It lacks details on what 'details' include, error handling, or behavioral traits, which could hinder an agent's ability to use it effectively in varied contexts.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds no parameter-specific information beyond what's in the input schema, which has 100% coverage and clearly documents the 'id' parameter as 'Skill ID'. Since the schema does the heavy lifting, the baseline score of 3 is appropriate, as the description doesn't enhance or clarify parameter usage further.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get details') and resource ('specific skill'), making the purpose immediately understandable. However, it doesn't differentiate this tool from its sibling 'goclaw_skill_list' (which presumably lists multiple skills), nor does it specify what 'details' include, keeping it from a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'goclaw_skill_list' or other skill-related tools. It lacks context about prerequisites, such as needing a skill ID from another operation, or any exclusions for its use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states 'grant access' which implies a mutation/write operation, but doesn't disclose behavioral traits like required permissions, whether it's idempotent, what happens on conflict (e.g., if agent already has access), rate limits, or what the response looks like (success/failure indicators). 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, clear sentence with zero waste—it directly states the tool's purpose without fluff. It's appropriately sized and front-loaded, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (a mutation with 2 parameters), lack of annotations, and no output schema, the description is minimally adequate but has clear gaps. It covers the basic purpose but misses behavioral details, usage context, and output expectations. It's complete enough to understand what the tool does at a high level but not enough for reliable invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both parameters ('skill_id' and 'agent_id') documented in the schema. The description doesn't add any meaning beyond what the schema provides (e.g., format examples, where to find IDs, validation rules). Baseline 3 is appropriate when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('grant') and resource ('access to a skill') with a specific target ('an agent'). It distinguishes from obvious siblings like 'goclaw_skill_grant_user' which grants to users instead of agents. However, it doesn't specify what 'access' entails (e.g., read, execute, modify) or differentiate from other agent-skill tools that might exist.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., agent and skill must exist), when not to use it (e.g., if agent already has access), or refer to related tools like 'goclaw_skill_list' to find skill IDs or 'goclaw_agent_list' for agent IDs. The context is implied but not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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. While it indicates this is a listing operation (implying read-only behavior), it doesn't specify whether this requires authentication, has rate limits, returns paginated results, or what format the output takes. For a tool with no annotation coverage, this leaves significant behavioral questions unanswered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that communicates the core functionality without unnecessary words. It's appropriately sized for a listing tool and front-loads the essential information. Every word earns its place in the description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (listing with filtering), 100% schema coverage, but no annotations and no output schema, the description is minimally adequate. It states what the tool does but leaves significant gaps about behavioral characteristics and output format. For a listing tool with filtering capabilities, more context about result format and behavioral constraints would be helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all three parameters with their descriptions. The tool description adds no additional parameter information beyond what's in the schema. According to the scoring rules, when schema coverage is high (>80%), the baseline is 3 even with no parameter information in the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('List') and resource ('LLM execution traces') with additional context about what data is included ('with cost and token usage'). It distinguishes itself from sibling tools like 'goclaw_trace_get' by indicating it's a listing operation rather than retrieval of a single trace. However, it doesn't explicitly contrast with other list operations in the system.
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. There's no mention of when this tool is appropriate compared to other trace-related tools (like 'goclaw_trace_get') or other listing tools in the system. The agent must infer usage from the name and description alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states it's a list operation, implying read-only behavior, but doesn't disclose any behavioral traits like pagination, rate limits, authentication requirements, or what data is returned. For a tool with zero annotation coverage, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose with no wasted words. It's front-loaded with the core action and resource, 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?
Given the tool has no parameters, no annotations, and no output schema, the description is minimally adequate but lacks completeness. It doesn't explain what the list output contains (e.g., channel IDs, names, types) or any behavioral context, which is needed for a tool with zero structured data.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters with 100% schema description coverage (empty schema). The description doesn't need to add parameter details, so it appropriately focuses on the tool's purpose. Baseline is 4 for zero parameters, as no compensation is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('List') and resource ('all messaging channels') with examples of channel types (Telegram, Discord). It distinguishes from sibling tools like goclaw_channel_toggle (which modifies channels) and other list tools for different resources, but doesn't explicitly differentiate from other list operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description doesn't mention prerequisites, limitations, or compare it to other list tools (e.g., goclaw_agent_list, goclaw_session_list). Usage is implied by the name and description alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states a read operation ('List'), implying it's non-destructive, but doesn't disclose behavioral traits like pagination, sorting, filtering, rate limits, authentication needs, or what 'registered' entails. This leaves significant gaps for a tool that likely returns a collection.
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, direct sentence with no wasted words. It's front-loaded with the core action and resource, making it highly efficient and 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?
Given zero parameters and no output schema, the description is minimally complete for a simple list tool. However, without annotations or output details, it lacks context on return format (e.g., array of objects), error handling, or system state implications, which could hinder agent usage.
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 0 parameters with 100% coverage, so no parameter documentation is needed. The description doesn't add param details, which is appropriate, but it could hint at implicit filtering (e.g., by status) to enhance semantics. Baseline is 4 for zero params.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('List') and resource ('all registered MCP servers in GoClaw'), making the purpose specific and understandable. It distinguishes from siblings like 'goclaw_mcp_server_get' (single server) and 'goclaw_mcp_server_create' (creation), though it doesn't explicitly mention these distinctions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, context (e.g., after server creation), or comparisons to other list tools (e.g., 'goclaw_agent_list'), leaving the agent to infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states the action ('List') but doesn't disclose behavioral traits like whether this is a read-only operation, if it requires authentication, what format the output takes, if there are rate limits, or if it's paginated. For a list operation with zero annotation coverage, this leaves significant gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that states exactly what the tool does with zero wasted words. It's front-loaded with the core action and resource, making it immediately scannable and understandable without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (0 parameters, no annotations, no output schema), the description is minimally complete. It tells the agent what the tool does but lacks important context about output format, behavioral constraints, and usage guidelines. For a basic list operation, this is adequate but leaves the agent to guess about implementation details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters with 100% schema description coverage (empty schema), so the baseline is 4. The description appropriately doesn't discuss parameters since none exist, and it doesn't need to compensate for any gaps. It correctly focuses on the tool's purpose rather than non-existent inputs.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('List') and resource ('all configured LLM providers'), making the purpose immediately understandable. It distinguishes from siblings like goclaw_provider_get (retrieve single provider) and goclaw_provider_create (create new provider) by focusing on listing all providers. However, it doesn't specify what 'configured' means or the scope of the listing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., whether providers must be configured first), when to choose this over goclaw_provider_get for specific providers, or any contextual constraints. The agent must infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It only states what the tool does ('List all available skills') but provides no information about permissions required, rate limits, pagination behavior, response format, or whether this is a read-only operation. For a tool with zero annotation coverage, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence that states exactly what the tool does with zero wasted words. It's appropriately sized and front-loaded with the essential information.
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 that this is a simple list operation with no parameters and no output schema, the description provides the basic purpose. However, with no annotations and no output schema, the description should ideally provide more context about what 'skills' are in this system and what the response looks like. The current description is minimally adequate but leaves important questions unanswered.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters with 100% schema description coverage, so the schema already fully documents the parameter situation. The description doesn't need to add parameter information, and it doesn't. A baseline of 4 is appropriate for zero-parameter tools where the schema coverage is complete.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('List') and target resource ('all available skills in GoClaw'), making the purpose immediately understandable. However, it doesn't differentiate this tool from other list tools in the sibling set (like goclaw_agent_list, goclaw_custom_tool_list, etc.), which would require 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 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. There are many other list tools in the sibling set (e.g., goclaw_agent_list, goclaw_custom_tool_list), but no indication of when this specific skill listing is appropriate versus those other resources.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states it's a list operation, implying it's likely read-only and non-destructive, but doesn't confirm this or provide details on output format, pagination, or error handling. For a tool with zero annotation coverage, this leaves significant gaps in understanding its behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no wasted words. It's front-loaded with the core action and resource, making it highly efficient and easy to parse at a glance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (0 parameters, no output schema, no annotations), the description is minimally adequate. It states what the tool does but lacks details on output format or behavioral traits. For a list operation, this might suffice, but without annotations or output schema, it leaves the agent guessing about the return structure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters with 100% schema description coverage, meaning the schema fully documents the lack of inputs. The description doesn't need to add parameter semantics, so it meets the baseline expectation. However, it doesn't explicitly state 'no parameters required,' which could slightly improve clarity, but this is minor.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('List all') and resource ('teams in GoClaw'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'goclaw_team_get' (which retrieves a specific team) or 'goclaw_team_create' (which creates a team), so it doesn't reach the highest score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With sibling tools like 'goclaw_team_get' for retrieving a specific team and 'goclaw_team_create' for creating teams, the agent must infer usage from the name alone, which is insufficient for clear decision-making.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool 'Get[s] detailed trace,' implying a read-only operation, but doesn't clarify aspects like authentication requirements, rate limits, error conditions, or what 'detailed' entails (e.g., format, depth). For a tool with no annotations, this leaves significant gaps in understanding its behavior and constraints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It is front-loaded with the core action ('Get detailed trace') and adds specificity ('with individual LLM call spans'), making it easy to parse and understand quickly. There is no wasted verbiage.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (a read operation with one parameter) and the absence of annotations and output schema, the description is minimally adequate. It covers the basic purpose but lacks details on behavior, output format, or error handling. For a tool that likely returns structured trace data, more context would be helpful, but it's not entirely incomplete for a simple get 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?
The input schema has 100% description coverage, with the single parameter 'trace_id' documented as 'Trace ID.' The description doesn't add any semantic details beyond this, such as format examples or where to obtain the trace ID. Since schema coverage is high, the baseline score of 3 is appropriate, as the description doesn't compensate but also doesn't detract from the schema's information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb ('Get') and resource ('detailed trace with individual LLM call spans'). It distinguishes this tool from its sibling 'goclaw_trace_list' by specifying it retrieves detailed information for a specific trace rather than listing traces. However, it doesn't explicitly contrast with other trace-related tools beyond the obvious list vs. get 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 context by specifying 'detailed trace' and mentioning 'individual LLM call spans,' suggesting this is for in-depth analysis of a specific trace. It doesn't provide explicit guidance on when to use this versus alternatives like 'goclaw_trace_list' or other trace tools, nor does it mention prerequisites or exclusions, leaving the agent to infer based on the tool name and description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses that this operation 'overwrites current config,' which is a critical behavioral trait indicating it's destructive and non-incremental. However, it lacks details on permissions needed, rate limits, error handling, or what happens to the gateway during application, leaving gaps in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with two sentences: one stating the purpose and one providing a caution. It's front-loaded with the core action and wastes no words, making it easy to parse quickly without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (a destructive configuration tool with nested objects) and lack of annotations or output schema, the description is minimally complete. It covers the overwrite behavior and caution but misses details like response format, side effects, or error conditions. For a high-stakes tool, more context would be beneficial.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, with the parameter 'config' described as 'Full configuration object to apply.' The description adds no additional parameter semantics beyond this, as it doesn't explain the structure, format, or examples of the config object. This meets the baseline for high schema coverage but doesn't enhance 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 action ('Apply a full configuration') and target resource ('to the GoClaw gateway'), with the verb 'apply' being specific. However, it doesn't explicitly differentiate from its sibling 'goclaw_config_patch', which likely applies partial configurations, though the 'full configuration' wording provides some 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 includes 'Use with caution,' which implies this is a high-impact operation, but it doesn't specify when to use this versus 'goclaw_config_patch' or other alternatives. There's no explicit guidance on prerequisites, timing, or exclusions, leaving usage context somewhat implied rather than clearly defined.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states it's a list operation, implying read-only behavior, but doesn't disclose traits like pagination, rate limits, authentication needs, or output format. For a tool with zero annotation coverage, this leaves significant behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose without any wasted words. It's appropriately sized for a simple list tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (0 parameters, no output schema, no annotations), the description is adequate but incomplete. It covers the purpose but lacks behavioral context (e.g., output structure, error handling), which is needed since no annotations or output schema exist to fill those gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters with 100% schema description coverage, so no parameter information is needed. The description appropriately doesn't discuss parameters, earning a baseline score of 4 for not adding unnecessary 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 clearly states the action ('List all available LLM models') and the resource scope ('across all configured providers'), using specific verbs and distinguishing it from sibling tools that manage agents, providers, sessions, etc. It precisely communicates what the tool does without being tautological.
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 to see available models, but lacks explicit guidance on when to use this versus alternatives (e.g., provider-specific listing tools if they existed) or prerequisites. It provides basic context but no exclusions or comparisons.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states this is a 'Get' operation, implying read-only behavior, but doesn't disclose any behavioral traits like authentication requirements, rate limits, error conditions, or what format the status information returns. The description is minimal and lacks operational context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the purpose ('Get GoClaw gateway status') and specifies the returned data. There's no wasted language, and it's appropriately sized for a simple status-checking tool.
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 zero-parameter tool with no annotations and no output schema, the description is complete in stating what it does. However, it lacks details about the return format (e.g., JSON structure) and any behavioral context (e.g., is this a real-time status or cached?), which would be helpful given the absence of structured output documentation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters with 100% schema description coverage, so no parameter information is needed. The description appropriately doesn't discuss parameters, focusing instead on what the tool returns. This meets the baseline expectation for a zero-parameter tool.
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 ('Get') and the specific resource ('GoClaw gateway status'), including what information will be returned ('version, uptime, and connection counts'). It distinguishes itself from all sibling tools which focus on agents, channels, configs, etc., rather than gateway status.
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 gateway status information is needed, but doesn't explicitly state when to use this tool versus alternatives. No exclusions or prerequisites are mentioned, though the context of sibling tools suggests this is for monitoring rather than configuration.
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:

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

Score Badge

Copy to your README.md:

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

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/nextlevelbuilder/goclaw-mcp'

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