hostinger-mcp-server

Server Quality Checklist

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

Latest release: v2.0.1
Disambiguation4/5
Most tools follow a clear resource_action pattern (e.g., vps_start, hosting_db_create, wp_plugins_list), which makes them easy to distinguish. However, with 284 tools, there are a few overlapping or ambiguous entries such as domains_get_list vs list_all_domains_paginated and hosting_deploy_js_app vs agency_deploy_node_static, which could lead to misselection.
Naming Consistency5/5
Tool names consistently follow a snake_case resource_verb convention across all domains (e.g., dns_get_records, mail_mailboxes_create, ecommerce_products_create_digital). Minor exceptions like health_check and account_overview are clear and do not break the overall pattern.
Tool Count1/5
Defining 284 tools is extreme, far beyond the recommended 3-15 range even for a comprehensive hosting platform. This scale creates a massive, hard-to-navigate tool surface and is likely to degrade agent performance rather than help it.
Completeness4/5
The tool set covers an impressively wide range of Hostinger services including billing, VPS, domains, hosting, WordPress, email, ecommerce, and agency plans. Some gaps exist such as lack of SSL/certificate management, VPS resizing, and a snapshot listing operation, but they are minor relative to the overall coverage.
Average 3.2/5 across 238 of 284 tools scored. Lowest: 1.9/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 5 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations present, the description must shoulder the burden of transparency, but it merely says 'Update a webhook' without disclosing side effects, permission requirements, or behavior if the webhook doesn't exist. It adds no behavioral context beyond the verb itself.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely brief, but this is under-specification rather than good conciseness. A single sentence that only restates the tool's purpose provides no useful information and fails to earn its place.
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 with three parameters, no annotations, and no output schema, the description is severely inadequate. It gives no context about required fields, effects of the update, or relationship to other webhook operations, leaving the agent without enough information to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides descriptions for all three parameters (webhook_id, url, event), so schema coverage is 100%, which establishes a baseline of 3. The description itself adds no extra parameter meaning, but the schema is sufficient to understand the basic semantics.
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 'Update a webhook' is essentially a tautology of the tool name and title. It doesn't specify that this is for mail webhooks or what specific attributes (URL, event) can be updated, and it doesn't distinguish the update operation from create or delete siblings.
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 mail_webhooks_create or mail_webhooks_delete. There's no mention of prerequisites, such as first retrieving the webhook_id via a list/get call, or any context for when updating is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of disclosing behavior, but it only states 'Get segment details' with no information about output format, pagination, error handling, or any side effects. It does not even clarify whether this is a read-only operation, which is critical given the 'reach_segments' naming implies a data structure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, which is not necessarily concise but under-specified. It lacks structure and does not earn its place because it repeats the tool's name and title without adding meaningful information.
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?
This is a simple one-parameter read tool, but the description is so minimal that it fails to convey essential information: what a 'segment' is, what details are included, and how this differs from list/contact tools. Without annotations or output schema, the description is the only source of context and it is woefully insufficient.
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 single parameter 'segment_uuid' is fully described in the schema (100% coverage), and the description 'Get segment details' adds minimal value but does not contradict. Since the schema already documents the parameter adequately, the baseline is 3, and the description's clarity about 'segment details' provides slight extra context.
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 only says 'Get segment details,' which is a vague verb+resource but lacks specificity about what a 'segment' is or what details are returned. It does not distinguish itself from sibling tools like reach_segments_list or reach_segments_contacts, leaving the agent unsure which tool to use.
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 given on when to use this tool versus alternatives. The presence of sibling tools like reach_segments_list, reach_segments_contacts, and reach_segments_profile_contacts creates ambiguity, but the description provides no exclusions or context to resolve it.
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?
The annotation destructiveHint=true already flags the operation as destructive. The description adds no additional context about the impact (e.g., overwriting current state, potential downtime, irreversibility). Since the description merely restates the action without enriching the safety profile, it adds minimal value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is only four words, which might seem concise, but it is under-specification rather than effective conciseness. It fails to provide necessary context and does not earn its place as a useful explanation, making it more of an omission than a well-structured description.
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 destructive operation with no output schema, this description is severely incomplete. It does not explain what a backup restore entails, any prerequisites, potential side effects, or what the response might be. The tool would be hard to use safely 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%, with clear descriptions for vm_id and backup_id. The description itself adds no parameter semantics, but according to the rubric, high schema coverage yields a baseline of 3. No extra meaning is provided, so the baseline stands.
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 'Restore a backup.' is essentially a less specific restatement of the title 'Restore VPS Backup'. It does not distinguish this from sibling tools like vps_restore_snapshot or vps_get_backups, and it fails to mention the VPS context explicitly.
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 or how it relates to alternatives such as vps_restore_snapshot. There are no exclusions, prerequisites, or alternative suggestions, leaving the agent without direction on tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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. It only states 'Stop' without mentioning whether the stop is graceful, whether data is preserved, or whether it affects billing. This is a significant omission for a mutating action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one short sentence with no wasted words, but it is under-specified. It is concise yet adds little value, similar to a minimal restatement rather than a helpful explanation. The structure is fine, but the content is too sparse to earn a higher score.
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 simple one-parameter tool, the description is still inadequate. It lacks context about the lifecycle of a VPS (e.g., how to resume, differences from restart), the consequences of stopping, and any practical details such as whether the vm_id refers to the same ID used in vps_list. The absence of an output schema and annotations further increases the need for descriptive context, which is not provided.
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% coverage for the single parameter vm_id, with a clear description 'Virtual machine ID'. The tool description adds nothing beyond this, so the baseline of 3 is appropriate—no extra context is provided, but none is required since the schema fully documents the parameter.
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 'Stop a virtual machine' is essentially a restatement of the title 'Stop VPS' and the tool name. It provides a verb and resource but adds no new information, failing to differentiate from sibling tools like vps_start or vps_restart beyond the obvious action.
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?
There is no guidance on when to use this tool versus alternatives such as vps_start, vps_restart, or vps_docker_stop. The description provides no context about prerequisites, side effects, or selection criteria, leaving the agent without decision support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility for behavioral disclosure. It only says 'Browse' which implies a read operation but provides no details about return format, filtering, pagination, or any side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, which is concise, but it is under-specified. 'Browse' is less precise than 'list available', and the sentence lacks essential scope information. This is closer to under-specification than effective conciseness.
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?
Despite having no parameters or output schema, the description is incomplete. It does not specify what the tool returns, whether it lists available themes from the repository, or whether it is a read-only operation. The minimal text leaves the tool's behavior largely undefined.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema already reflects this. The baseline for 0 params is 4, and the description need not add parameter details; there is nothing to explain.
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 'Browse WordPress themes' identifies the resource but uses the vague verb 'Browse' instead of 'list available' from the tool name. It does not clarify whether these are available or installed themes, so it fails to distinguish from sibling wp_themes_list_installed.
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?
No guidance is provided about when to use this tool versus alternatives like wp_themes_list_installed or wp_plugins_available. The description gives no context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure, but it only states the action. It does not mention side effects (e.g., invalidating sessions), permission requirements, or post-change behavior, making it impossible for an agent to predict the tool's full impact.
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, clear sentence with no unnecessary words. However, it is under-specified, meaning the conciseness comes at the cost of informativeness, so it does not fully earn 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 or output schema, the description is too sparse. It fails to mention any consequences of changing the password, such as whether existing sessions are terminated, or how the operation relates to mailbox management workflows.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides descriptions for both required parameters ('New password' and 'Mailbox ID'), so the description adds no additional meaning. With 100% schema coverage, the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Change a mailbox password.' is a direct restatement of the title 'Change Mailbox Password', adding no new information. While it identifies a specific resource (mailbox password), it does not elaborate on scope or distinguish from similar sibling tools like hosting_db_change_password.
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, such as mail_mailboxes_create or hosting_db_change_password. There are no prerequisites or exclusions mentioned, leaving the agent to infer the appropriate 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 present, so the description carries the full burden of behavioral disclosure. It fails to mention whether the email must be unique, what happens if the order_id is invalid, whether a confirmation is sent, or whether the operation is reversible.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short and front-loaded, but it is under-specified rather than concise. It omits necessary behavioral and contextual details that a one-sentence description could include, making it less than appropriately sized for a mutating 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 no annotations or output schema, the context is incomplete. A creation tool should at least mention that it requires an existing mail order and any side effects or return behavior; the description is insufficient for an agent to know when to invoke it safely.
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?
All three parameters (email, order_id, password) are documented in the schema with 100% coverage, so the baseline is 3. The description adds no additional semantics beyond the schema, such as password constraints or how to obtain the order_id.
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 says 'Create a new mailbox,' which is a clear verb+resource but merely restates the tool title and name. It adds no additional information about scope, constraints, or relation to the required order_id.
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, what prerequisites must exist (e.g., a valid mail order), or which alternative to choose among sibling tools like mail_aliases_create. The intended use is only implied by the verb 'create.'
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 only says 'Stop' without explaining side effects, whether the operation is safe, if it requires a running project, or what happens to data. This is a significant gap for a mutating operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, but this is under-specification rather than effective conciseness. It simply repeats the title without earning its place in the description. It lacks the substance needed to be genuinely helpful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no annotations and no output schema, the description is too sparse. It doesn't explain what 'stopping' does to the Docker project, whether data is persisted, any prerequisites, or what the response looks like. The agent is left with only the bare action.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with clear descriptions for 'vm_id' (Virtual machine ID) and 'project_name' (Project name). The text description adds nothing beyond the schema, which is acceptable given the high coverage, so a baseline of 3 is appropriate.
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 'Stop a Docker project.' is a direct restatement of the title 'Stop Docker Project'. It states the action clearly but adds no new information, making it a tautology. It does distinguish from siblings via the verb 'stop', but not explicitly beyond that.
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 vs alternatives like vps_docker_start, vps_docker_restart, or vps_docker_delete. There are no prerequisites, context, or examples. The description gives no directional information at all.
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?
The description adds no behavioral context beyond the annotations. The destructiveHint: true annotation already signals the destructive nature, but the description does not disclose specifics such as whether the deletion is permanent, irreversible, or has cascading effects on associated resources. No additional transparency is provided.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence and is concise, but it is also under-specified, essentially repeating the title. It is not excessively padded, but it lacks any informative structure or supplementary details that would earn a higher score. It is appropriately short, but conveys minimal value.
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 the lack of an output schema, the description is incomplete. It does not explain the effect of deletion, edge cases, or any required context for safe usage. The annotation and schema cover basic safety and parameters, but the description fails to provide a complete picture for 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?
The input schema has 100% description coverage: 'domain' is Website domain, 'username' is Hosting account username, 'subdomain' is Subdomain to delete. The description itself adds no further meaning or clarification, but the schema fully documents each parameter, so a baseline of 3 is appropriate.
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 'Delete a subdomain.' is a direct restatement of the tool name and title (hosting_subdomains_delete / Delete Subdomain), providing no additional clarification or distinction beyond what is already obvious. While it is not misleading, it is a tautology, which aligns with a score of 2.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers no guidance on when to use this tool versus alternatives (e.g., hosting_subdomains_list or hosting_subdomains_create), nor does it mention any prerequisites, exclusions, or special conditions. It simply states the action with no contextual usage information.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/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 only states 'Get snapshot details,' which implies a read operation but does not disclose what happens, what is returned, authentication requirements, or any side effects. There is no additional behavioral context beyond the verb 'Get.'
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, but it is under-specified rather than concise. It lacks essential details about what 'snapshot details' means or how the vm_id is used. While it is short, it does not earn its place by providing useful information beyond the title.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no description of return values, the tool is incomplete for an agent to understand what it will receive. The simplicity of the tool (one parameter) mitigates the gap, but the ambiguity about whether multiple snapshots are returned and the lack of any output description leaves significant 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 one parameter, vm_id, with 100% schema description coverage ('Virtual machine ID'). The description adds no extra meaning to this parameter or its relationship to snapshots. Baseline 3 is appropriate because the schema already fully documents the parameter, but the description does not enrich it.
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 'Get snapshot details' clearly indicates a read operation for snapshot information, with a specific verb and resource. It distinguishes from sibling tools like vps_create_snapshot, vps_restore_snapshot, and vps_delete_snapshot. However, it doesn't clarify whether it retrieves all snapshots for a VM or a single snapshot, which is ambiguous given the only parameter is vm_id.
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 is no mention of scenarios, exclusions, or references to sibling tools. It lacks any context such as 'Use this to view snapshot details for a VM' or 'For managing snapshots, see vps_create_snapshot/restore/delete.'
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, but it only restates the action. It fails to disclose prerequisites, side effects, permissions, or whether the database is tied to a website_uid, providing no behavioral insight beyond the bare action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, but it under-specifies the tool. It is too short to be useful and omits essential context, making it under-specification rather than effective conciseness.
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?
The tool has no output schema and no annotations, and the description does not explain the agency context, the relationship to website_uid, or the difference from hosting_db_create. This leaves the tool inadequately described for a create operation with required parameters.
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 provides 100% coverage with descriptions for all three parameters, so the baseline is 3. The description adds no additional semantic information beyond what the schema already 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 ('Create') and the resource ('a database'), making it unambiguous. However, it lacks the 'agency' scope present in the title and does not differentiate from sibling tools like hosting_db_create or agency_db_create_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 such as agency_db_create_user or hosting_db_create. It only states the action without any context about the intended use case or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of disclosing behavioral traits. It merely restates the action without any detail about privileges, side effects, idempotency, or error behavior. For a mutating operation, this is a critical omission.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence and front-loaded, but it is severely under-specified. It saves words at the expense of essential information, making it more under-specification than effective conciseness.
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 4 required parameters, no annotations, and no output schema, the description is too sparse. It does not explain the role of website_uid or database_name, what access the user gets, or how this fits into the broader agency database management context implied by sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers all 4 parameters with descriptions (100% coverage), establishing a baseline of 3. However, the parameter descriptions are minimal (just field names), and the tool description adds no further meaning or relationships between 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 action ('create') and the resource ('database user'), matching the tool's name. It is specific enough to convey the core function, though it does not explicitly differentiate from related tools like agency_db_create or hosting_db_create.
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 usage guidance is provided. The description does not indicate when to use this tool over alternatives, nor does it mention any prerequisites, context, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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. It gives no information about side effects (e.g., overwriting existing websites), required archive format, idempotency, or what happens to related resources. This is a significant gap for a mutating import operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise (one short sentence) and front-loaded, but it lacks substantive content. While there is no redundant wording, the extreme brevity makes it minimally informative rather than optimally concise.
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?
This is a potentially complex tool involving importing a website from an archive, yet there is no output schema and the description fails to explain the process, expected outcomes, or any operational context. The agent has no way to anticipate the tool's behavior or return value, making the description grossly 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 schema has 100% coverage for the single parameter and the description adds no meaning beyond the schema. Baseline 3 applies because the schema documents the parameter adequately, but the description does not enhance understanding of where to find the website_uid or its format.
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 uses a specific verb ('Import') and resource ('Agency Plan website from an archive'), which clearly distinguishes it from other tools like hosting_nodejs_build_from_archive. However, it doesn't explicitly differentiate itself from potential sibling import tools or explain what 'from an archive' entails, so it falls short of a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers no guidance on when to use this tool versus alternatives (e.g., agency_website_provision, hosting_deploy_wp_import). It does not state scenarios, prerequisites, or exclusions, leaving the agent without context for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/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 does not mention side effects, idempotency, reversibility, or any impact on existing payment configurations. The single sentence conveys only the action, not the consequences or context of enabling manual payment.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with no wasted words, but it borders on under-specification. It front-loads the action but lacks necessary context, making it less useful than a slightly longer description that includes usage or behavioral 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?
Given the tool has only one parameter and no output schema, the description is minimal. However, it lacks usage guidelines and any behavioral transparency, which are critical for an agent to know when to invoke it and what to expect. The description is inadequate for fully informed selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully documents store_id with a 'Store ID' description, so schema coverage is 100%. The description adds no extra meaning beyond what the schema already provides, which aligns with the baseline of 3 for high schema coverage. No additional parameter context is offered.
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') and the resource ('manual payment method for a store'), which distinguishes it from billing payment tools like billing_get_payment_methods. It is specific enough to convey the core function, though it could mention the ecommerce context explicitly to further differentiate from potential payment-related siblings.
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 gives no guidance on when to use this tool versus alternatives. With siblings like billing_set_default_payment_method and ecommerce_stores_metadata, there is no mention of prerequisites, scenarios, or why manual payment should be enabled via this tool instead of another.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden of behavioral disclosure. 'Get webhook details' is merely a restatement of the tool's purpose and provides no information about the return format, potential errors, authentication requirements, or any side effects. The agent gains no behavioral context beyond the obvious read-only nature implied by 'get'.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, which is good, but it is so minimal that it borders on under-specification. It is a single fragment that restates the title. While there is no verbosity, the conciseness sacrifices useful information. It earns a score of 3 as acceptable but not exemplary.
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?
Given the tool has no output schema and no annotations, the description must provide enough context about what 'details' means or what the agent can expect. 'Get webhook details' offers no information about the response structure, fields, or how to interpret the result. This is insufficient for a tool with a single parameter and no other structured metadata.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers 100% of the parameters (webhook_id with description 'Webhook ID'), so the description does not need to add much. The description adds no semantic value beyond the schema, but the baseline for high coverage is 3, and the parameter is self-explanatory. No additional context 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 'Get webhook details' uses a specific verb and resource, and the tool name clearly indicates the mail webhooks context. It distinguishes from sibling tools like mail_webhooks_list by implying retrieval of a single webhook's details, and the required webhook_id parameter confirms this. However, it does not explicitly mention 'by ID' or differentiate from the list tool, so it is clear but not a perfect 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?
There is no guidance on when to use this tool versus alternatives such as mail_webhooks_list or mail_webhooks_get. The description only states what it does, leaving the agent to infer usage from the tool name and parameters. No exclusions, prerequisites, or alternative recommendations are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The destructiveHint annotation already indicates the operation is destructive, but the description adds no behavioral context beyond that. It does not mention irreversibility, what is affected, or any side effects, which is critical for a delete operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at one short sentence, which is good for readability, but it is under-specified. It provides only the basic action without any contextual details, so the sentence does not fully earn 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 destructive tool with no output schema and minimal annotations, the description is incomplete. It fails to convey that the database belongs to a website, that the operation is irreversible, or any implications of deletion, leaving important gaps for the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for both parameters, so the schema already documents the parameters. The tool description adds no additional meaning about the parameters, such as how they relate to the database being deleted, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Delete a database' clearly states a verb and resource, but it is generic and does not distinguish this tool from other database deletion tools like hosting_db_delete. The title adds 'Agency' for context, but the description itself 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?
No guidance is provided on when to use this tool versus alternatives. It neither mentions prerequisites nor explains scenarios where this tool is appropriate, leaving the agent to infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It does not mention effects, side effects, requirements, idempotency, or whether this operation is safe or destructive. 'Start' implies an action but reveals nothing about consequences.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with zero fluff, but it is under-specified. While it is front-loaded, it lacks substantive content that every sentence should convey. A few more words could drastically improve clarity without becoming verbose.
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 state-changing tool with no annotations and no output schema, the description is incomplete. It does not explain what happens when the project starts, what the expected outcome is, or any prerequisites. Given the simple parameters, more context is needed for an agent to invoke 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 coverage is 100% for the two parameters (vm_id and project_name), so the schema already documents them. The description adds no additional meaning or usage hints beyond what the schema provides, so baseline 3 is appropriate.
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 'Start a Docker project' provides a clear verb and resource, but it is essentially a direct restatement of the tool name. It does not specify what 'start' entails (e.g., starting containers, building the project) or distinguish itself from related operations beyond the name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like vps_docker_stop, vps_docker_restart, or vps_docker_create. The description gives no context for selection 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?
With no annotations, the description must carry full behavioral disclosure. It implies validation is a pre-application step (likely read-only), but does not state whether records are modified, if external DNS lookups are performed, how invalid records are handled, or any side effects. This is a significant gap for a tool that could have complex behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is concise but severely under-specified. It communicates one key point but lacks any structured information such as return behavior, examples, or prerequisites. This is under-specification rather than effective conciseness, as it leaves the agent without necessary context.
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?
Despite having a moderately complex schema (array of nested record objects) and no output schema or annotations, the description offers minimal context. It does not explain what validation means, what the tool returns, or how it relates to other DNS operations like dns_update_records or dns_delete_records. This is incomplete for an agent to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides 100% coverage of parameter descriptions, including nested fields for records (type, name, value, ttl, priority). The description adds no additional parameter semantics, so it remains at 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 uses the specific verb 'validate' with the resource 'DNS records' and adds context 'before applying them', which distinguishes it from siblings like dns_get_records or dns_update_records. However, the exact nature of validation (syntax, propagation, existence) is not specified, 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 phrase 'before applying them' implies the tool should be used as a pre-application check, but there is no explicit guidance on when to use it versus alternatives, nor any mention of when not to use it. It does not reference sibling tools or specific application scenarios like update, delete, or reset.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It merely says 'Create a subdomain' and provides no information about side effects (e.g., whether DNS records are automatically updated), idempotency, uniqueness constraints, or required permissions. This is functionally a tautology of the tool name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise (four words) with no filler, but it simply restates the title without adding new information. While brevity is positive, this sentence does not 'earn its place' by contributing additional context or clarification.
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 create tool with no annotations, no output schema, and no behavioral explanations, the description is incomplete. It does not explain what creating a subdomain entails (e.g., whether it provisions a directory, updates DNS, or has naming constraints) or how it integrates with related hosting tools. The schema covers only parameter meanings, not the operational context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers all three parameters with descriptions (domain, username, subdomain prefix), achieving 100% coverage. The tool description adds no additional parameter semantics, so the baseline of 3 is appropriate; the schema already provides the necessary meaning.
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 states the verb and resource clearly ('Create a subdomain'), which distinguishes it from sibling tools like hosting_subdomains_list and hosting_subdomains_delete. However, it lacks any scope detail (e.g., which domain or hosting account), so it is not as strong as descriptions that explicitly scope the operation.
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?
There is no guidance on when to use this tool versus alternatives. It does not mention prerequisites (e.g., the domain must exist), relationship to hosting_subdomains_list/delete, or any conditions under which subdomain creation would be inappropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It simply says 'Update an autoreply' with no mention of side effects, overwrite behavior, prerequisites, or return value, making it a tautology.
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 concise sentence with no wasted words. It states the purpose directly, though it is sparse and could include additional useful details without becoming verbose.
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?
This is a mutation tool with no annotations, no output schema, and an extremely minimal description. It fails to convey behavior, return format, prerequisites, or effects, leaving the agent with insufficient context 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?
The input schema provides 100% coverage with descriptions for all three parameters (autoreply_id, subject, body). The tool description adds no additional meaning beyond the schema, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Update an autoreply' clearly states the verb (update) and resource (autoreply), distinguishing it from create/delete/list siblings. However, it does not mention that it updates subject/body, which the schema covers.
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 mail_autoreplies_create or mail_autoreplies_delete. The description only restates the obvious without any contextual usage cues.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden for behavioral disclosure. It only states the action itself and reveals no side effects, confirmation requirements, idempotency, or mutation characteristics, which is a significant gap for a create tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence and is not verbose, but it offers minimal information beyond the title. It is under-specified rather than optimally concise, as the sentence adds little value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a creation tool with no annotations and no output schema, the description is inadequate. It fails to convey result values, prerequisites, or post-creation steps, and the environment lacks the richness to compensate.
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% for both parameters, so the baseline is 3. The description adds no additional meaning about the parameters beyond the schema's existing descriptions.
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 ('email forwarder'), using a specific verb and noun. It implicitly differentiates from sibling tools like mail_forwarders_list and mail_forwarders_delete, but it merely restates the tool name/title without adding scope or 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 usage guidance is provided. The description does not mention when to use this tool, prerequisites, or alternatives. It lacks any mention of related tools such as mail_forwarders_resend_confirmation or mail_forwarders_keep_copy.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only says 'List,' which implies a read-only operation, but provides no details on return format, permissions, pagination, or what 'action logs' actually contain. This is a significant transparency gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with zero wasted words. It is front-loaded and immediately states the action and resource, making it highly economical.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no output schema and no annotations, the description should explain what the logs contain, what the response looks like, or how it differs from similar log tools. It does none of this, leaving the agent under-informed despite the simple one-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 coverage is 100% with a single parameter 'order_id' described as 'Mail order ID.' The description adds nothing beyond this, but since the schema already documents the only parameter, the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List mail action logs.' clearly states the verb (List) and resource (mail action logs), making its basic purpose clear. However, it doesn't distinguish this from sibling tools like mail_logs_access, mail_logs_inbound, or mail_logs_outbound, so it 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 Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus the many other mail log tools or how it differs from them. The description provides no context, prerequisites, or alternatives, leaving the agent without any usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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. 'Install plugins by slug' only names the action; it does not disclose side effects (e.g., whether existing plugins are overwritten), required permissions, or whether installation of a plugin is reversible. This is a significant transparency 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at four words and front-loads the core action. It is not padded with redundant information. It could be slightly more informative while remaining succinct, but it is appropriately sized for a simple tool.
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?
Despite a simple tool, there are no annotations, no output schema, and initial schema descriptions are minimal. The description does not explain how 'username' and 'software' are used, what happens upon successful installation, or how errors are surfaced. This is insufficient for an AI agent to invoke the tool confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description covers 100% of parameters, with 'plugins' described as 'Plugin slugs to install'. The description's phrase 'by slug' adds slight reinforcement but no new semantic detail beyond the schema. Baseline 3 is appropriate because the schema already carries the load.
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 'Install plugins by slug' uses a specific verb and resource, clearly indicating an installation operation. It distinguishes itself from siblings like wp_plugins_activate, wp_plugins_deactivate, and wp_plugins_uninstall by focusing on installation. However, it could be more precise about the target (e.g., a specific WordPress installation), so it does not quite reach 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?
No guidance is provided on when to use this tool versus alternatives such as wp_plugins_activate or wp_plugins_update. The description does not mention prerequisites, such as an existing WordPress installation, or any exclusions. The context is entirely implied by the name and sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description provides no behavioral information beyond repeating the tool's purpose. With no annotations present, it does not disclose the mutation side effects, potential risks, permission requirements, or return behavior. This is a significant gap for a tool that modifies the system.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no wasted words, but it is essentially redundant with the tool's name and title, offering no new information. It is concise but under-specified for a tool with multiple parameters and side effects, lacking any structured detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no annotations and no output schema, a one-sentence description is insufficient for a tool of this complexity. It omits essential context about the update workflow, prerequisites, side effects, and results. The abundance of sibling tools makes this lack of context particularly problematic.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3 even though the description itself adds no parameter-specific meaning. The schema descriptions are minimal, but they are present and not contradictory. The tool description does not clarify the ambiguous 'WordPress software identifier' or explain how the parameters interact.
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 target (WordPress plugins), so the core purpose is clear. However, it does not differentiate from sibling tools like wp_plugins_update_hostinger or wp_update_core, and it lacks specificity about the scope (e.g., specific plugin slugs and installation).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers no guidance on when to use this tool, any prerequisites, or alternatives. It does not mention that this tool updates a specified set of plugins on a particular WordPress installation, nor when to prefer it over other plugin-management tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 disclosing behavioral traits. However, it merely restates the tool name ('Update domain forwarding/redirect') without adding any information about side effects, irreversibility, required state, or what happens upon execution. This is essentially a tautology.
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, front-loaded sentence that directly states the action. It is concise and avoids unnecessary verbosity, although it sacrifices informational richness for brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite being a simple tool with only 3 parameters and no output schema, the description is too minimal to be contextually complete. It does not explain what 'update' entails, whether the operation replaces existing forwarding, or any expected behavior, leaving the agent without sufficient context for correct 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 each parameter (domain, redirect_to, type) already described in its own schema field. The description adds no extra parameter semantics, but the baseline of 3 is appropriate because the schema fully documents 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 uses a specific verb ('Update') and resource ('domain forwarding/redirect'), which clearly conveys the tool's function. It does not explicitly differentiate from sibling tools like create or delete forwarding, but the verb itself implies modification of an existing rule.
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 domains_create_forwarding or domains_delete_forwarding. It does not mention any prerequisites, context, or conditions that would help an agent decide to invoke it.
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?
Annotations are absent, so the description carries the full burden. It discloses only that the tool updates a sales channel, without mentioning side effects, whether updates are partial or full, permission requirements, or any other behavioral traits. This is minimal and not sufficiently transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, but this is under-specification rather than effective conciseness. The single sentence simply restates the tool name without adding meaningful value or earning 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 tool with 4 parameters, no output schema, and no annotations, the description is incomplete. It lacks usage guidelines, behavioral context, and any practical information beyond the most basic action, leaving the agent to rely entirely on the 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?
The input schema provides descriptions for all four parameters, covering 100% of the parameter semantics. The tool description adds no additional parameter information, but the baseline of 3 is appropriate since the schema already handles 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 ('Update') and the resource ('sales channel'), which distinguishes it from sibling tools like ecommerce_channels_create or ecommerce_channels_list. However, it lacks detail about which specific fields can be changed, making it less informative than the high-caliber examples.
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, no prerequisites are mentioned, and there is no indication that an existing sales channel must exist. The description merely states the action without any contextual usage cues.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure, but it only restates the operation. It does not mention side effects, prerequisites (e.g., existing mailbox), uniqueness constraints, or any post-creation behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no unnecessary words. While it is minimal, it is not verbose and conveys the primary purpose immediately.
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 mutating create tool with no annotations or output schema, the description is too sparse. It does not explain expected outcomes, error conditions, or prerequisites, leaving the agent without enough context to use the tool confidently.
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 provides complete descriptions for both alias ('Alias email address') and mailbox_id ('Mailbox ID'), and the description adds no additional parameter meaning. With 100% schema coverage, a baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Create an email alias.' clearly identifies a create operation on an email alias resource, which distinguishes it from sibling tools like mail_aliases_delete or mail_forwarders_create. However, it does not elaborate on the specifics of what an alias does or how it differs from a forwarder, so it stops short of full 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 about when to use this tool instead of alternatives such as mail_forwarders_create or mail_mailboxes_create. The description simply states the action without any context for 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, the description must disclose what restart entails. It merely says 'restart' without explaining whether it causes downtime, preserves container state, or is safe on a stopped project. This is a significant transparency gap for a mutating tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that essentially restates the tool's name, providing no additional value. While brief, it is under-specified and fails to be an efficient, informative description, similar to a tautology.
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?
The tool is simple with only two parameters and no output schema, but the description still leaves out important context such as the effect of restart, potential side effects, and expected response. It is not complete enough for an agent to know what to expect when invoking the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides full descriptions for both parameters (vm_id and project_name), achieving 100% coverage. The description adds no additional meaning beyond the schema, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
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 action ('restart') and resource ('a Docker project'), with a specific verb that distinguishes it from sibling tools like start and stop. However, it lacks any detail about scope or what 'project' specifically refers to, so it doesn't fully earn 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 restart versus start/stop, no prerequisites, and no context on the project state. It is purely a statement of the operation with no practical usage instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden. It implies a read-only operation via 'Check' but does not disclose what checks are performed, what happens if installations are invalid, or any return/error behavior. This is a significant gap for a tool without annotation support.
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, compact sentence—'Check if WordPress installations are valid/intact.' It front-loads the action and resource with no unnecessary words. While extremely terse, it earns a high score for conciseness, though not perfect because it omits useful structure like optional examples.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no annotations, the description must explain return values and what constitutes 'valid/intact.' It only states the tool's purpose without describing result interpretation, edge cases, or when such a check is needed. For a simple one-parameter tool, this incompleteness leaves the agent guessing.
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 sole parameter 'username' is fully documented in the schema with a clear description, providing 100% schema coverage. The description adds no parameter-specific meaning, but the schema already handles it adequately, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool checks WordPress installations for validity/integrity, distinguishing it from siblings like wp_list_updates or wp_get_version. The term 'valid/intact' is somewhat vague but conveys a health-check purpose.
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 offers no guidance on when to use this tool versus alternatives. It does not mention sibling tools like wp_detect_installations or wp_installations_list, nor does it provide any context for choosing this validation check.
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. 'Create a cron job.' only states the action, with no mention of the agency scope, effects on the website, required permissions, or return values. This is a significant gap for a creation operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, which is front-loaded and efficient. However, it is so brief that it borders on under-specification, providing only slightly more information than the tool name itself. It is not bloated, but also not appropriately detailed.
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 should offer more context. It fails to explain what makes this tool 'agency-specific', how it relates to website_uid, or any behavioral implications (e.g., schedule format, execution details). This makes the tool difficult to invoke correctly without additional documentation.
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% parameter description coverage (command, schedule, website_uid), so the schema already documents parameters effectively. The description itself adds no additional semantic context beyond what the schema provides, so it neither helps nor detracts.
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 cron job.' clearly states the action and object, which is a specific verb+resource pair. However, it does not explicitly mention the 'agency' context, and with sibling tools like hosting_cron_create and agency_cron_delete, the description alone could be ambiguous without the tool name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives such as hosting_cron_create or agency_cron_list. The description provides no context for appropriate use, prerequisites, or exclusions, leaving the agent to infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the full burden of behavioral disclosure. It only says 'Get', implying a read-only operation, but does not disclose what settings are returned, whether any side effects occur, or if any special permissions are needed. This is insufficient for a getter 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 no redundant words. It is concise and front-loaded, earning a high score for efficiency.
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?
The tool is simple with one parameter and no output schema, but the description does not explain what 'WordPress settings' includes or what the response will look like. Since no output schema exists, the description should compensate by outlining return values, but it does not. This leaves the agent with incomplete 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?
The input schema lists a single parameter 'website_uid' with description 'Website UID', which is essentially the parameter name restated. The tool description does not explain what a website_uid is, how to obtain it, or its format. High schema coverage is technically met, but the added meaning is negligible.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Get WordPress settings for an Agency Plan website.' It uses a specific verb (Get) and resource (WordPress settings) with context (Agency Plan). It does not explicitly distinguish itself from sibling tools like agency_website_get, but the focus on 'settings' and 'Agency Plan' provides reasonable clarity.
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 is no mention of prerequisites, scenarios, or exclusions. The description only states what it does, leaving the agent to infer usage from the tool name and 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. While 'Get' implies a read operation, the description doesn't disclose any behavioral traits like error handling, response format, or whether the domain must be managed under the account. This is minimal but not completely absent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no unnecessary words. It effectively communicates the core action and resource.
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 an output schema and annotations, the description is incomplete. It doesn't specify what 'detailed info' includes, what fields are returned, or any edge cases. The tool is simple, but the description still leaves significant gaps.
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% parameter coverage for the single required 'domain' parameter, with a basic description 'Domain name'. The tool description adds no additional parameter context, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the resource 'detailed info about a specific domain', which distinguishes it from list-type tools like domains_get_list. However, it doesn't differentiate from other detail-oriented sibling tools like domains_get_whois_profile or domains_get_forwarding, so it's clear but not fully distinct.
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?
No guidance is provided about when to use this tool versus alternatives such as domains_get_whois_profile or domains_get_forwarding. The description lacks any context about prerequisites or selection criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only states 'Purchase a new domain' without explaining financial implications, required steps, or potential failures. This is a significant gap for a purchase operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no wasted words, but it is underspecified. It lacks any structure beyond the basic statement of purpose, making it not appropriately sized for the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a high-stakes purchase tool with three parameters, no output schema, and no annotations, the description is drastically incomplete. It fails to explain what happens after purchase, what response to expect, or what conditions must be met.
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 provides descriptions for all three parameters (domain, whois_id, payment_method_id), so the baseline is 3. The description adds no additional parameter-level meaning beyond the schema.
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 (purchase) and resource (domain), making the tool's purpose explicit. However, it does not differentiate from sibling tools like domains_check_availability or billing_create_order, so it earns a 4 rather than 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?
There is no guidance on when to use this tool versus alternatives, nor any mention of prerequisites like checking domain availability or having a payment method. The description provides no context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must disclose behavioral traits. It only says 'reset to defaults' but does not explain whether this overwrites all custom extensions, if it is safe, or what the impact is. This is a significant gap for a 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no filler, but it is under-specified. It essentially restates the tool title without adding context, so while no words are wasted, the brevity hinders informativeness.
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 insufficient for a mutation tool. It doesn't state whether the reset is reversible, what 'defaults' means, or what the response/return value will be. More context is needed for the agent to use it safely.
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 descriptions fully document both parameters (domain and username). The description adds no additional parameter semantics beyond what the schema already provides, 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the operation (reset) and target (PHP extensions), with 'to defaults' specifying the action's outcome. It distinguishes from sibling tools like hosting_php_update_extensions, which modifies rather than resets.
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 provided on when to use this tool versus alternatives. It does not mention that this resets all custom extension settings to hosting defaults, nor does it advise when a user might want this (e.g., to troubleshoot a misconfiguration).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations available, the description must convey behavioral traits but does not. It simply states 'Create a catch-all' without mentioning side effects, validation requirements, confirmation steps (there's a resend_confirmation sibling), or reversibility. The description adds no context beyond the tool's name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, which is efficient, but it largely repeats the title and adds minimal value. It is front-loaded but doesn't earn its place since it doesn't provide new information beyond the name.
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 create tool with no annotations and no output schema, the description is incomplete. It omits crucial context such as whether a confirmation is required (indicated by mail_catchalls_resend_confirmation sibling), what happens to existing catch-alls, and any limitations. The simple input schema covers parameters, but the operational context is missing.
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 baseline is 3. The description adds no additional meaning about parameters beyond what the schema already documents. It correctly lists forward_to and mailbox_id as required, but offers no further clarification such as format or constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action: 'Create a catch-all for a mailbox.' It specifies a concrete verb ('create') and resource ('catch-all') with context ('for a mailbox'), distinguishing it from sibling tools like list, delete, and resend_confirmation.
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 mailbox), confirmation flows, or scenarios where the catch-all would be appropriate. Sibling tools like mail_catchalls_delete and mail_catchalls_resend_confirmation hint at related usage, but the description gives no exclusions or contextual 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?
There are no annotations, so the description carries the full burden of behavioral disclosure. 'Clear cache' implies a mutating action, but the description does not explain side effects, scope (full-site vs. partial), or whether the action is reversible. This lack of detail leaves the agent uncertain about the operational impact.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no unnecessary words. It efficiently conveys the action and target, earning a perfect score for conciseness.
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 simple tool with one parameter and no output schema, the description covers the basic purpose but misses critical context: when to use it vs. similar cache tools, what clearing the cache actually does, and any safety considerations. This makes the description insufficient for confident selection.
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 fully documents 'website_uid' as 'Website UID', and the description adds no additional meaning beyond that. Since schema coverage is 100%, the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Clear' and the resource 'cache for an Agency Plan website', which conveys the specific scope. It distinguishes from generic cache tools by referencing the Agency Plan, but it does not explicitly contrast with the sibling 'hosting_cache_clear', so it falls short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage 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 alternative cache-clearing tools like 'hosting_cache_clear' or 'clear_api_cache'. There is no mention of prerequisites, context, or exclusions, leaving the agent without help in selecting the correct 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?
Annotations are absent, so the description carries full responsibility for behavioral disclosure. It does not mention side effects, whether the build is synchronous, or potential impact on the website. This is a significant gap for an action that likely modifies deployment state.
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?
Exactly one sentence with no filler. It is appropriately concise and front-loaded, earning its place 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 lack of output schema, the description should at least indicate what a successful build returns, whether it is asynchronous, or what next steps are. It only states the action, leaving out expected results and operational context, making it incomplete for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers the only parameter (website_uid) with a description, so baseline 3 applies. The description adds only a bit of domain context ('Agency Plan website') but does not explain how the parameter affects the build or how to use it beyond the schema.
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 (Build) and target (Node.js assets for an Agency Plan website). It is a specific verb+resource construction that distinguishes the tool from many siblings, though it does not explicitly name alternative tools for contrast.
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 gives no context about prerequisites, timing, or related tools like hosting_nodejs_build_* or agency_website_processes, leaving the agent without decision support.
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 burden. It merely restates the tool's name, offering no details on side effects, permissions, errors, or return format. However, the verb 'get' inherently implies a read-only operation, so it is not misleading.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One short sentence with no wasted words. It is appropriately brief for a simple get operation, though it could arguably expand on what details are returned.
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 simple getter with one parameter, the description states the core purpose, but it fails to describe the return value or what 'details' encompasses. Given no output schema, this is a significant gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers 100% of the parameter (website_uid) with a description, so the baseline is 3. The description adds no additional meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
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) and resource (Agency Plan website details), distinguishing it from sibling tools like agency_website_delete or agency_website_setup_status. It is concise but not as detailed as the calibration exemplar.
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 information about when to use this tool versus alternatives such as agency_website_setup_status or horizons_get_website. No explicit use cases 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 the full burden. It only states the high-level action without disclosing side effects, such as billing, asynchronous completion, or changes to the order. This is insufficient for a mutating provision operation.
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, focused sentence with zero fluff, earning its place. However, it is overly minimal, bordering on under-specification, though it is concise without being verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, no annotations, and a mutating action, the description is incomplete. It lacks context on what 'provision' entails, how long it takes, what the response contains, or how it relates to order_id and existing orders.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides descriptions for both parameters (order_id and domain), giving 100% coverage. The tool description adds no additional parameter semantics, so the baseline of 3 is appropriate given the schema handles it.
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 provisions a new Agency Plan website, using the verb 'provision' and identifying the resource. It distinguishes itself from sibling tools like agency_website_get and agency_website_delete by indicating creation of a 'new' website, though it could be more specific about prerequisites.
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 the required order_id, any context about order status, or comparisons to other provisioning/creation tools like hosting_websites_create or horizons_create_website.
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 available, so the description must carry behavioral disclosure. It indicates a read operation via 'Get' but does not describe what 'status' includes, whether it's pollable, or any error behaviors.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no extraneous information, effectively front-loaded.
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 status-checking tool with no output schema or annotations, the description lacks context about return value structure, expected usage flow, or relationship to provisioning.
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 provides 100% coverage for both parameters (order_id and setup_uuid), so the description adds no additional parameter semantics. Baseline 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 gets setup status for Agency Plan websites, using a specific verb and resource. However, it doesn't differentiate from sibling tools like agency_website_get or agency_website_processes, which could also relate to status.
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 only states what it does, not when to invoke it or what prerequisites exist.
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 disclosing behavior. It only states the action and target, but fails to mention potential side effects (e.g., downtime, prerequisites, reversibility) or any operational details. This is a notable 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one concise sentence with no wasted words. It is front-loaded with the action and resource, making it easy to scan. It loses a point for being too terse to convey essential context, but as a pure structural matter it is 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?
The tool has no output schema and no annotations, so the description must supply context. It only states the basic operation without explaining the process, expected outcomes, error conditions, or any constraints (e.g., valid versions, whether the change is synchronous). This is inadequate for an agent to fully understand the tool's behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds little beyond the schema: 'version' and 'website_uid' are minimally described in the schema, and the description does not explain valid version formats, how to obtain them, or any relationships between parameters. Still, no compensation is required 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 tool changes the WordPress core version and scopes it to Agency Plan websites, which distinguishes it from generic WordPress update tools like wp_update_core. The verb 'change' and resource 'WordPress core version' are specific, though it could more explicitly contrast with alternative 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 given on when to use this tool versus alternatives such as wp_update_core or agency_wp_versions. The description simply states what it does, leaving the agent to infer appropriate usage without any exclusion criteria or contextual hints.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits like irreversibility, effects on subscriptions, or default payment method handling. It only restates the tool's name ('Delete a payment method') with no additional context, failing to convey important implications of the deletion.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that is front-loaded and contains no redundant words. It is appropriately sized for the simplicity of the tool, though it lacks substance 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?
Given the simplicity of the tool (one required parameter, no output schema), the description is minimal but missing critical context about deletion consequences, such as irreversibility or impact on subscriptions. The lack of behavioral disclosure makes it incomplete for an agent to fully understand the operation's impact.
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 provides 100% coverage for the single parameter 'payment_method_id' with a description, so the description doesn't need to add parameter details. Per the baseline, a score of 3 is appropriate since the schema already documents the parameter 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 'Delete a payment method' clearly states the action (delete) and the resource (payment method), distinguishing it from sibling tools like billing_get_payment_methods and billing_set_default_payment_method. It is specific and unambiguous, though it doesn't add any extra detail beyond the title.
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 usage is implied by the tool's name and description: when you want to remove a payment method. There is no explicit guidance on when to use it versus alternatives, but the sibling context makes the purpose clear. No when-not or alternative recommendations are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of disclosing behavioral traits. It fails to mention that restoring a snapshot will overwrite current DNS records, any required permissions, or the irreversible nature of the operation. The single sentence only restates the action.
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 concise sentence with no unnecessary words, making it easy to parse. However, its brevity leaves out critical information, but that is more a completeness issue than a conciseness issue.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
As a restore operation with no annotations and no output schema, the description is under-specified. It does not explain what happens to existing DNS records, prerequisites like needing to list snapshots first, or what the response contains. This is a significant gap for a mutating tool, so completeness is low.
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?
Both parameters (domain and snapshot_id) are already described in the input schema with 100% coverage. The description adds no additional meaning beyond restating that a domain is involved, and it does not clarify how to obtain a valid snapshot_id (e.g., from dns_get_snapshots). Baseline score of 3 applies due to full schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'restore' and names the resource 'DNS snapshot for a domain,' clearly indicating this tool restores a DNS snapshot to a domain. It distinguishes from related siblings like dns_get_snapshot/dns_get_snapshots (view only) and vps_restore_snapshot (VPS snapshots) through the 'DNS' and 'restore' wording.
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 dns_get_snapshots/dns_get_snapshot for viewing snapshots, or vps_restore_snapshot for VPS snapshots. It merely states the action without any context 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, the description carries the full burden of behavioral disclosure. It implies a mutation via 'update/replace' but does not state whether this replaces the full set of records, whether the operation is destructive/reversible, or what response or errors to expect. The word 'replace' hints at overwrite semantics but is not explicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. It quickly communicates the verb and resource, earning every word it uses.
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?
The tool has no annotations or output schema, and the description omits critical context about replace-all behavior, validation, and relation to sibling DNS tools. While the schema covers parameters, the overall description is too minimal for an agent to safely invoke this potentially destructive operation without additional assumptions.
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 provides descriptions for both 'domain' and 'records' with 100% coverage, so the description does not need to add parameter-level detail. However, the description adds no extra meaning beyond the schema, not even clarifying that 'records' is the complete replacement list.
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 uses a specific verb ('Update/replace') and identifies the resource ('DNS records for a domain'), making the core action clear. However, it does not explicitly disambiguate from sibling operations like dns_reset_records or batch_dns_update, and it leaves ambiguous whether this replaces the entire record set or just modifies given records.
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 over alternatives. The description does not mention dns_get_records, dns_delete_records, dns_reset_records, or dns_validate_records, and it offers no 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 full burden for behavioral disclosure. It only states the action without revealing whether deletion is irreversible, whether it affects email routing or website functionality, or whether it removes all forwardings or a single rule. This leaves the agent without safety-critical information for a destructive operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at four words, and it is front-loaded with the action. However, the extreme brevity sacrifices additional context that could be valuable, so while it is concise, it is not optimally informative. A score of 4 reflects good conciseness with room for more substance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a simple one-parameter delete tool, but the description is so minimal that it provides no context about what forwarding is, what the side effects are, or what the response will be. Without an output schema, more detail is needed to make the tool self-explanatory. The description is below the minimum viable threshold for contextual completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one parameter, 'domain', with a description 'Domain name', giving 100% schema coverage. According to the baseline rule, the description does not need to add parameter details, and it does not. Thus a score of 3 is appropriate, as the schema already handles parameter semantics fully.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Remove domain forwarding' uses a clear verb+resource structure and distinguishes from sibling tools like domains_create_forwarding and domains_update_forwarding. However, it lacks specificity about whether it removes all forwarding rules or a specific one, which prevents a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It does not mention prerequisites, such as the domain being verified or existing forwarding setup, nor does it contrast with domains_update_forwarding or domains_get_forwarding. Usage is only implied by the name and action.
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 only states 'Delete a WHOIS profile' without mentioning consequences like irreversibility, impact on domains using the profile, or error scenarios. This is a significant transparency gap for a destructive operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, consisting of one short sentence with no fluff. It is appropriately front-loaded and every word earns its place, though it is so brief that it may be under-specifying rather than being efficiently informative.
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 mention irreversibility, what happens to domains referencing the profile, or how to obtain the whois_id. While the schema covers parameters, the description lacks essential contextual information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully documents the single parameter whois_id with the description 'WHOIS profile ID', providing 100% schema coverage. The description adds no additional meaning beyond the schema, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Delete' and identifies the resource as 'WHOIS profile', clearly stating the action. It does not explicitly distinguish it from sibling WHOIS profile tools, but it is the only delete operation among them, so the purpose is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage 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, nor does it mention prerequisites, exclusions, or related actions. For example, it doesn't indicate whether a profile must be unused or what happens if the profile is currently in 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 must carry the full burden of behavioral disclosure. It does not mention that this is a read-only operation, what happens if the domain is invalid or not found, or whether any authentication is required. This is minimal behavioral information for a tool that could have error cases.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that communicates the essential purpose with zero wasted words. It is concise and easy to scan, which is ideal for an agent needing to quickly understand the 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?
With no output schema and no annotations, the description should provide more detail about what 'renewal information' includes (e.g., expiry date, price, auto-renewal status) and any edge cases. The current description is too vague to fully inform an agent about the tool's behavior, especially given the lack of sibling differentiation.
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 full coverage (100%) for the single parameter 'domain', which is described as 'Domain name'. The tool description adds no additional semantic meaning beyond what the schema already provides, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves renewal information for a domain, using a specific verb ('get') and resource ('renewal information'). However, it doesn't distinguish it from sibling tools like domains_get_details or billing_get_subscriptions which might also return renewal-related data, so it lacks explicit 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?
No guidance is provided on when to use this tool versus alternatives such as domains_get_details or billing_get_subscriptions. There is no mention of preferred contexts, prerequisites, or exclusions, which is a clear gap given the number of related domain and billing 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 the full burden. It only states 'Get details', providing no information on read-only behavior, error conditions, return payload, or side effects. The verb 'Get' implies a read operation but adds no context about behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. It is concise and conveys the core purpose immediately, though it could be longer with useful 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?
With no output schema and no annotations, the description should clarify what 'transfer details' includes (e.g., status, dates) and when to call this tool. It only provides the bare minimum and leaves the agent guessing about return values and prerequisites.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the single parameter 'domain', so the baseline is 3. The description adds no extra meaning beyond what the schema already provides ('Domain being transferred').
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 gets details for a specific domain transfer, using the verb 'Get' and the resource 'details of a specific domain transfer'. It is specific, but it does not explicitly distinguish this from the plural sibling domains_get_transfers, which likely lists all transfers.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It does not mention that this is for a single transfer while domains_get_transfers lists all transfers, nor does it note any prerequisites such as the transfer being in progress.
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 relies on 'Get' to imply a read-only operation, but it discloses no other behavioral traits such as return format, error conditions, or whether the profile includes detailed data. This is a minimal disclosure for a 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single front-loaded sentence with no fluff. It is efficient but lacks helpful contextual details that could have been included without much extra length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no annotations, the description should clarify what a WHOIS profile contains and what a successful response looks like. It does neither, making the tool incomplete for an agent that needs to interpret results or handle errors 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 coverage is 100%—the only parameter 'whois_id' is documented as 'WHOIS profile ID'. The description adds no additional meaning beyond the schema, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get a specific WHOIS profile' uses a clear verb ('Get') and identifies the resource ('WHOIS profile'). The word 'specific' distinguishes it from the sibling list tool 'domains_get_whois_profiles', though it does not explicitly name 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?
The description provides no guidance on when to use this tool versus alternatives like domains_get_whois_profiles or domains_get_whois_profile_usage. It does not state any prerequisites or context, leaving the AI agent to infer usage from the terse text.
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 only says 'Create a digital product,' without mentioning side effects, permissions, validation rules, or what happens on creation. This is minimal and leaves the agent without expectations 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is concise and front-loaded with the action. Every word is relevant, but it is perhaps too terse to be fully helpful, which prevents a perfect score.
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 create operation with a fully documented schema, the description is minimally adequate. However, it lacks context about store requirements, return values, or how digital products differ from physical ones. Given the presence of a sibling tool, this gap makes the description incomplete in 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%, with every parameter (name, price, store_id, description) having a one-line description. The tool description adds no additional meaning to the parameters, but since the schema already documents them, a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb ('Create') and resource ('digital product in a store'), which is specific enough to understand the tool's basic function. However, it does not explicitly differentiate from the sibling tool ecommerce_products_create_physical beyond the word 'digital' in the tool 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 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 the sibling ecommerce_products_create_physical. There are no stated alternatives, prerequisites, or exclusions, so the description offers no decision support beyond the obvious action.
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 only states the tool gets instructions, but does not clarify whether it is a safe read-only operation, what accounts/scopes are involved, or what the returned instructions look like. The term 'custom' is ambiguous and unexplored.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, which is concise and front-loaded. However, it under-specifies by omitting what 'custom' means or what the instructions contain, making it minimally informative despite its brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given its simplicity (no params, no annotations, no output schema), the description should still explain what the setup instructions cover, whether they are generic or store-specific, and how to use them. The current text leaves these elements open-ended and is insufficient for an agent to fully understand the tool's value.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, and schema coverage is 100% (vacuous). The baseline for no parameters is 4, and the description adds no conflicting or necessary parameter information. No additional semantic explanation 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 tool's function: 'Get custom storefront setup instructions.' The verb 'get' and resource 'storefront setup instructions' specify the purpose. It distinguishes from sibling ecommerce tools that manage storefronts, though it doesn't explicitly contrast with them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidance is provided. The description does not indicate when to use this tool versus alternatives, nor does it mention prerequisites or what to do after receiving instructions. This leaves the agent to infer based solely on the tool name.
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 bears the full burden. It states the action but does not disclose effects (e.g., whether it enables/disables caching, if it affects site performance, or if the operation is reversible). The behavior of a 'toggle' without state context is unclear.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence with no filler or repetition. It is concise and immediately conveys the core 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?
Despite the tool's simplicity, the description lacks essential context. It does not explain what 'cacheless mode' entails, what 'toggle' implies about the resulting state, or any side effects. With no annotations or output schema, the description is incomplete 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?
The input schema already provides descriptions for both parameters (domain, username), covering 100% of the parameters. The description adds no additional meaning beyond the schema, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: toggling cacheless (bypass) mode for a website. It uses a specific verb and resource. However, it does not differentiate from sibling tools like hosting_cache_toggle, which likely toggles the general cache, leaving some ambiguity about the exact distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as hosting_cache_toggle or hosting_cache_clear. There is no mention of prerequisites, expected context, or situations where this toggle is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The tool has no annotations, so the description carries the full burden of behavioral disclosure. The description only says 'Create a cron job,' implying a mutation but providing no details about side effects, success/failure responses, idempotency, or access requirements. This is a significant gap for a create operation.
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 concise sentence that directly states the action. It is efficient and front-loaded, with no wasted words. However, it is so brief that it misses opportunities to add useful context, but for pure conciseness it is well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (3 required parameters, no annotations, no output schema), the description is incomplete. It does not explain key context such as the cron schedule format, the need for an absolute command path, or the role of the username. The description provides only the most basic idea and leaves the agent to infer important operational details from the schema alone.
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 provides 100% coverage with descriptions for all three parameters (command, schedule, username). The description adds no extra meaning beyond the schema, so it neither enhances nor degrades parameter understanding. Baseline 3 is appropriate since the schema handles 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 states the action ('Create') and resource ('cron job'), which clearly indicates the tool's purpose. It distinguishes from sibling tools like hosting_cron_list, hosting_cron_get_output, and hosting_cron_delete by specifying the create operation. However, it lacks any detail about the scope or type of cron job, limiting differentiation from similar create tools like agency_cron_create.
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 agency_cron_create or hosting_cron_list. There is no mention of prerequisites, validation rules, or scenarios where this tool should or should not be used. The description is purely declarative with no contextual usage information.
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 must disclose behavior. It states 'List' (implying read-only), but does not mention pagination, ordering, output format, or any prerequisites/permissions. The behavioral profile is almost entirely unspecified.
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, concise sentence with no fluff. However, it is so brief that it sacrifices useful context, making it less effective than a slightly longer but more informative description.
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?
There is no output schema or annotations to supplement the description. For a list operation, the description does not specify what the response contains, whether any filtering is possible, or how results are ordered, leaving significant gaps 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?
The input schema has 100% coverage for the single parameter ('username' with description), so the baseline is 3. The description's 'for a hosting account' simply restates the schema's purpose without adding syntax, constraints, or examples.
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 uses a specific verb ('List') and identifies the resource ('cron jobs') scoped to a hosting account. It is clear but does not explicitly distinguish from the sibling tool agency_cron_list, which may target the same resource at a different level.
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 agency_cron_list or hosting_cron_get_output. The description only states what it does, not the context 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. 'Change a database password' only restates the action and does not disclose side effects, permission requirements, or impact on existing connections/applications. 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no wasted words, making it appropriately concise. However, it is so minimal that it borders on under-specification, which prevents a perfect score for structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple and the schema fully covers its parameters, but with no annotations and no output schema, the description does not explain return values, prerequisites, or side effects. For a straightforward password change, this is adequate but with clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already describes all three parameters (username, name, password) with 100% coverage, so the baseline of 3 applies. The description adds no additional meaning beyond the schema, neither compensating nor enhancing parameter semantics.
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 'Change a database password' clearly states the specific verb (change) and resource (database password), distinguishing it from siblings like hosting_db_create or hosting_db_delete. However, it adds little beyond the tool's title, so it doesn't earn 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, no prerequisites, and no exclusions. It is a single statement without contextual direction, so it fails to help the agent choose appropriately among the many sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states only the core creation action but does not disclose side effects, required permissions, reversibility, or potential constraints (e.g., database name rules, hosting account requirements). This is a minimal disclosure, though it is not misleading.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no redundant words, front-loading the action and resource. There is zero unnecessary prose, making it maximally concise and well-structured 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?
The description is terse and does not address the broader context. It lacks any mention of return values (since there is no output schema), prerequisites, or differentiation from the many sibling database tools. Given the presence of agency_db_create and hosting_db_remote_create, more context would be needed to confirm the correct tool selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers all three parameters (name, password, username) with descriptions, giving 100% coverage. Per the rubric, the baseline is 3 when schema coverage is high. The description adds no parameter-specific information, but the schema already provides sufficient semantics.
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 database.' clearly states a specific verb (create) and resource (database). It is unambiguous, though it does not explicitly differentiate from sibling tools like agency_db_create, which is a similar action in a different context. The hosting prefix in the tool name provides some differentiation, but the description itself does not.
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 hosting_db_remote_create or agency_db_create. No prerequisites, exclusions, or context for usage are mentioned. The absence of any such direction leaves the agent to infer usage solely from the name and schema.
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 must disclose behavioral traits on its own. It does not mention potential side effects such as downtime, data loss, or whether repairs are reversible. The term 'repair' implies a mutation, but no details are given about what happens during the process.
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 sentence with no redundant words, making it concise. It is not verbose, but it is also quite terse; however, it avoids fluff and is appropriately sized 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 simplicity of the tool (2 params, no output schema), the description still lacks important context about the repair operation's behavior, prerequisites, and possible side effects. An agent would know the parameters but not what 'repair' entails or when it should be used.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already fully describes both parameters (name and username) with clear descriptions, and schema coverage is 100%. The description adds no additional meaning or context for the parameters, so it meets the baseline but does not go beyond it.
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 'Repair a corrupted database.' clearly states the tool's action (repair) and resource (database). It distinguishes itself from sibling DB tools like hosting_db_create, hosting_db_delete, etc., by adding the 'corrupted' condition. However, it is brief and could be more specific about the repair 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, nor any prerequisites or context. It merely states the function without explaining scenarios (e.g., when a database is corrupted) or mentioning related tools like hosting_db_change_password or hosting_db_delete.
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 merely states 'Get logs' without revealing whether the operation is read-only, how logs are returned, or any constraints like log availability or retention. This is minimal transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that directly states the tool's purpose. It is front-loaded and contains no extraneous information, earning high marks for conciseness.
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?
The tool is simple, but the description lacks important context such as when logs are available, how they are formatted, or how the build UUID relates to other build tools. Without an output schema, the description should explain more about the return value, which it does not.
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% coverage with descriptive fields (Build UUID, Website domain, Hosting account username), so the baseline is 3. The description adds no additional parameter context, but the schema already provides sufficient meaning.
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 'Get logs for a Node.js build' clearly identifies the action (get) and the resource (logs for a Node.js build). It is specific and unambiguous, though it does not explicitly differentiate itself from sibling tools like hosting_deploy_js_logs or vps_docker_logs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers no guidance on when to use this tool versus alternatives, nor does it mention prerequisites such as obtaining a build UUID from a list endpoint. There is no mention of exclusions or complementary tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. However, it reveals nothing beyond the tool's name—no return format, pagination, read-only confirmation, or prerequisites. This is a significant gap for a 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that directly states the tool's purpose without unnecessary words. It is appropriately brief for a simple list operation, though it could include more detail without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is minimal but covers the basic action and resource. However, it lacks details about output, usage context, or differentiation from related build tools. For a simple list, it is adequate but leaves clear gaps that could confuse 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?
The schema provides 100% description coverage for both parameters with clear, unambiguous definitions ('Website domain' and 'Hosting account username'). The tool description adds no additional meaning beyond what the schema already provides, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists Node.js builds for a website, using a specific verb ('List') and resource ('Node.js builds'). It distinguishes itself from the sibling 'hosting_nodejs_build_logs' by focusing on builds rather than logs, but does not explicitly name this alternative.
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 any alternative. It simply states the action without mentioning contexts, exclusions, or related tools, leaving the agent to infer usage from sibling names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of disclosing behavioral traits. It only states the action, without mentioning whether the operation is mutating, if it requires verification, any side effects, or the response structure. The vagueness of 'park' adds little insight.
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, front-loaded sentence with no waste. However, it is almost too terse, lacking any structural elaboration. It earns a 4 for extreme brevity but loses a point for missing an opportunity to add helpful 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?
Given the absence of annotations and output schema, the description is insufficient. It does not explain the concept of a parked domain, prerequisites, or success/failure behavior. For a create operation with 3 required parameters, this is a notable gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all three parameters are already documented (username, domain, parked_domain). The description contributes no additional parameter meaning beyond the schema, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Park a domain') and the target ('on a website'), which identifies the tool's core purpose. It distinguishes from siblings like hosting_parked_list and hosting_parked_delete by focusing on creation, though it could be more explicit about 'parked domain' semantics.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives (e.g., subdomain creation, domain forwarding). There are no prerequisites, examples, or exclusion scenarios, leaving the agent without context for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description only says 'Get PHP configuration' without disclosing behavioral details such as read-only nature, output format, or required permissions. The description carries the full burden but offers minimal information.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that is front-loaded and contains no unnecessary words. It earns a perfect score for conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a simple getter with two well-documented parameters, but there is no output schema and the description does not explain what configuration details are returned. Given the presence of the similar sibling hosting_php_info, the description is not complete enough to fully orient 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?
The input schema provides 100% coverage with descriptions for both parameters (domain and username). The description adds no additional meaning beyond the schema, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get PHP configuration for a website' with a specific verb and resource. However, it does not explicitly distinguish itself from sibling tools like hosting_php_info, so it 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?
No guidance is provided on when to use this tool versus alternatives such as hosting_php_info. The purpose implies usage, but there are no explicit contexts, exclusions, or alternative recommendations.
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 must carry the full behavioral burden. It only states 'Enable/disable PHP extensions' without disclosing whether the operation is additive, replaces the existing extension set, persists across restarts, or triggers service reloads. It also omits side effects and required permissions, making it insufficient for autonomous invocation.
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, front-loaded sentence with no redundant text. It is concise and well-structured, though perhaps too terse for the tool's complexity. For its length, it earns its place and receives a score of 4.
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 there is no output schema and no annotations, the description should cover edge cases, return values, and preconditions. It does not explain whether the 'extensions' map represents a complete set or partial updates, what response the API returns, or any requirements such as domain existence or account permissions. The three parameters with nested objects warrant a richer description, so a score of 2 is given.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides 100% coverage with descriptions for all three parameters (domain, username, extensions). The description adds the general operation context ('Enable/disable') but does not elaborate on parameter semantics beyond the schema, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Enable/disable PHP extensions' uses a specific verb and resource, clearly distinguishing it from sibling tools like hosting_php_reset_extensions (which resets to defaults) and hosting_php_update_version (version changes). However, it is terse and does not mention that it operates per domain/username, leaving some ambiguity about the scope of the operation.
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 sibling tools hosting_php_update_options and hosting_php_reset_extensions are not referenced, and there are no prerequisites, exclusions, or examples. This leaves the agent without context for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden. It only states what the tool does without disclosing key behavioral traits such as whether the update merges with existing options or replaces them entirely, whether there are restrictions on which ini settings are mutable, or any side effects. 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, focused sentence that front-loads the verb and the object. It is concise without being terse to the point of confusion, and every word adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no annotations and no output schema, the description leaves out critical information about behavior, such as whether the options parameter represents a full replacement or a partial update, and what happens to existing settings. The schema covers param types but not operational semantics, so the tool is under-specified 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 clear descriptions for username, domain, and options. The description adds a minor clarification by equating options to 'ini settings', but this mostly aligns with what the schema already says. The baseline of 3 is appropriate, as the description doesn't complicate or conflict with the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Update') and resource ('PHP options (ini settings)'), making the action unambiguous. It distinguishes itself from sibling tools like hosting_php_update_version and hosting_php_update_extensions by focusing on 'options' rather than version or extensions, though it doesn't explicitly name 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?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., having a hosting account/domain), or contrast with related PHP tools like hosting_php_details or hosting_php_update_extensions. The agent is left without contextual guidance.
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 only states the action without noting potential side effects like downtime, version compatibility risks, or whether it alters only the version and not other PHP settings.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one concise sentence with no wasted words, immediately conveying the core purpose. It is front-loaded and appropriately sized.
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 terse description, the tool lacks essential context for safe usage. It does not mention impact on the website, validation of the version, or how it relates to the other PHP update tools in the sibling list.
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 fully describes all three parameters (domain, version, username) with 100% coverage. The description adds no additional parameter detail, so it meets the baseline 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 'Change PHP version for a website' clearly identifies the action and resource. It is specific enough to distinguish from general hosting operations, though it does not explicitly reference sibling tools like hosting_php_update_extensions or hosting_php_update_options.
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 the related PHP management tools. It lacks any mention of prerequisites, such as checking the current version via hosting_php_details, or exclusions like not being for extension changes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of disclosing behavioral traits. 'Create a new website' only states the action, without mentioning side effects, required resources, potential costs, or whether the operation is synchronous. It offers no additional insight beyond the tool's name.
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 concise sentence with no wasted words and is front-loaded. However, it is so minimal that it borders on under-specification; it earns points for structure but loses the top score due to lack of substance.
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 simplicity of the tool (2 params, no output schema), the description is still incomplete. It omits any context about what order_id does, whether an existing hosting order is required, or what happens after creation. This leaves the agent without essential operational 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 already documents both parameters (domain and order_id) with descriptions. The tool description adds no further meaning, leaving the baseline score of 3 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 'Create a new website' is a clear verb+resource statement that matches the tool name and title. It distinguishes from list/delete/get tools by using 'create', but among sibling tools like agency_website_provision and horizons_create_website, it offers no differentiation, so it stops short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage 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 agency_website_provision or horizons_create_website. It does not mention prerequisites like existing hosting orders or how to choose between creating a website here vs. other creation 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?
The annotation includes destructiveHint: true, which already indicates the destructive nature. However, the description adds no additional behavioral context, such as whether deletion is permanent, what associated resources (databases, files) are affected, or if there are any safeguards or confirmations required.
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 concise sentence with no redundant words. It is front-loaded and efficiently conveys the core action. However, it is extremely sparse and relies heavily on the tool name and schema for 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 destructive operation with one parameter and no output schema, the description is too minimal. It does not explain the scope of deletion (e.g., whether it removes databases, emails, or SSL certificates), nor does it warn about irreversibility or offer guidance on recovery. More context is essential for such a high-impact action.
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 full coverage (100%) for the sole parameter 'domain' with the description 'Website domain'. The description itself does not add any semantic detail beyond the schema, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Delete a website' clearly states the action (delete) and resource (website), distinguishing it from sibling tools like hosting_websites_create or hosting_websites_list. It is specific and unambiguous, though it lacks any scope details such as whether this affects only the website files or also associated databases.
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 or any exclusions. The tool name implies the purpose, but there is no explicit context about appropriate scenarios or prerequisites, such as confirming the website is no longer needed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of disclosing behavior. It only says 'Create an autoreply,' with no mention of side effects, permissions, idempotency, or return values. This is minimal disclosure and leaves the agent unaware of important operational details.
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 sentence with no filler, making it concise and front-loaded. However, it is so terse that it lacks any structural elements or explanatory context, though it avoids unnecessary verbosity.
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 simple three-parameter tool, the description is under-specified. It does not explain what an autoreply is, when it is sent, or how this operation fits into the broader mail management context. Without annotations or an output schema, the description should provide more contextual information to be complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage with descriptions for all three parameters (body, subject, mailbox_id). The description itself adds no additional semantic meaning beyond what the schema provides, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Create' and the resource 'autoreply,' which distinguishes it from sibling tools like mail_autoreplies_update and mail_autoreplies_delete. However, it does not add context about what an autoreply is or that it is tied to a mailbox, which is implied by the tool name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. Sibling tools include mail_autoreplies_update and mail_autoreplies_delete, but there is no mention of prerequisites, such as the need for an existing mailbox or whether this replaces an existing autoreply.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It only states 'List catch-all configurations,' which implies a read-only operation but says nothing about return format, pagination, ordering, or whether the list is tied to the required order_id. The behavioral surface is almost entirely undisclosed.
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 one short sentence with no filler, making it efficient and front-loaded. However, it is so terse that it borders on under-specification for a tool with no output schema or annotations, so it loses one point for appropriateness of size.
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 output schema and annotations, the description should explain what catch-all configurations are, that they are tied to an order_id, and what the response will contain. It does none of these, leaving the agent with only the tool name and parameter name to infer 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?
The input schema fully describes the only parameter (order_id: 'Mail order ID'), so schema coverage is 100%. The description adds no parameter-specific meaning, but per the baseline for high schema coverage, a 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 uses a specific verb ('List') and a clear resource ('catch-all configurations'), distinguishing it from sibling tools like mail_catchalls_create or mail_catchalls_delete. However, it lacks any scoping detail (e.g., 'for a given order'), so it is clear but not fully differentiating beyond the resource name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives such as mail_aliases_list, mail_forwarders_list, or the non-list catch-all operations. There are no exclusions, prerequisites, or alternative suggestions, leaving the agent to infer usage solely from the name and parameter.
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 exist, so the description carries the full behavioral disclosure burden. It only conveys a read-only 'List' operation but does not mention what the logs contain, any date/time range, pagination, response format, or access requirements.
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 filler words. It effectively communicates the core operation and resource, making it appropriately 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?
With no output schema and no annotations, the description is underspecified. It fails to explain what 'access logs' contain, how the response is structured, or any limitations. The tool is simple, but the description leaves too much unclear for an AI agent to confidently use it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema fully documents the single required parameter (order_id as a string), and schema coverage is 100%. The description adds no extra parameter meaning, but per the baseline for high schema coverage, a 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 ('List') and the resource ('mail access logs'), making the tool's purpose understandable. It doesn't explicitly differentiate from sibling log tools like mail_logs_inbound or mail_logs_outbound, but the 'access' qualifier provides enough distinction from those 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 about when to use this tool versus the many sibling mail log tools (action, inbound, outbound, mailbox_actions). The description only states what the tool does, not the context in which it should be selected.
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. It only states the tool lists inbound mail logs, without disclosing behavior like pagination, filtering, date ranges, or what order_id does beyond the schema. No contradictions, but insufficient detail.
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 short sentence, highly concise and front-loaded. However, it is so minimal that it borders on under-specification, adding little beyond the tool title.
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 simple list tool with one parameter and no output schema, the description is incomplete. It doesn't explain what 'inbound' means, how it differs from 'outbound', what the returned logs look like, or any limitations. Lacks the context needed for confident tool selection.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the parameter description ('Mail order ID') is present. The tool description adds no extra meaning beyond the schema, which is adequate but not enhanced.
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 states 'List inbound mail logs,' which uses a clear verb and resource. It does not distinguish from sibling tools like mail_logs_outbound, mail_logs_access, or mail_logs_action, so it lacks 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. The description does not mention prerequisites, exclusions, or related tools, leaving the agent to infer 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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states it lists outbound mail logs but does not mention pagination, response format, potential side effects (if any), or required permissions, leaving the agent without important 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, concise sentence ('List outbound mail logs.') that is front-loaded and free of unnecessary words. Every word earns its place, and the structure is simple and direct.
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, absence of an output schema, and the minimal description, the agent is left without contextual details such as what 'outbound' specifically means, how logs are filtered (if at all), or what the response contains. This is barely more than a tool label and insufficient for a complex family of log-related tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage for the single parameter 'order_id' ('Mail order ID'), so the schema already documents the parameter clearly. The tool description adds no parameter information, but no compensation is needed given the high schema coverage, so a baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List outbound mail logs' clearly states the tool's action (list) and resource (outbound mail logs), and the qualifier 'outbound' distinguishes it from sibling tools like mail_logs_inbound. However, it provides no additional scope or context beyond what the tool name implies.
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 usage guidance is provided. The description does not indicate when to use this tool versus alternatives such as mail_logs_inbound, mail_logs_access, or mail_logs_action, nor does it mention any exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosing behavioral traits. It only states that it retrieves a plan, implying read-only behavior, but it does not clarify potential edge cases, error conditions, permissions, or response structure. This is insufficient for a tool with no annotation support.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with zero wasted words. It efficiently communicates the primary purpose without filler, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and no output schema, the description is too sparse. It does not explain what the returned 'plan' contains, how it relates to mail orders, or any prerequisites or failure modes. The lack of output schema should be compensated with a richer description, which is absent.
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 fully describes the only parameter order_id with 'Mail order ID', giving it 100% schema coverage. Since the description adds no additional meaning beyond that, it meets the baseline of 3. The parameter is simple and well-documented by the schema, so no further 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 action ('Get') and the resource ('the plan for a mail order'), which is specific enough to understand the tool's function. However, it does not differentiate the tool from siblings like mail_orders_list or explain what 'plan' entails, so it loses a point for not distinguishing it in 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?
There is no guidance on when to use this tool versus alternatives such as mail_orders_list or other mail order functions. The description implies the usage (when you need the plan of a specific order), but it provides no explicit context, exclusions, or alternative mentions, leaving the agent to infer the appropriate scenario.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only says 'Create a webhook', which implies mutation, but it doesn't disclose side effects such as whether the URL is validated, whether duplicate webhooks are allowed, or what the response contains. This minimal disclosure is inadequate for a mutating 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that is front-loaded with the key action and resource. It has no fluff or redundant wording. However, it is so brief that it omits useful details, which slightly detracts from its structural effectiveness.
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?
The tool has no output schema and the description does not explain the return value or the expected response. It also lacks context about event types, URL constraints, or how this fits into the webhook management workflow. Given the rich set of sibling webhook tools, this description leaves important 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?
The input schema provides 100% description coverage for all three parameters (url, event, mailbox_id). The description adds no additional meaning beyond the schema, so a baseline score of 3 is appropriate. It doesn't compensate for missing information like allowed event values or URL formats.
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 ('webhook for a mailbox'), which distinguishes it from sibling webhook tools like mail_webhooks_get, update, and delete. It is direct and unambiguous, though it doesn't add extra context about the mailbox scope beyond what the schema provides.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites, such as requiring an existing mailbox, or conditions that would make this tool preferable to updating or testing a webhook. There is no contextual information about the webhook lifecycle.
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 only states the action 'create a new contact' without detailing potential outcomes, validation rules, duplicate handling, or response behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no wasted words. It is front-loaded with the action and resource, but its brevity means it lacks substantive 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 create tool with no annotations, no output schema, and a sibling bulk-create tool, the description is too thin. It does not mention required fields, uniqueness constraints, return values, or how it differs from bulk creation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage for its three parameters (email, first_name, last_name), so the baseline is 3. The description adds no additional parameter semantics beyond what the schema already 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 'Create a new contact.' uses a specific verb and resource, clearly indicating it creates a single contact. It is distinguishable from the sibling reach_contacts_create_bulk by the absence of 'bulk', though it does not explicitly state 'single'.
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 gives no guidance on when to use this tool versus alternatives like reach_contacts_create_bulk or reach_contacts_delete. There is no mention of use cases, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description repeats the destructive nature already indicated by the destructiveHint annotation and adds no additional behavioral context. It does not disclose whether deletion is permanent, reversible, or cascades to related data, missing an opportunity to inform the agent of critical side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with no filler words. It is appropriately sized for a simple delete operation, though it may be slightly under-specified for a complex use case.
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 tool with a single parameter, a destructive hint, and no output schema, the description is minimally sufficient. However, it lacks context about what 'delete' entails (e.g., permanence, impact on related data) and any prerequisites, making it only partially complete for an agent's decision-making.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the single parameter 'uuid' is described as 'Contact UUID'. The description itself provides no additional semantic value beyond the schema, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Delete a contact.' uses a specific verb and resource, clearly indicating the tool's function. It distinguishes from sibling tools like reach_contacts_list and reach_contacts_create, though it could be slightly more explicit about the unique identifier (UUID) used to select the contact.
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, nor any mention of prerequisites, consequences, or edge cases. The description is purely functional and lacks contextual direction for an agent deciding between this and other contact-related tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description only states the action, with no disclosure of behavioral traits such as read-only nature, authentication requirements, pagination, or return format. With no annotations provided, the description fails to convey any safety or side-effect information.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one short sentence, extremely concise and front-loaded. Every word adds value, though it may be too sparse for the 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?
Given the lack of annotations, output schema, and the ambiguity around 'contact groups' vs sibling resources, the description is incomplete. It does not explain what a contact group is, how it relates to contacts/segments, or what the response contains.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the input schema is fully covered. The description adds no parameter information, but none is needed. Baseline for 0 params is 4.
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 contact groups' with a specific verb and resource. However, it does not differentiate from sibling tools like reach_contacts_list and reach_segments_list, leaving ambiguity about what 'contact groups' means distinctly.
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 compared to alternatives. There is no mention of use cases, exclusions, or relationships to reach_contacts_list or reach_segments_list.
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?
The description implies a read-only operation ('Check') but provides no details about behavior such as return format, error handling, or what specific DNS records are examined. Since no annotations exist, the description carries the full burden and fails to disclose these traits.
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 clear sentence with no unnecessary words, making it appropriately concise for a simple read-only tool. However, it is also quite sparse, providing only the bare function without supporting 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?
The tool has no output schema and no annotations, so the description should explain what 'DNS configuration status' means and what the response contains. It does neither, leaving an agent uncertain about the tool's output and how to interpret 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 input schema describes profile_uuid as 'Profile UUID' with 100% coverage, so the baseline is 3. The description adds minimal context by mentioning 'profile domain' but does not explain how the UUID relates to a domain or add meaningful semantics beyond the schema.
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 states a clear action ('Check') and resource ('DNS configuration status for a profile domain'), specifying the target as profile-related. However, it does not explicitly distinguish this tool from the many DNS sibling tools, 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?
No guidance is provided on when to use this tool versus the many DNS-related sibling tools. The description simply restates the function without prerequisites, exclusions, or alternative tool references.
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 bears the full burden of behavioral disclosure. It only states 'Create a new contact segment' without revealing any behavioral traits such as whether it's a mutating operation, required permissions, idempotency, or what happens to existing data. This lack of detail is a significant gap for a create operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that directly states the tool's purpose with no redundant or irrelevant content. It is appropriately sized for a simple create operation and is well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description is too sparse to be complete. It doesn't explain the expected behavior of the 'conditions' parameter, the response format, or any constraints on the segment name. For a create tool, this leaves the agent without enough context to use it correctly beyond the most basic level.
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 provides descriptions for both parameters (name and conditions), achieving 100% schema description coverage. The description adds no extra meaning beyond the schema, so the baseline of 3 is appropriate. 'conditions' lacks a type in the schema, but the description doesn't compensate for that.
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 the resource ('a new contact segment'), which is specific and distinguishable from the sibling list/get tools. However, it doesn't explicitly differentiate from similar create tools like reach_contacts_create, and the term 'segment' could be confused with 'group' from reach_contacts_groups, so it's clear but not fully differentiating.
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, the relationship to reach_segments_list/get, or when a segment would be appropriate compared to other contact grouping methods. There is no implied usage context beyond the name.
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 only states the action without mentioning whether snapshot creation is asynchronous, requires a running VM, incurs costs, or affects existing snapshots. This lack of side-effect and requirement info 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 with no unnecessary words. It is front-loaded and appropriately sized 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?
For a basic create operation with one parameter, the description is minimal but lacks context about the operation's effects, timing, or requirements. Without annotations or an output schema, an agent would need more behavioral details to use the tool safely and 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?
The schema fully documents the only parameter (vm_id) with its description and 100% coverage, so the tool description adds no additional meaning beyond the schema. 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 states a clear verb ('Create') and resource ('snapshot of a virtual machine'), which distinguishes it from sibling snapshot operations like vps_get_snapshot, vps_restore_snapshot, and vps_delete_snapshot. However, it relies on the tool name for VPS context and doesn't explicitly mention scope, so it's clear but not deeply differentiated.
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 snapshots vs backups, prerequisites (e.g., VM must exist or be running), or alternatives. It doesn't mention exclusions or contrast with related tools like vps_get_backups or vps_restore_backup.
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 exist, so the description must disclose behavior. It only states 'List' without explaining return format, whether it requires a running VPS, or any side effects. This leaves the agent guessing about the output structure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence front-loaded with the action verb. Every word contributes meaning; there is no redundant 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?
With no output schema, the description should specify what 'list projects' returns. It also lacks any note about relationship to vps_docker_containers or vps_docker_get. For a simple tool, it is barely adequate but 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 single parameter vm_id is fully documented in the schema (Virtual machine ID), so schema coverage is 100%. The description adds no additional meaning beyond the schema, but the schema is sufficient for a single required parameter.
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 uses a specific verb ('List') and resource ('Docker projects') with scope ('on a VPS'), clearly indicating its read-only enumeration purpose. However, it does not explicitly distinguish from the sibling tool vps_docker_containers, which may overlap in meaning.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives such as vps_docker_containers or vps_docker_get. No prerequisites or context for the required vm_id are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It only says 'get logs' without disclosing any behavioral details such as output format, pagination, or prerequisites beyond the required parameters. It does not contradict any annotations.
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 concise sentence, front-loaded with the essential information. It is efficient but under-specified; however, for what it says, every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description is too sparse. It doesn't explain what logs are returned (e.g., container logs, build logs) or any filtering options, leaving users with incomplete expectations for a log retrieval tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers both parameters with descriptions (vm_id and project_name) at 100% coverage, so the schema does the heavy lifting. The description adds minimal context by referring to the project but doesn't elaborate on parameter values or format.
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) and the resource (logs of a Docker project), aligning with the tool name and title. It distinguishes from other Docker tools like vps_docker_containers and vps_docker_get, but lacks specifics on log scope or output.
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 instead of other Docker tools. There are no alternatives, exclusions, or contextual hints to help an agent choose this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only mentions 're-deploy', which hints at an action but fails to explain potential consequences like downtime, container recreation, or whether existing data is preserved. This is insufficient 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 concise sentence with zero filler words. It effectively front-loads the core action and the '(re-deploy)' parenthetical, making it highly 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?
Despite having a fully described schema and no output schema, the lack of annotations places the responsibility on the description to explain the update process and side effects. The vague 're-deploy' does not adequately inform an agent about the operational impact, leaving the description incomplete 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?
All three parameters have schema descriptions (100% coverage), so the baseline is 3. The description itself adds no additional parameter semantics beyond the schema, but the schema descriptions are clear enough (e.g., 'Updated compose YAML'), thus no deduction 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 provides a specific verb ('Update') and resource ('Docker project'), and the parenthetical '(re-deploy)' clarifies the action, distinguishing it from sibling tools like create/start/stop/restart. However, it does not explicitly state what is being updated (e.g., compose configuration), leaving some ambiguity that the schema partially resolves.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers no guidance on when to use this tool versus alternatives such as vps_docker_create or vps_docker_restart. It lacks any context about prerequisites, exclusions, or scenarios where this tool is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose side effects and requirements, but it only says 'Activate a firewall on a VPS.' It does not mention whether the firewall must already exist, whether activation is reversible, or what happens if the firewall is already active. This is insufficient for a state-changing tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. It could be more informative, but it is concise and well-structured for such a simple operation.
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?
The tool has only two simple parameters and no output schema, but the description omits essential context: it should mention that the firewall must already exist, contrast activation with deactivation or sync, or describe the expected state change. This is incomplete for an MCP 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?
The input schema fully documents both parameters (firewall_id and vm_id) with descriptions, and schema description coverage is 100%. The description adds no additional semantics beyond the schema, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Activate') and resource ('firewall on a VPS'), which distinguishes it from sibling tools like vps_firewall_create or vps_firewall_deactivate. However, it lacks any additional context about what activation entails, so it stops short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage 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 vps_firewall_create, vps_firewall_sync, or vps_firewall_deactivate. The description merely restates the function without 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, the description carries the full burden of behavioral disclosure. It only states what it does (create) but gives no context on side effects, whether the firewall starts empty, if activation is required, or if name uniqueness is enforced. This is a minimal disclosure 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, front-loaded sentence with no wasted words. It is appropriately sized for a simple create operation and immediately conveys 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?
While the tool is simple (one parameter, no output schema), the overall firewall management context involves creating a firewall, adding rules, and activating it. The description fails to mention that a newly created firewall likely needs further setup (rules, activation), leaving the agent without guidance on next steps.
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 'name' parameter described as 'Firewall name'. The tool description does not add any additional meaning beyond the schema, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Create a new firewall' clearly states a specific verb (create) and resource (firewall). It distinguishes from sibling tools like vps_firewall_list, vps_firewall_get, vps_firewall_delete, and vps_firewall_create_rule, making its purpose clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites (e.g., need for a VPS) or suggest pairing with vps_firewall_create_rule or vps_firewall_activate to complete the firewall setup.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full disclosure burden. 'Deactivate a firewall from a VPS' conveys a state change but omits details about effect on rules, reversibility, prerequisites, or response. This is minimal disclosure for a 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 a single sentence with no redundant words, making it very concise and easy to parse. It front-loads the action immediately, and 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?
As a mutating tool with no annotations and no output schema, the description should explain consequences, prerequisites, or return behavior. It only provides a basic action statement, leaving important context missing for an agent deciding whether to invoke this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully documents both parameters (vm_id and firewall_id) with clear descriptions. The tool description adds no parameter-specific information, so it neither enhances nor detracts from the schema's already adequate 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: deactivate a firewall on a VPS. It specifies the resource (firewall) and scope (VPS), and the verb 'deactivate' distinguishes it from siblings like 'activate' and 'delete', though it does not explicitly contrast them.
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 such as vps_firewall_delete or vps_firewall_activate. It simply states the action without context, 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?
The description adds no behavioral context beyond the destructiveHint annotation. It does not disclose that the deletion is irreversible, what happens if the rule does not exist, or any side effects. Annotation covers the destructive nature, but description fails to add further value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one short, front-loaded sentence with no unnecessary words. It clearly states the action and resource in minimal length, earning its place without verbosity.
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 two-parameter delete operation, the description is minimal and lacks context. It does not explain return behavior, error conditions, or differentiation from firewall-level deletion, leaving the agent without enough information for robust decision-making.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already describes both parameters (firewall_id and rule_id) with 100% coverage. The description adds no additional meaning about how to obtain these IDs or their relationships, so it relies entirely on the schema.
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 'Remove a firewall rule.' uses a specific verb and resource, clearly indicating the action targets a firewall rule. It implicitly distinguishes from sibling tools like vps_firewall_delete, which likely deletes the entire firewall, but does not explicitly name 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 usage guidance is provided. The description does not specify when to use this tool versus related tools such as vps_firewall_delete or vps_firewall_update_rule, nor does it mention prerequisites like an existing firewall ID and rule 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 must fully disclose behavior. It only says 'Sync firewall rules to a VPS' without explaining side effects, whether it overwrites existing rules, whether the firewall must be active, or whether it is reversible. This is a minimal disclosure for a mutating operation.
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 one sentence of five words, front-loaded with the core action. It is efficient, though it sacrifices valuable detail; thus not a perfect score.
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?
The tool has no annotations or output schema, and the description is a single clause. It fails to clarify the operational semantics of 'sync' (e.g., does it replace all rules? does it require activation?), leaving the agent under-informed for a complex firewall action.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides descriptions for both vm_id and firewall_id, covering 100% of parameters. The description adds no extra semantic information about the parameters or their relationship.
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 uses a specific verb 'sync' with explicit target 'firewall rules to a VPS'. It clearly identifies the operation's resource and destination, and distinguishes from sibling tools like vps_firewall_activate or vps_firewall_create_rule by implying a bulk replication action. However, it doesn't elaborate on what 'sync' includes, so it's not 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?
There is no guidance on when to use this tool versus alternatives such as vps_firewall_activate or vps_firewall_update_rule. The description simply states what it does, with no context about prerequisites, typical scenarios, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden of behavioral disclosure. It only states 'Upload a new SSH public key' without explaining validation, duplicate handling, or whether the key is associated with a VPS. This is minimal for a mutating operation.
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, front-loaded sentence with no filler words. It is appropriately concise for a simple create operation, though it could be expanded with usage context without becoming overly long.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is low-complexity with two required parameters and no output schema, so the description is minimally adequate. However, it lacks context about the purpose of the key in the VPS ecosystem, naming constraints, or expected return value, making it incomplete in isolation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides 100% coverage with clear descriptions for both 'name' and 'key'. The description adds no additional parameter details, so it neither enhances nor detracts from the schema-provided semantics.
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 uses 'Upload' as a specific verb and 'SSH public key' as the resource, clearly indicating a creation action. The word 'new' helps distinguish from listing or deleting, though it does not explicitly reference sibling tools like vps_keys_attach.
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?
There is no guidance on when to use this tool vs. alternatives such as attaching an existing key, listing keys, or deleting keys. The description does not mention prerequisites or scenarios where this tool is appropriate, leaving the agent to infer usage from the tool name.
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 must disclose behavioral traits, but it only says 'Purchase a new virtual machine.' It does not mention that this will likely initiate a billing transaction, provision a server, or return an order ID. Missing details about side effects, required permissions, or asynchronous 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 filler or redundant information. It is extremely concise and front-loaded, achieving the goal of being short and readable.
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?
The tool has no output schema, no annotations, and only a minimal description. Given the complexity of purchasing a VPS (needing catalog item selection, payment method validation, and potential provisioning steps), the description is incomplete. It does not mention any return values, post-purchase actions, or how to obtain the required IDs.
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 baseline is 3. The description adds no additional meaning to the parameters beyond what the schema already provides (item_id and payment_method_id). However, since the schema is fully documented, the description does not need to compensate.
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 ('Purchase') and the resource ('a new virtual machine'). It is specific enough to distinguish from most siblings, though it could better differentiate from similar purchase tools like billing_create_order or domains_purchase.
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 billing_create_order or vps_setup. The description does not mention any prerequisites (e.g., retrieving available VPS plans via billing_get_catalog or ensuring a payment method exists).
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 only states the action without revealing side effects such as VPS downtime, loss of normal network access, or the need to explicitly stop recovery mode afterward. This is minimal disclosure for a state-changing operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single 5-word sentence with no filler, front-loading the action and target. It is appropriately concise for a one-parameter 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?
The description is extremely minimal and lacks important context for an agent: what recovery mode entails, when it should be used (e.g., for troubleshooting), whether the VPS must be stopped first, and how to return to normal mode. It also does not reference related tools like vps_recovery_stop, leaving the agent to infer the full workflow.
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 one required parameter, vm_id, with a description 'Virtual machine ID' (100% schema coverage). The tool description adds no additional meaning beyond the schema, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Boot') and resource ('VPS') with a specific target ('recovery mode'), which distinguishes it from normal start (vps_start) and recovery stop (vps_recovery_stop). It is concise and unambiguous, though it does not explicitly mention the VM ID parameter or the recovery mode's purpose.
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 given on when to use recovery mode versus normal operations, nor does it mention prerequisites, alternatives, or how to exit recovery mode. The tool is listed among many VPS lifecycle tools, but the description provides no context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears full responsibility for behavioral disclosure. It says nothing about downtime, service disruption, rate limits, or whether the operation is reversible. The description merely restates the title without adding any 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, front-loaded, and contains no filler. It is concise and readable, though it is minimal and could include additional context without becoming verbose.
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?
The tool has no output schema and no annotations, so the description must inform about return values, consequences, and appropriate use. It fails to mention that restarting causes downtime or whether confirmation is required. Sibling tools and usage contexts are also not addressed, making the description incomplete for a disruptive operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (vm_id is documented as 'Virtual machine ID'), so the description does not need to add param detail. The description also does not add extra meaning beyond the schema, hence the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (Restart) and the resource (a virtual machine), which distinguishes it from siblings like vps_start and vps_stop. It is specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage 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 instead of alternatives like vps_start, vps_stop, or batch_vps_restart. There are no exclusions, prerequisites, or contextual hints.
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 must carry the full burden of behavioral disclosure. It only states the primary effect (setting hostname) but omits side effects, such as whether the VM must be running, whether a restart is needed, or how quickly the change applies. 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, front-loaded sentence with no redundant or filler content. It efficiently conveys the core action, earning top marks for conciseness despite being minimal.
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 simplicity and full schema coverage, the description is still incomplete as a standalone guidance for an agent. It lacks any mention of return values, prerequisites, side effects, or how it differs from vps_reset_hostname. The mutation nature and absence of annotations demand more context than this single sentence provides.
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 parameter descriptions ('Virtual machine ID' and 'New hostname'). The tool description adds no additional meaning beyond what the schema provides, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
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 hostname') and the resource ('a virtual machine'), which is sufficiently specific. It does not explicitly differentiate from the sibling tool vps_reset_hostname, so it loses a point for lack of 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 gives no guidance on when to use this tool versus alternatives. It does not mention any prerequisites, context, or that vps_reset_hostname exists as a related but distinct operation. The agent is left without information on when 'set' is appropriate versus 'reset'.
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 responsibility for disclosing behavior. It does not mention any side effects, requirements, or return values. It only states the action, leaving the agent to infer mutation and potential prerequisites.
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, clear sentence with no wasted words. It is appropriately brief, though it could benefit from additional details without becoming verbose.
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?
The tool has 5 parameters and no output schema, yet the description is minimal. It does not explain the overall installation process, prerequisites, or what the agent should expect after invocation, leaving significant gaps.
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 each parameter already has a description. The tool description adds no extra meaning or context about the parameters, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Install WordPress' and specifies the target 'on a hosting account.' This distinguishes it from sibling tools like wp_plugins_install or wp_themes_install, though it doesn't explicitly reference 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, prerequisites, or alternatives. The description only gives the basic action without context, such as whether the hosting account must exist or if a domain is required.
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 only says 'Purge the LiteSpeed Cache' without explaining side effects (e.g., cache is cleared, site performance impact), required permissions, or what the result is. This is insufficient for a 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no fluff or redundant information. It effectively communicates the core purpose in minimal words, though it lacks additional structured guidance.
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?
The tool is a cache purge with no annotations and no output schema, so the description must provide more context. It omits critical details like whether the purge is site-specific or server-wide, the impact on the site, and how it relates to sibling tools. This is insufficient for an agent to safely invoke it without further assumptions.
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% for the two parameters (username, software), both with clear descriptions. The tool description adds no additional meaning beyond the schema, meeting the baseline but providing no extra value.
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 a specific verb ('Purge') and resource ('LiteSpeed Cache'), which distinguishes it from tools like wp_litespeed_status. However, it doesn't specify whether this purges all LiteSpeed caches or just for a specific site, 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?
No guidance is provided on when to use this tool versus alternatives such as hosting_cache_clear or wp_litespeed_status. There is no mention of prerequisites, context, or exclusions, leaving the agent without direction on 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, the description must carry the behavioral burden. 'Show' implies a read-only operation, but no details are given about side effects (likely none), the meaning of 'status', or whether it works for all hosting accounts. It adds no context beyond the tool's one-line purpose.
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 one sentence, with no wasted words. While this is structurally efficient, it could arguably be too sparse, missing useful context. Still, for a simple status tool, it is appropriately sized, though it sacrifices substance for brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema and no annotations, so the description should explain what 'status' returns (e.g., enabled/disabled, version, cache hit rate). It doesn't. Sibling tools with similar status functions (e.g., wp_memcached_status) likely provide more detail. Given the low complexity, only a bit more information is needed, but it's absent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers both parameters (username, software) with descriptions, achieving 100% schema description coverage. The description itself adds no parameter meaning, so the baseline of 3 applies. No extra context is provided to clarify the parameters or their relationship to the status query.
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 'Show LiteSpeed Cache status.' uses a clear verb ('show') and specific resource ('LiteSpeed Cache status'), making the tool's core function obvious. It distinguishes itself from purge/clear cache tools in the sibling list (e.g., wp_litespeed_purge, hosting_cache_clear) by being a read-only status query. However, it doesn't elaborate on what aspects of status are covered, so it stops short of full 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?
There is no guidance on when to use this tool versus alternatives. It doesn't mention that this is the status-check counterpart to purging or that it pairs with other wp_*_status tools. The intended usage is only implied by the name and description, 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 must carry the full burden of behavioral disclosure. It only states 'Show maintenance mode status' without detailing what the return value looks like, whether it is read-only, any permission requirements, or potential side effects. The succinctness leaves significant ambiguity.
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, concise sentence with no filler. It is appropriately brief for a simple status query, though it lacks substance. The structure is clear and front-loaded.
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 absence of an output schema and annotations, the description should provide more context about expected return values, usage scenarios, or examples. It only offers a bare statement of purpose, leaving the agent without enough info to understand the tool's full behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for both 'username' and 'software'. The tool description does not add any extra meaning beyond the schema, but schema already documents the parameters adequately, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Show maintenance mode status' clearly states the verb ('Show') and the resource ('maintenance mode status'). It distinguishes from sibling 'wp_maintenance_toggle' by focusing on status rather than toggling, though it does not explicitly reference WordPress.
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 'wp_maintenance_toggle' or other status tools. There is no mention of context, prerequisites, or comparison to siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries the full burden of behavioral disclosure, but it only states a basic listing action. It does not mention that the operation is read-only, nor does it disclose permissions, rate limits, or the structure of the returned 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, focused sentence with no redundant words or filler. It is concise and front-loaded, making it easy 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?
The description is minimal and leaves out important context such as what 'available' means exactly (e.g., from the WordPress repository vs. pre-uploaded options), the output format (since no output schema exists), and whether any preconditions exist. This is particularly important given the absence of annotations and output 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?
The input schema already provides descriptions for both parameters (100% coverage), so the baseline is 3. The description itself adds no extra meaning to the parameters, and the schema's phrase 'WordPress software identifier' is still somewhat vague, but the schema coverage means the description does not need to compensate much.
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 uses the specific verb 'List' and identifies the resource as 'plugins available for installation', which clearly distinguishes it from sibling tools like wp_plugins_list (likely lists installed plugins) and wp_plugins_search. The scope is implied via 'available for installation', but it is minimal and does not elaborate on the source or criteria.
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 wp_plugins_search or wp_plugins_suggested. There are no exclusions, prerequisites, or contextual notes that would help an agent decide the appropriate scenario for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states the action without mentioning side effects (e.g., whether plugin settings are preserved), reversibility, or required permissions. This is a significant gap for a mutating operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, 'Deactivate a WordPress plugin.', which is concise, front-loaded, and contains no unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Although the action is simple and parameters are well-documented, the lack of any behavioral context (e.g., what happens on success/failure, side effects, or prerequisites) makes it incomplete for an agent needing to understand the full impact of this mutating operation. No output schema exists to compensate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already describes all three parameters (plugin slug, software identifier, hosting account username), so the description adds no additional parameter semantics. With 100% schema coverage, a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'Deactivate' and the resource 'WordPress plugin', distinguishing it from sibling tools like wp_plugins_activate or wp_plugins_install. However, it lacks any broader scope or context beyond the basic action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites (e.g., plugin must be active) or contrast with related tools like wp_plugins_activate or wp_plugins_uninstall.
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 only says 'Update' without revealing side effects, permission requirements, or the impact on the plugin or website. This is a significant gap for a mutating operation.
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, concise sentence with no unnecessary words. While very brief, it is efficiently front-loaded, though its brevity might border on under-specification rather than purposeful conciseness.
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?
Without an output schema, annotations, or additional context, the tool description is inadequate. It does not explain expected outcomes (success/failure), return values, or side effects, and the minimal parameters are not expanded upon. Given the complexity of plugin updates, the description is under-specified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides descriptions for both parameters (username, software) covering 100% of parameters, so the baseline is 3. The description adds no additional meaning about how these parameters relate to the update operation, leaving the schema's vague 'WordPress software identifier' as the only explanation.
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 a specific action ('Update') and resource ('the Hostinger WordPress plugin'), making the tool's purpose unambiguous. However, it does not explicitly differentiate from sibling tools like wp_plugins_update, which also update plugins, though the target is clear from the name and description.
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 wp_plugins_update, nor any context on prerequisites or circumstances that warrant its use. The description simply states the action without any situational advice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It fails to mention that activating a theme will change the active theme, deactivate the previous one, or require the theme to be already installed. This lacks critical side-effect information.
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, well-formed sentence with no wasted words. It is front-loaded and easily parsed, though its brevity borders on under-specification rather than effective concise communication.
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 insufficient. It does not explain the expected outcome, any prerequisites, or error conditions. A simple activation tool still requires context about its effects and dependencies, which is absent.
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 provides descriptions for all three parameters (theme slug, software identifier, username) with 100% coverage. The description does not add any additional meaning beyond the schema, so it remains at 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 'Activate a WordPress theme' uses a specific verb and resource, clearly indicating the tool's function. It distinguishes the action from sibling tools like wp_themes_install or wp_plugins_activate, though it does not explicitly differentiate from similar theme 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, nor are prerequisites mentioned (e.g., the theme must be installed). The description gives no context for choosing this tool over wp_themes_install or wp_themes_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 must carry the full burden of behavioral disclosure. It only states the action without explaining side effects, such as whether the theme is downloaded from the WordPress repository, whether it becomes active after installation, or what happens if the theme already exists. This is a significant gap for a mutation-type operation.
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, short sentence with no wasted words. It is front-loaded with the essential action. However, it is so brief that it borders on under-specification, though for the purpose of this dimension, conciseness is excellent and structure is straightforward.
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 there is no output schema and no annotations, the description needs to explain more about the tool's behavior and prerequisites. It does not mention how the theme slug is obtained, what the response will look like, or whether any post-install steps (like activation) are required. The description is too sparse to be fully complete for an agent to invoke the tool with confidence.
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 provides 100% coverage for all three parameters (theme slug, software identifier, username), each with a brief description. The tool description adds no additional meaning beyond the schema. Since schema descriptions already clarify the parameters, a baseline score of 3 is appropriate, but the description does not enhance understanding or provide usage examples.
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 states a clear verb and resource: 'Install a WordPress theme.' It distinguishes from sibling tools like wp_themes_activate, wp_themes_update, and wp_themes_uninstall by focusing on the installation action. However, it lacks any additional context such as the source of the theme or the hosting account scope, so it doesn't fully reach the level of specificity shown in high-quality examples.
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 that users should first search for a theme using wp_themes_list_available or that installation is a prerequisite for activation. There are no exclusions or 'when not to use' instructions, leaving the agent without context for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotation destructiveHint=true already signals destructiveness, but the description adds no additional context such as whether files are permanently deleted, whether themes are deactivated first, or if the action is reversible. This is a missed opportunity for a destructive operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no fluff or redundant information. It is concise and front-loaded, though its brevity borders on under-specification.
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 three required parameters and no output schema, this description is incomplete. It does not explain the consequences of uninstalling themes, any prerequisites, or what happens to active themes, leaving the agent to infer critical behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with each parameter described (username, software, themes). The description itself adds no parameter-level detail, but the schema already provides sufficient semantics, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Uninstall WordPress themes' clearly states the action and resource. It distinguishes from siblings like wp_themes_install, wp_themes_activate, and wp_themes_update, though it lacks any further elaboration on scope or effect.
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, what alternatives exist, or any prerequisites. The description simply states the action without context on how it fits among related theme tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It only says 'Update WordPress themes', which conveys mutation but doesn't disclose any behavioral traits such as side effects, requirements, or that it updates to the latest version. This is insufficient for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words. It is front-loaded with the action. However, it may be too terse to convey additional context, but it remains appropriately concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple update tool with fully documented parameters and no output schema, the description is minimally adequate. It lacks context on what updating entails (e.g., fetching latest versions) or any side effects, but given the tool's simplicity, a 3 is reasonable.
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 (username, software, themes). The description adds no extra parameter context, thus baseline 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 uses a specific verb 'Update' and resource 'WordPress themes', clearly distinguishing it from sibling tools like wp_themes_install, wp_themes_activate, and wp_plugins_update. However, it lacks explicit scope (e.g., that it updates the specified theme slugs).
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 vs alternatives. It doesn't mention that this is for updating existing themes or that it should be used after checking wp_themes_list_installed or available updates. No exclusions or alternatives 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?
There are no annotations, so the description must disclose behavior. It only states 'Get output' without clarifying whether this is a read-only operation, what happens if no output exists, response format, or rate limits. It adds little beyond the tool name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
It is a single concise sentence with no fluff, but it is under-specified. It could have included usage guidance or alternative references without becoming verbose.
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 there is no output schema, the description should explain what 'output' means (e.g., logs, stdout) and any context about the UID. It lacks context about how to retrieve the UID (from cron list) and what the response might contain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers both parameters (username and uid) with descriptions. The tool description adds no additional semantic meaning, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and identifies the resource ('output of a cron job execution'). It clearly differs from sibling tools like hosting_cron_list, which list cron jobs, and hosting_cron_create/delete. It is specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage 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. The description does not mention that the UID should come from hosting_cron_list or that this is for retrieving execution logs. There are no explicit exclusions or preferred 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?
Annotations already include destructiveHint: true, but the description adds no further context such as irreversibility, impact on mailbox data, or any side effects. It simply repeats the operation name, offering no additional transparency beyond the annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise, but it essentially restates the title 'Delete Mailbox' and does not earn its place. It is not verbose, yet it adds no new information and is not structured to guide an agent beyond the obvious.
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, the description is incomplete. It does not indicate whether the operation is reversible, what happens to the mailbox's emails, or what the response looks like (no output schema). The destructive annotation covers one aspect, but the description itself lacks essential contextual guidance.
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% coverage for the single parameter mailbox_id with a description, so the baseline of 3 applies. The tool description does not add any extra meaning about the parameter beyond what the schema already provides.
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 'Delete a mailbox.' clearly states a specific verb (delete) and resource (mailbox), distinguishing it from sibling tools like mail_mailboxes_list, mail_mailboxes_create, and mail_mailboxes_change_password. There is no ambiguity about the operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites, permanence, or alternative deletion tools for aliases/forwarders. It is purely a restatement of the action.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/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 only says 'List webhook delivery logs', adding no behavioral information beyond the name—no pagination, ordering, security, or output details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no redundant words. It is front-loaded and immediately states the action and object.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no annotations, no output schema, and a terse description, the tool lacks sufficient context about return values, error conditions, or what 'delivery logs' entails. An agent would need external knowledge 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?
The schema describes order_id as 'Mail order ID' with 100% coverage, so the description needs not repeat it. However, it adds no further context such as how to obtain the ID or any constraints, meeting baseline but adding no extra value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'List' and the resource 'webhook delivery logs', clearly distinguishing it from sibling tools like mail_webhooks_list (lists webhooks) and mail_logs_outbound (different log 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 given on when to use this tool versus alternatives. It does not mention prerequisites, context, or exclusions, leaving the agent to infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The destructiveHint annotation already signals that this is a destructive operation, but the description adds no further behavioral context. It does not mention permanence, cascading effects on privileges, or any safety caveats, which would be valuable 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, clear sentence that directly states the tool's purpose. It is concise and front-loaded with no unnecessary words or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with a fully described schema and a destructiveHint annotation, so the context is adequate. However, it lacks any mention of consequences (e.g., irreversible removal, impact on associated grants) or return behavior, leaving some gaps for a destructive operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with each parameter (website_uid, database_name, database_user_name) having a basic description. The tool description adds no additional semantic meaning beyond what the schema already provides, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
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 the resource ('a database user'), making it unambiguous. However, it does not distinguish this tool from similar delete tools like agency_db_delete or hosting_db_delete, which also target database entities.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives or on prerequisites (e.g., the user must exist, must be removed before the database, etc.). The sibling context (agency_db_create_user) implies an inverse relationship, but the description does not state it.
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 only says 'List', which implies a read-only operation, but gives no details about pagination, sorting, or what data is returned. This is minimal transparency beyond the action itself.
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, concise sentence with no redundant wording. It gets straight to the point and is easy to parse, though it could arguably be slightly more informative without becoming verbose.
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 minimal but sufficient for a basic understanding. However, it lacks context such as whether all orders are returned, pagination behavior, or any caveats. It is adequate but leaves clear 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 zero parameters, and the input schema is empty (100% coverage). With no parameters to document, the description need not explain parameter semantics. The baseline of 4 applies for parameterless tools, as there is nothing to add.
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 the resource 'Agency Plan orders', which identifies the tool's primary function. It distinguishes from sibling tools like mail_orders_list and hosting_orders_list through the 'Agency Plan' qualifier, though it doesn't elaborate on what exactly an Agency Plan order is.
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 usage guidance is provided. The description does not mention when to use this tool versus alternatives like billing_get_subscriptions or list_all_subscriptions_paginated, nor does it state any exclusions or prerequisites. Usage is only implied by the tool's name.
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?
The description simply repeats the destructive nature already indicated by the destructiveHint annotation, adding no new behavioral context such as irreversibility, cascading effects on domains or databases, or required permissions. It provides no value beyond the annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no unnecessary words or repetition. It is concise and immediately conveys the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter delete operation with a destructive annotation, the description is minimally adequate. However, it lacks any mention of what happens to associated resources (e.g., domains, databases) or whether the operation is reversible, which could be important for a destructive action.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers 100% of the parameter (website_uid) with a description, so the baseline is 3. The tool description adds no additional meaning or context about the parameter beyond what the schema already 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 ('Delete') and the resource ('an Agency Plan website'), which distinguishes it from sibling tools like agency_website_provision or hosting_websites_delete. It does not explicitly contrast it with alternatives, but the 'Agency Plan' qualifier gives enough 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?
No guidance is provided on when to use this tool versus similar deletion or website management tools such as agency_website_provision, hosting_websites_delete, or agency_website_get. There is no mention of prerequisites, exclusions, or alternative 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 the full burden of behavioral disclosure. It only states that a new store is created, but does not mention return value, side effects, idempotency, name uniqueness, or any permissions required. This is a significant gap for a creation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no redundant words or filler. It is appropriately sized for the tool's simplicity and immediately conveys the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (one parameter, no output schema), so the description is mostly sufficient. However, without annotations or mention of return type or any behavioral caveats, an agent is left without full context on what to expect after invocation. It is adequate but has clear gaps.
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 'name' parameter is fully described). The description adds no extra meaning beyond the schema, so it meets the baseline of 3. 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 tool's action ('Create a new ecommerce store') with a specific verb and resource. It is not tautological and distinguishes itself from sibling store tools (list, delete, metadata) by the 'create' action, though it does not explicitly mention 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?
The description provides no guidance on when to use this tool versus alternatives. It does not state prerequisites, exclusions, or context that would help an agent decide between this and related ecommerce tools (e.g., ecommerce_stores_list or ecommerce_products_create_physical).
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 disclosing behavior. It only states a read operation ('Get metadata') but does not disclose return format, error handling, rate limits, or any specifics about what 'metadata' includes. This is minimal transparency.
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 concise sentence with no filler words. It is front-loaded and easy to parse. However, it is slightly under-informative, but for a simple getter it is appropriately sized.
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?
The tool has no output schema and no annotations, so the description should explain what metadata will be returned or any important context. It only says 'Get metadata' without specifying the content or structure of the response, making it incomplete for an agent to anticipate 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 already provides 100% coverage with the store_id parameter described as 'Store ID'. The description does not add any additional semantic meaning beyond the schema, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get metadata for a store' clearly states the verb (Get) and resource (store metadata). It distinguishes from sibling tools like ecommerce_stores_list (which lists stores) by indicating a single store. The purpose is unambiguous and aligned with the tool name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention that it should be used when a store_id is known or contrast with ecommerce_stores_list, ecommerce_stores_create, or ecommerce_stores_delete. No exclusions or alternative references are given.
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, and the description only restates the purpose. It does not disclose whether the operation has side effects, requires specific permissions, returns particular data fields, or handles errors. The read-only implication of 'Get' is not enough to cover behavioral transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no filler. It is front-loaded with the key verb and resource, though it is slightly redundant with the title 'Get Horizons Website'.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no annotation, the description fails to explain what 'details' are returned, what format they take, or any relevant caveats. For a get operation, users need to know what to expect in the response, and this information is absent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the single parameter website_id, which is self-explanatory. The description adds no additional context beyond the schema, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get details of a Horizons website' uses a specific verb ('Get') and resource ('Horizons website'), clearly distinguishing it from sibling tools like horizons_create_website (create) and hosting_websites_list (list). It communicates exactly what the tool does.
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 agency_website_get or hosting_websites_list. There is no mention of use cases, prerequisites, or exclusions, leaving the agent to infer applicability 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 the full burden. It only states the action 'toggle cache on/off' without disclosing side effects, whether the toggle is persistent, or what specific cache types are affected. Minimal behavioral detail.
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 conveys the action without redundancy. It is front-loaded and efficient, earning a high score.
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 tool with full schema coverage, the description is minimally viable. However, it lacks context about sibling tools and behavioral specifics, particularly the distinction from hosting_cacheless_toggle, leaving some ambiguity.
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?
Both parameters are fully described in the schema with high coverage (100%). The description adds no extra meaning beyond the schema, but baseline 3 is appropriate since the schema already documents the parameters clearly.
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 (toggle) and resource (website cache) with a specific verb. It distinguishes from hosting_cache_clear (clearing cache) but not from hosting_cacheless_toggle, which could be ambiguous. Overall, purpose is clear.
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 hosting_cacheless_toggle or wp_memcached_toggle. There is no mention of scenarios, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must disclose behavior. It only says 'Get a link' with no mention of whether this is a read-only operation, if special permissions are needed, if the link expires, or if any state changes occur. The description offers minimal behavioral context beyond the action itself.
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 sentence and is concise with no wasted words. However, it largely restates the title ('Get phpMyAdmin Link') and adds only 'access' and 'for a database,' which provides minimal additional structure or information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no annotations and no output schema, the description is underspecified. It does not explain what the phpMyAdmin link is, how it will be returned, or any prerequisites. Given the tool's simplicity, some context about usage or return format is still expected; this description falls short.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides descriptions for both parameters ('Database name' and 'Hosting account username'), covering 100% of the schema. The description adds no additional meaning about the parameters or their relationship, so it scores at the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action: 'Get a phpMyAdmin access link for a database.' It identifies a distinct purpose among sibling hosting_db_* tools (list/create/delete/repair), making it easy to distinguish. Though it's brief, it fully conveys the tool's function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide any guidance on when to use this tool over alternatives. It does not mention that this is for accessing a database via phpMyAdmin, nor does it distinguish from tools like hosting_db_remote_create or hosting_db_list. No exclusions or conditions are given.
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?
The only behavioral signal is the destructiveHint annotation. The description itself adds no additional context beyond the fact that it removes a connection. It does not state that the action is permanent, irreversible, or what side effects occur (e.g., removing the remote access entry). Given the annotation covers the core destructive nature, the description still fails to provide richer behavior details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single clear sentence. It is perfectly concise and front-loaded, with no filler. However, its brevity contributes to the lack of detail in other dimensions.
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 delete operation with two documented params and a destructive annotation, the description is minimal but adequate. It lacks any mention of response/return behavior or impact, but given the tool's simplicity and the annotation, it meets the minimum threshold. It doesn't explain what 'remote database connection' means in this hosting context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully documents both parameters ('username' and 'name') with descriptions. The description does not add any further meaning to the parameters, but the schema coverage is 100%, so this is acceptable.
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 uses the specific verb 'Remove' and identifies the resource as 'a remote database connection', clearly distinguishing it from general database deletion tools like hosting_db_delete. It could be stronger with an explicit alternative reference, but it's unambiguous within the 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 about when to use this tool instead of hosting_db_delete or other DB management tools. It does not mention prerequisites such as the connection needing to exist, or any conditions. This is a significant gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It conveys that a subdomain is generated, but does not disclose consequences (e.g., is it permanent? any limits?), return format, or whether it consumes any quota. This is minimal transparency for a creation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no redundant phrasing. It efficiently states the core action and purpose without wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description is too brief to fully inform an agent. It does not explain what the resulting subdomain format is, whether it requires any prior setup, or what the response contains. This is inadequate for a tool with zero structured context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline score is 4. The description does not need to explain parameter meaning since none exist, and the empty schema fully covers the input structure.
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 'Generate a free subdomain for testing' clearly identifies the action (generate), resource (free subdomain), and purpose (testing). It distinguishes from sibling tools like hosting_subdomains_create by specifying 'free' and 'testing', though it does not explicitly explain the difference from a regular subdomain creation.
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 gives only a vague usage context ('testing') but does not provide explicit guidance on when to use this tool versus alternatives like hosting_subdomains_create. It lacks any mention of when not to use it or what prerequisites exist (e.g., an active hosting plan).
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?
The description simply repeats the action without adding behavioral context. While the destructiveHint annotation already flags this as destructive, the description does not mention permanence, potential impact on the website, or that the parked domain becomes inaccessible. No additional information is disclosed beyond the annotation.
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?
At four words, the description is maximally concise with no wasted words. It front-loads the verb and object clearly. The short length is appropriate for a simple delete operation, though it sacrifices other dimensions.
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 and the destructiveHint annotation, the description is adequate but minimal. It does not explain the consequences of removal or any prerequisites. With no output schema, it leaves out what happens on success or failure, making it slightly under-specified for a destructive action.
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 fully describes all three required parameters (username, domain, parked_domain) with clear descriptions, so the schema already provides high coverage. The description adds no additional parameter-level detail or relationships. Baseline score of 3 is appropriate given the 100% 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 'Remove a parked domain' provides a specific verb and resource, clearly indicating the delete operation for a parked domain. It distinguishes from siblings like hosting_parked_create and hosting_parked_list by implying removal rather than creation or listing, though not explicitly. The phrasing is direct and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers no guidance on when to use this tool versus alternatives such as hosting_parked_create or hosting_parked_list. It lacks any context about prerequisites, scenarios, or exclusions. This is a clear gap for a destructive operation.
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 only restates the action without mentioning that this is a read-only operation, or whether results are paginated, sorted, or return full domain details. The name implies a safe list, but the description adds no explicit 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?
A single, front-loaded sentence that directly states the operation. No wasted words or redundant content, making it highly efficient for an agent 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?
The tool is simple with fully described parameters, but lacks an output schema and annotations. The description does not hint at return values or any edge cases (e.g., what happens if no parked domains exist). It is minimally viable 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 covers both parameters with clear descriptions (username and domain), giving 100% coverage. The description does not add any additional parameter meaning, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
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 the resource (parked domains) with a scope ('for a website'). It is specific enough to distinguish from siblings like hosting_parked_create or hosting_parked_delete, though it doesn't explicitly differentiate from other list 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 is no mention of exclusions, prerequisites, or related tools, so the agent gets no context for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure, but it only says 'verify ownership' without explaining the verification process, side effects, asynchronous behavior, or expected output. This leaves significant ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no superfluous words. It efficiently communicates the core action and context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (one parameter, no output schema), but the description leaves gaps about what 'verify' means, what success/failure looks like, and how it relates to domain ownership verification workflows. It is minimally adequate but not complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a single 'domain' parameter described as 'Domain to verify'. The description adds the hosting context but no additional semantic value beyond what the schema already provides, matching the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Verify') and resource ('ownership of a domain') with a clear hosting context. It does not explicitly differentiate from related siblings like domains_get_verifications, so it falls short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage 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 domains_get_verifications or dns_validate_records. There are no exclusions, prerequisites, or context signals to help select it.
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 must carry the full burden. It only states the action and gives no details about pagination, date range, response size, or any side effects. For a log-listing tool, users would need to know e.g., whether logs are recent or all, or any limits, none of which are disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no filler. It is front-loaded and easy to parse, earning a top score for 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?
For a tool with one well-defined parameter and no output schema, the description is minimal but not entirely inadequate. It clearly indicates the resource type. However, it doesn't explain what mailbox action logs contain, how they are scoped, or when they are available, which could leave an agent uncertain about the return value and filter options.
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 single parameter order_id is fully described in the schema ('Mail order ID'), so schema coverage is 100%. The description does not add any additional parameter semantics, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List mailbox-level action logs' uses a specific verb (list) and resource (mailbox action logs), making the purpose clear. However, it does not explicitly distinguish this from sibling tools like mail_logs_action or mail_logs_access, so it falls short of the top 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. Given many similar mail log tools (mail_logs_access, mail_logs_inbound, mail_logs_outbound, mail_logs_action), the lack of any contextual recommendation or exclusion is a clear gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only says 'List email marketing profiles', which implies a read operation but doesn't disclose return format, pagination, sorting, or any potential side effects. While listing is typically safe, the description doesn't confirm this or provide any additional 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no filler. It's front-loaded with the key verb and resource. However, it's extremely brief, which could be seen as under-specification, but for a simple list tool it's acceptable. Structure is straightforward.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (0 params, no output schema), so the description is minimally viable. However, it lacks context about what a 'profile' is, whether results are paginated, and how this compares to other list tools. It's adequate but leaves the agent without enough context to fully understand the tool's role.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the description doesn't need to explain parameter details. The schema fully covers the parameter space (vacuous coverage). The description adds no param-related semantics, but nothing is missing. Baseline 4 is appropriate for 0 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 states a clear action ('List') and a specific resource ('email marketing profiles'). It is distinguishable from siblings like reach_contacts_list and reach_segments_list, though it doesn't explicitly contrast them. It could be more specific about what these profiles include, but the core purpose is obvious.
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?
There is no guidance on when to use this tool versus alternatives. It doesn't explain the relationship to reach_profiles_dns_status or other profile-related tools, nor does it mention any prerequisites or typical use cases. 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?
No annotations are provided, so the description carries the full burden. It only says 'List contacts' implying a read operation, but it does not disclose pagination behavior, response format, error conditions, or any other behavioral traits beyond the bare 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, focused sentence that directly states the tool's purpose without unnecessary fluff. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with two required parameters and no output schema, the description is minimally complete. However, it lacks any mention of pagination, response shape, or how this tool relates to the similarly named reach_segments_contacts, leaving some ambiguity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for both parameters ('Profile UUID' and 'Segment UUID'). The description adds no additional meaning beyond these basic labels, but the schema already does the heavy lifting, so a baseline 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 ('List contacts') and the resource ('for a segment within a specific profile'). It distinguishes from siblings like reach_contacts_list by including the segment and profile scoping, though a similar sibling reach_segments_contacts exists and differentiation could be stronger.
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 reach_segments_contacts or reach_contacts_list. The description is purely declarative and gives no context for selection 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?
The description adds no behavioral context beyond what the annotation already conveys. The destructiveHint=true annotation covers the destructive nature, but the description does not mention irreversibility, recovery options, or any other consequences, offering no added transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence making it structurally concise, but it essentially repeats the title ("Delete VPS Snapshot") without adding value. It is not wasteful, but it does not earn its place by contributing new 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?
For a tool this simple (one parameter, no output schema), the description combined with the annotation and schema is minimally adequate. However, it omits any details about side effects (e.g., whether deletion is permanent or if there are restrictions on which snapshots can be deleted), so it is not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema fully describes the only parameter (vm_id with type and description), so baseline is 3. The description adds no parameter-related information, so it neither enhances nor detracts from the schema's coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ("Delete") on a clear resource ("VPS snapshot"), which unambiguously distinguishes it from sibling tools like vps_create_snapshot, vps_get_snapshot, and vps_restore_snapshot.
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, nor any prerequisites or exclusions. It merely restates the operation indicated by the name, leaving the agent to infer usage solely from the tool name.
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 behavioral burden. It only says 'Get firewall details with rules,' but does not disclose that this is a read-only operation, what happens if the firewall_id does not exist, whether rules are returned inline or separately, or any rate limits/authentication requirements. No additional context is provided beyond the verb itself.
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, direct sentence that front-loads the purpose. It is appropriately sized for a simple get operation, though it could incorporate more behavioral detail without becoming verbose.
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?
The tool has no output schema, so the description should explain return values. It mentions rules but not other firewall details, leaving the full response ambiguous. Given the simplicity of the tool, a more complete description of expected outputs and prerequisites 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 coverage is 100%, so the baseline is 3. The description does not add any meaning beyond the schema's 'Firewall ID' parameter description. It neither explains how to obtain the ID nor clarifies the expected value format.
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 resource ('firewall details'), and explicitly includes 'with rules' to indicate the response scope. This distinguishes it from sibling tools like vps_firewall_list (which likely lists firewalls) and vps_firewall_create/delete.
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 usage guidance is provided. The description does not mention when to use this tool instead of vps_firewall_list or other firewall management tools, nor any prerequisites or alternative scenarios. The need for a firewall_id is only implicit via the schema, not stated in the description.
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 only states that it auto-detects installations, but does not clarify whether this is a read-only scan, whether it modifies anything, what triggers it, or what the output looks like. This is minimal information for an agent to safely invoke the tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is front-loaded with the action and resource, containing no redundant or filler words. It is appropriately sized for the information it conveys.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one parameter and no output schema, and the description conveys the core action. However, it lacks context about what happens after detection (e.g., return format, whether installations are listed or counted) and any constraints, leaving it minimally adequate but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides 100% coverage for the single parameter 'username' with a description 'Hosting account username', so the schema already fully explains the parameter. The tool description adds no additional semantic value beyond the schema, resulting in the baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Auto-detect' and identifies the resource as 'WordPress installations on a hosting account', making the primary purpose clear. However, it does not explicitly distinguish from sibling tools like wp_installations_list or wp_check_valid, which may also relate to WordPress installations, preventing a full 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, nor does it mention prerequisites, exclusions, or context. It only states the action without any framing for appropriate 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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states 'List available WordPress core updates' and gives no details about potential side effects, authentication requirements, rate limits, or response format. The read-only nature is implied but not explicitly stated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, front-loaded with the action and resource, and contains no extraneous information. It is appropriately concise for a simple listing 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?
The tool is simple (list updates) and the schema covers both parameters, but there is no output schema and no mention of what the returned update list looks like or how to interpret it. The description is minimal and does not convey the full context needed for an unannotated tool, though the purpose is clear.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The descriptions of 'username' and 'software' are generic, and the tool description adds no additional context about how these parameters should be used or what values are valid. The description does not compensate for the schema's vagueness.
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 specifies the verb 'List' and the resource 'available WordPress core updates', which is distinct from plugin/theme update tools. However, it doesn't explicitly reference sibling tools like wp_update_core, so it doesn't fully differentiate from the update action.
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 vs alternatives. The description does not mention that this is a read-only counterpart to wp_update_core or that it should be used to check for updates before applying them. The agent must infer usage from the verb 'list' and sibling names.
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 must carry the full burden of behavioral disclosure. It only states the action 'List' without mentioning return format, whether authentication is required, or any side effects (though listing is likely read-only). The description adds little beyond what the tool name already implies.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the core action and object. No unnecessary words or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with two well-described parameters, but there is no output schema and no mention of what the response contains (e.g., plugin names, versions, active status). While minimal, the description is not severely incomplete for a straightforward list operation, but it could clarify scope (e.g., a specific WordPress installation).
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 already documented. The description adds no extra information about how username and software relate to the WordPress installation, but the schema descriptions are sufficient 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 'List installed WordPress plugins' clearly states a specific verb and resource, and is distinct from sibling tools like wp_plugins_available or wp_plugins_search. However, it does not explicitly differentiate itself from those siblings beyond the word 'installed'.
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?
There is no guidance on when to use this tool versus alternatives. Sibling tools like wp_plugins_available, wp_plugins_search, and wp_plugins_install exist, but the description provides no context for choosing this tool over them.
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 must fully convey behavioral traits. It only says 'Search the WordPress plugin repository' and provides no details about return format, result limits, error behavior, or whether it is read-only. The read-only nature is implied but not disclosed, and no other behavioral context is added.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence that wastes no words. It is appropriately sized for a simple search 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?
For a tool with one optional parameter and no output schema, the description is minimally adequate but leaves gaps. It doesn't mention what the search returns or how results are ordered, which could be important for an agent to know. Given the simplicity, a 3 is fair.
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 one parameter 'query' with a description 'Search query', giving 100% schema coverage. The description adds no further meaning about the parameter, such as expected format or optionality, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Search') and resource ('the WordPress plugin repository'), clearly conveying the tool's purpose. It distinguishes from sibling tools like wp_plugins_list and wp_plugins_available by using 'search' instead of 'list', though it doesn't explicitly name 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 given on when to use this tool vs. other plugin-related tools. There is no mention of scenarios, exclusions, or alternatives such as wp_plugins_available or wp_plugins_suggested, leaving the agent to infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It only states the function in one short sentence, without explaining how suggestions are generated, what the response contains, or whether any context is needed. The meaning of 'suggested' is unclear.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that directly states the tool's purpose. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with no parameters, but the description is under-specified: 'suggested' is vague and no output format or dependencies are mentioned. Given the context of many sibling plugin tools, more detail would improve clarity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so there is no parameter semantics to clarify. The description does not need to explain parameters; the baseline for no-param tools is 4.
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 uses the verb 'Get' and resource 'suggested WordPress plugins', clearly indicating it fetches recommendations. It distinguishes from sibling tools like wp_plugins_list and wp_plugins_available by the word 'suggested', though it could state more specifically what qualifies as suggested.
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 instead of related tools like wp_plugins_search or wp_plugins_available. The description lacks any context about ideal use cases or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the full burden of behavioral disclosure. It doesn't mention potential side effects, whether the update is a background process, if it could overwrite customizations, or any required permissions. The word 'update' implies mutation, but no safety or risk cues are given.
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, clear sentence with no filler. It gets straight to the point. However, it could arguably be slightly more detailed while still remaining concise, but the brevity is acceptable given the simplicity of the operation.
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?
The description lacks critical context for a mutation tool. There is no output schema or annotations to supplement it. It doesn't explain what happens after the update, whether it's reversible, or what the response looks like. For a tool that modifies a WordPress installation, this feels 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?
Both parameters are fully described in the schema (username and software with clear descriptions), so parameter semantics are adequately covered. The description adds no extra meaning beyond the schema, but the baseline of 3 applies given the 100% schema coverage.
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 ('Update'), the target ('WordPress core'), and the specific goal ('to latest version'). This distinguishes it from sibling tools like wp_plugins_update or wp_themes_update. Verb+resource+scope are all present.
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 vs alternatives. It doesn't mention checking for available updates with wp_list_updates first, nor any prerequisites like WordPress being installed. The description simply states the action without context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description is consistent with the destructiveHint annotation, but adds no extra behavioral context beyond what the annotation already signals. It does not state whether the deletion is permanent, what happens to associated data, or any side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, short sentence that is front-loaded and free of filler. However, it is somewhat redundant with the title and could have used the space to add differentiating context, so it does not fully earn 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 delete operation with fully documented parameters and a destructive hint, the description is minimally sufficient. Yet it lacks important contextual distinction from the analogous 'hosting_cron_delete' tool, and does not clarify the agency-specific scope, making it incomplete for seamless tool selection.
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 provides full descriptions for both parameters (uuid and website_uid), covering all necessary details. The description adds no additional parameter semantics, which is acceptable 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 states a clear verb ('Delete') and resource ('a cron job'), making the core action evident. However, it does not distinguish this tool from the sibling tool 'hosting_cron_delete', as it omits the 'agency' qualifier present in the title and name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'hosting_cron_delete'. There is no mention of prerequisites, context, or scenarios where this specific agency cron deletion is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only says 'List', implying a read-only operation, but does not mention authorization needs, pagination, response format, or any side effects. This is a significant gap even for a simple list tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no superfluous words, making it efficient. However, it is so minimal that it could include additional useful context (e.g., alternative tools) without becoming verbose, so a perfect score is not warranted.
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, the description is minimally adequate. However, with no output schema and no annotations, it does not explain the return format or any caveats. Given the presence of a closely related sibling tool (hosting_cron_list), a bit more contextual information would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema fully describes the single required parameter 'website_uid' with a clear description. The tool description adds no additional meaning to this parameter, so the baseline of 3 for high schema coverage is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (List), the resource (cron jobs), and the scope (Agency Plan website), making its purpose unambiguous. The explicit 'Agency Plan website' qualifier helps distinguish it from the similar hosting_cron_list sibling.
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 hosting_cron_list or agency_cron_create. There is no mention of prerequisites, exclusions, or context clues beyond the implicit Agency Plan scope, leaving the agent to infer.
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 behavioral disclosure burden. It only states that the tool lists domains, without mentioning response format, pagination, authorization requirements, or whether results are filtered by plan status. This is minimal disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence containing only necessary information: the action (List) and the scope (all Agency Plan domains). It is front-loaded and free of filler or redundant content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless listing tool, the description is minimally viable, but it omits details about the returned data shape, pagination, or plan-specific constraints. Since there is no output schema, some indication of return format would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and an empty input schema, so schema description coverage is 100% vacuously. The baseline of 4 for a parameterless tool applies; the description cannot add parameter semantics where none exist.
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 uses the specific verb 'List' and resource 'Agency Plan domains', clearly conveying a read-only listing operation. It lacks explicit differentiation from sibling tools like domains_get_list or list_all_domains_paginated, but the 'Agency Plan' scope makes it reasonably distinct.
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 related domain-listing tools such as domains_get_list or list_all_domains_paginated. There are no exclusions, prerequisites, or alternative tool references.
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 only states the action and lacks details on side effects (e.g., DNS changes), required permissions, reversibility, or what happens on failure. 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, concise sentence that is front-loaded and wastes no words. It is appropriately sized for the simple action described.
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?
The tool has low complexity and a simple schema, but the description omits important contextual details such as return values, domain ownership verification, or potential propagation delays. For a mutation tool with no output schema or annotations, more depth is needed to be fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with 'Domain to link' and 'Website UID' already described. The tool description adds no extra meaning beyond the schema, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Link') and resource ('domain to an Agency Plan website'), clearly distinguishing it from sibling tools like 'unlink_domain' and 'change_domain'. The verb is explicit and the target is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage 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, nor any prerequisites or exclusions. The description only states the action without context on domain verification, website requirements, or relationship to other domain-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?
There are no annotations, so the description carries the full burden. It only states the action without disclosing potential side effects like charging, order status implications, or whether it is a one-time or recurring purchase. For a billing tool, this is a significant transparency gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that directly states the purpose. It is appropriately front-loaded and contains no filler, earning a high score for efficiency.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no annotations, the description leaves out critical context: what the response contains (e.g., order ID, status, payment link), potential errors, and dependencies on other billing tools. For a transaction-like operation, this is 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?
Schema description coverage is 100% for both parameters ('items' and 'payment_method_id'), so the baseline is 3. The description adds no extra meaning beyond the schema, such as how to obtain valid item IDs or if there are constraints on cart contents.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Create') and a clear resource ('purchase order for Hostinger services'). It distinguishes from sibling billing tools like billing_renew_subscription and billing_get_payment_methods, which handle renewals or 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?
No guidance is provided on when to use this tool versus alternatives. It does not mention prerequisites such as needing item IDs from billing_get_catalog or payment methods from billing_get_payment_methods, nor does it exclude cases like renewals.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, but it does clearly imply a read-only operation via the word 'Get,' which is a key behavioral trait. However, it does not disclose return format, error behavior, or any prerequisites, which could be expected for a more complex tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no extraneous words, which is highly concise and front-loaded. It effectively communicates the core function, though it could be slightly more informative without adding verbosity.
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 (simple 2-parameter read operation) and the absence of an output schema, the description is minimally adequate. It clearly states what it does, but does not explain what 'details' includes or how it fits into the DNS snapshot lifecycle with sibling tools like dns_get_snapshots and dns_restore_snapshot.
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 fully documents both parameters (domain and snapshot_id) with descriptions, so the schema coverage is 100%. The description's 'specific DNS snapshot' aligns with these parameters, but adds no additional meaning beyond what the schema already provides, earning a baseline score.
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 uses a specific verb ('Get') and identifies the resource as 'a specific DNS snapshot details,' which clearly indicates the operation is to retrieve one snapshot. This distinguishes it from the sibling tool 'dns_get_snapshots' which likely lists all snapshots, though it does not explicitly reference the sibling.
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 dns_get_snapshots or dns_restore_snapshot. It only states what it does without any contextual advice, leaving the agent to infer its place in the workflow.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must carry the full transparency burden. It only says 'List DNS snapshots', which implies a read-only operation, but does not state this explicitly, nor does it disclose output format, pagination, or any side effects. This is insufficient for a tool without annotation support.
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 redundant words. It is appropriately compact and front-loads the action verb, making it easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no annotations, the description is too sparse to be contextually complete. It doesn't describe the structure of the returned list, how snapshots are identified, or how this tool relates to dns_get_snapshot and dns_restore_snapshot, leaving the agent under-informed.
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 provides 100% coverage for the only parameter, 'domain', described as 'Domain name'. The description adds no additional parameter semantics beyond restating that snapshots are for a domain, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the verb 'List' with the resource 'DNS snapshots' and scope 'for a domain', clearly indicating a listing operation. However, it does not explicitly distinguish itself from the sibling tool dns_get_snapshot, relying only on pluralization to imply it lists all snapshots versus retrieving one.
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?
No explicit when-to-use or alternative guidance is provided. The description implies the tool is for listing snapshots, but it doesn't mention related tools like dns_get_snapshot or dns_restore_snapshot, leaving the agent without clear direction on tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It merely restates the title ('List all WHOIS profiles') without adding context on pagination, rate limits, empty results, or how profiles relate to domain purchases, providing minimal insight beyond what the tool name already conveys.
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, tight sentence with no filler or redundant elaboration. Every word earns its place and the primary action ('List') is front-loaded, making it maximally concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list operation with no output schema and no annotations, the description is adequate but minimal. It could improve by noting the relationship to sibling tools, such as clarifying that domains_get_whois_profile retrieves a single profile, but the low complexity of the tool keeps this gap modest.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero properties, and the schema already makes clear that no parameters are required. With 0 parameters, the baseline of 4 applies, as the description has no additional parameter semantics to explain.
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 'List all WHOIS profiles' uses a specific verb ('List') and a clear resource ('WHOIS profiles'), making the core operation unambiguous. However, it does not explicitly differentiate from the sibling tool domains_get_whois_profile, relying on the singular/plural contrast in tool names to convey the 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 choose this tool over its siblings. It does not mention that domains_get_whois_profile should be used for retrieving a single profile, nor does it explain the relationship to domains_get_whois_profile_usage, leaving the agent to infer the appropriate context solely from the tool name.
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 responsibility for behavioral disclosure. It only states the action without mentioning whether nameservers are replaced or merged, whether propagation time applies, or whether authentication/scoped permissions are needed. For a mutation 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, front-loaded sentence with no redundant words or filler. It earns its place by conveying the core purpose 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?
Despite having only two well-described parameters, this is a mutation tool with no annotations and no output schema. The description lacks behavioral context such as replacement semantics, required permissions, or post-update considerations, so it is not fully complete for an agent to invoke confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with both domain and nameservers having basic descriptions. The tool description adds no extra parameter semantics, so the baseline of 3 applies since the schema already documents the parameters adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the exact action ('Update nameservers') and the resource ('a domain'), making the tool's purpose immediately clear. It also implicitly distinguishes from sibling tools like vps_set_nameservers, which target VPS resources instead.
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 given on when to use this tool versus alternatives. It does not mention prerequisites, exclusions, or compare with related tools such as dns_update_records or domains_update_forwarding, leaving the agent to infer usage solely from the name.
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 must disclose behavioral traits. It only states the action 'Set shipping configuration' without explaining whether it replaces existing configuration, authentication needs, validation rules, or side effects. 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?
A single seven-word sentence that is front-loaded and contains no filler. Every word contributes to stating the action and target.
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 output schema and no annotations, the description fails to convey return behavior, prerequisites, or the expected shape of the shipping configuration. It is too sparse to fully guide an agent, leaving key operational details unspecified.
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 baseline is 3. The description adds minimal context by indicating the target is a store, but it does not clarify the structure or allowed values of the 'shipping' object, whose schema description is only 'Shipping configuration object'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Set') and resource ('shipping configuration') scoped to 'a store', clearly distinguishing this from sibling ecommerce tools like store creation or product creation.
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 instead of alternatives, prerequisites, or whether it should be called after store creation. The description offers no usage context 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, the description carries the full burden of behavioral disclosure. It only says 'Clear cache' without explaining the scope (e.g., entire website vs. specific cache), side effects, or dependencies (e.g., whether cache must be enabled). This is a significant gap for a mutating operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, directly front-loaded with the core action and resource. Every word is necessary, and there is no redundancy or filler, making it highly 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?
The description is minimally sufficient but incomplete given the complexity of the domain. It fails to mention how this relates to hosting accounts, the role of the username/domain, or how it differs from the many sibling cache tools. Without this context, an agent may mis-select this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers 100% of parameters with basic descriptions ('Website domain', 'Hosting account username'). The description adds no additional meaning or relationship between the parameters, so it only meets the baseline without exceeding it.
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 (clear) and resource (cache for a hosted website), distinguishing it from similar tools like agency_cache_clear and clear_api_cache by the 'hosted website' context. It avoids vague language and directly matches the tool's name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as hosting_cache_toggle, hosting_cacheless_toggle, or clear_api_cache. The description lacks any conditional use cases, prerequisites, or exclusions, leaving the agent to guess.
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?
The annotation destructiveHint=true already signals the destructive nature, and the description 'Delete a cron job' is consistent with that. However, the description adds no additional behavioral context (e.g., irreversibility, consequences) beyond what the annotation provides.
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, concise sentence with no filler. It is front-loaded and every word earns its place, though it is minimal.
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 delete tool with two fully described parameters and a destructiveHint annotation, the description is adequate but sparse. It does not mention potential pitfalls, prerequisites, or what happens after deletion, which would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% (both 'uid' and 'username' have descriptions), so the schema carries the parameter meaning. The description adds no further context about how the parameters relate to the deletion process.
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 'Delete a cron job' clearly states the action (delete) and the resource (cron job). It is unambiguous and consistent with the tool name and title. It distinguishes from create/list cron tools by specifying deletion, though it doesn't explicitly differentiate from agency_cron_delete.
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?
There is no guidance on when to use this tool, prerequisites, or alternatives. The one-sentence description gives no context about needing existing cron job UIDs or how this fits into cron management workflows.
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. The description adds minimal behavioral context, simply restating the action. It does not disclose response format, authorization requirements, or what 'available' means, which is a gap for a no-annotation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, front-loaded and free of unnecessary detail. It is appropriately sized for the tool's simple nature.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no params and no output schema, but the description is still too terse. It does not specify that this lists hosting-specific datacenters, which is important given sibling tools for VPS and agency datacenters. Also, no return value details are given, leaving some ambiguity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and the schema is empty, so schema coverage is 100%. There are no parameter semantics to clarify; the description correctly implies no inputs are 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 states it 'List available datacenters,' which is a clear verb+resource. However, it does not explicitly distinguish hosting datacenters from sibling tools like vps_datacenters_list or agency_datacenters. The title and name provide the hosting context, so it is still clear enough.
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 vs. alternatives. With sibling tools vps_datacenters_list and agency_datacenters, there is no differentiation or explicit context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only mentions granting remote access but does not explain side effects, whether the action is reversible, any security implications, or what happens to existing connections. This is a thin description 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 sentence with no waste. It is front-loaded and immediately conveys the core function. This is an example of efficient writing, every word contributes.
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?
The tool has no output schema and no annotations, so the description should compensate by explaining outcomes, prerequisites, or error conditions. It does none of these. For a tool that modifies database access, the description leaves out significant context that an agent would need to invoke 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?
The input schema covers 100% of parameter descriptions (ip, name, username), so the baseline is 3. The description does not add any additional parameter semantics beyond what the schema already provides, but it also does not need to since the schema is clear.
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: allowing a remote IP to connect to a database, which aligns with the tool name 'hosting_db_remote_create' and distinguishes it from sibling tools like hosting_db_remote_list or hosting_db_remote_delete. The verb 'Allow' and resource 'database' are specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage 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 is no mention of prerequisites, such as needing an existing database, or exclusions, such as not using it for local connections. It simply states what the tool does without contextualizing its 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 must disclose behavioral traits. It only states that the tool lists remote database connections, without explaining whether it is read-only, what it returns, or any side effects. The description doesn't even confirm that it lists all connections or if any filtering applies.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that clearly states the action and resource. It avoids redundancy and is front-loaded with the verb. There is no unnecessary information or filler.
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?
The tool has no output schema and no annotations, so the description needs to provide enough context for the agent to understand what the tool does and returns. It only restates the title and lacks details about the response format or the nature of remote database connections. The description is too sparse to be fully complete for an agent invoking this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage for the single parameter (username), so the schema already explains it. The description adds no additional meaning beyond the parameter's existence, but the baseline of 3 is appropriate since the schema is self-sufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: listing remote database connections. It uses a specific verb (list) and resource (remote database connections), distinguishing it from sibling tools like hosting_db_list which list general databases. The word 'remote' differentiates it from other database tools in the sibling set.
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?
There is no guidance on when to use this tool versus alternatives. It does not mention that it returns a list of remote DB connection entries, nor does it reference related tools for creating or deleting remote connections. The usage context is only implied by the tool's name and sibling set.
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 must disclose behavioral traits but only states the action 'create.' It does not mention whether the build is asynchronous, what side effects occur (e.g., restart), or how to monitor progress. This is a significant gap for a creation 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 that states the action and source without wasted words. It is appropriately front-loaded and 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 create operation with no annotations and no output schema, the description is under-specified. It omits essential context such as how the archive is uploaded, what the build process entails, expected outcomes, and follow-up actions (e.g., checking build logs or listing builds).
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%, providing descriptions for 'domain' and 'username.' The description adds no additional meaning about how these parameters relate to the archive or the build process, so it earns the baseline score without compensating for any gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'create' with the resource 'Node.js build' and the source 'from an uploaded archive,' making the action specific and distinguishable from sibling tools like hosting_nodejs_builds_list (list) and hosting_deploy_js_app (deploy).
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 (e.g., hosting_deploy_js_app), no prerequisites (e.g., how to upload the archive), and no context about typical use cases. Users are left without information to decide correctly.
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 for behavioral disclosure. 'Auto-patch' implies a mutating operation, but it does not disclose potential side effects (e.g., service restart, file changes, downtime) or any confirmation/rollback behavior. This is a significant gap for a security patching 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 sentence with no filler. Every word contributes meaning, and the structure is straightforward. It is appropriately concise for a tool with simple 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 that this is a mutation tool with no output schema, the description is severely lacking. It does not explain what the tool returns, whether it affects all known vulnerabilities or just one, or any preconditions. The presence of sibling tools like hosting_nodejs_vulnerabilities suggests a workflow that is not mentioned.
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 provides descriptions for both parameters (domain, username) with 100% coverage. The description adds no additional meaning or context beyond that, matching the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Auto-patch' and clearly identifies the resource ('Node.js vulnerabilities'). It distinguishes itself from the sibling tool 'hosting_nodejs_vulnerabilities' (which likely lists vulnerabilities) by focusing on the patching action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It does not mention prerequisites like running a vulnerability scan first, or exclusions such as 'only for known vulnerabilities' despite the word 'known' implying some prior check.
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 disclosing behavioral traits. It only says 'Restart a Node.js application,' which conveys the basic stop/start action but gives no information about side effects, downtime, required permissions, whether it affects all app instances, or what the response indicates. This is minimal beyond what the tool name already suggests.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that is instantly scannable. Every word earns its place, and there is no redundant phrasing. It is front-loaded with the action and clearly states the target resource.
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 simple restart tool with no annotations, output schema, or complex parameters, this description might suffice at a bare minimum, but it lacks essential context. It does not explain what a 'Node.js application' means in this hosting context, how it relates to other hosting_nodejs tools, or what happens after restart. Given no annotations to fill the gap, the description feels incomplete for a production API tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema descriptions cover both parameters (username and domain) with clear labels, and schema coverage is 100%. The description adds no additional parameter context, but the baseline of 3 is appropriate since the schema already documents meaning. No extra semantics are needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action ('Restart') applied to a specific resource ('a Node.js application'). This distinguishes it from sibling tools like vps_restart (for VPS) and vps_docker_restart (for Docker), and aligns with the hosting_nodejs_* family. The verb+resource combination is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites, scenarios (e.g., after deployment or when the app is unresponsive), or exclusions (e.g., not for VPS or Docker restart). Users must infer usage from the tool name and sibling context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility for disclosing behavior, but it only states the action. It does not mention whether the token is returned in the response, any required permissions, idempotency, or side effects beyond creation.
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 wastes no words. It is appropriately front-loaded and easy 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 tool's simple nature, the description still lacks contextual completeness. It does not explain what the API token is used for, how the token is returned, or any setup instructions. The presence of sibling token tools implies a broader workflow, but this description does not situate the tool within that 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 has 100% coverage for the only parameter order_id ('Mail order ID'). The description's phrase 'for a mail order' adds no new detail beyond the schema, so it meets the baseline but provides no extra semantic value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (create), the resource (API token), and the scope (for a mail order). It distinguishes itself from sibling tools like mail_tokens_list and mail_tokens_revoke by specifying the creation operation and the associated order 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 or any prerequisites. The description only states what it does, not when it should be invoked, nor does it mention that list and revoke are the complementary 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?
The description merely restates the title and adds no behavioral context beyond the destructiveHint annotation. It does not disclose that the action is permanent or that services using the token will lose access.
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 concise sentence with no fluff, but it is essentially a restatement of the title. It is appropriately sized for a simple tool but lacks any supporting structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter destructive action, the description is minimally viable. It states the action, and the annotation covers destructiveness, but it omits any consequences such as token invalidation affecting existing services.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already fully documents token_id with a description, and the description adds no additional meaning. Baseline 3 applies due to 100% schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Revoke' and the resource 'mail API token', clearly distinguishing it from sibling tools like mail_tokens_list and mail_tokens_create.
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 vs alternatives. It does not mention that it invalidates a previously created token or any prerequisites, so the agent must infer usage from the tool name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of disclosing behavioral consequences. 'Regenerate' implies the old secret is replaced, but the description fails to state that the previous secret becomes invalid immediately or that consumers using the old secret will need to be updated. It does not mention any irreversible side effects or whether this action can be undone.
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 action. Every word is necessary, with no fluff or redundant phrasing. It is optimally 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?
The tool is a simple one-parameter mutation, but since there is no output schema, the description should explain what the response contains (e.g., the new secret) and any immediate effects. It does neither, leaving the agent to guess about the return value and the impact of regenerating the secret. This information is critical for correct invocation and handling.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the single parameter webhook_id, so the baseline is 3. The description adds no additional meaning beyond the schema, as it simply refers to 'a webhook' without clarifying how to identify it or any constraints. It neither enhances nor diminishes the parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Regenerate' and the specific resource 'signing secret for a webhook.' This precisely distinguishes it from sibling tools like mail_webhooks_update or mail_webhooks_create, which perform different actions on webhooks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It does not mention that this is for rotating a compromised secret or that mail_webhooks_update should be used for other webhook modifications. The description simply states what the tool does without usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. It only says 'Create multiple contacts for a profile' and lacks any disclosure of behavioral traits such as whether the profile must exist, how duplicates are handled, partial failure behavior, or authentication needs. This is insufficient for a mutating 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 short sentence that is front-loaded with the verb and resource. Every word earns its place, and there is no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no annotations and no output schema, the description is too thin to be complete. It does not explain the relationship to reach_contacts_create, bulk size limits, return behavior, or failure modes. While the schema handles parameter coverage, the overall tool context is underdeveloped.
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 (profile_uuid, contacts array, email, first_name, last_name) already described. The description adds no extra meaning beyond what the schema provides, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Create multiple contacts for a profile' with a specific verb (create), resource (contacts), and scope (multiple, for a profile). It distinguishes from the sibling reach_contacts_create by explicitly saying 'multiple', though the sibling name already implies the single variant.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied for bulk creation based on the name and description, but there is no explicit when-to-use guidance, exclusions, or mention of the alternative reach_contacts_create. The bulk vs. single distinction is carried by the title and name, not the description.
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 only states 'List contact segments' without mentioning whether the operation is purely read-only, what the response contains, any pagination or ordering, or potential side effects. The verb 'list' implies a safe read, but no explicit behavioral details are given.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that is front-loaded and contains no filler. Every word adds value for a zero-parameter tool, making it appropriately sized 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?
The tool is simple with zero parameters, but since there is no output schema, the description should ideally convey what the response looks like (e.g., a list of segments with names/IDs) or any relevant behavior like pagination. It does not go beyond the basic action, leaving some gaps in expectations for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema coverage is 100%, so the description is not required to explain parameter details. The baseline of 4 for a zero-param tool is appropriate; the description adds nothing about parameters because there are none to describe.
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 'List contact segments' uses a clear verb (List) and a specific resource (contact segments), which distinguishes it from general 'segments' and implies a collection action versus a single-segment operation like reach_segments_get. However, it does not explicitly differentiate from related sibling tools or specify any filtering 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?
There is no guidance on when to use this tool versus alternatives such as reach_segments_get or reach_segments_profile_contacts. The description simply states the action without any context, exclusions, or mention of alternative tools for specific 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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It does not explain side effects (e.g., adding the key to the VM's authorized_keys), prerequisites (e.g., the key must already exist), or error conditions. The verb 'attach' implies mutation but lacks operational detail.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence with no superfluous words. It is appropriately sized for the tool's simplicity and front-loads the 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 no annotations and no output schema, the description is too minimal. It does not clarify the operational effect (e.g., the key becomes usable for SSH), prerequisites (e.g., the key must exist), or how this compares to vps_keys_create. For a mutation tool with only two parameters, more context is needed to avoid misuse.
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 both parameters (vm_id and public_key_id) are already documented. The description adds no extra meaning beyond the schema, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Attach') and the resources involved ('SSH public key', 'virtual machine'), which is specific and distinguishes it from siblings like vps_keys_create (create a key) and vps_keys_list (list keys). It is not a tautology and provides clear intent.
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, prerequisites, or conditions. It merely states what it does without context on how it fits among related key management 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 must disclose side effects. It does not mention whether the VM needs to be powered off, if the change takes effect immediately, or if there are password complexity requirements. This is a mutation tool with no 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, concise sentence that is front-loaded with the essential action. No wasted words or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Although the operation is conceptually simple, the description lacks important context such as the effect on running services, whether the VM must be stopped, or any security considerations. The complete absence of behavioral guidance makes it 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?
Schema coverage is 100% and both parameters (vm_id, password) have clear descriptions. The tool description adds no extra meaning beyond what the schema already provides, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (set), the resource (root password), and the target (virtual machine). It effectively differentiates from siblings like vps_set_panel_password by specifying 'root' vs panel.
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 usage guidance is provided. There is no mention of when to use this tool versus alternatives, prerequisites, or conditions like VM state. The description simply states the action 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?
With no annotations, the description carries full responsibility for behavioral disclosure. It only says 'Setup' without explaining side effects, whether it is destructive, required permissions, or what happens to existing data on the VM. For a provisioning operation, 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, well-front-loaded sentence with no unnecessary words. It efficiently communicates the core action and target.
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?
The tool has 6 parameters, no output schema, and no annotations. The description fails to mention prerequisites (e.g., VM must be purchased), postconditions, or return values, leaving a complex setup operation underspecified. It needs more detail to be fully useful.
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 provides 100% coverage for all 6 parameters with descriptions, so the baseline is 3. The description adds a slight conceptual mapping by linking 'OS' to template_id and 'credentials' to password/public_key_ids, but it does not go beyond what the schema already states.
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 states a specific action ('Setup') on a clear resource ('purchased virtual machine') with scope ('OS and credentials'). It distinguishes from vps_purchase (buying) and vps_recreate (recreating), though not explicitly naming alternatives. The verb 'setup' is slightly generic but the context makes it clear enough.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this tool is used after a VM is purchased ('purchased virtual machine'), but it does not explicitly state when to use it, when not to use it, or mention alternative tools like vps_purchase or vps_recreate. The usage context is implied but not spelled out.
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 must carry the full burden of behavioral disclosure. It only states the action, omitting any side effects (e.g., VM must be powered off, boot time, billing implications) or what happens after execution. The agent cannot anticipate outcomes or failure modes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that directly states the purpose. It is not verbose, though it could benefit from a bit more context; however, the brevity is appropriate for a simple one-parameter action.
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 action with one parameter, the description plus schema provides the minimum needed to invoke the tool. However, it lacks context about VM state (e.g., must be stopped first) or what the expected result is, leaving some ambiguity for the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema fully documents vm_id with a description and 100% coverage, so the description does not need to add parameter details. It adds no extra meaning beyond the schema, which aligns with the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Start' and identifies the resource as 'a virtual machine', which clearly differentiates it from sibling actions like vps_stop, vps_restart, and vps_docker_start. The scope is unambiguous and matches the tool name and title.
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 vps_restart or vps_recovery_start. There are no exclusions, prerequisites, or references to other tools, leaving usage context entirely up to the agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only states the action (enable/disable) without explaining what 'AI tools' encompasses, whether the operation is reversible, what permissions are needed, or what the response or side effects might be. This is a significant gap for a state-changing 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, and front-loaded sentence with no wasted words. It effectively communicates the core action and target, 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 the simplicity of the tool, the description is still not complete. It does not explain what 'AI tools' refers to in the WordPress context, how the username and software parameters identify the target, or what the result of the operation is. With no output schema and no annotations, the agent is left without sufficient context to reliably invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents each parameter. However, the descriptions are terse (e.g., 'WordPress software identifier', 'Hosting account username') and the tool description adds no extra meaning. The baseline of 3 applies because the schema handles the documentation, though richer descriptions would improve clarity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'enable or disable' and the resource 'AI tools for WordPress', making the tool's function immediately obvious. It distinguishes itself from sibling tools like wp_ai_status (which likely queries status) and other toggles by specifying the target as AI 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?
There is no guidance on when to use this tool versus alternatives. It does not mention checking status first with wp_ai_status, nor does it indicate prerequisites or scenarios where toggling AI tools might be inappropriate. The usage context is only implied by 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only states that it creates a link, without details on whether the link expires, security implications, required permissions, or any side effects on the WordPress installation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler words. It efficiently communicates the core function 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?
The tool has no output schema, and the description does not state what the API returns (e.g., the generated login link). It also omits any mention of dependencies or constraints, leaving the agent without a full picture of the operation's result.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides descriptions for both parameters (software and username) with 100% coverage. The description adds no additional meaning beyond the schema, so it does not compensate for any ambiguity in how the parameters should be used.
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 ('Create') and the resource ('one-click WP admin login link'), using the specific 'one-click' qualifier to distinguish it from related tools like wp_jwt_token. It leaves no ambiguity about what the tool does.
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 is no mention of prerequisites (e.g., needing a WordPress installation) or how this compares to other auth-related tools like wp_jwt_token or wp_check_valid.
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, but it only says 'Show'. It does not explicitly state that the operation is read-only, describe any side effects, or clarify what happens if Memcached is unavailable or disabled.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that immediately front-loads the action and resource. There is no redundant or extraneous 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?
The tool has no output schema, so the description should clarify what 'status' entails (e.g., enabled/disabled, hit rate, memory usage). It also fails to explain the 'software' parameter or any installation context, making the description incomplete for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides 100% coverage with descriptions for both parameters (username and software). The description adds no additional meaning beyond what is already in the schema, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Show') and the resource ('Memcached object cache status'), making it distinct from sibling tools like wp_memcached_toggle (which changes state) and wp_litespeed_status (which covers a different cache).
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 is no mention of prerequisites, context, or exclusions, leaving the agent to infer the use case solely from the tool name.
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 bears full responsibility for disclosing behavioral traits, but it only states 'toggle on/off.' It omits side effects (e.g., cache flush, reversibility), permission requirements, or what happens to existing state. This is thin for a mutating operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. Every word contributes to conveying the action and target, making it highly concise and easy 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?
Despite being a simple toggle, the description lacks essential context: it does not mention return values, prerequisites (e.g., Memcached installed), or the relationship to the sibling wp_memcached_status. An agent would not know what to expect or how this fits into the workflow.
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%: both parameters have descriptions, so the baseline is 3. The tool description adds no parameter-level detail beyond the schema, so no higher score is justified.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Toggle') and a clear resource ('Memcached object cache'), making the tool's purpose unambiguous. It distinguishes this tool from related siblings such as wp_memcached_status (status check) and hosting_cache_toggle (general cache toggle).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It does not mention related tools like wp_memcached_status or clarify scenarios where toggling is appropriate, leaving the agent without decision support.
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 must carry the full burden. It only states the action 'activate' but does not disclose side effects (e.g., changing plugin state), idempotency, error behavior, or required context like authentication via username/software. This is insufficient 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 sentence, front-loaded, and contains no unnecessary words. It is concise and to the point, though it sacrifices depth for brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with 3 well-documented parameters, the description is still incomplete. It omits essential context like installation prerequisites, expected outcomes, and relationships to sibling tools. Without an output schema, the description should provide more operational context but fails to do so.
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 describes all three parameters (plugin slug, software identifier, username) with 100% coverage, so the description adds nothing beyond the schema. The baseline of 3 applies since parameters are already self-documented.
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 'Activate a WordPress plugin' uses a specific verb and resource, clearly distinguishing it from sibling tools like wp_plugins_install, wp_plugins_deactivate, and wp_plugins_update. It directly states the tool's function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers no guidance on when to use this tool versus alternatives. It does not mention prerequisites (e.g., the plugin must already be installed), nor does it reference related tools like wp_plugins_install or wp_plugins_list. There is no when/to-use or when-not-to-use 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?
The description does not add any behavioral context beyond the destructiveHint annotation. It does not explain the permanent consequences, whether plugin data is removed, or whether the operation is reversible. For a destructive tool, this is a notable gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no filler or redundancy. It efficiently conveys 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 the destructive nature and absence of an output schema, the description is insufficient. It omits details about the uninstall scope (e.g., files and database tables), side effects, expected results, and does not explain the required parameters username and software.
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 fully describes all parameters (100% coverage), so the schema carries the parameter semantics. The description adds no additional parameter context beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Uninstall' with the resource 'WordPress plugins', clearly distinguishing it from sibling tools like wp_plugins_deactivate or wp_plugins_install. It directly states the tool's primary function.
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 deactivating plugins or using list/update tools. There is no mention of prerequisites or criteria for choosing uninstall over other plugin 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 present, so the description must fully explain behavior. It only says 'Check if WooCommerce is installed' and does not disclose return format, error behavior, or confirm it is side-effect-free. This is minimal and restates the tool name/title.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler or redundant content. Every word contributes to the meaning.
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, the description is minimally adequate but lacks explicit return-value details, which matter because no output schema exists. It also gives no usage context beyond the literal check, making it acceptable but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema is empty and there are zero parameters, so there are no parameter semantics to describe. The no-parameter baseline applies, making the absence of parameter-specific documentation 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 ('Check') and the resource ('WooCommerce') with a specific status ('installed'). It is understandable and distinct in intent, though it does not explicitly differentiate itself from sibling WP check/list tools such as wp_check_valid or wp_plugins_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?
There is no guidance about when to use this tool versus alternatives, no prerequisites, and no mention of what to do if WooCommerce is not installed. The description simply states the action without contextual usage rules.
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 must carry the burden of disclosing behavioral traits. It only repeats the obvious mutation ('Enable auto-renewal') without mentioning side effects, requirements, or reversibility. It fails to inform the agent of any financial implications or state changes beyond the literal 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 clear sentence that delivers the core purpose without any filler. It is appropriately sized for the tool's simplicity and front-loads the essential action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has one parameter and no output schema, so the description is nearly sufficient. However, as a billing-affecting mutation, it lacks critical context like whether a payment method is required or whether enabling auto-renewal triggers immediate charges. The agent is left without enough information to safely anticipate consequences.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides 100% coverage with a description for subscription_id ('Subscription ID'), so the description adds no further parameter meaning. The baseline of 3 applies since the description does not contradict or extend the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Enable') and the target ('auto-renewal for a subscription'). It is concise and unambiguous, and its purpose is distinct from the sibling tool 'billing_disable_auto_renewal', even without explicit cross-referencing.
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 billing_disable_auto_renewal or billing_renew_subscription. The description omits context such as prerequisites (e.g., having a payment method) or whether the operation is reversible.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It only states the action without disclosing irreversibility, potential propagation delays, validation behavior, or partial failure handling. For a destructive operation, this is a notable transparency gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that front-loads the action and resource. Every word is meaningful, with no fluff or repetition of schema details.
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 tool with full schema coverage, the description is minimally adequate. However, it lacks important operational context such as whether deletions are immediately effective, whether they are reversible, or what happens if a record doesn't exist. Since this is a destructive action, more caveats would be expected.
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 fully describes both parameters (domain and records) and the nested record fields (type, name, value). The description adds no additional semantic value beyond what the schema already provides, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (delete), the resource (DNS records), and the scope (specific records from a domain). It distinguishes this tool from siblings like dns_update_records and dns_reset_records by emphasizing 'specific' rather than bulk or all records.
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 that this is for removing individual records as opposed to resetting all records, nor does it reference any companion functions like dns_get_records for verification.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility for disclosing behavioral traits. It merely states the action without mentioning prerequisites (e.g., domain ownership verification), side effects (e.g., immediate activation), or failure modes (e.g., behavior if a forwarding already exists). This is sparse for a 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 a single, front-loaded sentence with no filler. It efficiently conveys the core purpose without redundancy. For a simple tool, this is appropriately concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the basic purpose but omits useful context such as whether the 'type' parameter defaults to 301, whether an existing forwarding is overwritten or causes an error, and what the response format will be (given no output schema). While not terrible for a simple tool, it leaves several practical 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 input schema already provides 100% coverage with descriptions for all three parameters (domain, redirect_to, type), so the description adds no extra parameter-level meaning. The baseline of 3 is appropriate; the schema handles the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action ('Create') and resource ('domain forwarding/redirect'), which unambiguously distinguishes this tool from sibling tools like domains_update_forwarding, domains_delete_forwarding, and mail_forwarders_create. The term 'domain' clarifies that this is for web domain redirects, not email forwarders.
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 domains_update_forwarding or mail_forwarders_create. The only signal is the verb 'Create,' which implies a new forwarding, but the description does not explicitly explain the separation of concerns or any conditions that would make this tool inappropriate.
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 must fully disclose behavioral implications. 'Disable registrar lock' conveys the core action but omits critical details such as whether the lock must currently be enabled, any verification steps, reversibility, or potential impacts on domain transfers. This is insufficient 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, front-loaded sentence. It is extremely concise and contains no superfluous information. Every word contributes directly to the tool's purpose.
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 tool with one well-documented parameter and no output schema, the description provides the minimum viable information. However, it lacks any broader context about registrar locks, prerequisites, or side effects, so while it meets the baseline, it does not exceed it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage: the sole 'domain' parameter is described as 'Domain name'. The tool description adds no additional parameter meaning, so the baseline of 3 applies—the schema adequately documents the parameter.
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 'Disable registrar lock' clearly states a specific verb (disable) and resource (registrar lock), distinguishing it from the sibling tool domains_enable_lock. It is unambiguous and directly names the action performed.
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 does not mention the context in which disabling registrar lock is appropriate, nor does it reference the sibling enable tool or any other related 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?
With no annotations, the description carries the full behavioral burden. 'Get' implies a read operation, but it does not disclose return format, error behavior for invalid IDs, pagination, or whether the response is a list of domain names or full domain objects. This is a significant gap for a tool with no output schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that is front-loaded with the primary action and resource. Every word earns its place, with no redundant information or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-parameter read tool with no output schema and no annotations, the description provides the minimum needed to understand the core action. However, it lacks details about the returned data structure and the precise meaning of 'usage', making it adequate but not comprehensive.
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 fully documents whois_id with a clear description ('WHOIS profile ID'), and schema coverage is 100%. The description adds only the word 'specific', which does not meaningfully expand on the schema, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get'), the resource ('domains'), and the filtering context ('using a specific WHOIS profile'), making it distinct from sibling tools like domains_get_whois_profile or domains_get_whois_profiles. The verb+resource combination is specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to choose this tool over alternatives, nor does it state exclusions or prerequisites beyond needing a whois_id. It implies a use case but does not explicitly differentiate it from related domain tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It simply says 'Create a custom sales channel' without disclosing side effects, permissions, idempotency, or impact on other resources. This is minimal 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, front-loaded sentence with no redundancy. It conveys the essential action efficiently.
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 create tool with fully documented parameters, the description is adequate but lacks context about what a 'custom sales channel' entails, the relationship to store_id, and any post-creation behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with all properties described, so the schema provides full parameter meanings. The description adds no additional parameter context beyond what the schema already states.
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 'Create a custom sales channel' with a specific verb and resource. It distinguishes from sibling tools like ecommerce_channels_update and ecommerce_channels_list by the action 'create'.
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 is no mention of prerequisites, such as needing an existing store, or when to choose create over update or list.
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?
The destructiveHint annotation already signals that this is a destructive operation. The description adds no additional behavioral context, such as irreversibility, cascading deletes, or impact on related data (e.g., products, orders). Thus it provides no value beyond the annotation.
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, directly worded sentence with zero wasted words. It is appropriately front-loaded and concise for the tool's simple purpose.
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 simplicity of the tool (one parameter, no output schema) and the destructiveHint annotation, the description is minimally complete. However, it omits important contextual details for a destructive operation, such as whether deletion is permanent or cascades to associated resources. More guidance would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully documents the single parameter store_id with a description 'Store ID'. The description adds no additional meaning about the parameter, so the baseline of 3 applies since schema coverage is 100%.
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 'Delete an ecommerce store.' uses a specific verb+resource combination, clearly distinguishing it from sibling tools like ecommerce_stores_create, ecommerce_stores_list, and ecommerce_stores_metadata. The purpose is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidelines are provided. It does not state when to use this tool versus alternatives, nor does it mention any prerequisites, such as ensuring the store has no active products or orders before deletion. The agent gets no contextual guidance beyond the action itself.
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?
The description adds no behavioral context beyond the annotations. The destructiveHint annotation already signals danger, but the description does not clarify whether deletion is permanent, cascades to dependent objects, or requires special permissions. It simply restates the action without enriching the agent's understanding.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence with no wasted words. It is appropriately sized for a simple delete operation, achieving maximum clarity in minimal space.
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?
While the tool is simple and the schema covers parameters, the description lacks context about what happens after deletion (no output schema to describe return values) and does not mention that the username parameter identifies the hosting account. It is minimally complete but leaves room for more 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% for both parameters (name and username), so the schema fully documents the inputs. The description adds no additional parameter semantics, but the baseline of 3 is appropriate because the schema already handles parameter meaning.
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 ('Delete') and the resource ('a database'), making the tool's purpose immediately obvious. It also differentiates from sibling tools like hosting_db_create and hosting_db_list by specifying the delete operation.
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 compared to alternatives. There is no mention of prerequisites, exclusions, or scenarios where another hosting_db tool would be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, and the description provides no behavioral details beyond the action itself. It doesn't state what is returned (e.g., database names, statuses), whether pagination applies, or any permissions required. The scope 'for a hosting account' is the only added 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 sentence that is direct and free of unnecessary words. It effectively communicates the essential action and scope without 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 lack of annotations and output schema, the description is minimal. It misses clarifying the return format or how this differs from related list tools, but for a single-parameter list operation it is not severely deficient.
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 fully documents the sole parameter 'username' with its description 'Hosting account username'. The tool description adds no additional parameter semantics beyond the schema's coverage, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'List databases for a hosting account', with a specific verb 'List' and resource 'databases' scoped to a hosting account. This distinguishes it from sibling tools like hosting_db_create or hosting_db_delete, as well as other list tools for 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?
No guidance is provided on when to use this tool versus alternatives such as hosting_db_remote_list or agency_db_list. The description only gives a basic purpose, without exclusions, prerequisites, or recommended 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 must disclose behavioral traits, but it only says 'List known vulnerabilities' with no details about read-only behavior, caching, scanning process, or response format. It does not disclose whether this triggers a scan or returns cached results, nor does it mention any side effects or prerequisites.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no redundant words. It immediately states the action and resource, making it appropriately concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool, the description is minimally viable but lacks important context. There is no output schema, so the description should explain what kind of vulnerability information is returned (e.g., severity, patched status). It also does not reference related tools like the patch operation or clarify the scope of 'dependencies' beyond the required domain and username.
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 'domain' and 'username' clearly described in the schema. The tool description adds no additional parameter semantics, but the baseline of 3 applies because the schema fully documents the parameters.
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 'List known vulnerabilities in Node.js dependencies' clearly states a specific action (list) and resource (known vulnerabilities in Node.js dependencies). It distinguishes itself from the sibling tool 'hosting_nodejs_patch_vulnerabilities' by focusing on listing rather than patching.
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 the existence of 'hosting_nodejs_patch_vulnerabilities' or suggest running this before patching. No prerequisites or usage context are provided beyond the required parameters in the schema.
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?
The description states that the tool returns the full phpinfo() output, which is a clear behavioral outcome. However, since no annotations are provided, the description carries the full burden and does not elaborate on output format (e.g., raw HTML), potential side effects, or requirements beyond the parameters, resulting in a moderate transparency gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence ('Get full phpinfo() output.') that is front-loaded with the action and resource. Every word adds value, with no redundancy or unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple and the description adequately explains the output, but it lacks differentiation from the sibling hosting_php_details and provides no usage context. The absence of an output schema and annotations means the description alone is not fully complete for an agent to make an informed decision.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides descriptions for both parameters (domain: 'Website domain', username: 'Hosting account username') with 100% coverage. The description does not add any additional semantic meaning or usage details for the parameters, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
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) and the resource (full phpinfo() output), making the purpose specific. However, it does not differentiate from the sibling tool hosting_php_details, which could also provide PHP-related 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?
No guidance is provided on when to use this tool versus alternatives such as hosting_php_details or hosting_php_update_*. There is no mention of exclusions, prerequisites, or preferred scenarios, leaving the agent without usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds no behavioral context beyond the destructiveHint annotation. It does not state that deletion is permanent, irreversible, or what happens to the autoreply after deletion. The annotation already flags destructiveness, so the description contributes no additional 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 one short sentence, perfectly concise, front-loaded with the verb and resource. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter delete tool with a destructiveHint annotation, the minimal description does not cover additional context such as return value, irreversibility, or side effects. It is adequate but lacks richness that would fully inform 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% (autoreply_id is described). The description 'Delete an autoreply' does not add further meaning to the parameter; it relies entirely on the schema. Baseline of 3 is appropriate for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Delete') and resource ('an autoreply'), clearly distinguishing it from sibling tools like mail_autoreplies_create, mail_autoreplies_update, and mail_autoreplies_list. It directly states what the tool does.
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 does not mention any prerequisites, consequences, or scenarios where this tool should be preferred over other autoreply operations. The 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?
The description says only 'List API tokens for mail,' which implies a read-only operation, but no annotations are provided to confirm safety. It does not mention authentication requirements, whether token secrets are returned, pagination, or any other behavioral context. With no annotations, the description carries the full burden and fails to disclose adequate detail.
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, concise sentence ('List API tokens for mail.') that conveys the essential purpose without waste. It is appropriately sized for a zero-parameter list operation, though it is terse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with no parameters and no output schema. The description states the action and resource, but does not specify what the returned list contains (e.g., token names, IDs, or full secrets). Since there is no output schema, a bit more detail about the return value would improve completeness, but the verb 'List' partially covers this.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and an empty schema. There are no parameter semantics to explain, and the description adds no conflicting information. The baseline of 4 applies because with no parameters, nothing further 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 tool's purpose: 'List API tokens for mail.' It uses a specific verb ('List') and specifies the resource ('API tokens for mail'), which distinguishes it from sibling create/revoke token tools. However, it does not explicitly reference those alternatives, so it stops short of 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool versus alternatives or any prerequisites. However, the simple verb and resource imply that it is used to view existing mail API tokens, so usage is implied rather than 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 present, so the description must carry behavioral details. However, it only repeats the title and does not disclose output format, pagination, filtering, or any side effects. It adds no behavioral context beyond what the name already implies.
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 filler. It is appropriately terse for a simple read operation, and the essential information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple nature and full schema coverage, the description is minimally adequate. However, it lacks any indication of return values or behavior for edge cases (e.g., empty project, invalid VM). With no output schema and no annotations, a bit more context about expected results 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?
Both parameters have schema descriptions ('Virtual machine ID', 'Project name'), covering 100% of the schema. The description adds no extra meaning, but the schema already provides sufficient clarity for both parameters, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get containers of a Docker project' uses a specific verb and resource, clearly indicating a read operation for container lists. It differentiates from sibling tools like vps_docker_get and vps_docker_logs by explicitly mentioning containers within a project.
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 are many sibling docker tools (vps_docker_list, vps_docker_get, vps_docker_logs), and the description does not explain the distinction or when this tool should be preferred over them. It relies solely on the tool name.
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?
While the destructiveHint annotation already indicates this is a destructive operation, the description adds no extra behavioral context. It does not specify whether the deletion is permanent, whether associated containers or data are removed, or any other side effects beyond what the annotation already conveys.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, compact sentence ('Delete a Docker project.') that is direct and easy to parse. Every word is meaningful, and it avoids any unnecessary elaboration or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple schema and the destructiveHint annotation, the description is minimally sufficient to understand the basic action. However, it lacks details about potential side effects or prerequisites, such as whether the project must exist or whether all associated resources are removed. For a delete operation, this leaves some contextual gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides clear descriptions for both vm_id and project_name, achieving 100% schema_description_coverage. The description in the tool text adds no further semantic detail about the parameters, so it does not exceed the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'delete' and identifies the resource 'Docker project', clearly differentiating it from sibling tools like vps_docker_create, vps_docker_get, and vps_docker_stop. It is unambiguous and aligns with the tool's name and title.
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 vps_docker_stop or vps_docker_restart. It does not mention prerequisites, irreversible consequences, or any conditions that would warrant using this 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 only states the action. It does not disclose side effects, prerequisites (e.g., firewall must exist), whether rules need activation/sync, or reversibility. No contradiction but significant behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no wasted words. It is efficient but could add a bit more value without becoming verbose.
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?
No output schema or annotations. The description omits important context like the need for firewall activation/sync after adding a rule, prerequisites, and post-creation behavior. An agent might not know what to expect or what steps follow.
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 baseline is 3. The description adds no parameter-level detail beyond what the schema already provides. It does not explain parameter relationships or defaults.
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 'Add a rule to a firewall', using a specific verb and resource. It distinguishes from sibling tools like vps_firewall_create (creating a firewall) and vps_firewall_update_rule (modifying existing rules).
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 action 'Add a rule' implies when to use this tool, but it does not explicitly mention alternatives or provide exclusion criteria. No guidance is given about when to use vps_firewall_update_rule or other 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?
The description simply reiterates the action implied by the tool name and the destructiveHint annotation. It adds no additional behavioral context such as whether associated rules are removed or if deletion is reversible.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one concise sentence that is front-loaded and contains no unnecessary words. It efficiently states the tool's purpose.
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 delete operation with one well-documented parameter and a destructiveHint annotation, the description is minimally sufficient. However, it lacks mention of side effects or dependencies, leaving some room for misinterpretation.
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 provides full coverage for the single parameter 'firewall_id' with a clear description. The tool description does not add further semantics beyond the schema, which is acceptable given the high schema coverage.
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 'Delete a firewall' uses a specific verb and resource, clearly distinguishing the action from sibling tools like vps_firewall_create or vps_firewall_list. It is unambiguous in intent.
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 usage guidance is provided. There is no indication of when to use this tool versus vps_firewall_delete_rule or vps_firewall_deactivate, and no mention of 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. It only says 'Update an existing firewall rule' without explaining whether the update is a full replacement or partial modification, whether the rule is validated against existing firewall state, what happens if the rule ID does not exist, or any side effects such as reapplying the firewall. 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single clear sentence with zero waste, which is efficient and front-loaded. However, it is so minimal that it under-specifies the tool's behavior, but this is more a completeness issue than a conciseness one. The structure is adequate for such a short description.
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 (7 parameters, mutation, no annotations, no output schema), the description is highly incomplete. It does not explain the update semantics (e.g., whether all required fields must be provided, how action and direction interact, or what the response contains). This is inadequate for an AI agent to use safely and 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 seven parameters including their types and descriptions. The description adds no additional meaning beyond what is in the schema, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Update an existing firewall rule' with a specific verb ('Update') and resource ('firewall rule'), distinguishing it from sibling tools like create, delete, activate, or sync rules. It leaves no ambiguity about what the tool does.
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 that this tool is for modifying an existing rule rather than creating or deleting one, but it does not explicitly state when to use it versus alternatives. No exclusionary context or alternative tool names are mentioned, leaving the usage guidance solely to inference from the name and siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of disclosing behavior. It simply states that it gets a list, but does not mention pagination, ordering, permissions, rate limits, or any details about the returned action objects. This is minimal 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, concise sentence that front-loads the verb and object. It contains zero wasteful words and is perfectly scannable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one parameter and no output schema, but the description is somewhat vague about what constitutes an 'action' or 'operation.' It could benefit from examples or details on the return format, but for a basic list operation it is minimally adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the single parameter vm_id, and the schema already describes it as 'Virtual machine ID'. The description adds no additional meaning beyond what the schema provides, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Get list' with a clear resource ('actions/operations for a VPS'). It distinguishes the listing functionality from the sibling tool vps_get_action, which likely retrieves a single action.
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 does not mention vps_get_action or any other related tool, nor does it specify any conditions or prerequisites for use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the action ('Install Monarx malware scanner on a VPS') but fails to mention potential side effects, installation time, idempotency, costs, or whether the action is reversible. The description is too sparse to help the agent understand the operation's impact 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, highly concise sentence that immediately communicates the tool's core function. It is front-loaded with the action verb and contains no fluff or redundant 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?
The tool is simple (one required parameter, no output schema), so the description is minimally adequate. However, it lacks contextual details that could help the agent, such as what happens after installation, success/failure indications, or any prerequisite checks. Given the absence of annotations and output schema, the description is sufficient for basic understanding but leaves gaps for a complete operational picture.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers 100% of parameter descriptions, with 'vm_id' well-described as 'Virtual machine ID'. The description adds no additional semantics for the parameter, but none are needed given the schema's completeness. Baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action: installing the Monarx malware scanner on a VPS. It uses a specific verb ('Install'), names the exact resource ('VPS'), and identifies the specific software ('Monarx'), which distinguishes it from sibling tools like vps_malware_uninstall and vps_malware_metrics.
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 vps_malware_uninstall for removal or vps_malware_metrics for checking status. It does not mention prerequisites, exclusions, or conditions under which installation is appropriate, leaving the agent to infer usage solely from the name and description.
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 transparency burden. It states the action but does not disclose read-only behavior, the nature of the statistics returned, or any limitations. 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?
A single, front-loaded sentence containing no filler. It is concise and immediately communicates the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter getter, the description is minimally adequate. However, it lacks detail on what 'statistics' includes, and since there is no output schema, some indication of available data 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 input schema fully describes vm_id with 'Virtual machine ID', so schema description coverage is 100%. The tool description adds no extra parameter semantics beyond the schema, justifying a baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Get' and a clear resource 'malware scan statistics for a VPS'. It clearly distinguishes from sibling tools like vps_get_metrics (general metrics) and vps_malware_install/uninstall.
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 vps_get_metrics or vps_malware_install. It does not mention prerequisites, exclusions, or suggested contexts.
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?
The annotation destructiveHint=true already signals destructiveness, but the description adds no additional context about what gets overwritten, whether the restore is reversible, or the impact on the current VPS state. It does not disclose any behavioral traits beyond what the annotation provides, so the description carries little extra value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no filler or redundancy. It is appropriately sized for a tool with one parameter and a clear action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one parameter and an annotation for destructiveness, but the description lacks any mention of side effects, return value, or operational requirements. While minimally adequate, it could be more complete by noting that the current VPS state is replaced or that an action is triggered.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers 100% of the parameter 'vm_id' with a clear description, so the tool description does not need to add parameter details. Given the full schema coverage, a baseline score of 3 is appropriate; the description adds no semantic value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Restore a VPS from snapshot' uses a specific verb and resource, clearly indicating the action and object. It distinguishes itself from sibling tools like vps_restore_backup and vps_create_snapshot by explicitly mentioning snapshot restoration for a VPS.
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?
There is no guidance on when to use this tool versus alternatives, such as vps_restore_backup or vps_create_snapshot. It does not mention prerequisites, conditions like VPS being stopped, or any scenarios where this tool is preferred.
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 does not disclose side effects (e.g., behavior on duplicate names, whether content is validated), permission requirements, rate limits, or the return format. For a mutation tool, this is a significant transparency gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, front-loaded with the purpose, and contains no fluff. It is appropriately concise but so minimal that it borders on under-specification, though for a simple create tool it is acceptable.
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?
The tool is simple, but with no annotations and no output schema, the description should provide more context. It lacks information about the response/return value, error handling, uniqueness constraints, or any behavioral expectations. The description is under-specified for a complete tool definition.
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% coverage: 'name' is described as 'Script name' and 'content' as 'Script content (bash)'. The description adds no additional parameter semantics. With full schema coverage, the baseline is 3.
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 ('Create') and the resource ('post-install script'), which distinguishes it from sibling tools like vps_scripts_list, vps_scripts_get, vps_scripts_update, and vps_scripts_delete. The verb and resource are specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage (when you need to create a new script), but it does not explicitly state when to use this tool over alternatives or provide exclusions. There is no mention of prerequisites, uniqueness constraints, or scenarios where another tool would be more appropriate. This is implied usage rather than clear guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of explaining behavior. It does not disclose whether setting nameservers replaces the existing list, whether validation occurs, or if the VM requires a reboot. This is a mutation tool, and the lack of side-effect information leaves the agent under-informed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. It communicates the essential purpose efficiently, appropriate 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?
The tool is simple with only two parameters, and the schema covers them fully. However, the description lacks important behavioral context (e.g., whether this replaces all nameservers) and there is no output schema to clarify return values. Given the lack of annotations, this is adequate but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides full coverage for both parameters with clear descriptions ('Virtual machine ID' and 'Nameserver addresses'). The tool description adds no additional parameter-level meaning, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Set') and clearly identifies the resource ('nameservers for a virtual machine'). It distinguishes itself from sibling VPS settings tools like vps_set_hostname or vps_set_root_password by naming the exact attribute being modified.
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 given on when to use this tool versus alternatives. There is no mention of prerequisites, whether it replaces existing nameservers, or how it differs from domain-level DNS tools like domains_update_nameservers. The description simply states the action without contextual usage advice.
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 must disclose behavioral traits. It only states the action and purpose, but doesn't indicate whether it's read-only, what side effects (if any) occur, or how the token is delivered. This lack of detail leaves the agent uncertain about operational impact.
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, succinct sentence that front-loads the core action. Every word contributes value, with no 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?
This is a simple tool with two well-documented parameters, and the description states the output (JWT token) and purpose. However, without annotations or an output schema, it would benefit from clarifying whether this operation is safe and how the token is meant to be used. It's minimally adequate but lacks behavioral context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides descriptions for both parameters ('software' and 'username'), achieving 100% coverage. The tool description does not add additional information about parameter semantics, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the verb 'Get' with a specific resource ('installation JWT token') and clarifies its purpose ('for API access'). It clearly distinguishes this tool from siblings like wp_login_link or wp_check_valid by specifying the JWT token 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. It doesn't mention prerequisites, exclusions, or reference sibling tools. Users must infer usage from context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states 'Toggle maintenance mode on/off' without detailing side effects, reversibility, or impact on the site. There is no mention of what happens to visitors or whether the toggle is a safe operation.
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 short sentence that is easy to parse and front-loaded with the action. It is not verbose, but it is appropriately sized for a simple toggle operation, though it could benefit from a bit more 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?
The tool has two required parameters and no output schema or annotations. The description provides no information about expected return values, error conditions, or how to verify the toggle succeeded. For a mutation operation, this leaves significant gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides descriptions for both parameters ('WordPress software identifier' and 'Hosting account username'), covering 100% of parameters. The description adds no extra meaning beyond the schema, which is the baseline when schema coverage is high.
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 'Toggle maintenance mode on/off' clearly identifies the specific action (toggle) and resource (maintenance mode). It distinguishes from the sibling tool wp_maintenance_status, which presumably only reads the status, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for toggling maintenance mode, but it does not explicitly state when to use this tool versus alternatives, such as checking status with wp_maintenance_status. There are no exclusions or context cues beyond the action itself.
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 'change the primary domain' but does not disclose potential side effects: whether old domain becomes invalid, whether DNS records are updated automatically, whether there is downtime, or if verification is needed. For a mutating operation, this lack of behavioral context is a significant gap, though the description is not misleading.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that accurately captures the operation. It front-loads the action and resource. No wasted words, no redundant 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 the operation is a domain change, the description is minimal but the schema covers all parameters. However, there is no information about prerequisites (e.g., domain must be verified), side effects, or error conditions. The sibling tools show related operations (link/unlink domain, DNS updates), and the absence of any caveats makes it less complete for a potentially risky operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, meaning every parameter has a description. The description adds a little: it tells the purpose of the parameters (current domain and new domain) in the context of 'primary domain change.' While the schema descriptions are minimal, the combination of schema and description is sufficient. The tool's description doesn't need to add more because the parameter names and descriptions are clear.
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: 'Change the primary domain of an Agency Plan website.' It uses a specific verb (change), identifies the resource (Agency Plan website's primary domain), and distinguishes itself from related domain tools like agency_website_link_domain/unlink_domain and domains_update_nameservers. However, it could be slightly more explicit about why this differs from link/unlink domain operations.
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: you use this when you need to change the primary domain of an Agency Plan website. It doesn't explicitly state when not to use it or mention alternatives like link_domain/unlink_domain. Given the sibling context, a clear mention of alternative tools would improve guidance, but the core scenario is evident.
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 must fully disclose behavior. It only states the action without mentioning consequences (e.g., subscription will not renew), reversibility, or side effects. For a billing mutation, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one short sentence with no unnecessary words. It is front-loaded and directly conveys 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?
As a mutation tool with no annotations and no output schema, the description should provide more context about post-condition effects or return behavior. The single sentence is too sparse to be considered complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the single parameter 'subscription_id'. The description adds no extra meaning beyond the schema, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Disable') on a specific resource ('auto-renewal for a subscription'). It is unambiguous and distinct from the sibling tool 'billing_enable_auto_renewal'.
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 intended use is implied by the tool's name and description, but no explicit guidance is given about when to choose this over 'billing_enable_auto_renewal' or 'billing_renew_subscription'. The context is clear but lacks exclusionary details.
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 that the tool resets all DNS records to defaults, which implies a destructive and potentially irreversible operation, but it does not explicitly warn about data loss, mention whether the action can be undone (e.g., via snapshots), or clarify what 'defaults' means. 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 one concise sentence that communicates the action, scope, and outcome without superfluous words. It is front-loaded and directly to the point, 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 that this is a destructive tool with no annotations and no output schema, the description should provide more context. It does not explain what 'defaults' are, warn about the irreversible nature of the operation, or mention any related recovery options like dns_get_snapshots or dns_restore_snapshot. The description is too sparse for a tool that resets all records, leaving significant gaps in the agent's understanding of the operational impact.
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 only parameter, 'domain', is described in the schema with 'Domain name,' giving 100% schema description coverage. The tool description adds no additional meaning beyond the schema; it merely says 'for a domain,' which is already covered. Since schema coverage is high, the baseline of 3 applies, and the description does not add value beyond the structured data.
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 ('reset all DNS records') and the target ('for a domain'), with the outcome 'to defaults.' It is easily distinguished from sibling tools like dns_update_records, dns_delete_records, and dns_get_records, which perform different operations on DNS records.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool: when you want to reset DNS records to their default state. However, it provides no explicit guidance on when not to use it, no mention of alternatives (e.g., dns_update_records or dns_delete_records), and no prerequisites or caveats, so it only implies usage rather than offering clear 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 must disclose effects. It only states the action without explaining the consequences, such as making WHOIS data public or potential exposure of contact information. This is inadequate for a mutation that reverses a privacy feature.
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 gets straight to the point. No unnecessary words or filler, making it concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the tool is simple with one parameter, the description lacks any information about the result or side effects of disabling privacy. Given there is no output schema, the description should at least mention what happens after the operation, such as the domain's WHOIS becoming public. This is a significant gap.
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 only parameter `domain` is fully described in the schema as 'Domain name', and the description adds no further detail. With 100% schema coverage, a baseline of 3 is appropriate; the description does not enhance the schema's parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Disable' and the resource 'WHOIS privacy protection', making the tool's purpose unambiguous. It also distinguishes from the sibling tool `domains_enable_privacy` by indicating the opposite action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is used when the user wants to remove privacy protection from a domain, but it does not explicitly state when to use it or mention alternatives like `domains_enable_privacy`. Usage is only implied, not explicitly guided.
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 only states that it creates a website using Horizons, but does not mention side effects, prerequisites, return behavior, or whether the operation is asynchronous. For a creation 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, clear sentence that is front-loaded with the action and resource. It contains no unnecessary words or repetition, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one parameter and no output schema, but the description provides minimal context. It does not explain what happens after creation, what the response contains, or how to retrieve the created website (e.g., via horizons_get_website). This leaves the agent without enough information to handle the tool's outcome 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 already provides full coverage for the single parameter 'prompt' with a clear description. The tool description adds no additional parameter semantics beyond what the schema states, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb 'Create' and resource 'new website', and distinguishes this tool from other website creation tools by specifying 'using Hostinger Horizons (AI website builder)'. This clearly differentiates it from siblings like hosting_websites_create and agency_website_provision.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by mentioning 'Hostinger Horizons (AI website builder)', indicating this is for AI-generated sites. However, it does not explicitly state when to use this tool versus alternatives or provide any exclusions. The guidance is implied rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It mentions uploading files and triggering deployment but omits side effects, prerequisites (e.g., archive location), whether existing plugins are overwritten, or potential destructive impact. This is a thin description for a mutating operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with no filler. The key action and source are front-loaded, making it easy 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?
The tool is a deploy operation with no annotations or output schema, so the description should explain prerequisites, behavior, and return value. It fails to cover these, leaving significant gaps for an agent to select and invoke 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 descriptions cover all four parameters, and the description adds minimal extra meaning like 'directory/archive' and 'custom plugin'. The baseline of 3 is appropriate since schema already handles parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool deploys a custom WordPress plugin from a directory/archive, with a specific verb and resource. It distinguishes from sibling tools like hosting_deploy_wp_theme and hosting_deploy_wp_import by specifying plugin deployment.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for custom WordPress plugins but does not explicitly contrast with alternatives like wp_plugins_install or hosting_deploy_wp_import. It offers context but no clear when-not-to-use guidance.
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?
The destructiveHint annotation already signals destructive behavior, but the description adds no further context. It simply restates the title without explaining effects on mail routing or reversibility.
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 short sentence, 'Delete a catch-all.' It is concise and front-loaded with the action and object, with no unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple one-parameter schema and the destructive annotation, the description is minimally sufficient for basic invocation. However, it lacks any additional context about prerequisites or consequences, though the annotations and schema compensate somewhat.
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 fully documents the only parameter catchall_id as a string with description 'Catch-all ID'. The description adds no extra parameter details, but schema coverage is 100%, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (Delete) and the resource (a catch-all), matching the tool name and title. It distinguishes itself from sibling tools like mail_catchalls_list and mail_catchalls_create by focusing on deletion.
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 usage guidance is provided. The description does not mention when to use this tool vs alternatives, prerequisites for deletion, or any implications. An agent would need to infer that the catchall_id must be obtained from elsewhere.
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 must carry the full burden of behavioral disclosure. It only states that it sends a test event, but does not mention whether this action has side effects, requires specific permissions, or is reversible. As it triggers an external request, the agent is left unaware of potential impacts or safety considerations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one short sentence, front-loaded with the main action, and contains no redundant words. It is appropriately concise for a simple tool with a single parameter, achieving maximum efficiency.
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?
The tool has no output schema and no annotations, so the description should explain what happens when the test event is sent and what the expected outcome is. It only says 'send a test event', leaving ambiguity about the result, the nature of the event, and whether the action verifies configuration. For a low-complexity tool, this is under-specified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers 100% of the parameter (webhook_id) with a basic description 'Webhook ID'. The tool's description does not add any extra meaning beyond the schema, such as format, origin, or constraints. With full schema coverage, the baseline is 3, and the description provides no additional value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Send a test event to a webhook.' This uses a specific verb ('send') and identifies the resource (webhook) and the action's nature (test event). It distinguishes itself from sibling tools like mail_webhooks_list, mail_webhooks_create, and mail_webhooks_delivery_logs by focusing on testing, not management or retrieval.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage: it is for testing a webhook by sending a test event. However, it does not explicitly state when to use this instead of alternatives, nor does it mention any prerequisites or conditions. For example, it doesn't say 'Use this to verify a webhook configuration' or exclude cases where the webhook doesn't exist. The context is implied but not fully elaborated.
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. It only says 'Get all firewalls,' which indicates a read operation but does not disclose any behavioral traits such as pagination, return format, scoping (e.g., account-wide vs per-VPS), or potential side effects. No additional context is given.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one short sentence, 'Get all firewalls,' with no wasted words or irrelevant details. It is front-loaded and easy to parse, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no params, no output schema), the description could still provide more context, such as the return value (e.g., an array of firewall objects) or scope of the listing. Without this, an agent may not know what to expect from the response or whether 'all' means all in the account or all for a specific VPS. The description is too minimal to be fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and the schema is empty (100% coverage by default). The baseline for 0 params is 4, and the description adds nothing about parameters since there are none, which is appropriate. It does not need to explain any input semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get all firewalls' clearly states the action (get/list) and the resource (firewalls), and it distinguishes from sibling tools like vps_firewall_get (which likely retrieves a single firewall) and vps_firewall_create. It is specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage 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 does not mention that vps_firewall_get should be used for a specific firewall, or that this tool lists all firewalls without filtering. The usage is implied by the name 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 must carry the burden of behavioral disclosure. It only restates the name ('Get details') without explaining idempotency, error behavior, or clarifying that this is a safe read operation. Minimal value added beyond the tool name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. It directly states the purpose without redundancy or unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite being a simple getter, there is no output schema, and the description does not indicate what 'details' include, any prerequisites, or how it relates to sibling tools. The description is minimal and leaves notable gaps in context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers both parameters (vm_id and action_id) with descriptions, providing 100% coverage. The description adds no additional meaning or context to the parameters, so it stays at the baseline of 3.
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?
Description clearly states the action: 'Get details of a specific VPS action.' It uses a specific verb (Get) and resource (details of a specific VPS action), and distinguishes itself from the sibling tool vps_get_actions (plural), which likely lists actions.
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?
No explicit guidance on when to use this tool versus vps_get_actions or other VPS tools. The phrase 'specific VPS action' implies usage with a known action ID, but no alternatives or exclusions 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?
The description adds no behavioral context beyond the destructiveHint annotation. It does not disclose irreversibility, impact on attached servers, or any other side effects. With the annotation already signaling destruction, the description still offers no extra 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 sentence with no wasted words. It is front-loaded and appropriately sized for a simple delete operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a low-complexity tool with one parameter, a clear action, and a destructive annotation, the description plus schema is largely complete. However, it lacks details about post-delete effects (e.g., whether the key is removed from all attached VPS instances), preventing a perfect score.
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 fully describes the only parameter (public_key_id) with 100% coverage, so the description does not need to add parameter details. Baseline 3 is appropriate since the schema does the heavy lifting and the description contributes no additional parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Delete' with a clear resource 'SSH public key', which distinguishes it from sibling tools like vps_keys_list, vps_keys_create, and vps_keys_attach. It is unambiguous and concise.
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, nor does it mention prerequisites, consequences, or exclusions. It simply states the action 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 present, so the description carries the full burden of behavioral disclosure. It only states the action without covering side effects, idempotency, required permissions, or potential conflicts with existing records. This is a notable gap for a create operation, though the verb 'Create' at least implies a mutating 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, front-loaded sentence with no filler. It efficiently communicates the core purpose, though it sacrifices depth for brevity. 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?
With no annotations and no output schema, the description should explain prerequisites, side effects, and expected outcome, but it only states the purpose. It is insufficient for a mutation tool with three required parameters, leaving the agent without critical context about behavior and post-conditions.
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 fully documents all three required parameters with clear descriptions, achieving 100% coverage. The description adds no additional parameter semantics, so the baseline score of 3 is appropriate given the schema handles parameter meaning completely.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Create') and names the exact resource ('PTR (reverse DNS) record for a VPS IP'), which clearly distinguishes it from sibling tools like vps_ptr_delete and other DNS tools. This is unambiguous and directly states the tool's function.
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?
No explicit guidance on when to use this versus alternatives, but the purpose is implied by the name and description. It lacks mention of prerequisites or scenarios where other DNS tools (e.g., dns_get_records) would be more appropriate, but the intended use case is reasonably clear.
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 does not state that the operation is read-only, what the response contains, how errors are handled, or any other behavioral details. The term 'Get' implies read-only, but no specifics are disclosed.
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 short sentence, front-loaded with the verb and resource, and contains no fluff or extraneous 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?
Given there is no output schema, the description should clarify what the tool returns (e.g., script content, metadata), but it does not. This is a fairly simple tool, yet the lack of return-value information leaves significant uncertainty for the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has a single parameter (script_id) with a description 'Script ID' and 100% coverage. The description adds no additional semantic meaning beyond what the schema already provides, so the baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the concrete verb 'Get' with the specific resource 'post-install script' and qualifies it with 'specific', clearly signaling retrieval of one item by ID. This distinguishes it from sibling tools like vps_scripts_list which lists all scripts.
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 usage context is implied: you use this tool when you need a particular post-install script, likely after listing scripts to find an ID. However, there is no explicit statement of when to use it versus alternatives or any exclusions, so it does not fully guide the agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must disclose behavioral traits. It only states the basic action without detailing side effects (e.g., overwriting existing content), required permissions, or response behavior. This is a mutation tool, and such minimal disclosure 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, focused sentence with no wasted words. It is well-structured and front-loaded with the verb 'Update', making it appropriately sized for a simple update operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no annotations, no output schema, and a one-line description, the tool lacks context about prerequisites, side effects, or expected responses. The schema defines parameters but doesn't compensate for missing operational details, leaving the overall definition 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 schema covers all three parameters with brief descriptions (script_id, name, content), giving 100% coverage. The description adds no supplementary meaning beyond the schema, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Update an existing post-install script' clearly specifies the action (update) and resource (post-install script). The word 'existing' distinguishes it from creation tools like vps_scripts_create, and the verb 'update' separates it from get, list, and delete siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for an already-created script (via 'existing'), but it doesn't explicitly state when to use this tool versus alternatives like create, get, or delete. No exclusions or alternative comparison is provided, leaving guidance mostly implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden for behavioral disclosure. It only says 'Get details' with no mention of permissions, rate limits, response format, or whether the operation is read-only. The description simply restates the title without adding behavioral context beyond what is already obvious from the word 'Get.'
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with zero wasted words. It states the action and the object clearly. Every word earns its place, making it appropriately 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?
This simple tool has one parameter and no output schema, but the description provides almost no context beyond the basic action. It does not explain what kind of 'details' are returned, error conditions, or any prerequisites. Given the minimalism, the description is slightly inadequate even for a simple get tool, as it leaves the agent without expectations about the response.
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 is fully covered (100%) with a single parameter 'template_id' described as 'Template ID.' The description adds nothing beyond the schema, but the schema itself is self-explanatory. Baseline of 3 is appropriate because the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the resource 'details of a specific OS template.' It distinguishes itself from the sibling tool vps_templates_list (which presumably lists all templates) by specifying 'specific' and 'details.' This leaves no ambiguity about what the tool does.
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 usage context is implied by the name and description: use this to get one template, while vps_templates_list would list all. However, no explicit when-to-use or alternatives are mentioned. The description does not state that it should be used when a template_id is known or that it should be used instead of listing all templates.
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 burden. The verb 'show' implies a read-only operation, which is a useful hint, but no details are given about response format, error conditions, or side effects. It does not contradict any annotations but adds minimal behavioral context beyond the basic action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no unnecessary words. It is front-loaded with the action and resource, making it highly scannable for an agent.
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?
The tool has no output schema and no annotations, so the description should provide some context about the return value or expected output (e.g., whether status is on/off). The current description only says 'show status' without detailing what the status result looks like, which is a significant gap for an agent deciding whether the output meets its needs.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already covers both parameters with descriptions (WordPress software identifier, Hosting account username), so the schema provides 100% coverage. The tool description adds no additional meaning to the parameters, leaving the baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'show' and identifies the resource 'AI tools option status for WordPress'. It clearly distinguishes from sibling tools like wp_ai_toggle (which toggles) and other status tools for different features (litespeed, memcached, maintenance).
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, no prerequisites, and no context about when it should be called. It simply states what it does without any exclusions or situational advice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. 'Show' implies a read-only operation, but it does not explicitly state that no modifications occur, nor does it mention potential error conditions, authentication requirements, or the exact return format.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that directly states the tool's purpose without any redundant wording. It is appropriately sized for the simplicity of the operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only getter, the description is mostly sufficient: it indicates the return value (WordPress core version) and the schema covers parameters. However, it lacks any context about when to use it or how it relates to WordPress installation status, which could affect correct selection.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides full descriptions for both parameters (username and software), so the description adds no additional semantic value. The high schema coverage (100%) justifies the baseline score.
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 'Show WordPress core version' clearly indicates the action ('show') and the resource ('WordPress core version'), making its purpose unambiguous. It is distinct from sibling tools like wp_installations_list or wp_check_valid, which have different focuses.
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 for when to use this tool versus alternatives. The description does not mention prerequisites, such as whether the WordPress installation must be detected or managed, or scenarios where this tool would be inappropriate.
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 only states the action without disclosing behavioral details such as read-only status, return format, or prerequisites (e.g., whether the order must be active). The term 'list' implies a safe read, but the description does not add explicit 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, front-loaded sentence that efficiently conveys the purpose without wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter list tool with no output schema, the description is adequate but lacks details about the return structure or specific behavior (e.g., whether all datacenters are returned regardless of availability for the order). It could be more complete by clarifying these points.
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 provides 100% description coverage for the single parameter order_id ('Agency order ID'), so the baseline is 3. The description adds context by linking the datacenter list to an agency order, but does not add further parameter-level detail beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'List' with the resource 'datacenters' and scopes it to 'Agency Plan order', clearly distinguishing it from sibling tools like vps_datacenters_list and hosting_datacenters_list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for agency plan orders but does not explicitly state when to choose this over the similar datacenter listers or provide conditions/exclusions. No alternative tools 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?
While the destructiveHint annotation is present, the description adds no additional behavioral context beyond what the annotation already provides. It does not mention potential side effects (e.g., website accessibility, DNS effects, irreversibility), which would be useful for a destructive operation. The description neither contradicts the annotation nor enriches it.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that perfectly captures the tool's purpose without any fluff or redundancy. Every word earns its place, and the structure is ideal for a simple operation.
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 tool with two fully documented parameters and a destructiveHint annotation, the description is minimally adequate. However, it lacks any mention of return values, side effects, or prerequisites, and there is no output schema to fill that gap. The description could be slightly more informative, especially given the destructive nature, but it is not 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?
Schema description coverage is 100% with both parameters ('Domain to unlink' and 'Website UID') already described in the input schema. The description itself adds no extra meaning beyond the schema, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Unlink a domain from an Agency Plan website' clearly states the action (unlink) and the resource (a domain from an Agency Plan website). It effectively distinguishes this tool from siblings like agency_website_link_domain and agency_website_change_domain by specifying the exact operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the use case (removing a domain from a website) but does not explicitly state when to use this tool versus alternatives like link_domain or change_domain. There are no explicit exclusions or alternative references, so the usage guidance is only implied by the tool's purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states the action but does not explicitly disclose whether it is read-only, the response format, or any side effects. The verb 'List' weakly implies a read operation, but this is not stated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that states the core purpose with no filler. It is front-loaded and efficiently communicates the tool's function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one parameter and no output schema, but the description lacks information about the return format (e.g., array of version strings) and how it relates to version-changing tools like agency_wp_change_version. It also does not explicitly differentiate from wp_list_updates, leaving some ambiguity in context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 100% coverage for the single parameter (website_uid). The description adds context by implying the UID must belong to an Agency Plan website, which helps interpret the parameter's meaning beyond the schema's generic 'Website UID'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and resource ('available WordPress versions') with a scope qualifier ('for an Agency Plan website'). This clearly distinguishes it from siblings like wp_get_version (current version) and wp_list_updates (available updates).
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 agency_wp_change_version or wp_list_updates. The phrase 'for an Agency Plan website' indicates audience rather than usage conditions, leaving the agent without clear selection criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds no behavioral detail beyond what the destructiveHint annotation already conveys. It does not mention potential downtime, irreversibility, or any effects on the VPS instances beyond 'restart'. Since annotations already flag destructive behavior, the description contributes little extra 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 short sentence with no wasted words. It effectively communicates the core function without redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with a single parameter and no output schema, but the description omits usage guidance and any behavioral caveats. It is adequate for a straightforward operation, but leaves the agent to rely on the sibling list and annotations for context. Missing explicit when-to-use guidance (e.g., vs vps_restart) prevents a higher score.
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 fully describes the vm_ids parameter with a clear description ('Array of virtual machine IDs to restart'). The tool description does not add any additional parameter semantics, so the schema carries the explanatory burden. Baseline score of 3 is appropriate given 100% schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'restart' and the resource 'VPS instances', and specifies the batch nature ('multiple ... at once'), which distinguishes it from the single VPS restart sibling tool (vps_restart). It is specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use for restarting multiple VPS instances at once, but it does not explicitly state when to prefer this over vps_restart or mention any alternatives. The context is inferable from the word 'batch' and 'multiple', but there is no explicit guidance or exclusion.
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 only says 'List all active subscriptions' – a read-only operation – but does not describe pagination, sorting, what constitutes 'active', or whether the result is a full list or paginated. This lack of behavioral detail is a gap for a list tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, front-loaded with the verb and resource. It wastes no words and is easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (no params), but with no output schema, the description should clarify the return format or behavior. It also doesn't mention that there is a paginated sibling, which could be relevant. For a list operation, this is adequate but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so there are no parameter semantics to clarify. Per the baseline for 0 params, the score is 4; the description correctly implies no inputs are needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states exactly what it does: 'List all active subscriptions.' The verb 'list' and resource 'active subscriptions' make the purpose clear and specific. It distinguishes from sibling tools like billing_get_catalog and list_all_subscriptions_paginated by the 'active' filter.
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. Sibling tools such as billing_get_catalog and list_all_subscriptions_paginated could be confused, but the description gives no comparison or exclusion criteria, leaving the agent without 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?
No annotations are provided, so the description carries the full burden of disclosing behavioral details. It only states the action ('Set a payment method as the default') without revealing any side effects, requirements, reversibility, or error behavior. For a mutation tool with no annotation coverage, this is a significant gap—it does not tell the agent what happens after the operation or any special conditions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence: 'Set a payment method as the default.' Every word is necessary and there is no fluff. It is appropriately concise for such 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?
The tool is simple with one parameter and no output schema, but the description still lacks useful context: what it means to be the 'default' (e.g., for renewals or purchases), any prerequisites, or what the return value/response will be. While the core function is clear, the missing context could lead to an agent using it without understanding the broader billing implications.
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% (payment_method_id is described as 'Payment method ID'). The description adds no extra parameter semantics beyond what the schema already provides. Since the schema covers the only parameter, the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Set') and clearly indicates the resource ('a payment method') and the resulting state ('as the default'). This clearly differentiates it from sibling billing tools like billing_delete_payment_method, billing_get_payment_methods, and billing_enable_auto_renewal, which focus on different operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage: when you want to set a payment method as the default, use this tool. However, it does not provide explicit guidance on prerequisites (e.g., that the payment method must already exist), nor does it compare with alternatives. The usage is clear from the tool's name and direct statement, but no explicit when-to-use or exclusions are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, but it only restates the tool's name and doesn't disclose behavioral traits like whether it performs a live lookup, rate limits, or that it doesn't actually purchase/reserve the domain. This is a minimal disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The one-sentence description is appropriately sized for a simple single-parameter tool and is front-loaded with the essential action. Every word adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is sufficient for basic selection but lacks mention of return format or edge cases (e.g., invalid domains). Given no output schema, this leaves the agent to infer the response type.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides 100% coverage, describing the 'domain' parameter with an example ('example.com'). The description adds no additional parameter semantics, so it stays at the schema-based baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool checks domain availability for registration, using a specific verb and resource. It distinguishes from sibling domains tools like domains_purchase or domains_get_details.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool's use for checking availability but does not explicitly state when to use it versus alternatives like domains_purchase, nor does it provide exclusions or context such as whether it reserves the domain.
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 action but does not disclose consequences, reversibility, prerequisites, or potential impact on WHOIS records. This leaves the agent without critical 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 sentence with no redundant information. It is front-loaded and efficient, earning a high score for 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 simple one-parameter tool, the description minimally states the action. However, it lacks mention of eligibility, reversibility (sibling domains_disable_privacy), or any side effects, making it barely adequate.
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 only parameter 'domain' is described in the schema as 'Domain name' (100% coverage). The tool description adds no additional meaning beyond the schema, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Enable WHOIS privacy protection' uses a specific verb (Enable) and specific resource (WHOIS privacy protection), clearly distinguishing it from sibling tools like domains_disable_privacy and domains_enable_lock.
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 provides no explicit guidance on when to use this tool versus alternatives. It does not mention the reversible sibling domains_disable_privacy or any prerequisites, so usage context is only implied by the name.
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 only states that the tool retrieves an auth/EPP code, but does not disclose whether the operation is read-only, whether the domain must be unlocked, whether any notification is sent, or other potential side effects. This is a significant transparency gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. It efficiently conveys the action, resource, and purpose, making it appropriately concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one fully documented parameter, but the description does not explain the return format or any conditions/preconditions (e.g., domain lock status). Given no output schema and no annotations, the description is adequate for a basic getter but leaves some gaps around expected response and prerequisites.
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 fully documents the single 'domain' parameter with a clear description ('Domain name'), so the description adds no additional parameter-specific meaning. Baseline 3 applies because schema coverage is 100%.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function with a specific verb ('Get') and resource ('domain authorization/EPP code'), and adds context for its intended use ('for transfers'). This distinguishes it from sibling tools like domains_get_details or domains_get_transfers.
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 phrase 'for transfers' implies the usage context, but there is no explicit guidance on when to use this tool versus alternatives such as domains_get_transfers or domains_get_transfer. No exclusions or prerequisites 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 the full transparency burden. It indicates a read-only list operation implicitly, but does not disclose any behavioral traits such as what statuses are included, whether the list is paginated, or any scope limitations. It adds no information beyond the tool name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the action and resource. Every word is necessary, with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with no parameters, this is minimally adequate but leaves gaps. Without an output schema, the agent doesn't know the return format or fields. It also doesn't clarify whether 'all' means all per account or includes historical transfers, but the simplicity somewhat compensates.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters and 100% schema coverage. The baseline for 0 parameters is 4, and the description correctly does not attempt to explain parameters that don't exist.
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 'List all domain transfers' uses a specific verb (list) and resource (domain transfers). The word 'all' distinguishes it from the sibling tool domains_get_transfer (singular), clarifying that this is the plural, list-all variant.
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 gives no explicit guidance on when to use this tool versus the singular domains_get_transfer or other domain-related tools. The plural vs singular naming implies the difference, but no explicit alternatives or exclusions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It implies a read operation but does not disclose what 'active' means, whether permissions are required, how results are returned, or any edge cases. This is insufficient for a 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, front-loaded sentence with no wasted words. It is appropriately sized for the tool's simplicity and communicates the essential purpose immediately.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with no parameters and no output schema, so the description is borderline adequate. However, it omits details such as what constitutes a 'verification request', what 'active' means, or expected response format, making it incomplete for an agent navigating the extensive sibling toolset.
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 accepts zero parameters, so the input schema is trivially 100% covered. The description does not need to explain parameter semantics, and no additional clarification is required. Baseline of 4 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and resource ('active domain verification requests'), clearly distinguishing it from sibling tools like domains_get_forwarding or domains_get_whois_profiles. It also adds the 'active' qualifier, making the scope explicit.
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 is a bare statement with no context about prerequisites, typical scenarios, or exclusions, leaving the agent to infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose any behavioral details beyond the action itself, such as return format, pagination, permissions, or error conditions. The verb 'List' implies read-only, but this is not explicitly stated.
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, succinct sentence without any fluff. It is front-loaded with the action and clearly states the scope, making it efficiently 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?
The description is minimal and adequate for a simple list operation, but it lacks any mention of the response format, potential filters, or other caveats. With no output schema or annotations, more context would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 100% coverage for store_id (described as 'Store ID'), and the tool description adds no additional meaning beyond that. This matches the baseline for high schema coverage; the description does not compensate with extra parameter insights.
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) and resource (sales channels) with the scope 'for a store', which distinguishes it from sibling tools like ecommerce_channels_create/update and ecommerce_stores_list. The verb is specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no explicit guidance on when to use this tool over alternatives, nor any exclusions. The phrase 'for a store' implies the need for a store_id, which is also evident from the schema, but no context about use cases or alternative tools is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of disclosing behavioral traits. It only states 'Get all ecommerce stores' but does not mention return format, pagination, required permissions, or whether 'all' includes archived or inaccessible stores. This is minimal and leaves the agent guessing about important behavioral characteristics.
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 is front-loaded with the action and resource. For a simple tool with no parameters, this level of conciseness is well-optimized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is low-complexity (no parameters, no output schema), and the description adequately states the primary purpose. However, without any detail about the return structure, result size, or potential errors, the description is only minimally viable. The lack of annotations and output schema increases the need for description to provide completeness, which it does not fully deliver.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so there is nothing to explain. The description does not need to add parameter meaning, and the schema confirms no parameters exist. A baseline of 4 is appropriate for a parameterless 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 'Get all ecommerce stores' uses a specific verb ('Get') and resource ('ecommerce stores'), clearly distinguishing it from sibling tools like ecommerce_stores_create, ecommerce_stores_delete, and ecommerce_stores_metadata. The scope ('all') adds 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?
No guidance is provided on when to use this tool versus alternatives such as ecommerce_stores_metadata, which could also retrieve store-related information. The description lacks explicit context for selection, merely stating a basic action without contrasting with other list or read tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must fully disclose behavioral traits. It merely says 'List autoreplies' which implies a read operation, but it does not state that no modifications are made, what the return format is, or whether filters apply. This lack of disclosure is a significant gap given the absence of annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that effectively communicates the essential purpose. It is front-loaded with the verb and resource, and every word contributes meaning.
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 documented parameter, the description is minimally adequate. However, with no output schema, the description does not mention what is returned (e.g., an array of autoreplies) or any additional context such as filtering, which would enhance completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one parameter (order_id) with a complete description 'Mail order ID', giving 100% schema coverage. The tool description adds no extra parameter meaning beyond this, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (List), the resource (autoreplies), and the scope (for an order). It distinguishes this from sibling tools like mail_autoreplies_create, update, and delete, as well as other mail list tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is used to retrieve autoreplies for a specific order, but it does not explicitly mention when to use this over alternatives or provide any exclusions. There are no prerequisites stated beyond having an order_id, which is 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 must disclose behavioral details. It only states 'Update whether forwarder keeps a copy' without clarifying that the boolean parameter sets the value, whether the forwarder must already exist, what side effects occur (e.g., affecting future forwarded emails), or whether the change is reversible. As a mutation tool with zero annotation coverage, this is a significant transparency gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence of seven words, immediately front-loading the action and resource. Every word earns its place with no redundancy or filler. It is optimally concise for the simplicity of the operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (2 params, boolean update) and the description covers the core behavior, but it lacks any context about prerequisites (e.g., forwarder must exist), relationship to other forwarder settings, or what the response indicates. Given no output schema and no annotations, the description leaves some gaps but is minimally adequate for a trivial setter operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%: both parameters have descriptions ('Keep copy in original mailbox' and 'Forwarder ID'). The description adds no additional meaning beyond restating the purpose, so the baseline of 3 is appropriate. The schema fully documents the parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Update') and resource ('forwarder keeps a copy'), clearly distinguishing it from sibling tools like mail_forwarders_list, mail_forwarders_create, and mail_forwarders_delete. It exactly matches the tool's name and title, leaving no ambiguity about the action performed.
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 (update keep-copy setting for a forwarder) but provides no explicit guidance on when to use it versus alternatives or any prerequisites/exclusions. There is no mention of when not to use it, such as needing to create the forwarder first. The context is inferable from the name 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 present, so the description carries the full burden of behavioral disclosure. It only states 'Get', which implies read-only access, but it does not explicitly confirm the absence of side effects, describe the response format, or note any operational constraints. For a simple list operation, this is minimal but lacks useful 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, concise sentence that directly states the tool's function with no redundancy or filler. It is appropriately sized and front-loaded, earning the highest rating for 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?
While the tool is simple (no parameters, no annotations, no output schema), the description is skeletal. It lacks context such as the purpose of listing data centers (e.g., for VPS provisioning) or differentiation from sibling data center tools. However, it does convey the basic action clearly, making it minimally viable but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the input schema is empty. The description does not need to explain parameter semantics, and per the baseline rule for no parameters, a score of 4 is appropriate since there is nothing to compensate for.
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 'Get available VPS data centers' clearly states the action (Get) and the resource (available VPS data centers). The 'VPS' qualifier distinguishes it from sibling tools like hosting_datacenters_list and agency_datacenters, making its purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage 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 any contextual triggers, prerequisites, or exclusions, leaving the agent without explicit usage direction beyond the resource name itself.
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 responsibility for disclosing behavior. It only states that a new project is created, but does not disclose whether it overwrites existing projects, what happens if the project name already exists, whether it validates the compose content, or what response to expect. This is a significant gap for a create operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no filler or redundancy. It is front-loaded and communicates the core purpose immediately, earning a 5.
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 straightforward nature and well-documented parameters, the description is minimally sufficient. However, the absence of behavioral details (e.g., return value, failure modes) and no output schema means it is not fully complete for an agent to predict outcomes. It does neither exceed nor fall far short of expectations for a simple create 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 each parameter (vm_id, project_name, compose_content) having a clear description. The tool description adds no extra parameter meaning beyond what the schema already provides, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Create a new Docker Compose project' uses a specific verb ('create') and resource ('Docker Compose project'), clearly distinguishing it from sibling operations like vps_docker_update, vps_docker_delete, or vps_docker_start. It precisely states what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for creating a new project, but does not explicitly state when to use it versus alternatives like vps_docker_update, nor does it mention prerequisites (e.g., VM must exist) or exclusions. The purpose is clear enough that an agent can infer when to use it, but no explicit guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of indicating side effects. 'Get details' clearly implies a read-only operation, but the description does not explicitly state that no changes are made or provide any additional behavioral context such as error handling or rate limits. It is minimally sufficient for a simple read.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler or redundant phrasing. It efficiently communicates the tool's essence.
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 single-parameter read tool, the description is adequate for selecting it. However, with no output schema, it does not specify what 'details' are returned (e.g., IP, status, specs) or how missing/nonexistent VM IDs are handled. This leaves some ambiguity, but the low complexity 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 for the single parameter (vm_id, 'Virtual machine ID'), so the description does not need to compensate. The description adds no extra meaning beyond the schema, aligning with the baseline score for high schema coverage.
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 target resource ('details of a specific virtual machine'). It distinguishes itself from sibling tools like vps_list, which lists all VMs, and vps_docker_get, which targets Docker containers.
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?
There is no guidance on when to use this tool versus alternatives. It does not mention that vps_list should be used for enumerating VMs or that this tool returns full details for a single VM, nor does it note any 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 should disclose behavioral traits such as read-only nature, permissions, or pagination. It only says 'List backups,' which hints at read-only but omits any safety or side-effect details. The lack of explicit non-destructive labeling or additional behavioral context lowers the score.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that conveys the core action with no extraneous words. It is perfectly sized for a simple list operation.
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 one-parameter list tool with no output schema, the description is adequate but minimal. It doesn't specify the return format, pagination, or any constraints, though the simplicity of the operation makes this gap less critical. A slightly richer description would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the vm_id parameter is described as 'Virtual machine ID' in the schema. The description does not add any extra meaning to the parameter, but the baseline of 3 applies because the schema already fully documents it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('List') and resource ('backups for a virtual machine'), clearly distinguishing it from sibling tools like vps_restore_backup or vps_create_snapshot. The purpose is immediately unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use when backups need to be listed, but it does not explicitly contrast with related tools such as vps_get_snapshot or vps_restore_backup. No when-not-to-use guidance or alternative tool mentions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It lists metric categories but omits details such as sampling period, units, return format, or behavior when the VPS is offline, which are important for a metrics tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, front-loaded with the action and scope, with no unnecessary words.
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?
This is a simple tool with one well-described parameter, but there is no output schema or annotations. The description lists metric types but does not explain return format, units, or prerequisites, leaving some ambiguity for the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully describes the single parameter (vm_id with 'Virtual machine ID') at 100% coverage, so the description adds no extra parameter meaning. The baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the resource 'performance metrics' with specific scope '(CPU, RAM, disk, network)', which distinguishes it from sibling tools like vps_get and vps_malware_metrics.
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?
No explicit guidance on when to use this tool versus alternatives, and no alternatives are mentioned. The description implies its usage context (retrieving performance metrics) but does not provide clear selection criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states the operation is a 'get' (read) and lists 'all virtual machines,' but does not clarify behaviors such as whether results are paginated, whether deleted VPSs are included, or whether any account-level scope applies. This lacks the transparency expected for a tool with zero annotation support.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that is easy to parse. It avoids redundancy and includes no extraneous information. For a tool with no parameters and simple behavior, this is appropriately sized 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 low complexity (no params, no output schema, no annotations), the description covers the basic purpose but omits any additional context that would help the agent understand what to expect as a return value or any special behavior. It lacks details like whether the list is paginated or if any filtering is possible, which could be relevant for a list operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline is 4. The description correctly implies no inputs are required, and the schema confirms this with an empty object. No additional parameter semantics are needed because there are no parameters to clarify.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Get list of all virtual machines.' It uses a specific verb ('Get') and resource ('all virtual machines'), which unambiguously indicates the scope (listing all VPS resources). It distinguishes itself from sibling tools like vps_get (which retrieves a single VPS) and vps_purchase (which creates a new 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. There is no mention of scenarios (e.g., 'use this to retrieve all VPSs at once') or exclusions (e.g., 'for a specific VPS, use vps_get'). The context of being a list tool is implicit, but no explicit usage advice is given.
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 must disclose behavioral traits. It only restates the removal action without mentioning side effects, reversibility, or requirements. It does not warn that this is a destructive operation or whether the VPS needs to be stopped.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One concise sentence with no wasted words. It is direct and front-loaded, clearly stating the action and target.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter removal tool, this description is minimal but adequate. It lacks behavioral context (e.g., whether the VPS must be offline, whether the action is irreversible) and no output schema exists, so an agent may not know what to expect.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter vm_id is fully documented in the schema (type, description, required). The description adds no further parameter meaning, but baseline holds at 3 due to 100% schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb ('Remove') and a specific resource ('Monarx malware scanner from a VPS'). This distinguishes it from sibling tools like vps_malware_install and vps_malware_metrics.
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 purpose implies usage for uninstalling the scanner, but no explicit when-to-use or alternative guidance is given. It does not state prerequisites (e.g., VM must exist) or contrast with install/metrics beyond the obvious opposite.
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 responsibility. It does not disclose whether the operation is destructive, requires a stopped VM, or what 'default' means. For a mutation tool, this lack of behavioral context 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, direct sentence with no wasted words. It is front-loaded and immediately communicates the purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool, the description gives the core action, but it lacks behavioral context such as side effects, requirements, or reversibility. The absence of annotations and output schema means it should provide more detail to be fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema describes vm_id as 'Virtual machine ID' with 100% coverage. The description adds no additional meaning, but the schema is sufficient. Baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (reset), the resource (hostname), and the result (to default). This distinguishes it from sibling vps_set_hostname, which sets a custom hostname.
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 phrase 'to default' implies it should be used when reverting to a provider-assigned hostname rather than setting a custom one. However, there is no explicit guidance on when to use this tool versus alternatives, nor any mention of 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 simply states 'Get all' with no mention of side effects, return structure, pagination, or permissions. The read-only nature is only implicit in the verb 'Get'.
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, brief sentence with no unnecessary words. It is front-loaded with the action and resource. However, it is so terse that it may sacrifice clarity for brevity, though it remains appropriately sized for a simple list operation.
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 an output schema and annotations, the description should explain what the returned list contains or any additional context (e.g., whether it returns IDs and names). It does not, leaving the agent uncertain about the response format. For a list tool with zero params, this is a notable gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline is 4. The description's use of 'all' implies no filtering/parameters are needed, which aligns with the empty schema. It adds no additional parameter-specific details, but none are required.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Get' and resource 'all post-install scripts', clearly stating the tool's function. The title 'List Post-Install Scripts' reinforces the purpose. It distinguishes itself from sibling tools like vps_scripts_get and vps_scripts_create, which perform different operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving a list of all post-install scripts, but provides no explicit guidance on when to use it versus alternatives such as vps_scripts_get for a specific script or vps_scripts_create. No exclusions or conditional context are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility for disclosing behavioral traits. It only states that the tool sets a password, without mentioning effects on running VPS, required permissions, whether the password change is immediate, or any potential service impact. This lack of detail makes it hard to anticipate consequences for a write operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no redundant words. It is front-loaded with the action and includes examples in parentheses, making it highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with only two params and full schema coverage, so the description is arguably sufficient for basic understanding. However, the absence of annotations and output schema means the description should ideally clarify what happens on success (e.g., returns confirmation, restarts panel) or any prerequisites. It is adequate but leaves a gap in operational expectations.
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 baseline is 3. The description does not add additional semantics beyond the schema; it just reaffirms that 'password' is the new panel password. No extra value or context is provided for the parameters.
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: 'Set panel password for a VPS' with specific examples (cPanel/Plesk). It uses a specific verb+resource and distinguishes from the related sibling tool vps_set_root_password by focusing on the panel password.
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 usage is implied: this tool is for setting the panel password on a VPS. However, it does not explicitly mention when to use it over alternatives like vps_set_root_password or provide exclusion criteria. The context is clear but lacks guidance on 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?
The destructiveHint annotation already informs the agent that this is a destructive operation. The description adds no further behavioral context—it merely restates the title without mentioning consequences, irreversibility, or what specifically gets deleted (files, database, etc.).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no redundant information. It is front-loaded and efficiently conveys the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple nature of the tool (two clear params, destructive annotation, no output schema), the description is minimally adequate. However, it lacks guidance on how to identify the correct installation (e.g., by using wp_installations_list) and does not explain the extent of the deletion, leaving some gaps for the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Both parameters are fully described in the input schema: 'software' is a WordPress software identifier and 'username' is a hosting account username. Schema coverage is 100%, so the description adds no additional parameter meaning, but none is required.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the specific verb 'Delete' and the exact resource 'WordPress installation', clearly distinguishing it from sibling delete tools for other resources like DNS or VPS. The title reinforces this, leaving no ambiguity about the tool's function.
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 usage context is implied by the tool name and description: it is used to remove a WordPress installation. However, there is no explicit guidance on when to use this tool versus alternatives, nor are any prerequisites (e.g., listing installations first) or exclusions 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, the description carries the full burden of behavioral disclosure, but it only restates the purpose. It does not mention whether records are overwritten or merged, partial failure behavior, or the potentially destructive impact of overwrite=true, leaving significant gaps for a batch 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 two short, front-loaded sentences with no redundancy or filler. Every word contributes to conveying the tool's purpose and primary use case.
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 batch DNS mutation with an optional overwrite flag, no output schema, and no annotations, the description lacks crucial context about overwrite semantics, error handling, or atomicity. It is too minimal to fully prepare an agent for safe invocation, especially given destructive sibling tools like dns_reset_records.
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% coverage with descriptions for all parameters, so the baseline is 3. The description's 'same records across many domains' aligns with the schema's 'Records to apply to all domains' but adds no new parameter-level detail beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool updates DNS records for multiple domains at once, specifying a concrete action and resource. It distinguishes itself from single-domain DNS update tools like dns_update_records by emphasizing the batch scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description notes it is 'useful for applying the same records across many domains,' which gives clear context for when to use it. However, it does not explicitly name alternatives or state when not to use it, such as pointing to dns_update_records for single-domain updates.
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 only says 'List all configured payment methods' without disclosing whether authentication is required, the return format, pagination, or any rate limits. The term 'List' implies non-mutating, but the description adds little 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, front-loaded sentence: 'List all configured payment methods.' Every word earns its place, with no fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with no parameters, but the description is too terse given that no output schema or annotations are provided. It does not explain what a payment method entry contains (e.g., id, brand, last4) or that it returns an array, leaving the agent without enough context to parse the response effectively.
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?
Input schema has zero parameters, so there are no parameter semantics to describe. The description's 'all configured' clarifies the scope (no filtering), which aligns with the empty parameter set. Per rubric, baseline for 0 params is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'List' and a clear resource 'configured payment methods'. It distinguishes itself from sibling tools like billing_set_default_payment_method and billing_delete_payment_method, which are mutation operations, and billing_get_catalog, which deals with products/services.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when one needs to retrieve payment methods, but provides no explicit when-to-use or alternatives. It is a simple read operation, so the context is clear, but no exclusions or comparisons to sibling billing tools are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the effect (transfer protection) but omits details like reversibility, immediate effect, or prerequisites. This is minimal but not absent, providing the core behavioral consequence.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence with no filler. It front-loads the verb and resource, and every word contributes meaning, 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.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter toggle tool, the description adequately conveys the core action and effect. While it lacks usage conditions and explicit reversal cues, the simplicity of the tool means the description is reasonably complete for invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with the 'domain' parameter described as 'Domain name'. The description adds no additional meaning beyond the schema, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Enable') and the resource ('registrar lock'), with a clarifying parenthetical ('transfer protection') that explica la functional effect. It fully distinguishes from sibling tools like domains_disable_lock and privacy toggles.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. It does not mention that domains_disable_lock reverses the operation or any prerequisites, leaving the agent to infer usage from context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It indicates a read operation but discloses no additional behavior such as pagination, scope details, or return format. It is a minimal but safe description; could be improved by noting that it is non-destructive and returns domain details.
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, front-loaded sentence with no redundant words. It is concise, though slightly under-specified; adding a few more details would not hurt, but it does not contain unnecessary content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a simple, parameterless list tool, but the description lacks information about the return structure or potential pagination limits. Given no output schema exists, the description should at least mention the response format or domain properties returned. The presence of a paginated sibling suggests possible limitations not addressed here.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema is empty with 100% coverage. There is nothing to describe, so the baseline of 4 applies. The description appropriately omits parameter details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'List' and the resource 'all domains in your portfolio,' making the purpose unambiguous. It distinguishes from related tools like agency_domains_list by specifying user-owned domains, though it doesn't explicitly mention the paginated sibling.
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 list_all_domains_paginated or agency_domains_list. The description implies usage via the 'List all' wording, but there is no explicit context or exclusion.
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. The description only states 'Create a physical product', which implies a write operation but provides no information about prerequisites, consequences, or response format. This is a significant gap for a creation 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 that is appropriately concise for a simple create operation. It is front-loaded with the verb and resource, and contains no filler or unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no annotations or output schema, the description should compensate by explaining the full context of the operation. It fails to mention what happens on success, whether the store must already exist, any potential errors, or how this differs from digital product creation. The schema provides field names but not behavioral 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%, with each parameter having a basic description in the schema. The tool description adds no additional parameter semantics beyond the schema. The baseline score of 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'create' and resource 'physical product' with context 'in a store', distinguishing it from the sibling ecommerce_products_create_digital. This makes the tool's purpose unambiguous and clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly indicates this tool is for physical products in a store, providing clear context. However, it does not explicitly mention alternatives or when not to use it (e.g., for digital products), though the sibling name implies the distinction.
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?
The description is consistent with the destructiveHint annotation but adds no extra behavioral context such as permanence, side effects on mail delivery, or whether confirmation is required. The annotation already flags destructive intent, so the minimal disclosure is acceptable but not enriched.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no filler or repetition. It is optimally concise and front-loaded with the action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple delete tool with one well-documented parameter and a destructive annotation, the description is reasonably complete. It lacks output/effect details, but the low complexity and existing schema/annotation cover most needs.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the single parameter alias_id, and the description adds no additional meaning beyond 'Alias ID' already in the schema. Baseline score is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Delete' and a clear resource 'email alias', unambiguously distinguishing this tool from sibling tools like mail_aliases_list and mail_aliases_create.
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, how to obtain the required alias_id, or any conditions/preconditions. The description merely states the action without context or alternatives.
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?
The destructiveHint annotation already flags the destructive nature of the action, and the description aligns with it. However, the description adds no extra behavioral context beyond the verb 'delete', such as irreversibility, confirmation requirements, or what happens to associated settings. With the annotation present, this is minimally adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single four-word sentence that states the action and target directly, with no filler or repetition. It is perfectly front-loaded and uses every word effectively.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple one-parameter delete operation, the description covers the essential behavior and the schema supplies the parameter details. The destructiveHint annotation covers the safety context, and with no output schema, no return value explanation is needed. It could be slightly more explicit about permanence, but it is largely complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully documents the sole parameter forwarder_id with its type and description, achieving 100% schema coverage. The tool description adds no additional semantic meaning to the parameter, so it relies entirely on the schema, which is acceptable and warrants the baseline score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Delete' and the resource 'email forwarder', clearly distinguishing it from sibling deletion tools like mail_mailboxes_delete and mail_aliases_delete. The noun phrase unambiguously identifies the target entity, making the purpose immediately clear.
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 mail_forwarders_list or mail_forwarders_create. It doesn't mention prerequisites, exclusions, or related tools, leaving the agent without context for selection among the many mail-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?
The annotation already declares destructiveHint: true, so the description is not required to restate that deletion is destructive. However, the description adds no additional behavioral context such as permanence, irreversibility, immediate effect, or any required conditions. It is essentially a restatement of the name/title without enriching the agent's understanding beyond the annotation.
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, short sentence: 'Delete a webhook.' It is front-loaded with the verb and object, contains no filler, and earns its place. It is appropriately sized for a simple delete operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity (one required parameter, no output schema, destructive annotation), the description is nearly sufficient. Combined with the schema (webhook_id) and annotation (destructiveHint: true), the agent has the core information: what to delete and that it is destructive. A small gap is that the description does not mention the consequence (e.g., preventing future deliveries) or that the action is permanent, but the destructive annotation carries that weight. Thus it is complete enough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers 100% of parameters: webhook_id is a required string with its own description 'Webhook ID'. The description does not add any additional meaning about the parameter, but since schema coverage is full, the baseline of 3 is appropriate. The parameter is self-explanatory.
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 'Delete a webhook' uses a specific verb ('delete') and resource ('webhook'), clearly distinguishing it from sibling tools like mail_webhooks_list, mail_webhooks_get, mail_webhooks_create, mail_webhooks_update, and mail_webhooks_test. It is unambiguous and directly states the action.
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: it is the delete operation within the mail webhooks family. However, it provides no explicit guidance about when to choose this tool over alternatives (e.g., use mail_webhooks_update to modify, use mail_webhooks_create to add). No exclusions or prerequisites are mentioned, but the verb and resource make the intended use reasonably clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It states the behavior (listing) plainly and implies a read-only operation, but it does not disclose any additional traits such as pagination, sorting, or required permissions. The simplicity of the operation mitigates the lack of detail, but there is room for improvement.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one short sentence that immediately conveys the core purpose. There is no wasted text, and it is front-loaded with the action verb.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-parameter list operation, the description adequately captures the tool's purpose. However, it omits any information about the response format or how it differs from similar reach tools, which is a minor gap. Given the low complexity, it is nearly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides a 100% description for the single parameter (segment_uuid as 'Segment UUID'). The description adds no additional information about the parameter, so it meets the baseline but does not enhance understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific operation: listing contacts within a given segment. It uses a clear verb and resource, and the title is consistent. It distinguishes this from reach_contacts_list (all contacts) and reach_segments_list (segments) by specifying 'in a segment'.
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 reach_contacts_list or reach_segments_get. The description only restates the function without any context or exclusions, leaving the agent to infer appropriateness.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the burden of behavioral disclosure. It implies a safe read operation via 'Get', but it does not describe response format, error behavior, whether keys are returned as a list, or any rate limits. This is adequate for a simple read operation but lacks richness.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no filler, front-loading the key action and resource. Every word is necessary and the structure is immediately scannable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple: one well-documented parameter, no output schema, and no annotations. For a straightforward read operation, the description sufficiently conveys the purpose and expected resource, though it omits details like return shape or edge cases. This is nearly complete for the tool's low 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?
Schema coverage is 100% for the single vm_id parameter, which is described as 'Virtual machine ID'. The description adds the context that keys are attached to a VPS, but this aligns with the parameter rather than enriching it. Baseline 3 is appropriate given full schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and resource ('SSH public keys attached to a VPS'), clearly distinguishing this from siblings like vps_keys_list, which likely lists all keys, and vps_keys_attach, which attaches keys. The vm_id parameter reinforces the target VPS scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as vps_keys_list or vps_keys_attach. The description does not mention scenarios, prerequisites, or exclusions, so the agent must infer usage from the tool name and siblings.
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?
The description confirms the destructive action, consistent with the destructiveHint annotation. It adds the resource scope (VPS IP) but doesn't disclose additional behavioral details such as irreversibility or impact beyond the annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single front-loaded sentence with no fluff. It communicates the essential operation without redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter delete tool, the description covers the core operation and the schema handles parameter details. However, it lacks any mention of use cases or distinctions from related DNS/VPS tools, leaving some context 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?
Both parameters are fully described in the schema, and the tool description does not add further parameter-level semantics. Per the baseline for full schema coverage, a score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Delete') and resource ('PTR record from a VPS IP'), clearly distinguishing it from vps_ptr_create and DNS record deletion tools. It is concise and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool vs alternatives like vps_ptr_create or dns_delete_records. Context is implied by the name but never explicitly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It indicates a read-only operation by the verb 'List', but does not disclose return format, permission requirements, or potential limitations of the process list. Minimal but adequate for a simple read operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that efficiently communicates the action, target, and scope. No unnecessary words.
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 low-complexity tool with one parameter and no output schema, the description is adequate for selecting and invoking, but it lacks detail about the return value or process information. Since there's no output schema, this leaves the agent uncertain about what data it will receive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 100% description coverage for website_uid, yet the tool description adds meaningful scope by specifying 'Agency Plan website', which the schema parameter description lacks. This clarifies the required context for the UID.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'List' and resource 'running processes' scoped to 'Agency Plan website', clearly distinguishing it from other agency_website_* tools. No 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 states only the function, not when to use it or what alternatives exist. No prerequisites, exclusions, or context is provided. For a simple list operation, usage is implied but not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states 'Get all DNS records,' which implies a read-only operation with no side effects. However, it does not disclose details such as whether the response is paginated, what fields are included, or any permissions required. This is adequate for a simple getter but lacks deeper 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 one succinct sentence of eight words, front-loaded with the verb 'Get.' Every word earns its place, with no redundancy or extraneous 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?
The tool is low-complexity with a single parameter and no output schema. The description covers the core function of retrieving all DNS records, but does not explain return values or response structure. Given the absence of an output schema and annotations, it is adequately complete for a simple getter, though it could benefit from mentioning what is returned.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with the only parameter 'domain' described as 'Domain name' in the schema. The tool description says 'for a domain,' which aligns with the schema but adds no additional meaning beyond what is already in the schema. 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Get all DNS records for a domain.' The verb 'Get' and resource 'DNS records' are specific, and the scope 'for a domain' matches the required parameter. It distinguishes itself from siblings like dns_update_records and dns_delete_records by focusing on retrieval.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage: when you need to view DNS records. However, it does not explicitly state when to use this tool versus alternatives like dns_validate_records or dns_get_snapshots. There is no guidance on when not to use it or any prerequisites, so it provides only basic implied context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states that it creates a profile, but does not mention validation rules, whether multiple profiles are allowed, required permissions, side effects, or what the response looks like. This is a significant gap for a create operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. It conveys the core purpose efficiently without wasting words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The schema provides complete parameter coverage, but there is no output schema or annotations. The description does not mention return values or success behavior, which is typically needed for a create tool. It is adequate but has clear gaps in behavioral 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%, with each parameter already having a clear description in the input schema. The tool description adds no extra parameter details, so it relies entirely on the schema. This meets the baseline of 3.
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 ('Create') and resource ('new WHOIS profile'), with context ('for domain registration'). This distinguishes it from sibling tools like domains_get_whois_profiles, domains_get_whois_profile, and domains_delete_whois_profile.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when a new WHOIS profile is needed for domain registration, providing clear context. However, it does not mention when not to use it or explicitly reference alternatives, though the sibling list makes them apparent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. The description indicates a read-only 'Get' operation, which is a useful behavioral hint. However, it does not disclose what the response contains, how errors are handled, or any side effects (if any). Since it is a simple getter, this minimal disclosure is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that is front-loaded with the key information. It contains no filler or redundant wording, making it highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (one parameter, no output schema, no annotations). The description adequately states the core action. However, without an output schema or additional explanation, the agent cannot infer the return structure or potential edge cases, leaving some gap in completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% (the only parameter 'domain' is described as 'Domain name'). The description adds no additional meaning beyond the schema, which is already clear. Baseline for high coverage is 3, and the description does not compensate further.
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 'Get forwarding config for a domain' uses a specific verb ('Get') and resource ('forwarding config') with a clear scope ('for a domain'). This distinguishes it from sibling tools like domains_update_forwarding and domains_delete_forwarding, which are clearly different operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool's usage: retrieve forwarding configuration for a domain. However, it does not explicitly state when to use this over alternatives or mention any preconditions. No alternative tools are referenced, and no exclusions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that builds run on the server and that status should be checked via a sibling tool, implying an asynchronous deployment. However, it does not mention permissions, side effects, or return values, leaving significant ambiguity 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?
Three sentences, front-loaded with the main action, and each sentence adds value: purpose, constraints, and status-check guidance. No filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the core workflow (archive source-only, auto-build, status check) but omits key contextual details such as the need for the archive to be pre-uploaded (though in schema) or any asynchronous behavior beyond the status check reference. With no output schema and no annotations, the description leaves gaps for a tool with six parameters.
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 six parameters. The description adds no additional parameter-specific semantics, other than implying the archive must contain source files, which relates to archive_path. Baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function ('Deploy a JavaScript application from an archive') with a specific verb and resource. It also differentiates from a sibling by recommending hosting_deploy_list_js for status checks, though it does not distinguish from similar deploy/build tools like hosting_nodejs_build_from_archive.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context for use: the archive must contain source files only, build runs automatically, and a sibling tool is named for checking status. This gives clear when-to-use guidance but lacks explicit exclusions for alternative deployment methods.
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 only says 'List subdomains' without disclosing any behavioral details such as read-only nature, pagination, return format, or error scenarios. This is a significant gap 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, focused sentence with no fluff or repetition. It is front-loaded and every word contributes to the meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with complete schema coverage and no output schema, the description is minimally sufficient. It clearly states the action but lacks context about return values or any filtering behavior, which could be useful but is not strictly required for such a basic operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both 'domain' and 'username' clearly described. The tool description adds no parameter-specific information beyond what the schema already provides, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'List' with the resource 'subdomains' and scopes it to 'a website', clearly distinguishing it from sibling tools like hosting_subdomains_create and hosting_subdomains_delete.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies usage for viewing subdomains of a website, which is distinct from create/delete operations. However, it doesn't explicitly state when not to use it or name alternatives, but for a simple list tool the context is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It discloses the key behavior: automatic pagination to fetch all records. However, it does not mention potential large response sizes, performance considerations, or any other side effects beyond pagination, leaving some transparency gap for a zero-parameter read 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?
A single sentence, front-loaded with the action ('Auto-paginate to fetch ALL'), and zero wasted words. Every word earns its place, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple zero-parameter list tool, the description covers the essential behavior (fetch all, auto-paginate). It is slightly incomplete in not addressing potential scale-related caveats or explicitly contrasting with the sibling hosting_websites_list, but overall it is adequate for a tool of this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema coverage is 100% (empty object), so no parameter enrichment is needed. The baseline for zero params is 4, and the description adds nothing about parameters because there are none to explain.
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 function: 'Auto-paginate to fetch ALL hosting websites,' with a specific verb ('fetch') and resource (hosting websites). It distinguishes from siblings via the emphasis on 'ALL' and 'auto-paginate,' though it does not explicitly name an alternative like hosting_websites_list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool: when you need the full list without manually handling pagination. However, it does not explicitly state exclusions or name the alternative (e.g., hosting_websites_list) for cases where a non-paginated or filtered list is acceptable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses that the tool sends a confirmation email and applies to unconfirmed forwarders, but it does not describe error conditions, prerequisites (e.g., forwarder existence), or side effects beyond the resend. This is minimal behavioral disclosure for a 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 a single, concise sentence that front-loads the action and object. Every word earns its place, with no redundant or vague phrasing.
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?
With only one parameter and no output schema, the description is adequate but lacks details about success/failure behavior, preconditions, or what happens if the forwarder is already confirmed. For a mutation operation, more context would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage: forwarder_id is described as 'Forwarder ID'. The description adds no additional meaning beyond the schema, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action: 'Resend the confirmation email for an unconfirmed forwarder.' It includes a clear verb ('resend'), a specific resource (confirmation email for a forwarder), and a condition (unconfirmed). This distinguishes it from sibling tools like mail_catchalls_resend_confirmation by explicitly targeting forwarders.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly mentions the tool is for unconfirmed forwarders, which implies when to use it. However, it does not explicitly name alternative tools (e.g., mail_catchalls_resend_confirmation) or state exclusions, so it provides clear context but lacks explicit differentiation from similar resend operations.
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?
The description discloses that this is a read-only operation ('List') scoped to a mail order. However, it does not describe response format, pagination, or error behavior. Since no annotations are provided, the description carries the burden, but for a simple list tool, the basic behavior is clear.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, front-loaded with the action and resource, with no redundant words. It is appropriately concise for a tool with one 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?
With one parameter, no output schema, and no annotations, the description is minimal but sufficient for the agent to understand the tool's core function. It lacks details about the return structure and edge cases, but given the simplicity, it meets minimum viability.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides 100% coverage with order_id described as 'Mail order ID'. The description reinforces this by saying 'for a mail order' but adds no additional format, validation, or example details. Baseline of 3 is appropriate given high schema coverage.
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 'List mailboxes for a mail order' uses a specific verb ('List') and resource ('mailboxes') with a scope ('for a mail order'). It clearly distinguishes from sibling tools like mail_orders_list, which lists orders, and mail_aliases_list, which lists aliases.
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 you need mailboxes for a specific mail order, this is the tool. It does not explicitly mention when not to use it or provide alternatives, but the scope 'for a mail order' gives enough context for a simple list operation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the behavioral disclosure burden. The verb 'List' implicitly indicates a read-only operation, which is accurate. However, it does not disclose any additional traits such as pagination, sorting, or the full scope of 'orders' (e.g., whether historical orders are included).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one concise sentence, front-loaded with the action and resource. Every word contributes to clarity with no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the description adequately states the core action, it lacks context about what an 'order' contains or what the response will look like. Since there is no output schema, the agent has minimal guidance on expected return values. For a zero-parameter list tool, this is acceptable but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema is trivially complete. The description adds no parameter-specific information, but none is needed; the baseline of 4 for zero-parameter tools applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses an explicit verb ('List') and a specific resource ('mail/email orders'), clearly distinguishing it from sibling tools like hosting_orders_list and agency_orders_list by specifying 'mail/email'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It does not mention related tools like mail_orders_get_plan or clarify that this is for listing orders only, not for managing mailboxes or other mail resources.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries full behavioral burden. The verb 'Get' implies a read-only operation with no side effects, but the description does not add details about authorization, pagination, or return format. It is sufficient for a basic list, but not richly transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that directly states the tool's purpose without any filler. Every word contributes, making it an example of efficient communication.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple, parameterless list tool with no output schema, the description sufficiently conveys that it returns available OS templates. It could specify the structure or fields of the returned data, but given the low complexity, it is reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema coverage is trivially 100% and the description cannot add parameter-level detail. The phrase 'available OS templates' hints at the scope (all templates), providing marginal semantic value beyond the empty schema.
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) and resource (available OS templates for VPS). It distinguishes from the sibling vps_templates_get by implying a list vs. a single item, though it could explicitly say 'list all' to eliminate any ambiguity.
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 use when a user needs a list of OS templates, but it offers no explicit guidance on when to prefer this tool over vps_templates_get or other information-only tools. For a simple list with no parameters, the intended use is evident from the name, but context and exclusions are missing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of disclosing behavior. 'List' implies a read-only operation, but it does not explicitly state that nothing is modified, nor does it describe return format, permissions, or pagination. It is minimally transparent but not misleading.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, front-loaded with the action and target, containing no filler or redundant 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?
For a simple list tool with two well-described parameters and no output schema, the description is minimally viable. However, it lacks any mention of what the response contains (e.g., theme names, versions) or any usage prerequisites, leaving some gaps for the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds no additional meaning about the parameters 'username' and 'software' beyond what the schema already provides.
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 'List installed WordPress themes' uses a specific verb ('List') and resource ('installed WordPress themes'), clearly distinguishing it from the sibling tool wp_themes_list_available by the word 'installed'.
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 it is for viewing already-installed themes, but it does not explicitly state when to use this tool versus wp_themes_list_available or other wp_themes_* tools. Sibling names provide context, but the description itself gives no direct alternatives 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. It only states that the tool 'gets logs' and is for debugging, which is an obvious read operation. It does not disclose any additional behavioral traits such as return format, line limits, polling behavior with 'from_line', or error handling. This is a significant gap for a tool that could potentially return large log outputs.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured, consisting of two short sentences that immediately convey the main purpose and a key use case. There is no wasted language or redundancy, and the most critical information ('Get logs... Use for debugging') is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (fetch logs), the 100% schema coverage, and no output schema, the description is mostly complete. It explains the primary use case and identifies the target resource. However, it does not address potential nuances like the 'from_line' parameter for polling live logs, which could be important for full contextual understanding. Overall, it is adequate for a basic tool but leaves slight gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage for all four parameters, so the baseline is 3. The description adds no parameter-specific details beyond the schema, such as explaining the polling behavior of 'from_line' or the relationship between 'username', 'domain', and 'uuid'. The schema itself is adequate, so no compensation is needed, but the description does not enhance understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get logs for a JavaScript deployment build.' The verb 'get' specifies the action, and 'JavaScript deployment build' identifies the exact resource. The phrase 'Use for debugging failed deployments' adds practical context and differentiates it from sibling log tools like hosting_nodejs_build_logs, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear usage context with 'Use for debugging failed deployments,' which tells the agent when to use this tool. However, it does not explicitly mention alternatives or when not to use it, such as noting that Node.js build logs should use a different tool. This is a minor gap, as the context is sufficient for basic guidance.
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 must carry the full burden of behavioral disclosure. It only states the tool lists deployments and their status, which is already implied by the name and schema. It does not disclose any additional behavioral traits such as pagination, ordering, or whether it lists deployments for a specific domain only. This is a minimal disclosure for a read-only operation, so it falls short.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short, focused sentences. The first states the core function, and the second gives a direct use case. There is no unnecessary fluff, and it is concise and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with no output schema, the description adequately covers the purpose and usage. The schema covers parameter details. However, it could have mentioned that this is specific to JavaScript deployments and that the deployment list is per domain/username, but the schema provides these details. Overall, it is sufficiently complete for an agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, so the schema fully documents all three parameters (domain, states, username). The description does not add any extra meaning beyond what the schema already provides, such as the meaning of 'states' values. Therefore, the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists JavaScript application deployments and includes their status. This distinguishes it from sibling tools like hosting_deploy_js_app (creates a deployment) and hosting_deploy_js_logs (retrieves logs). It uses a specific verb and resource.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear usage context: 'Use to check if deployment is pending, running, completed, or failed.' It implies when to use this tool but does not explicitly mention alternatives or exclusions. This is clear context with no exclusions, matching a score of 4.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose its own behavior. It states that files are extracted and the site is deployed automatically, which is useful. However, it does not disclose potential side effects like overwriting existing files, permission requirements, or whether the operation is reversible, which is important for an import 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 two sentences with no redundant wording. It immediately states the purpose and includes the key behavioral outcome, making it easy 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?
The tool involves importing an entire WordPress site with four parameters, yet the description omits important context such as prerequisites, what happens to existing files, and the exact role of the optional SQL dump. It also doesn't clarify that sql_path is optional, creating potential ambiguity in interpreting 'database dump.'
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers all parameters with descriptions, so the baseline is 3. The description adds minimal semantic value beyond the schema, merely referencing 'archive' and 'database dump' which maps to archive_path and sql_path. It does not elaborate on the format, required structure, or the optionality of sql_path.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool imports a WordPress website from an archive and database dump, and explicitly mentions the extraction and automatic deployment. This distinguishes it from sibling deployment tools like hosting_deploy_static or hosting_deploy_js_app.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context that this is for importing an existing WordPress site from backup files, implying it's for migration/restoration rather than fresh installation. However, it does not explicitly mention alternatives or state when not to use this tool, such as for a new site or when using agency_import_archive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the transparency burden. 'List' implies a read-only operation, but the description does not mention pagination, response format, or any filtering behavior. It gives the basic action but no additional 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, succinct sentence: 'List all hosting orders.' It contains no redundant words and is immediately scannable, earning a perfect score for conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless list operation with no output schema, the description is adequate: it names the action and the resource. However, it could optionally clarify what constitutes a 'hosting order' or how results are ordered, but the tool's simplicity makes this non-critical.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, achieving 100% schema description coverage trivially. Since there are no parameters to explain, the description does not need to add parameter semantics, warranting the baseline score of 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'List' and the resource 'hosting orders', clearly indicating what the tool does. The qualifier 'hosting' distinguishes it from sibling tools like mail_orders_list and agency_orders_list, and 'all' clarifies the 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 does not provide any guidance on when to use this tool versus alternatives. With siblings like mail_orders_list and agency_orders_list, no exclusions or recommendations are given, leaving the agent to infer the use case 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, the description carries the full burden, but it only repeats the action of listing websites. It does not disclose return format, pagination behavior, or any side effects. Beyond the tool name, it adds only the scope 'on your hosting account'.
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 front-loads the action and resource. Every word adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter list tool, the description is sufficient to convey its core function. However, it does not mention pagination, which may be relevant given the sibling list_all_websites_paginated, but overall it is adequate for the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the description does not need to explain parameter syntax. The baseline for 0-param tools is 4, and the description provides no parameter-related details, which is acceptable given the absence of parameters.
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 it lists all websites on the hosting account, using a specific verb ('List') and resource ('websites'). It distinguishes from sibling tools like hosting_websites_create and hosting_websites_delete by focusing on the list action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for retrieving an overview of websites, but it does not explicitly state when to use it versus alternatives like list_all_websites_paginated or wp_installations_list. No exclusions or alternative guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the full burden. It indicates a read-only operation via 'List', but does not disclose any other behavioral details such as response format, pagination, or error conditions. The scoping to an order adds some 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 short sentence with no filler. Every word contributes to the purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter list operation, the description is mostly sufficient. It names the resource and scope, but lacks details about the response structure or list limits, which would be useful since there is no output 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?
The input schema covers the only parameter order_id with a clear description 'Mail order ID'. The description mentions 'for an order' which aligns with the parameter but does not add further semantic detail. Since schema coverage is 100%, a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'List' and identifies the resource 'email aliases' scoped by 'for an order'. This clearly distinguishes it from sibling tools like mail_aliases_create or mail_mailboxes_list.
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 you need to retrieve aliases associated with a specific order, but it does not explicitly state when to use it over alternatives or provide any exclusion criteria. No alternative tools are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It clearly implies a read-only list operation, but it does not disclose return format, pagination, or error behavior. This is a minor gap for a simple list 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?
A single concise sentence that immediately conveys the action, resource, and scope. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter list tool, the description adequately covers what it does and for which order. It lacks explicit return-value details, but these are largely self-evident for a list operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (order_id described as 'Mail order ID'), and the description adds only 'for an order', which slightly reinforces the parameter's role but adds no additional syntax or format details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb (List) and resource (email forwarders) with a clear scope (for an order), which distinguishes it from sibling tools like create, delete, or keep_copy.
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 phrase 'for an order' implies usage when you have an order ID and need its forwarders, but there is no explicit guidance on when not to use it or mention of alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden of behavioral disclosure. It indicates a read-only list operation, but does not disclose any additional behavior such as pagination, error handling, or what happens if the order id is invalid. While the listing nature is clear, no extra context is added.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no filler. It front-loads the action and scope, earning a high score for efficiency.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list operation with one parameter and no output schema, the description is sufficient for an agent to understand the basic function. However, it lacks any mention of return payload or behavior on missing order, so it's not fully complete, but the simplicity keeps it above average.
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 a single parameter 'order_id' with description 'Mail order ID', which is 100% coverage. The description repeats essentially the same information ('for a mail order') without adding further meaning about the parameter's format, constraints, or usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the verb 'List' and specifies the resource 'webhooks' scoped to 'a mail order,' clearly distinguishing it from sibling tools like mail_webhooks_get (which retrieves a single webhook) and mail_webhooks_create. It states exactly what the tool does.
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 usage is implied by the name and scope but there is no explicit guidance on when to use this tool versus mail_webhooks_get or other webhook operations. It does not mention alternatives or when-not-to-use scenarios, so it only partially meets the criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description itself must convey behavior. It indicates a read operation ('Get') and identifies the specific content (compose file), which helps. However, it lacks any statement about side effects, permissions, or response format, which would be valuable.
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?
Single sentence, front-loaded, no unnecessary words. It conveys the essence immediately.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read tool with two well-described params, the description is mostly sufficient. It identifies the target resource (compose file) but doesn't explicitly state the return format or error behavior, which 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?
Input schema already provides descriptions for both parameters (vm_id, project_name) with 100% coverage. The description adds no additional parameter meaning, so per the baseline for high schema coverage, this scores 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and resource ('Docker project contents (compose file)'), clearly distinguishing it from siblings like vps_docker_list (listing projects) and vps_docker_containers. The parenthetical clarifies exactly what is retrieved, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or alternatives are mentioned. The tool's purpose is implied by its name and description, but there is no guidance on when to prefer this over vps_docker_list or vps_docker_logs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden. 'Get all SSH public keys' implies a read-only operation and clarifies the scope ('all'), but it discloses no other behavioral traits such as auth requirements, pagination, rate limits, or return format. It is adequate for a simple read operation but adds minimal value beyond the tool name.
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 extraneous words. It is front-loaded with the main verb and resource, making it highly scannable and efficient. Perfectly sized for a simple list operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (zero parameters), the description covers the core purpose. However, there is no output schema, so the agent is left without hints about the response structure (e.g., array of objects with key IDs/fingerprints). This is a minor gap but does not compromise the basic understanding of the operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema description coverage is trivially 100%. Per the baseline rule for 0-parameter tools, the description does not need to explain parameters. It correctly omits any parameter information, and the schema already communicates that no arguments are required.
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 'Get all SSH public keys' uses a specific verb ('Get') and resource ('SSH public keys'), clearly indicating a read/list operation. It effectively distinguishes itself from sibling tools like vps_keys_create, vps_keys_delete, and vps_keys_attach, and even clarifies that it returns public keys 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. With siblings like vps_get_attached_keys (which lists keys attached to a VPS) and vps_keys_create, the agent would benefit from explicit context, but none is provided. There is no mention of exclusions or alternative tool references.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses an important behavioral trait—that the VM will reboot normally after exiting recovery mode—but it does not mention potential downtime, prerequisites, or whether recovery mode must be active. The reboot detail adds value, but the description is otherwise sparse.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence: 'Exit recovery mode and reboot normally.' It is concise, front-loaded, and every word contributes meaning. No redundant or irrelevant information is included.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one required parameter and no output schema, the description sufficiently conveys the action and the significant side effect (reboot). Minor details like whether the VM must already be in recovery mode could be added, but overall it is adequately complete for 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 input schema fully describes vm_id (type: number, description 'Virtual machine ID'), and the tool description adds no additional parameter context. Since schema coverage is 100%, the baseline of 3 applies; the description does not enhance parameter understanding.
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 'Exit recovery mode and reboot normally' clearly states a specific action: terminating recovery mode and initiating a standard reboot. It distinguishes itself from sibling tools like vps_recovery_start (which enters recovery mode) and vps_restart (which reboots without exiting recovery mode).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool should be used when the user wants to leave recovery mode and reboot the VM normally, but it does not explicitly state when to use it versus alternatives, nor does it mention any prerequisites or exclusions. This is implied usage rather than clear guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotation declares destructiveHint=true, and the description's 'Delete' is consistent with this. However, the description adds no additional behavioral context beyond the annotation, such as irreversibility or effects on associated resources.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, 'Delete a post-install script.', which is front-loaded and free of filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple delete operation with one required parameter and a destructiveHint annotation, the description is adequate but minimal. It does not mention return values or error states, though the simplicity of the operation makes this less critical.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already documents script_id as a required number with description 'Script ID', achieving 100% coverage. The description adds no further parameter meaning or usage details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Delete' and identifies the resource as 'post-install script', clearly distinguishing it from sibling tools like vps_scripts_create, vps_scripts_update, and vps_scripts_list.
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 provides no explicit alternatives or when-to-use guidance. It relies on the tool name and the delete operation to imply usage, but does not mention prerequisites or scenarios where deletion is appropriate versus other script operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. The description clearly indicates a read-only operation ('List'), but does not disclose details such as return format, pagination, or any prerequisites beyond the website_uid parameter. It is minimally transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that directly states the purpose with no filler 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 simplicity of the tool (one parameter, no output schema), the description is adequate but lacks details on return values or behavior, such as whether it lists all databases or only some. It is not incomplete enough to cause confusion, but could be enriched.
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% coverage for website_uid with a basic description. The tool description does not add param-specific details, but the baseline of 3 applies due to high schema coverage.
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), the resource (databases), and the scope (for an Agency Plan website), distinguishing it from sibling tools like hosting_db_list. It is specific and unambiguous about what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'for an Agency Plan website' implies when this tool is relevant, but it does not explicitly mention alternatives or exclusions. Still, the context is clear enough that an agent can infer usage versus other database-list tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of disclosure. It states the core actions (uploads theme files, optionally activates) but does not mention whether it overwrites existing themes, required permissions, or failure behaviors. This is partial transparency but leaves important side effects undisclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded, using two short sentences. The first sentence states the main purpose and the second clarifies the optional activation, with no wasted words.
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 deployment tool with 5 parameters and no output schema, the description provides a basic overview but lacks details on prerequisites (e.g., where the archive must reside), the format of the archive, and what happens upon successful deployment. It is adequate but not thorough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers all parameters with descriptions (100% coverage), so the baseline is 3. The tool description adds no extra meaning beyond the schema, simply referring to 'directory/archive' which aligns with archive_path.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Deploy') and resource ('custom WordPress theme from a directory/archive'), clearly indicating its function. It also distinguishes itself from sibling tools like hosting_deploy_wp_plugin and wp_themes_install by emphasizing 'custom' and 'directory/archive'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool: when deploying a custom theme from a directory or archive. It provides clear context but does not explicitly mention alternatives or when not to use it, such as for themes from the WordPress repository.
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 description carries full burden. It discloses auto-pagination behavior but this is essentially a restatement of the tool name. It omits return format, potential large data volume, or any safety implications. Minimal value added beyond the name.
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?
Single sentence, front-loaded and efficient, but contains redundancy: 'Auto-paginate' and 'handles pagination automatically' say the same thing. Could be tightened without losing meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter read tool, the description adequately explains its core function. However, lacks details about the output structure or any operational caveats, which would be valuable given no output schema or annotations. Still, it's reasonably complete for its simplicity.
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?
Tool has zero parameters, so schema coverage is trivially 100%. Baseline for 0 params is 4; description doesn't need to explain any parameters.
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?
Description uses specific verb 'fetch' with resource 'ALL domains' and scope 'portfolio', clearly distinguishing from siblings like domains_get_list by emphasizing full retrieval. It concisely states what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly indicates when to use this tool (when you need ALL domains without manual pagination) but doesn't explicitly mention alternatives or exclusion criteria. The context is clear enough for an agent to choose this over a paginated listing tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It discloses extraction, as-is serving, no build step, and synchronous operation, but does not mention potentially destructive aspects like overwriting existing content or required file structure.
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?
Three sentences with no fluff. First sentence gives the core purpose, second clarifies behavior, third clarifies operation mode. Each sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a deploy tool with no output schema, the description covers the essential behavior. It is missing minor context like what happens to existing site content, but overall is sufficient for an agent to invoke 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 coverage is 100%, so descriptions for both parameters already exist. The tool description adds no parameter-specific meaning beyond 'archive' and 'PHP application', so baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Deploy'), the resource ('PHP application to an Agency Plan website'), and the source ('from an archive'). It also differentiates from sibling deploy tools by noting 'no build step'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The context is clear: use for PHP apps on Agency Plan sites from an archive. However, it does not explicitly mention when not to use it or name alternative tools for other deployment types, so it lacks explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. The verb 'browse' implies a non-destructive read operation, and the optional filters disclose some behavior, but it does not provide details about return format, pagination, or any other side effects. This is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, front-loaded with the primary purpose. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple catalog browsing tool with no output schema and well-documented parameters, the description is sufficient to convey the tool's purpose and filtering capability. However, it could mention that it returns all matching products/pricing or any list limits, which is why it's not a 5.
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 parameters are already documented. The description simply reiterates that filters by category or name are available, adding no new semantic information beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('browse') and resource ('available Hostinger products and pricing'), clearly distinguishing this catalog tool from sibling billing tools like subscriptions or payment methods.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description makes clear it's for browsing the product catalog with optional filters, providing clear context. However, it does not explicitly state when not to use it or mention alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must cover behavior. It discloses the prerequisite that the catch-all must be unconfirmed and that an email is sent, but it does not mention any side effects (e.g., whether previous confirmation links are invalidated), error conditions, or permissions. This is adequate but minimal for a simple resend 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, concise sentence that conveys the essential purpose without any redundant words. Every word contributes meaning, making it highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool with no output schema, the description provides the core information needed: the action, the target resource, and the state condition (unconfirmed). It could mention potential error cases or the actual email recipient, but given the low complexity, it is substantially complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully documents the only parameter, catchall_id, with a description 'Catch-all ID'. The tool description adds no further semantic detail about the parameter, so with 100% 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (resend a confirmation email) and the target resource (an unconfirmed catch-all), using a specific verb-plus-resource structure. It distinguishes from the sibling tool mail_forwarders_resend_confirmation by explicitly mentioning 'catch-all' rather than 'forwarder'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context: it is for resending a confirmation email when the catch-all is unconfirmed. It does not explicitly state when not to use it or name alternative tools, but the context is specific enough to guide selection among mail-related siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states the operation is 'List all,' implying read-only, but it does not disclose potential response size, pagination behavior, or any side effects. For a simple list tool, this is minimal but not fully transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no extraneous words. It delivers the core message efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (0 params, no output schema, no annotations), the description is adequately complete for a 'list all' operation. It could mention pagination or limits, but for a basic list, the current text covers the essential behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With zero parameters, the schema fully covers the parameter space, and the description need not explain parameter details. Baseline for 0 params is 4; no additional semantics required.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'List' with a clear resource 'all email marketing contacts,' distinguishing it from sibling tools like reach_contacts_groups (groups) and reach_segments_list (segments). The purpose is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The tool's usage is implied by the description ('when you need contacts'), but there is no explicit guidance on when to use this tool versus alternatives, nor any mention of exclusions. Lacks explicit context such as 'use this instead of other list tools for contacts.'
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It discloses the operation flow (uploads archive, triggers build, deploys to public_html) and the synchronous behavior (site is live when tool returns). Does not mention overwrite behavior or permissions, which could be a gap, but it provides meaningful process transparency beyond a simple 'deploy' statement.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, first stating purpose and steps, second stating synchronous behavior. Information is front-loaded with no filler, every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple parameter schema (2 strings, no output schema) and no annotations, the description covers purpose, process, and a key behavioral trait (synchronous). It could be more explicit about whether the deploy overwrites existing content or any prerequisites, but for a straightforward deploy tool, it is adequately complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. Both parameters have brief descriptions ('Website UID' and 'Relative path to archive from document root'). The tool description adds no extra detail about parameter format or constraints beyond what the schema already provides, so it does not exceed the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description uses a specific verb 'Deploy' with a specific resource 'node-static Agency Plan website' and method 'from an archive'. It clearly distinguishes from siblings like agency_deploy_php and hosting_deploy_static by scoping to Agency Plan and node-static site type.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear context (Agency Plan, archive-based, synchronous) that implies when this tool is appropriate. However, it does not explicitly name alternatives or state when not to use it, but the context is sufficient for an agent to differentiate from similar deploy tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states the primary effect (clearing cache) and implies that after clearing, subsequent operations will see fresh data. However, it does not disclose any potential side effects such as global scope, temporary performance impact, or whether it affects other users. For a simple cache clear, this is acceptable but could be more transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences that are front-loaded: it states the action first, then the usage guidance. There is no redundancy or wasted words. Every part contributes meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter tool with no output schema, the description covers the essential points: what it does and when to use it. It is complete enough for an agent to select and invoke correctly. A slight gap is the lack of clarification on whether this clears only the current user's cache or a shared cache, but overall it is adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and schema coverage is trivially 100%. The description does not need to explain parameter semantics. Per the rubric, 0 params baseline is 4, and the description adds the necessary context about the operation's purpose.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (Clear) and the specific resource (internal response cache). It distinguishes itself from sibling tools like hosting_cache_clear and agency_cache_clear by focusing on the API-level cache. The phrase "Use when you need fresh data" reinforces the purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says when to use the tool: "Use when you need fresh data after making changes." This provides clear context, but it does not mention any alternative tools or explicitly state when not to use it. Still, the guidance is specific and actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the important precondition that the archive must contain pre-built files and that no build process occurs. However, it does not mention deployment side effects such as whether existing files are overwritten, if the site becomes immediately live, or any authorization requirements, leaving a transparency gap for a mutation 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 three concise sentences with no redundancy. The first sentence states the action, the second sets a precondition, and the third provides an alternative for a different use case. It is front-loaded and every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple 3-parameter deploy action with no output schema and no annotations, the description is largely complete: it defines the operation, states preconditions, and names the alternative tool. It only lacks explicit side-effect information (e.g., overwriting behavior), but this is a minor gap given the tool's simplicity and sibling guidance.
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 baseline is 3. The description adds the contextual constraint that the archive must be pre-built, but it does not provide additional parameter-level detail beyond what the schema already states. It also does not explain archive format or the relationship between username and domain.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Deploy'), identifies the resource ('static website'), and lists the content types (HTML/CSS/JS/images). It also distinguishes itself from the sibling 'hosting_deploy_js_app' by explicitly stating 'No build process' and directing JS apps to that alternative.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It clearly states when to use this tool (pre-built static files) and when not to ('For JS apps with build step, use hosting_deploy_js_app instead'). This explicit alternative guidance is exactly what agents need for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It discloses the key behavior of auto-pagination, which is useful, but omits details such as return format, potential limits, or performance implications. It does not contradict anything.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the operation (auto-paginate) and the target (all billing subscriptions). Every word earns its place; no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a simple zero-parameter list operation with no output schema. The description covers the essential behavior (auto-pagination, all subscriptions) and is sufficient for an agent to invoke it correctly. Slightly more detail about the response shape would improve it, but it is not critical.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline is 4. The description has nothing to add per-parameter, and the schema is empty, so this is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'fetch' and identifies the resource as 'billing subscriptions', with 'ALL' clarifying the full scope. This clearly distinguishes it from possibly limited subscription-listing tools like billing_get_subscriptions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The context is clear: this tool auto-paginates to fetch all billing subscriptions, implying it is the comprehensive variant. However, it does not explicitly name alternatives or state when not to use it, preventing a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotation already provides destructiveHint: true, but the description goes further by specifying "DESTROYS ALL DATA," clarifying the scope of destruction. This adds context beyond the structured annotation. There is no contradiction between the description and annotations.
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 only two sentences: the first states the action, the second delivers a critical warning. It is front-loaded, scannable, and contains no redundant or irrelevant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's destructive nature, the description sufficiently conveys the primary risk (data loss). It might also mention irreversibility or service interruption, but the annotation and schema fill in key gaps, making the description adequate for an agent to understand the critical action and its consequences.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage for all parameters (vm_id, password, template_id), so the description does not need to explain them. It adds no additional parameter semantics, but the baseline of 3 applies because the schema carries the descriptive load.
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: "Recreate (reinstall) a virtual machine." The verb is specific, and the parenthetical 'reinstall' removes any ambiguity. It distinguishes itself from sibling VPS tools (e.g., vps_start, vps_restart, vps_get) by focusing on the reinstall operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description makes the usage context obvious: use this tool when you want to reinstall a VPS. It does not explicitly name alternatives or exclusions, but among the sibling tools, there is no other reinstall operation, so the intent is clear. The "DESTROYS ALL DATA" warning also signals to avoid using it when data preservation is needed.
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?
Without annotations, the description carries the burden. It discloses the scope (all accounts) and the read-only nature (list), but doesn't go further to mention performance implications, output format, or any potential side effects. It's adequate but minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence, front-loaded with the action, no fluff. Every word is informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with no parameters and no output schema, the description is adequate. It clearly states the resource and scope. It doesn't list return fields, but that's not unusual for a list operation without an output schema. The distinction from wp_detect_installations is subtle but present via the 'all hosting accounts' phrasing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema coverage is 100%, so the description need not explain parameters. Baseline for 0 params is 4.
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 it lists WordPress installations across all hosting accounts, with a specific verb and resource. It distinguishes from siblings like wp_detect_installations by explicitly noting the global scope (all accounts).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: it's the tool for a global list of WordPress installations across all hosting accounts. It doesn't explicitly mention alternatives or exclusions, but the scope statement implies when to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It explicitly indicates a read operation ('Get') and discloses what data will be returned (counts and statuses across service types). It does not mention any side effects, permissions, or caveats, but as a no-parameter getter, this level of transparency is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that opens with the core action and resource, then enumerates the included categories. Every word earns its place, and there is no fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of an output schema, the description does a good job naming the specific data categories (VPS count, domains, websites, mail, subscriptions) and their statuses. While the exact response structure is not spelled out, this is sufficient for a simple no-parameter overview tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema properties are empty. Per the rubric, 0 parameters earns a baseline of 4. The description adds no parameter-specific info, which is appropriate since there are none.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool provides a comprehensive overview of all Hostinger services, enumerating specific categories (VPS count, domains, websites, mail, subscriptions) and their statuses. This distinguishes it from individual resource-specific tools like vps_list or hosting_websites_list, making its purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description conveys clear context: use when a high-level, cross-service summary is needed. While it doesn't explicitly mention alternatives or exclusions, the scope ('all Hostinger services') implies this is an aggregating overview, and the sibling tool names make it obvious that specific tools handle detailed operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavior disclosure. It reveals that the tool makes a live connectivity/auth check and returns account/service status, which is sufficient for a trivial no-parameter health check.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence that communicates purpose and return value without wasted words. Every clause earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with no parameters, the description adequately explains purpose and return value. The return value is only summarized ('service status summary') rather than detailed, but this is acceptable for a diagnostic tool without an output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has zero parameters, so the baseline is 4. The description need not add parameter detail because there are no parameters to document.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Check') and a clear resource ('connectivity and authentication with Hostinger API'), and explicitly states what it returns ('account info and service status summary'). This clearly distinguishes it from the many operational sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The diagnostic purpose implies usage as a preflight check before other API calls, but no explicit exclusions or alternatives are mentioned. The context is clear enough for an agent to decide when to invoke it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It clearly states that creating the order will use the default payment method if none is supplied, which is a crucial side effect for an agent to know. It doesn't mention charge processing or other side effects, but it covers the most important behavioral nuance.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description consists of two sentences, both essential: the first states the core action, the second adds the fallback behavior. No redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter tool with no output schema, the description provides all necessary information: what it does, on what entity, and the key default behavior. It is complete enough for an agent to select and invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already documents both parameters with descriptions, and the description reinforces the optional nature of payment_method_id by noting the default behavior. This adds practical guidance beyond the schema, though the schema is already sufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the specific action ('Create a renewal order') and the target resource ('an existing subscription'), distinguishing it from sibling tools like billing_enable_auto_renewal or billing_create_order. The verb and resource are unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use the tool (renewing an existing subscription), but it doesn't explicitly exclude alternatives like auto-renewal. The mention of default payment method implies the expected scenario of manual renewal.
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:

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

Score Badge

Copy to your README.md:

[![hostinger-mcp MCP server](https://glama.ai/mcp/servers/idugeni/hostinger-mcp/badges/score.svg)](https://glama.ai/mcp/servers/idugeni/hostinger-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/idugeni/hostinger-mcp'

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