hostinger-api-mcp

Official

by hostinger

Overview Schema Related Servers Score Discussions(1)

JavaScript

Remote

Server Quality Checklist

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

Latest release: v1.33.1
Disambiguation1/5
The tool set contains numerous near-duplicate and overlapping tools, such as reach_createANewContactV1 vs reach_createNewContactsV1, reach_listSegmentContactsV1 vs reach_listProfileSegmentContactsV1, and hosting_deployWordpressPlugin vs hosting_installWordPressPlugins. Deprecated endpoints are mixed with their modern replacements, making it very difficult to choose the correct tool.
Naming Consistency2/5
Naming is inconsistent across the set: some prefixes use hyphens (agency-hosting_*), others use camelCase (agencyHosting_*), and others use underscore prefixes (VPS_, DNS_, domains_). Verb forms vary (createANewContact vs createNewContacts, list vs get), and some tools have V1 suffixes while others do not.
Tool Count1/5
With 314 tools, the server is drastically over-scoped for an MCP interface. It aggregates many distinct API domains (VPS, domains, hosting, mail, billing, ecommerce, reach, etc.) and includes deprecated and duplicate endpoints, overwhelming agents and likely exceeding any reasonable tool limit.
Completeness4/5
Despite the bloat, the tool set provides broad CRUD/lifecycle coverage across most Hostinger product lines, including VPS, domains, hosting, mail, billing, and email marketing. Deprecated endpoints have modern replacements, so there are few hard dead ends, though the fragmented legacy endpoints add complexity.
Average 3.9/5 across 314 of 314 tools scored. Lowest: 2.6/5.
See the Tool Scores section below for per-tool breakdowns.
- 10 of 15 community issues answered or closed in the last 6 months
- 91 commits in the last 12 weeks
- Last stable release on August 13, 2026
- 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.
This repository includes a glama.json configuration file.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It indicates deletion is destructive but does not mention prerequisites, irreversibility, or required permissions, and the filter discrepancy adds uncertainty.
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?
Description is relatively concise with clear first sentence, but the misleading filter information wastes some words and could be restructured to match schema.
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 delete-tool with filtering, the description is incomplete because it does not specify how to provide the filter parameters (name/type) given the schema only includes 'domain', and lacks any output schema details.
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?
Input schema has only 'domain' with minimal description; the description adds filter semantics (name/type) that are not present in the schema, creating a contradiction and failing to add useful parameter meaning.
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 clearly states the tool deletes DNS records for a domain, but mentions filtering by name/type which are not in the input schema, causing confusion and reducing clarity.
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?
Provides guidance on when to use 'Update zone records' for partial deletions of records with same name/type, but the missing filter parameters in schema make the guidance unactionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "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, and the description does not disclose any behavioral traits beyond the obvious action. There is no mention of side effects, permission requirements, or outcomes, leaving the agent uninformed about potential impacts.
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 contains two sentences, but the second sentence is a redundant repetition of the first. It could be more concise without losing clarity.
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, the description is minimally adequate. It states the action but does not explain failure conditions, return values, or scope (e.g., which subscriptions qualify). The lack of an output schema reduces completeness slightly.
Complex tools with many parameters or behaviors need more documentation. Simple tools 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, 'subscriptionId', is described in the schema as 'Subscription ID'. The description does not add any additional meaning beyond what the schema already provides. With 100% schema description coverage, the baseline is 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 'enable' and resource 'auto-renewal for a subscription', clearly indicating the action. The sibling tool 'billing_disableAutoRenewalV1' contrasts the purpose, but the description does not explicitly differentiate from it.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps 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_disableAutoRenewalV1'. The description only repeats the purpose without context 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?
Without annotations, the description carries the full burden. It does not disclose any behavioral traits such as idempotency, side effects, auth requirements, or what happens on duplicate attempts. Mutation is implied but not detailed.
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 concise with two sentences, front-loading the main action. However, it could be slightly more structured (e.g., specifying required parameters or output).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (nested objects, no output schema), the description is incomplete. It doesn't specify what the response contains (e.g., profile ID) or how to structure the nested objects. Siblings dealing with WHOIS profiles imply a flow, but not explicit.
Complex tools with many parameters or behaviors need more documentation. Simple tools 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 schema already documents all parameters. The description adds no additional parameter meaning, especially for nested objects (tld_details, whois_details) whose structure is left unspecified. 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 it creates a WHOIS contact profile for domain registration. While it doesn't explicitly differentiate from sibling create tools, the resource (WHOIS profile) is distinct from others like domain forwarding.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Only a general directive to 'use this endpoint to add new contact information' is given. No guidance on when to prefer this over other methods, no prerequisites, and no mention of alternatives like update or 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?
No annotations are provided, so the description carries full burden. It only states the tool creates a store and a sales channel. It does not disclose side effects such as whether the store is immediately active, any charges incurred, or what happens if a custom sales channel is invalid. Missing important behavioral traits 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two sentences that convey the core purpose. However, the second sentence about the sales channel could be integrated more smoothly. Overall, minimal waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, no annotations, and the presence of sibling tools like ecommerce_createCustomSalesChannelV1, the description lacks context about the store creation process, expected response, and implications. It does not provide enough information 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?
The input schema has 100% description coverage, so baseline is 3. The description adds no additional meaning to the parameters; for example, the 'name' parameter is only described as 'name parameter' in the schema. The description does not enhance understanding beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates a store for the account, and adds that a primary sales channel is created alongside. This distinguishes it from other store-related tools like ecommerce_getStoresV1 and ecommerce_deleteStoreV1. However, it could be more explicit about how it differs from ecommerce_createCustomSalesChannelV1, which creates a sales channel independently.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps 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 explicit guidance on when to use this tool versus alternatives. It does not mention prerequisites, when not to use it, or provide context for using the sales channel parameter. The implied usage is for creating a new store, but with no required parameters, the tool's purpose is broad.
Agents often have multiple tools that could apply. Explicit usage guidance like "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 should fully disclose behavior, but it only states 'retrieve'. It omits details like pagination (the 'page' parameter hints but not explained), rate limits, or whether it returns all stores or a list with metadata.
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 brief sentence, which is efficient and front-loaded. However, it could be slightly longer to add useful context without losing 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 list tool, the description is minimal. There is no output schema, so the agent lacks information about the response structure (e.g., fields of a store). Pagination behavior is implied but not explained. The description does not fully equip the agent 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 coverage for the only parameter 'page' is 100% with a description, so baseline is 3. The description adds no extra meaning beyond what the schema provides, so no bonus.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'retrieve' and resource 'stores', making the purpose explicit. It distinguishes from sibling tools like ecommerce_getStoreMetadataV1 which targets metadata, not stores themselves.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives (e.g., ecommerce_listSalesChannelsV1 for sales channels). No mention of prerequisites or context, leaving the agent to infer 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, the description carries the full burden. It states 'uploads all plugin files and triggers plugin deployment' but doesn't disclose whether it overwrites existing plugins, deactivates the plugin, or handles conflicts. No side effects or requirements are mentioned.
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?
Two short sentences with no extraneous information. 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?
For a deployment tool with 3 parameters and no output schema or annotations, the description lacks details on success conditions, error handling, or any behavioral outcomes. It is insufficient for complete understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with all parameters described. The description adds minimal value beyond the schema, only confirming 'directory' context for pluginPath. 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 'Deploy a WordPress plugin from a directory' and the resource 'hosting server'. However, it does not differentiate from sibling tools like hosting_installWordPressPluginsV1 or hosting_activateWordPressPluginV1, which have similar purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives (e.g., hosting_installWordPressPluginsV1 for plugins from the repository). There are no prerequisites 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 full burden. It only states the immediate effect (messages no longer delivered) but omits other behavioral traits such as whether the action is reversible, required permissions, or impact on existing deliveries. This is insufficient 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise (two short sentences) and front-loaded with the action. However, it could include more context without being verbose, so it's not a perfect 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?
For a simple delete tool with one parameter and no output schema, the description covers the action and effect adequately. However, it lacks details like permissions, irreversibility, or error states, 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 coverage is 100% with the parameter 'aliasId' described as 'Alias resource ID'. The description adds no additional 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.
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 ('alias'), and mentions the consequence (messages no longer delivered). The name and siblings make it easy to distinguish from create/list/update 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 on when to use this tool or conditions for use. There is no mention of prerequisites, reversibility, or alternatives. Despite the obvious purpose, a user might benefit from knowing, e.g., 'use this to remove an alias that 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?
Without annotations, the description carries the full burden. It mentions double opt-in behavior but does not disclose other important aspects like permission requirements, idempotency, or error handling 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 concise at three sentences, front-loading the purpose. It is structured logically but could be improved with clearer separation of conditions.
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 6 parameters and no output schema, the description is incomplete. It does not explain the purpose of 'profileUuid', return values, or differentiate from the sibling tool, leaving gaps 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 coverage is 100%, so each parameter has a basic description. The description lists some fields but does not add significant meaning beyond the schema; 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 creates a new contact in the email marketing system, with specific verbs and resource. However, it does not differentiate from the sibling tool 'reach_createANewContactV1', which appears to have the same 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?
The description provides no guidance on when to use this tool versus alternatives, such as the sibling tool or other contact-related tools. It only describes basic functionality 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?
No annotations provided, so description carries full burden. It implies read-only behavior but does not state it explicitly. No mention of pagination limits or other behavioral traits like rate limits.
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?
Two sentences, concise and front-loaded. Efficiently communicates purpose, though could add more context without being 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?
For a simple list endpoint with one optional parameter and no output schema, the description is mostly adequate. However, it lacks information about return format and pagination, which limits 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 has 100% coverage with one parameter 'page' described as 'Page number'. Description adds no additional meaning beyond what's in the schema, so 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?
Description clearly states it retrieves post-install scripts associated with the account, using specific verb 'Retrieve' and resource 'post-install scripts'. It distinguishes from siblings like VPS_createPostInstallScriptV1 and VPS_getPostInstallScriptV1, but could be more explicit about listing multiple scripts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps 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. Does not mention pagination or how to use the page parameter effectively. Implied usage only.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It reveals that setup may fail and manual intervention is needed, and that default payment method is used if none provided. However, it does not disclose the nature of the operation (e.g., financial transaction), required authentication, response format, or rate limits. The provided info is adequate but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is structured in three paragraphs with front-loaded purpose. However, the last sentence ('Use this endpoint to create new VPS instances') is somewhat redundant with the first sentence. Some sentences could be combined, making it slightly longer than necessary but still readable.
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 4 parameters and no output schema, the description covers key aspects: action, failure handling, payment fallback. However, it omits how to obtain item_id (catalog), what the setup parameter accepts, and what the response contains. Sibling tools exist for catalog lookup, but the description does not reference them, leaving gaps in completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% but parameter descriptions are minimal: 'setup parameter' is a meaningless placeholder. The description adds value for payment_method_id (default behavior) but fails to clarify the 'setup' parameter's purpose, format, or required values. Thus the description does not sufficiently compensate for the schema's vagueness, scoring below 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 clearly states the tool purchases and sets up a new virtual machine, with the phrase 'Use this endpoint to create new VPS instances.' This distinguishes it from siblings like VPS_getVirtualMachinesV1 (list) and VPS_setupPurchasedVirtualMachineV1 (post-purchase setup). However, it does not explicitly differentiate between purchase and setup actions, which could cause confusion with the setup 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 some context like fallback if setup fails and default payment behavior, but lacks explicit guidance on when to use this tool versus alternatives. No comparison to VPS_setupPurchasedVirtualMachineV1 or billing tools is given, leaving the agent to infer usage without clear exclusions or when-not-to-use 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?
Without annotations, the description carries the full burden. It implies a write operation but fails to disclose side effects (e.g., downtime, data loss), required VM state, or whether the snapshot must exist. The description is too high-level.
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 three short paragraphs with some redundancy (e.g., 'restore' mentioned multiple times). It is not excessively long but could be more 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 tool with one required parameter and no output schema, the description covers basic purpose but omits return values, error conditions, and prerequisites. 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% with a description for virtualMachineId. The tool description adds no additional meaning beyond what the schema provides, so 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 it restores a VM to a previous state using a snapshot and lists use cases like system recovery and testing. However, it does not explicitly differentiate from sibling tool VPS_restoreBackupV1, which restores from backup rather than 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?
No guidance is provided on when to use this tool vs alternatives like VPS_restoreBackupV1. The description lacks usage 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?
No annotations provided, and description fails to disclose what 'status' entails (e.g., enabled/disabled, caching stats) or any prerequisites (e.g., Memcached configured).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, front-loads the purpose, no unnecessary 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?
No output schema or description of return value, leaving agents unsure what data they will receive for a status check.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but description only adds context for 'software' parameter; 'username' remains unexplained. Also, description mentions 'in the path' but schema shows it as a body parameter, causing inconsistency.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it shows the Memcached object cache status for a WordPress installation. Siblings like hosting_toggleMemcachedObjectCacheV1 imply a different action, but no explicit differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides guidance on how to obtain the software identifier from another endpoint, but does not specify when to use this tool versus alternatives like hosting_toggleMemcachedObjectCacheV1.
Agents often have multiple tools that could apply. Explicit usage guidance like "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 that the result is 'a paginated list' but does not disclose default pagination behavior, limits, ordering, or authentication requirements beyond the implied 'accessible to the authenticated client'.
Agents need to know what a tool does to the world before calling it. Descriptions 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-formed sentence that conveys the core purpose without any unnecessary words. It is efficiently structured and 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?
For a simple list tool with two optional parameters and no output schema, the description meets the minimum viable standard. However, it lacks details on result sorting, filtering options, and what constitutes an 'order', which could be beneficial 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 coverage is 100% with clear descriptions ('Page number', 'Number of items per page'). The description does not add additional 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 verb 'returns' and the resource 'Agency Plan orders', and the word 'paginated' indicates the result format. It distinguishes from sibling tools like 'hosting_listOrdersV1' by specifying 'Agency Plan orders', though it does not explicitly contrast with that 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 'hosting_listOrdersV1' or other agency-hosting list tools. There are no prerequisites 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?
No annotations are provided, so the description must convey behavioral traits. It only states the operation is 'disable auto-renewal', implying a mutation, but fails to disclose side effects, reversibility, or any restrictions. This is insufficient 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 consists of two sentences, but the second sentence is redundant and adds no value. It could be more concise by removing the duplicate phrase.
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 toggle operation with one required parameter and no output schema, the description is minimally complete. However, it lacks usage guidance and behavioral context, leaving gaps for the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with one parameter 'subscriptionId' described as 'Subscription ID'. The description adds no additional meaning beyond that, meeting the baseline for high 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 'Disable' and the resource 'auto-renewal for a subscription', distinguishing it from the sibling tool billing_enableAutoRenewalV1. The purpose is immediately apparent.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps 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 says 'Use this endpoint when disable auto-renewal for a subscription', which is a tautology and provides no guidance on when to use this versus alternatives like billing_enableAutoRenewalV1. No prerequisites or conditions 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?
No annotations provided. Description doesn't disclose behavioral traits like destructive nature, what happens to existing records, or how parameters like sync affect execution. Important context missing.
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?
Two sentences, front-loaded with purpose. No unnecessary words, but could benefit from a list or additional context 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?
Lacks explanation of parameter effects (sync, reset_email_records, whitelisted_record_types) and doesn't describe return values or success criteria. Inadequate for a 4-parameter tool with no annotations or 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?
Input schema has 100% coverage with descriptions for all 4 parameters. Description doesn't add extra meaning beyond the schema, meeting 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?
Description clearly states resetting DNS zone to default records and restoring original configuration. Distinguishes from sibling tools like DNS_deleteDNSRecordsV1 or DNS_updateDNSRecordsV1.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps 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. Doesn't mention prerequisites, limitations, or context for resetting compared to other DNS operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully convey behavioral traits. It only says it checks for WooCommerce installation, but does not disclose the return format, side effects (read-only), authentication needs, or scope (all domains vs filtered). This leaves the agent with significant uncertainty.
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 wasted words. It is concise and front-loaded. However, it could be slightly more informative without exceeding efficient 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?
Given the simplicity of the tool (one optional parameter, no output schema), the description is incomplete. It does not specify the return value (e.g., boolean, list of installation details) or behavior when no domain is provided. This leaves gaps for the agent to infer.
Complex tools with many parameters or behaviors need more documentation. Simple tools 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 optional parameter 'domain,' which is already described as 'Filter by domain name (exact match).' The description adds minimal value by restating 'optionally filter by domain.' This meets the baseline but does not enrich 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 'Check' and the resource 'whether WooCommerce is installed on any WordPress installation of a domain.' It is specific and distinguishes from sibling tools like listInstalledWordPressPluginsV1 which list all plugins, not a specific check.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps 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 vs alternatives, such as listInstalledWordPressPluginsV1 or searchWordPressPluginsV1. It only states what it does, with no when-not-to-use or comparison 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 provided; description only states action without disclosing behavioral traits like permissions needed, confirmation of change, 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?
Single sentence is concise and front-loaded, but could be slightly longer to include context without significant bloat.
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 simple task, the description is minimal; it omits any mention of return values or side effects, and the lack of output schema is not compensated.
Complex tools with many parameters or behaviors need more documentation. Simple tools 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 already explain both parameters thoroughly (100% coverage); the tool description adds no additional meaning beyond what is in 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?
Description uses a specific verb 'Change' and resource 'mailbox password', clearly distinguishing it from sibling tools like mail_createMailboxV1 or mail_deleteMailboxV1.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps 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 (e.g., mailbox must exist) or any 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 burden. It only states the basic behavior (listing all profiles) but does not disclose any potential limitations, pagination, or side effects. For a simple read-only list, this is minimal but 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, concise sentence that directly conveys the tool's purpose without any 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 description lacks information about return value structure (e.g., array of objects with fields), pagination, or any constraints. Given the absence of an output schema and annotations, more detail would help the agent understand what to expect.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters in the input schema, so the description does not need to add parameter-level information. The schema coverage is 100%, so no additional semantics are required.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it returns all profiles with basic information, and the verb 'returns' and resource 'profiles' are specific. While it does not explicitly differentiate from sibling reach tools like contacts or segments, the name and description make the purpose 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 alternatives (e.g., reach_listContactsV1). There is no mention of prerequisites or 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 discloses that the tool returns a paginated list and specifies the content of each entry (schedule expression and command). Since no annotations are provided, the description adequately covers the read-only nature and basic behavior, but omits any details about rate limits or authorization.
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 concise with two sentences, front-loading the main purpose. No unnecessary words, though the second sentence could arguably be merged.
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?
Without an output schema, the description partially compensates by noting the content of each entry. However, it lacks details on other potential fields (e.g., status, next run) and does not mention pagination parameters explicitly. 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?
Schema coverage is 100% (all parameters described). The description mentions pagination but does not add significant meaning beyond the schema. 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 it returns a paginated list of cron jobs for an Agency Plan website. It distinguishes itself from generic tools by specifying 'Agency Plan website', though it does not explicitly differentiate from similar sibling tools like hosting_listAccountCronJobsV1.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. There are sibling tools for listing cron jobs at different scopes (e.g., hosting_listAccountCronJobsV1), but no explicit direction 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?
The description discloses response codes (200 for success, 422 for error), but without annotations, it fails to explicitly state that the tool does not modify DNS records. Behavioral traits like authentication or side effects are omitted, which is a gap for a validation 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 concise with three sentences: purpose, response codes, and usage. It is front-loaded with the core function. No unnecessary repetition, though it could be slightly more 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?
Given no output schema, the description covers return codes but omits details on what constitutes a validation success beyond the code, and lacks information on error structure. Adequate for a simple validation tool but could be more 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?
With 100% schema description coverage, the baseline is 3. The description adds no extra parameter details beyond what the schema provides; it only mentions 'domain' and 'zone' in context but not with additional semantics 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 clearly states the tool validates DNS records before update, using verb 'validate' and resource 'DNS records' for a specific domain. It distinguishes from sibling tools like DNS_updateDNSRecordsV1 by emphasizing pre-update validation, but does not explicitly differentiate from other validation 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 advises using the tool 'to verify DNS record validity before applying changes', which is clear usage context. However, it does not explicitly mention when not to use it or suggest alternatives, such as using DNS_updateDNSRecordsV1 after successful validation.
Agents often have multiple tools that could apply. Explicit usage guidance like "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 should disclose behavioral traits. It only states 'Retrieve' implying a read operation, but does not mention read-only nature, authentication requirements, rate limits, or whether the operation is non-destructive. The description is minimal.
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 concise with two sentences, but the second sentence is somewhat redundant with the first. It is front-loaded with the 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?
Given the tool's simplicity (one optional param, no output schema), the description is fairly complete. However, it does not mention if the list is paginated or what fields are returned, which could be useful for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with one parameter (tld) described. The description does not add any extra meaning beyond the schema, so it adds no value. 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 retrieves WHOIS contact profiles and is used to view available profiles for domain registration. However, it does not explicitly differentiate from siblings like domains_getWHOISProfileV1 which retrieves a single profile.
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 tells when to use the tool (to view available profiles for domain registration) but does not mention when not to use it or provide alternatives among sibling tools, such as using domains_getWHOISProfileV1 for a specific profile.
Agents often have multiple tools that could apply. Explicit usage guidance like "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 implies read-only via 'Retrieve' and 'view', but does not explicitly state safety, authentication needs, or 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 two sentences, but the second is largely redundant. It is concise yet could be merged for better front-loading.
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 get-by-ID tool with one parameter and no output schema, the description is minimally adequate. Lacks details like return format or parameter format, but works for basic use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with the parameter 'whoisId' described as 'WHOIS ID'. The description adds no additional 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 'Retrieve a WHOIS contact profile' and 'view domain registration contact information', specifying the verb and resource. It distinguishes from siblings like list or create/delete tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like domains_getWHOISProfileListV1. It only says 'Use this endpoint to view...' without exclusions or 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 explains the tool checks validity and detects issues, implying a read-only operation. It mentions the `force` parameter for fresh validation, but does not disclose potential side effects, rate limits, or auth requirements. Without annotations, the description carries the burden, but it is moderately 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 sentences: the first states the purpose and detects issues, the second explains how to get the identifiers. It is concise, front-loaded, and contains no unnecessary 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 no output schema, the description should explain what the tool returns (e.g., validation results). It does not mention return values or error handling. It also does not elaborate on the `force` or `username` parameters, leaving gaps in understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds context that `software_ids` can be obtained from another endpoint, but does not add significant meaning beyond the schema. The `force` and `username` parameters are not elaborated.
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 whether...are valid and working correctly') and the resource ('WordPress installations'). It specifies what it detects ('broken installations caused by missing files, broken plugins, themes'). However, it does not explicitly distinguish from sibling tools like hosting_listWordPressInstallationsV1 or hosting_detectWordPressInstallationsV1.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides guidance on how to obtain the required `software_ids` from another endpoint, which is helpful, but it does not specify when to use this tool versus alternatives, nor does it mention 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?
No annotations are provided, so the description bears full responsibility for behavioral disclosure. It only states that the tool lists plugins; it does not explicitly confirm it is a read-only operation, nor does it explain what 'recommended' means or any permission requirements. The verb 'list' implies read-only, but the description 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two sentences. The first sentence states the core purpose, and the second provides a usage hint. No extraneous information is included, making it 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?
Given no output schema, the description does not mention what the response contains (e.g., plugin names, versions). It also lacks details on filtering or pagination. For a simple listing tool, it is adequate but misses opportunities to fully inform the agent about the response format.
Complex tools with many parameters or behaviors need more documentation. Simple tools 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 descriptions for both parameters, with 100% coverage. The description adds value by explaining how to obtain the 'software' identifier from another API endpoint. However, it does not elaborate on the 'username' parameter, whose schema description is unhelpful ('username parameter'). Thus, the description partially compensates but not 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 clearly states the tool lists 'plugins recommended for installation that are not yet installed'. It uses a specific verb 'list' and identifies the resource. However, it lacks explicit differentiation from similar siblings like 'hosting_listSuggestedWordPressPluginsV1', which may have overlapping functionality.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a concrete instruction on providing the software identifier and how to obtain it from another endpoint. It does not, however, specify when to use this tool versus alternatives like 'hosting_listInstalledWordPressPluginsV1' or 'hosting_listSuggestedWordPressPluginsV1', nor does it mention 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?
No annotations are provided, and the description does not disclose behavioral traits such as being read-only, permissions needed, or rate limits. The verb 'Get' implies a safe read operation, but explicit disclosure is missing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with two short sentences (20 words), no redundancy, and front-loaded 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 description is adequate for a simple list tool with no parameters, but it could mention the response format (e.g., array of group objects) since there is no output schema. Otherwise, it covers the basic purpose.
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 100%. The description does not need to add parameter info. Baseline 4 applies as per guidelines.
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 all contact groups, with specific verb 'Get' and resource 'contact groups'. It is distinct from sibling tools like reach_listContactsV1 which list contacts rather than groups, though it doesn't explicitly differentiate 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?
The description provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites, filtering, or use cases. For a read-only list tool, this is a 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 provided, the description must convey all behavioral traits. It mentions the constraint of one active firewall but does not disclose side effects (e.g., does activation overwrite an existing active firewall? Does it require specific permissions?). For a mutation endpoint, this is insufficient 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 three sentences long, with the first sentence stating purpose, the second adding a critical constraint, and the third essentially repeating the purpose. It is concise and front-loaded, though the third sentence could be merged. 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?
Given the tool's simplicity (2 parameters, no output schema), the description covers the core action and a key constraint. However, it lacks information on what happens if a firewall is already active or prerequisites (e.g., firewall and VM must exist). The description is adequate but has 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?
Both parameters (firewallId, virtualMachineId) are described in the input schema with clear, if minimal, descriptions ('Firewall ID', 'Virtual Machine ID'). The description adds no additional meaning beyond the schema, and schema coverage is 100%. Thus 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?
Description clearly states 'Activate a firewall for a specified virtual machine' with verb and resource. It also notes the constraint that only one firewall can be active at a time, providing context. However, it does not explicitly differentiate from sibling tools like VPS_deactivateFirewallV1 or VPS_syncFirewallV1, but the purpose is 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 includes a key guideline: 'Only one firewall can be active for a virtual machine at a time,' which implies behavior when activating. However, it does not provide explicit when-to-use or when-not-to-use guidance, nor does it mention alternatives like VPS_deactivateFirewallV1. This leaves the agent to infer usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It only says 'Create a new firewall' without stating whether creation is idempotent, if there are limits on number of firewalls, or what happens if a firewall with the same name exists. 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences are brief but could be improved by adding more detail without excessive verbosity. The current structure is adequate but not optimally informative.
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 creation tool with one parameter and no output schema, the description covers the basic purpose. However, it lacks context on what the created firewall looks like, how to interact with it later, or any prerequisites (e.g., existing VPS). It is minimally complete.
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 only parameter 'name' is described in the schema as 'name parameter', and the tool description adds no additional meaning. It does not clarify naming conventions, uniqueness constraints, or character limits, thus failing to add 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 clearly states 'Create a new firewall' which is a specific verb and resource. It distinguishes itself from sibling firewall tools like VPS_createFirewallRule and VPS_deleteFirewall by focusing on creating the firewall itself, not 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 description says 'Use this endpoint to set up new firewall configurations for VPS security' but does not specify when to prefer this over other firewall tools (e.g., VPS_activateFirewallV1). No excluded contexts or alternatives 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?
No annotations are provided, so the description carries the full burden for behavioral disclosure. It states 'Create or update' indicating a mutation, but does not detail additional behaviors like idempotency, whether updates overwrite or merge, required permissions, or rate limits. More transparency is needed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with two sentences that are front-loaded with the action and purpose. No extraneous information; every sentence 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?
Given no output schema and no annotations, the description should provide more context about the tool's behavior, such as success/error responses, or whether the call is idempotent. It mentions 'Create or update' but does not explain the update behavior or what happens on duplicate. The tool is a mutation with no output schema, so the description is incomplete without return value information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description does not add any additional meaning beyond the parameter names and schema descriptions. It does not explain the format of the domain parameter or any constraints 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 (create or update a PTR record) and the resource (specified virtual machine). It also mentions the purpose (configure reverse DNS lookup). However, it does not distinguish from sibling tools like VPS_deletePTRRecordV1.
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 explicit context for use ('configure reverse DNS lookup for VPS IP addresses'), which implies when to use the tool. But it offers no guidance on when not to use it or alternatives, such as when to delete a PTR record versus create/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 bears full responsibility. It only states the action but does not disclose potential side effects (downtime, reversibility), required website state, or success criteria.
Agents need to know what a tool does to the world before 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, no extraneous words, front-loaded with the main action. Highly 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?
Tool is simple with 2 params and no output schema. Description adequately covers the core purpose but lacks behavioral context that would fully inform an agent (e.g., is this a write action? what happens if version is invalid?).
Complex tools with many parameters or behaviors need more documentation. Simple tools 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 description adds no additional meaning beyond the schema's parameter descriptions. 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?
Description clearly states the verb 'Changes' and the resource 'WordPress core version on an Agency Plan website'. The 'Agency Plan' qualifier distinguishes it from sibling tool hosting_updateWordPressCoreV1 for regular hosting.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like hosting_updateWordPressCoreV1. No prerequisites or conditions 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 must disclose all behavioral traits. It explains the effect of overwrite=true (replace) vs. false (update/add), but omits other important details such as result validation, idempotency, sync/async behavior, or required permissions.
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 three sentences, front-loaded with purpose and key behavior. It is concise with no unnecessary repetition, though the final sentence could be considered redundant.
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?
Missing output schema and the description does not mention what the tool returns (e.g., success confirmation, updated records, errors). For a mutation tool, return behavior is important context that 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%, so the description adds minimal value beyond the schema. The overwrite parameter's behavior is elaborated, but other parameters like zone and domain are not further explained. 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 'Update DNS records for the selected domain' and explains the overwrite behavior, distinguishing it from other DNS mutation tools like delete or reset. However, it could be more explicit about the exact scope of modification compared to 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 provides context by stating 'Use this endpoint to modify domain DNS configuration' and explains the overwrite flag's effect. However, it lacks explicit when-to-use vs. alternatives like reset or delete, and does not mention prerequisites like domain ownership.
Agents often have multiple tools that could apply. Explicit usage guidance like "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 only says 'retrieve', implying read-only. It does not disclose required permissions, error behavior, or any side effects, leaving significant gaps for a tool that interacts with domain transfers.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the action and a usage note. No wasted words, very 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?
Given no output schema, the description could detail what fields are returned (e.g., status, dates). It is adequate but not exhaustive for a retrieval tool with a single parameter.
Complex tools with many parameters or behaviors need more documentation. Simple tools 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% as the 'domain' parameter is described as 'Domain name'. The description adds no extra meaning beyond what the schema provides, typical for baseline scoring.
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 it retrieves a transfer for a specified domain, using the verb 'retrieve' and resource 'transfer'. It implies singularity but does not explicitly differentiate from sibling 'domains_getTransferListV1'.
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 advises using it to track an incoming or outgoing transfer status, providing clear context. However, it omits when not to use it, such as for listing transfers or alternatives like 'domains_getTransferListV1'.
Agents often have multiple tools that could apply. Explicit usage guidance like "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 only says 'update existing redirect configuration.' It omits details on idempotency, error handling, or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, clear and direct, with no redundant or irrelevant 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?
Adequate for a simple update tool with three params and no output schema, but lacks behavioral context 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 coverage is 100% with descriptions for all parameters; the description does not add extra parameter details beyond the schema, justifying 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 clearly states it updates domain forwarding configuration, using 'Update' and 'modify existing redirect configuration.' It distinguishes from create/delete siblings in name, but does not explicitly differentiate in text.
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 existing configurations but does not specify when not to use it (e.g., for new forwards) or mention 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 disclose behavioral traits. It only states the action without describing side effects (e.g., whether it overwrites existing settings), required permissions, or return value. The description is too minimal for full 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 of 18 words, front-loaded with the verb and resource, and free of extraneous information. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with two parameters, the description covers the basic purpose, but lacks usage guidelines and behavioral context. Without an output schema, the agent might not know what to expect. 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?
Both parameters are described in the schema (100% coverage). The description adds no additional meaning beyond the schema, so it doesn't improve parameter understanding. 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 ('Enable') and the resource ('manual payment method'), and explains the purpose ('so the store can accept orders without an online payment provider'). It distinguishes itself from sibling tools, as no other sibling has 'manual payment' in its 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 does not provide any guidance on when to use this tool versus alternatives, nor does it mention prerequisites or conditions. For example, it doesn't indicate whether the store must exist or if this tool is for initial setup or re-enabling.
Agents often have multiple tools that could apply. Explicit usage guidance like "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, so description carries full burden. Only states it creates and returns uid. Lacks details on side effects, error cases, permissions, or validation.
Agents need to know what a tool does to the world before 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 waste. Front-loaded with purpose, then key output 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?
Covers core functionality and output, but missing context about username, error handling, and integration with related cron tools. 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?
Schema coverage is 100% but username description is vague. Description adds minimal parameter context beyond schema. Baseline 3 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?
Clearly states the action (create), resource (cron job for account), and inputs (schedule expression, command). Distinguishes from sibling tools like delete, list, get 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 on when to use this tool versus alternatives, prerequisites, or context. Does not mention related tools like delete or listing.
Agents often have multiple tools that could apply. Explicit usage guidance like "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 provided, so the description must carry the full burden. It indicates a destructive operation (delete) but does not disclose any side effects, permissions, or impact on related resources. This is a significant gap 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 extremely concise with two sentences, front-loaded with the action and purpose. 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?
For a simple delete operation with 3 parameters and no output schema, the description covers the basic purpose and usage. However, it lacks details on error handling, success/failure signals, or what happens to related resources. It is minimally 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. The tool description does not add any additional meaning beyond what the schema already provides. 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 (delete) and the resource (subdomain from a selected website). It implicitly distinguishes from siblings like create or list by specifying deletion. However, it could be more precise about how the website is identified.
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 a basic usage reason ('remove subdomains that are no longer needed') but lacks explicit guidance on when not to use, prerequisites, or alternatives. Compared to siblings, it's clear this is for deletion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It only states the mutation action without disclosing side effects (e.g., service restart, downtime), permissions, or idempotency. More behavioral details would be beneficial 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two sentences, each contributing value: action statement and usage tip. It is front-loaded but lacks a clear structure; however, it avoids waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, no annotations, and three required parameters, the description is minimal. It omits outcomes, prerequisites (e.g., website ownership), and error conditions, making it less complete for safe invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers all three parameters with descriptions. The description adds cross-tool guidance for the version parameter but does not enhance schema-provided meaning beyond that. 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 it changes the PHP version of a website, specifying the resource and action. It distinguishes itself from sibling tools like hosting_getPHPDetailsV1 or hosting_updatePHPOptionsV1, which serve different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description advises checking available versions via the Get PHP details endpoint, providing a helpful prerequisite step. However, it lacks explicit guidance on when not to use this tool or alternatives, leaving the agent to infer usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 that the webhook secret is never included, a critical behavior. However, it omits details on authentication, error handling, or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise, two sentences, no wasted words. Information is front-loaded and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequate for a simple retrieval tool with one parameter, but lacks mention of return format, error conditions, or when to choose this over sibling tools. Slightly incomplete given the large sibling set.
Complex tools with many parameters or behaviors need more documentation. Simple tools 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 clear description for webhookId. The description does not add extra meaning beyond the schema; 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 it retrieves details of a single webhook, using a specific verb and resource. It implies differentiation from list/create/delete/update webhook tools, though not 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 on when to use this tool versus alternatives like listWebhooks, createWebhook, etc. The description describes what it does but fails to advise on selection among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must fully disclose behavior. It only mentions pagination, but omits key details like required permissions, error handling for invalid orderId, or whether results include alias details like target addresses. A basic read operation is implied, but the lack of behavioral context is a 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?
Single sentence that is front-loaded with the key action 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?
No output schema exists, but description does not describe return format or fields (e.g., alias list, pagination metadata). Given the tool's simplicity, it is minimally adequate but incomplete for agents expecting structured response details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for all 3 parameters. The description adds 'paginated' context for page and per_page, but does not provide additional meaning beyond schema for orderId or the pagination parameters. 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?
Description clearly states the action (retrieve) and resource (paginated list of aliases across all mailboxes of a mail order), distinguishing it from sibling tools like mail_createAliasV1 or mail_deleteAliasV1.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps 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 such as mail_listMailboxesV1 or when pagination should be configured. The description only states what it does.
Agents often have multiple tools that could apply. Explicit usage guidance like "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 it retrieves firewalls, omitting pagination behavior implied by the optional 'page' parameter, and does not mention any side effects or limitations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with two short sentences, front-loading the action and resource. Every sentence is informative 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?
For a simple listing tool with one optional parameter and no output schema, the description is functional but incomplete. It does not explain pagination or the return format, which an agent would need for proper 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 'page' parameter described. The description adds no extra meaning beyond the schema, achieving the baseline. No additional parameter context is provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves all available firewalls, identifying the resource and action. However, it does not distinguish from sibling tool VPS_getFirewallDetailsV1, which retrieves details of a specific firewall, leaving ambiguity which to use for listing vs. 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 says 'Use this endpoint to view existing firewall configurations,' providing basic usage context. It lacks explicit guidance on when not to use (e.g., for detailed info) or alternatives like VPS_getFirewallDetailsV1.
Agents often have multiple tools that could apply. Explicit usage guidance like "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 behavioral burden. It implies a read operation ('Retrieve historical metrics') but does not explicitly state whether it is safe, idempotent, or has any side effects. No mention of authorization requirements or rate limits.
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 two short paragraphs, front-loading the purpose and then listing metrics. It is efficient but could be trimmed further; the second sentence of the first paragraph is redundant with the list. Still, it is concise overall.
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 is provided, and the description does not describe the response format (e.g., time series, units, granularity). For a metrics retrieval tool, this is a significant gap. The description also fails to explain data range or time zone expectations for the date 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 covers all three parameters with basic descriptions. The tool description does not add significant meaning beyond listing the metrics returned, which is indirectly helpful but does not clarify parameter formats (e.g., date format) or constraints. With 100% schema coverage, baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves historical metrics for a specified VM and lists the specific metrics (CPU, memory, disk, network, uptime). This verb+resource combination is specific and distinct from sibling tools like VPS_getScanMetricsV1.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes 'Use this endpoint to monitor VPS performance and resource utilization over time,' which provides a clear usage context. However, it does not mention when not to use this tool or suggest alternatives among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It states creation of database+user but omits what the response looks like, idempotency, limits, or association with the website_uid parameter. 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?
Two sentences directly state the action and a key requirement. No fluff, front-loaded with the main purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a create tool with 4 required params, no output schema, and many sibling tools, the description is inadequate. It does not explain the return value, the association with the website_uid, or any error conditions. The caller is left guessing about success indicators.
Complex tools with many parameters or behaviors need more documentation. Simple tools 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 descriptions. The description adds no new meaning beyond restating that database name, username, password must be provided, which is already clear from 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 it creates a MySQL database with a dedicated user for an Agency Plan website, which is specific and distinguishes from sibling tools like createAgencyPlanWebsiteDatabaseUserV1 (user-only) or delete versions.
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?
Description implies usage for creating a database+user pair but does not provide explicit when-to-use guidance or alternatives (e.g., the separate user creation tool). Siblings exist but no differentiation mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It only states it 'lists' versions, implying read-only, but fails to clarify side effects, permissions, or response behavior. 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, clear sentence with no redundancy. It is appropriately sized for a simple listing tool with one parameter.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with one parameter and no output schema, the description covers the main purpose and scope. However, it does not hint at the return format or any prerequisites (e.g., website must be Agency Plan), leaving minor 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%, and the description adds no extra meaning beyond the schema's parameter description for 'website_uid'. Baseline for high coverage is 3; no additional value is provided.
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 WordPress core versions available for installation on an Agency Plan website, using a specific verb-resource pair. This distinguishes it from sibling tools like hosting_listAvailableWordPressCoreUpdatesV1 and hosting_listWordPressInstallationsV1.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps 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_listAvailableWordPressCoreUpdatesV1 for updates or hosting_listWordPressInstallationsV1 for installed versions). 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?
No annotations provided. Description only states it creates/configures forwarding; lacks disclosure of side effects, idempotency, or permissions needed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded and efficient. Could be slightly more compact but no waste.
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?
Adequate for a simple creation tool, but lacks preconditions, error states, or return value info. No output schema exists to fill 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 covers 100% of parameters with descriptions. Description adds no extra meaning beyond the schema, so baseline score 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?
Clearly states it creates domain forwarding configurations for redirecting domains to other URLs. Distinct from sibling tools like get/delete forwarding.
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?
Implied usage for setting up redirects, but no explicit when-to-use or alternatives. No guidance on prerequisites like domain ownership.
Agents often have multiple tools that could apply. Explicit usage guidance like "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 briefly mentions 'published' but does not explain immediate effects, return values, permissions, or whether the operation is idempotent. Lacks depth 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?
Single sentence, no fluff. Front-loaded with key purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a creation tool with 6 parameters and no output schema, the description is too brief. It does not explain return values, error handling, or post-creation state, leaving gaps for the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so parameters are well-described in the schema. The description adds minimal extra meaning, only noting the optional download link, which is already captured.
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 creates a published digital product, distinguishing it from sibling tools like ecommerce_createPhysicalProductV1. It includes specific details about single variant and optional download link.
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?
Implies usage for digital products but does not explicitly guide when to use this over alternatives like createPhysicalProductV1. No 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?
No annotations provided, so description must fully disclose behavior. Only states it lists active channels with metadata, but omits return format, pagination, filtering, or any side effects. For a read operation, minimal risk but still lacking 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?
Single sentence, no fluff, efficiently conveys purpose. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one param, no output schema), the description is fairly complete. It covers what it does and the key constraint (active channels). Lacks explicit return structure, but 'full metadata' implies comprehensive info.
Complex tools with many parameters or behaviors need more documentation. Simple tools 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 store_id already documented. Description adds no extra meaning beyond the schema, merely restating 'store's active sales channels'. 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?
Clearly states the action (list), resource (sales channels), and scope (a store's active channels with full metadata). Distinguishes from sibling ecommerce tools like createCustomSalesChannel and updateSalesChannel.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps 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, prerequisites, or context. Does not mention when not to use 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 fully disclose behavior. It mentions creation (mutation) but does not detail permissions, side effects, idempotency, or 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 two sentences, front-loaded with the main purpose and concise in conveying optional inputs 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?
Without an output schema or annotations, the description lacks return value details and constraints (e.g., subdomain format, conflict behavior), making it incomplete for a tool with 5 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 coverage is 100%, so the baseline is 3. The description adds context about optional directory choices but does not elaborate on individual parameters beyond what the schema 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 verb 'Create' and the resource 'subdomain for the selected website', distinguishing it from related siblings like hosting_createWebsiteParkedDomainV1 and hosting_deleteWebsiteSubdomainV1.
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 context on what input to provide (subdomain prefix, optional directory), but does not explicitly specify when to use this tool vs alternatives or when not to use 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 provided. Description mentions 'optional file and database removal' but input schema lacks any parameter to control this option, creating ambiguity. It does clarify that all associated data is removed, but behavioral inconsistency lowers 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?
Two sentences: first states purpose and scope, second provides key usage hint. No redundancy; all information 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?
Covers deletion scope and identifier source, but lacks return value details and error conditions. No output schema, so description should indicate what to expect (e.g., success confirmation).
Complex tools with many parameters or behaviors need more documentation. Simple tools 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 100% of parameters. Description adds value by explaining the 'software' parameter is an identifier and how to obtain it, but the 'username' parameter remains generic ('username parameter') with no additional context.
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 deletes a WordPress installation and lists removed components (plugins, themes, staging). It distinguishes from sibling tools like 'uninstallWordPressPlugins' by mentioning full removal, but lacks explicit contrast.
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?
Provides guidance on obtaining the installation identifier via GET endpoint, but no direction on when to use this vs alternatives, prerequisites, or handling dependencies.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully cover behavioral traits. It discloses that it uploads files and triggers deployment, with optional activation. However, it omits key details like overwrite behavior, required permissions, what happens if the slug already exists, and error 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 two sentences with no extraneous content. It front-loads the primary purpose and follows with key detail about optional activation. Every sentence is informative and concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (4 parameters, no output schema, no annotations), the description is incomplete. It does not explain what the return value is, whether files are overwritten, if the directory must be accessible from the server, or any prerequisites like the website must exist. Leaves many unknowns 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% coverage with clear parameter descriptions. The description does not add any extra meaning beyond the schema. 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 deploys a WordPress theme from a directory to a hosting server, using specific verb 'deploy' and resource 'WordPress theme'. It distinguishes from siblings like hosting_installWordPressThemeV1 (likely installs from repo) and hosting_activateWordPressThemeV1 (activates an already installed theme) by focusing on uploading files from a local directory.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide explicit guidance on when to use this tool versus alternatives like hosting_installWordPressThemeV1. It does not state prerequisites, exclusions, or when not to use it. The usage context is implied but not clarified for an AI 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 provided; description only states it returns a paginated list. Does not disclose side effects, authorization requirements, rate limits, or pagination details beyond the 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?
One sentence, no wasted words. Action verb and key information are 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 pagination, the description is adequate. No output schema exists, but the return value (list of forwarders) is implied. Could mention it returns forwarder objects, but not 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?
Schema coverage is 100% with basic parameter descriptions. Description adds context that forwarders are across all mailboxes of an order, but does not add syntax or format details beyond 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?
Description specifies the verb 'retrieve', the resource 'forwarders', and the scope 'across all mailboxes of a mail order'. Clearly distinguishes from sibling mail tools like mail_createForwarderV1 and mail_deleteForwarderV1.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps 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 other mail list tools or forwarder management tools. Does not mention when not to use it or provide 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 full burden. It discloses that results are paginated, sorted by timestamp descending, and supports date range and event type filters. However, it does not mention rate limits, authentication needs, default pagination sizes, or output structure, which are gaps for a mutation-free retrieval 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 concise with four sentences, each contributing distinct information: purpose, constraint, filters, and sorting. It is front-loaded with the primary action and avoids redundancy. Minor room for improvement by structuring with bullet points, but it is effective.
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 8 parameters, no output schema, and no annotations, the description covers core aspects but omits details about the return format (e.g., fields in each log entry) and pagination mechanics beyond 'paginated'. It is sufficient for basic understanding but could be more complete for an agent to use without additional inference.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds context by grouping filters (date range, event type) and reinforcing the domain constraint, but does not provide new semantic details beyond what the schema already states. It is adequate but not exceptional.
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 retrieves paginated mailbox action logs for a mailbox in a given mail order, specifying the verb 'Retrieve', the resource 'mailbox action logs', and the scope (mail order, domain constraint). This distinguishes it from sibling tools like mail_listAccessLogsV1 or mail_listInboundLogsV1, 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?
While the description indicates the tool is for mailbox-specific action logs, it does not explicitly guide when to use this tool over alternatives. It lacks guidance on when not to use it or references to sibling tools for different log types, leaving the agent to infer usage context 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It mentions pagination and filtering by mailbox, implying read-only behavior, but does not explicitly state it's non-destructive or discuss behavior for invalid orderId, rate limits, or response structure beyond the mentioned fields.
Agents need to know what a tool does to the world before 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 redundancy. All information is front-loaded and relevant, earning each word's 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?
Given no output schema and many sibling tools, the description covers pagination, filtering, and key fields but lacks details on the exact response structure, error handling, or how to interpret the logs. It is adequate but not comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for all 4 parameters. The description adds context: 'paginated' for page/per_page, 'for the given mail order' for orderId, and 'filtering by mailbox' for mailbox_id, enhancing the schema's 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 clearly states the tool retrieves a paginated list of webhook delivery logs for a mail order, mentioning key fields (delivery outcome, duration, retry counts). This distinguishes it from other mail list tools like mail_listAccessLogsV1 or mail_listWebhooksV1, though not explicitly contrasting 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 on when to use this tool versus alternatives. With many sibling tools for logs and webhooks, the description lacks directions on when to prefer this over, e.g., mail_listInboundLogsV1 or mail_listWebhooksV1.
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?
Discloses the double opt-in behavioral trait (pending status and confirmation email), but no annotations are provided to cover safety or permissions. Does not mention idempotency, data overwrite, or authentication needs.
Agents need to know what a tool does to the world before 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, no wasted words. The first sentence states the purpose, the second lists typical parameters, and the third adds an important conditional behavior. Efficient and focused.
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?
Covers the creation process and double opt-in effect, but lacks details on return value (no output schema), required permissions, and behavior if contact already exists. For a tool with 5 parameters and no annotations, more completeness would be beneficial.
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?
Adds context beyond the schema by describing parameters as 'basic information like name, email, and surname' and notes the impact of double opt-in on the creation process. Schema descriptions are minimal, so this adds 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?
Clearly states the action 'Create a new contact' and the system 'email marketing system'. It distinguishes from siblings by the explicit singular 'a new contact', but does not explicitly differentiate from the bulk create sibling 'reach_createNewContactsV1'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps 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 the bulk creation sibling or other contact tools. Does not mention prerequisites or scenarios where this endpoint 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 must disclose behavioral traits. It does not mention that the operation is read-only, safe, or idempotent, nor does it describe error states, rate limits, or other side effects. The tool's behavior is assumed 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 concise, consisting of two sentences that front-load the purpose. Every word adds value, and there is no redundant or extraneous 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?
The tool has no output schema and the description does not explain what the response contains, nor does it provide any contextual details about the domain (e.g., reach/email marketing). Important behavioral details such as pagination handling are omitted, 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?
Schema coverage is 100%, so the baseline is 3. The description adds no additional parameter-level meaning beyond what is in the schema; it merely restates the role of the UUIDs. No extra context on pagination or constraints is provided.
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 retrieves contacts associated with a specific segment for a given profile, using specific verbs and resource identification. It distinguishes from siblings like reach_listContactsV1 and reach_listSegmentsV1 by specifying the segment and profile scoping.
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 (segment contacts) but does not explicitly state when to use this tool over alternatives like reach_listContactsV1 or reach_getSegmentDetailsV1, nor does it provide exclusion criteria or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden for behavioral disclosure. It only states that it 'retrieves a list', with no information about authentication requirements, side effects, rate limits, or whether it returns data for the current user or all domains. The description does not go 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 sentence of 8 words, concise and front-loaded with the verb 'Retrieve'. Every word is necessary; 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?
Given the tool has no parameters, no output schema, and no annotations, the description is minimal. While it conveys the core purpose, it lacks information about the scope of the list (e.g., current user, account-wide), pagination, response format, or authentication prerequisites. For a simple retrieval tool without output schema, more context would be helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema is empty (no parameters), so schema coverage is 100%. For zero-parameter tools, the baseline is 4. The description does not attempt to explain parameters since none exist, which 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 retrieves a list of pending and completed domain verifications. The verb 'Retrieve' and resource 'domain verifications' are specific, and the tool name includes 'getDomainVerifications' which aligns. Although sibling tools exist for DNS validation and domain ownership verification, this tool's focus on 'domain verifications' (likely a specific concept from the API) distinguishes it adequately.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps 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 simply states what it does without mentioning any context, prerequisites, or exclusions. The sibling list includes related tools like 'DNS_validateDNSRecordsV1' and 'hosting_verifyDomainOwnershipV1', but no comparison is made.
Agents often have multiple tools that could apply. Explicit usage guidance like "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 provided; description only states 'remove', failing to disclose side effects like permanent data loss, requirements for VM state, or confirmation steps.
Agents need to know what a tool does to the world before 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, no redundant information, front-loaded with 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?
No output schema and minimal description; lacks details on response format, error handling, or preconditions 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 coverage is 100% for the single parameter; description adds no extra meaning beyond the schema's 'Virtual Machine ID', meeting 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 clearly states the action ('Delete') and resource ('snapshot of a specified virtual machine'), distinguishing it from siblings like VPS_createSnapshotV1 and VPS_restoreSnapshotV1.
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?
Implies use for deleting VPS snapshots, but provides no guidance on when not to use (e.g., prerequisites, dependencies) or alternatives among 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?
No annotations are provided, yet the description lacks details on potential side effects, permissions required, or whether the installation is synchronous or async, leaving important behavioral aspects unclear.
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 efficiently structured with only a few sentences, though the link and general explanation of Monarx add some useful context without being overly 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?
For a simple install tool with one parameter and no output schema, the description is adequate but could be improved by mentioning prerequisites, return values, or error states.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with one parameter (virtualMachineId) described as 'Virtual Machine ID'. The description adds no extra meaning beyond what the schema provides, so it meets the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool installs 'Monarx malware scanner on a specified virtual machine', using a specific verb and resource, and distinguishes it from sibling VPS_uninstallMonarxV1.
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 mentions 'Use this endpoint to enable malware protection on VPS instances', which implies when to use, but does not explicitly state when not to use or compare to alternatives like VPS_uninstallMonarxV1.
Agents often have multiple tools that could apply. Explicit usage guidance like "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 states a delete operation but lacks details on consequences (e.g., irreversibility, impact on associated data). For a mutation tool, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, no redundant information, and the main action is front-loaded. Every word is meaningful.
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 parameter and no output schema, the description is adequate but could include details on idempotency or error 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?
The input schema covers the single parameter with a description. The description adds no additional meaning 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.
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 'payment method from your account.' It also specifies 'remove unused payment methods from user accounts,' which distinguishes it from other billing tools like get or set default.
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 advises to use for removing unused payment methods, implying not for currently used ones, but it does not explicitly discuss when not to use or mention alternatives among 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 must fully disclose behavioral traits. It mentions syncing capabilities but omits important details such as idempotency, uniqueness constraints, required permissions, or what happens upon creation (e.g., whether it modifies existing channels). The description is too sparse to provide adequate behavioral transparency 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with only two sentences. The first sentence clearly states the tool's main function, and the second sentence provides context on the benefit (syncing). There is no redundant or extraneous information, and it is front-loaded with the primary 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?
Given the tool has no output schema and no annotations, the description should cover key aspects like return format, prerequisites (store must exist), error handling, and the fact that only 'custom' type is allowed. The current description covers the core use case but lacks these details, making it adequate but not fully complete for a creation 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% coverage with descriptions for all 4 parameters. The description adds little beyond the schema, only reinforcing the purpose (e.g., 'url' as 'optional public address'). Since schema coverage is high, the baseline score of 3 is appropriate; the description does not introduce new 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 tool creates a custom sales channel for a store, using the specific verb 'Create' and the resource 'custom sales channel'. It distinguishes from sibling tools like ecommerce_updateSalesChannelV1 and ecommerce_listSalesChannelsV1 by focusing on creation and the ability to build your own frontend, 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 when building a custom frontend and syncing catalog/orders/shipping/payments, but it does not explicitly state when not to use this tool or mention alternatives like ecommerce_updateSalesChannelV1 for modifications. Guidance is implicit rather than 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?
The description discloses the side effect of creating a shipping zone, but does not mention idempotency, prerequisites, or whether the operation updates an existing price. With no annotations, this is partial 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?
Single sentence that is clear, direct, and contains no extraneous information. Well-structured and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description does not mention the output or return value, which is lacking for a tool without an output schema. It covers the basic behavior but misses what the agent can expect after calling.
Complex tools with many parameters or behaviors need more documentation. Simple tools 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 schema already defines both parameters. The description adds no additional meaning beyond stating the price is for shipping and the zone creation implicitly involves the store_id.
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') and the resource ('flat-rate shipping price for a store'), and also notes the creation of a shipping zone if needed. This sufficiently distinguishes the tool from sibling ecommerce 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 explicit guidance on when to use this tool vs alternatives or what prerequisites exist. The description only states what it does, not when it should be used.
Agents often have multiple tools that could apply. Explicit usage guidance like "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 full responsibility. It mentions creation and delivery but omits behavioral traits such as idempotency, error conditions, permission requirements, or side effects. This leaves significant gaps in understanding the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loads the purpose, and contains no extraneous information. Every sentence adds value, achieving high 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?
The description covers the core behavior but lacks details on return values (no output schema), required permissions, or potential error scenarios. For a simple create tool, it is somewhat complete but not fully sufficient given the absence of annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools 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 both parameters have descriptions. The description adds context by stating that the alias address is formed from the local part and the mailbox's domain, reinforcing the relationship. This adds moderate value beyond the schema, meeting the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Create' with the resource 'alias for the given mailbox'. It explains how the alias address is formed from the local part and mailbox domain, and the delivery behavior. This distinguishes it from sibling tools like mail_deleteAliasV1 or mail_listAliasesV1.
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 does not explicitly state when to use this tool versus alternatives or provide any exclusions. While the purpose is clear, there is no guidance on prerequisites like mailbox existence or duplicate handling. Implicit usage is adequate but not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description only covers basic function. Does not disclose behaviors such as duplicates, order existence requirement, or password validation beyond schema description, which is insufficient 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?
Two concise sentences with no wasted words. Front-loaded with action and follows with key composition 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?
Complete for a simple creation tool but lacks return value description or side effects. No output schema, so agent lacks context on expected result.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers all parameters with descriptions. Description adds context that domain comes from the order, but overall adds little beyond schema. Baseline 3 applies due to 100% 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?
Description clearly states 'Create a mailbox' and explains the address composition from local part and domain, distinguishing it from sibling tools like alias, forwarder, and catch-all creation.
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 like mail_createAliasV1 or mail_createCatchAllV1. Implies usage for new mailboxes but lacks prerequisites or 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?
Discloses that the secret is returned only in this response and is sent as bearer token. With no annotations, this adds useful behavioral context, but does not cover other important aspects like idempotency, rate limits, or error states.
Agents need to know what a tool does to the world before 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, no unnecessary words. Front-loaded with purpose. 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?
Adequate for a creation tool with no output schema. Mentions secret handling, but lacks details on defaults (e.g., status) or what happens after creation. Could be more 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%, so baseline 3. Description adds no additional meaning to parameters (url, name, events, etc.) beyond their schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the action (Create) and resource (webhook for a given mailbox). It distinguishes from sibling webhook tools (list, get, delete, update, test, regenerate secret) by focusing on creation and secret generation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like mail_updateWebhookV1 or mail_testWebhookV1. Does not state prerequisites or context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions pagination, sorting by timestamp descending, and filtering options, but does not disclose authorization needs, rate limits, or what happens on invalid input.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the core purpose. Every word is informative; 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?
With 10 parameters and no output schema, the description is adequate but lacks details on response format, pagination mechanics (e.g., total count), or how the logs are structured. It covers the basics but is not fully 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?
Schema coverage is 100%, so baseline is 3. The description adds a high-level grouping of filters (e.g., 'date range' for from_date/to_date) but does not provide additional syntax or 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 clearly states the verb 'Retrieve' and the specific resource 'access logs' for a domain attached to a mail order. It distinguishes from sibling log tools like mail_listActionLogsV1 by naming the exact log type, but does not explicitly differentiate.
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 lists supported filters (account, date range, protocol, status, deletion flag), implying use cases. However, it does not provide when-not-to-use guidance or compare with sibling log 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 carry the full behavioral disclosure. It only states 'retrieve' implying a read operation, but fails to mention what happens with invalid orderId, rate limits, pagination behavior, or any side effects. This is insufficient for an agent to understand the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the action and resource. It contains no unnecessary words and is easily parsable.
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 paginated list tool with no output schema and no annotations, the description is minimal. It does not specify default pagination values, the structure of return items, or error conditions. While adequate at a high level, it leaves gaps for an agent to safely 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?
The input schema has 100% description coverage, with each parameter having a basic description (page, orderId, per_page). The tool 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'retrieve' and the resource 'autoreplies' with the scope 'across all mailboxes of a mail order.' It also indicates pagination, which distinguishes it from sibling tools like mail_createAutoreplyV1 or mail_deleteAutoreplyV1.
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 listing autoreplies but does not provide explicit guidance on when to use this tool versus alternatives, nor does it mention prerequisites like requiring a valid orderId. No when-not-to-use 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries full burden. It discloses it reports actual and suggested records, implying read-only operation, but lacks details on permissions, rate limits, or idempotency.
Agents need to know what a tool does to the world before 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: first states the action, second provides details. No extraneous information, well-structured for quick agent comprehension.
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?
Covers key aspects: what it retrieves, which record types, and the distinction between actual and suggested records. Lacks description of return format, but for a simple retrieval tool without output schema, this is fairly 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 description adds meaningful context to the single parameter 'profileUuid' by linking it to 'profile's domain', enhancing understanding beyond the schema's generic description. Schema coverage is 100%, but the extra context justifies a score above baseline.
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 DNS configuration status for a profile's domain, listing specific record types (MX, SPF, DKIM, DMARC). This distinguishes it from sibling DNS management tools that handle general 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 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 like DNS_getDNSRecordsV1 or DNS_validateDNSRecordsV1. The usage context is implied (email delivery check), but no exclusions or comparisons are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states that it retrieves tags and provides conceptual background, but gives no details about return format, ordering, error behavior, or side effects. For a read-only listing tool, this is a noticeable 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 extremely concise: a single lead sentence stating the purpose followed by one sentence providing helpful context about tags. No redundant information, front-loaded with the main action, and every sentence 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?
Given the simplicity of the tool (1 parameter, no output schema), the description is functional but incomplete. It explains what tags are and that they can be used for filtering or segments, but does not mention what data is returned (e.g., tag IDs, names) or any prerequisite like profile existence. This is adequate but could be more informative.
Complex tools with many parameters or behaviors need more documentation. Simple tools 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% (profileUuid has a description 'Profile uuid parameter'), so the baseline is 3. The description does not add any parameter-specific meaning beyond what the schema already provides, merely referencing profiles without elaborating on the parameter's 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 'Get all tags defined in a profile' with a specific verb and resource. The second sentence explains what tags are and their role in grouping contacts and building segments, which helps distinguish this from sibling tools like reach_listContactGroupsV1 or reach_listSegmentsV1.
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 by explaining tags' purpose in Reach (grouping contacts, filtering, building segments), but it does not explicitly state when to choose this over alternatives or mention exclusions. There is no direct 'when to use' guidance, but the context is helpful enough for a basic decision.
Agents often have multiple tools that could apply. Explicit usage guidance like "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 provided, and the description only says 'Deactivate' without disclosing side effects, prerequisites, or reversibility, which is insufficient for full 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?
Two concise sentences with no wasted words, efficiently conveying 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?
Adequate for a simple two-parameter tool, but could be improved by noting prerequisites or state dependencies (e.g., firewall must be active).
Complex tools with many parameters or behaviors need more documentation. Simple tools 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 self-explanatory parameter names and descriptions; the description adds no additional meaning 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 a specific verb 'Deactivate' and resource 'firewall for a specified virtual machine', clearly distinguishing it from sibling tools like VPS_activateFirewallV1 and VPS_syncFirewallV1.
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?
It states to use for removing firewall protection from VPS instances, providing clear context but lacks explicit when-not-to-use or comparison with alternatives like deleting the firewall.
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 key behaviors (boot from recovery disk, mount original disk at /mnt) but omits side effects like VM restart/downtime, that recovery mode must be stopped explicitly, or any response format. With no annotations, the burden is higher.
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 well-structured: main action first, then explanation, then details, then usage directive. It is concise without unnecessary words, though could be slightly tighter.
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 crucial context: no output schema meaning the agent doesn't know what the response is (e.g., action ID, success status), no mention of async nature or how to monitor progress, and no prerequisites such as VM being stopped. Incomplete for a potentially long-running operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with adequate parameter descriptions. The tool description does not add extra semantic value beyond what the schema already provides, so 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 initiates recovery mode for a VM, explains what recovery mode is for, and distinguishes it from other VPS management tools like VPS_stopRecoveryModeV1. The action is specific and well-contextualized.
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 says 'Use this endpoint to enable system rescue operations,' providing a use case but lacking explicit when-not-to-use guidance or alternatives. It does not mention prerequisites like VM state or potential conflicts with other 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 the tool syncs (applies) the firewall to the VM and explains the reason for desync. However, it does not mention any side effects, prerequisites, or behavior in edge cases. Since no annotations exist, the description carries the full burden but falls short of full 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 three sentences long, each serving a purpose: stating the action, explaining the context, and providing guidance. It is front-loaded and concise 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?
For a simple two-parameter tool with no output schema, the description covers basic functionality adequately. However, it lacks information about return values, error handling, or prerequisites (e.g., firewall and VM state), leaving some 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 already provides descriptions for both parameters ('Firewall ID' and 'Virtual Machine ID'). The description does not add any additional meaning or constraints, so it meets the baseline for 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 clearly states the verb 'sync' and the resources 'firewall' and 'virtual machine'. It explains the purpose: applying updated firewall rules to VPS instances. However, it does not explicitly distinguish this tool from sibling tools like VPS_createFirewallRuleV1 or VPS_activateFirewallV1, which have different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives context on when to use the tool ('when firewall rules have been updated and need to be applied'), but it does not specify when not to use it or provide alternative tools for similar tasks.
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 indicates a read operation without destructive effects, but does not disclose auth requirements, rate limits, or other behavioral traits. The description 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?
A single, front-loaded sentence that efficiently communicates the tool's purpose without extraneous information. Every part is valuable.
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?
Although there is no output schema, the description lists the categories of information returned (configuration, status, metadata, etc.), providing a good overview. For a simple read tool with one parameter, this is fairly 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 covers the parameter fully (100% description coverage), and the description adds no additional meaning beyond what is in the schema. 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 that it retrieves detailed information about a specific Agency Plan website, listing the types of details (configuration, status, metadata, etc.), which distinguishes it from sibling tools like getSetupStatus or listRunningProcesses.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps 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 when-to-use or when-not-to-use guidance is provided. The description does not differentiate this tool from other information retrieval tools in the same namespace, nor does it mention 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?
No annotations are provided, so the description bears full responsibility for behavioral disclosure. It states the outcome ('serve traffic') but does not explain what operations occur (e.g., DNS changes, verification steps, or reversibility). This leaves significant gaps for an agent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, well-structured sentence conveys the entire purpose without unnecessary 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 simple linking tool with full schema coverage, the description covers the core action and purpose. However, it lacks details on behavioral traits and usage context, which would elevate completeness further.
Complex tools with many parameters or behaviors need more documentation. Simple tools 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 parameter descriptions already present (domain and website_uid). The tool description adds no extra semantic value beyond restating the schema, so 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 ('Links') and resource ('domain to Agency Plan website') and clearly states the purpose ('so it can serve traffic for that domain'). It distinguishes this from sibling tools like unlink or change domain.
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 linking a domain but does not provide explicit guidance on when to use this vs alternatives (e.g., changeDomain, unlinkDomain) or any prerequisites (e.g., domain ownership, DNS setup). No 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?
No annotations are provided, and the description only states 'Set' and 'configure' without disclosing side effects (e.g., overwriting previous default), reversibility, or required preconditions (e.g., existence of payment method).
Agents need to know what a tool does to the world before calling it. Descriptions 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 with two sentences, front-loaded with the primary action, and contains 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?
For a simple mutation with one parameter and no output schema, the description is mostly sufficient but could mention a confirmation or return value. However, it covers the essential purpose and usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds no extra meaning beyond the schema's 'Payment method ID' for the paymentMethodId 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 clearly states the action ('set the default payment method'), the resource ('payment method for your account'), and distinguishes from sibling tools like billing_deletePaymentMethodV1 and billing_getPaymentMethodListV1.
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 context ('for your account', 'for future orders') but lacks explicit guidance on when to use vs. alternatives, such as prerequisites or when-not-to-use 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?
No annotations provided, so description must disclose behavioral traits. It reveals it's a read operation ('Retrieve') but lacks details on permissions, rate limits, or side effects. Minimal 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?
Two concise sentences, front-loaded with the action. Every sentence adds value, no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read operation with two well-described parameters and no output schema, the description is complete enough to guide use. Mentions historical 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 coverage is 100% with clear parameter descriptions. Description adds 'particular DNS snapshot' but does not significantly enhance meaning beyond the schema. 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?
Description uses specific verb 'Retrieve' and resource 'particular DNS snapshot with contents of DNS zone records', clearly distinguishing from sibling tools like DNS_getDNSSnapshotListV1 (list) and DNS_restoreDNSSnapshotV1 (restore).
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?
Description states 'Use this endpoint to view historical DNS configurations for domains,' implying usage context, but does not explicitly mention when not to use or compare to alternatives like getDNSSnapshotListV1.
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 behaviors like default payment method, default WHOIS information, and TLD-specific validation. However, it omits critical behavioral traits: it is a financial transaction that incurs cost, it may be irreversible, there is no mention of asynchronous processing or error states, and the response format is not described.
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 paragraph but contains repetition: 'Purchase and register a new domain name' and 'Use this endpoint to register new domains' say the same thing. It also includes a troubleshooting instruction ('login to hPanel') that could be a separate note. While not overly long, it could be more concise 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 complexity of a domain purchase operation (financial, multi-parameter, dependencies), the description is incomplete. It does not specify what the agent should expect as a return value (no output schema), does not address fund sufficiency, does not mention if the operation is synchronous or asynchronous, and lacks information about cancellation or rollback. The prerequisites are partially covered but significant gaps remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for all parameters. The description adds value beyond the schema by explaining defaults (e.g., payment_method_id default, domain_contacts default) and that additional_details may be validated. This extra context helps the agent understand parameter behavior, going beyond 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 tool's purpose: 'Purchase and register a new domain name' and 'Use this endpoint to register new domains for users.' It uses a specific verb and resource, and it distinguishes itself from sibling tools like domains_checkDomainAvailabilityV1 and domains_createWHOISProfileV1.
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 implicit usage context, such as ensuring WHOIS information exists and that some TLDs require additional_details. However, it does not explicitly state when to use this tool versus alternatives, nor does it mention prerequisites like checking domain availability or having sufficient funds. It gives fallback instructions but lacks clear guidance on 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?
Without annotations, the description carries the full burden. It reveals the product is published and single variant, but omits behavioral traits like side effects (e.g., inventory impact), authentication needs, or error conditions. Moderate transparency with notable gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, 14-word sentence that is front-loaded and contains no superfluous information. Every word earns its place, and the structure prioritizes the key action and attributes.
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 information about the return value (e.g., product ID), error handling, or invocation context. Given no output schema and moderate complexity, it is incomplete and leaves important 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?
Schema coverage is 100% with clear parameter descriptions. The description adds context (published, single variant, store currency) but does not significantly enhance parameter meaning beyond the schema. 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 creates a published physical product with a single variant priced in store currency. It uses a specific verb ('Create') and resource ('physical product'), distinguishing it from siblings like 'ecommerce_createDigitalProductV1'.
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 physical products but does not explicitly state when to avoid it or mention alternative tools. No guidance on prerequisites or exclusions is provided, making it adequate but lacking explicit when/when-not 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?
Without annotations, the description carries the full burden. It states the tool creates a parked domain, but does not disclose behavioral traits such as required domain ownership, idempotency, limits, or side effects. This is insufficient 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 very concise with two sentences, no redundant information, and front-loaded with the main 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 create tool with three parameters and no output schema, the description provides sufficient context about the operation. However, it could mention return behavior or success indicators 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 coverage is 100%, so baseline is 3. The description adds value by clarifying that parked_domain can be a domain name or IP address, but does not explain the 'domain' parameter (parent domain) or 'username' beyond the schema's minimal descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'Create' and the resource 'parked or alias domain for the selected website'. It distinguishes from sibling tools like hosting_deleteWebsiteParkedDomainV1 and hosting_listWebsiteParkedDomainsV1 by focusing on creation.
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 explains the purpose but does not provide guidance on when to use this tool versus alternatives (e.g., domains_createDomainForwardingV1 or other domain-related tools). 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It states the action is 'purge' (destructive), but gives no additional behavioral context (e.g., impact on performance, reversibility). This is 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the action, no redundant words. However, could be even more concise by omitting the parameter retrieval sentence if the schema already describes it.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations or output schema, the description covers purpose and parameter source but lacks information about expected outcomes, side effects, or post-purging behavior. It is functional 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?
Schema coverage is 100%, so baseline is 3. The description adds value for 'software' parameter by explaining its source, but 'username' remains unelaborated. Overall, limited added meaning beyond 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 'Purge' and the resource 'LiteSpeed Cache' for a WordPress installation, using a specific verb and resource. It distinguishes itself from sibling tools like hosting_clearWebsiteCacheV1 and hosting_showLiteSpeedCacheStatusV1.
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 guidance on obtaining the WordPress installation ID from another API (GET /api/hosting/v1/wordpress/installations), but does not explicitly state when not to use this tool or name alternatives like hosting_clearWebsiteCacheV1.
Agents often have multiple tools that could apply. Explicit usage guidance like "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 full burden. It only states it searches the directory, not mentioning that it is a read-only operation, authentication requirements, rate limits, or what happens if no results are found. This leaves behavioral traits 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?
Two sentences, no wasted words. First sentence defines purpose, second gives actionable follow-up. Extremely 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 search tool with one parameter and no output schema, the description is mostly complete. It explains the search domain and how to use the result. However, it lacks detail about return format or pagination, and behavioral transparency is missing, lowering completeness slightly.
Complex tools with many parameters or behaviors need more documentation. Simple tools 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 'search' parameter described as a string with a minimum length of 3 characters. The description does not add additional meaning beyond the schema, 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 tool searches the WordPress.org plugin directory for available plugins. It specifies the action and resource, distinguishing it from sibling tools like listAvailableWordPressPlugins which list already known plugins, and install 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 provides some usage guidance by mentioning that returned slugs should be used with the install endpoint, but it does not explicitly state when to use this tool versus alternatives like listing already installed plugins or available ones. The context implies search is for installing new plugins, but lacks explicit when-not-to-use 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?
The description explains the behavioral outcome (messages no longer routed) but lacks details on prerequisites, error states, idempotency, or required permissions. Since no annotations exist, the description carries the full burden but 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?
Two concise sentences: first states the action, second explains the consequence. No wasted words. Front-loaded with the verb-delete.
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 simplicity (1 param, no output schema), the description is mostly complete. It explains the effect but could mention that the catch-all must exist. Missing error handling or return value info.
Complex tools with many parameters or behaviors need more documentation. Simple tools 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, so baseline is 3. The description does not add any additional meaning beyond the schema's 'Catch-all resource ID'. No extra context provided.
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 a catch-all') and the effect ('Messages sent to unknown addresses... are no longer routed'). It distinguishes from siblings (create, list, resend) 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use (when you want to stop routing unknown addresses) but does not explicitly state when not to use or mention alternatives. No comparison with sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses that the mailbox is soft-deleted and restorable for a limited period, which is beyond a simple 'delete'. However, it does not mention permissions, side effects on related resources, or error 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 two sentences, front-loaded with the action, and contains no filler. Every word adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity (1 parameter, no output schema, no nested objects), the description is sufficiently complete. It explains the action and the soft-delete behavior. Minor missing details about error handling or restoration period length, but not 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?
Schema coverage is 100% (parameters are described in the schema). The description adds no extra meaning to the mailboxId parameter beyond the schema's 'Mailbox resource ID'. 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 'Delete a mailbox' using a specific verb and resource. It also adds context about soft-deletion and restoration period, distinguishing it from other mail tools like mail_createMailboxV1 or mail_listMailboxesV1.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps 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, nor does it mention prerequisites or when not to use it. The agent must infer usage from the action 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; description omits details about pagination, result format, or any constraints beyond 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?
Two concise sentences, front-loaded purpose, 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?
Schema is complete; description covers basic purpose but lacks pagination/return format; adequate for a simple list 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 covers 100% parameters; description adds no extra meaning beyond schema fields.
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 retrieves backups for a specified virtual machine, distinct from restore operations like VPS_restoreBackupV1.
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?
Implied use case for viewing backup points before recovery, but no explicit when-to-use or alternatives 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 provided, so the description carries the burden. It discloses that the tool returns detailed container information including status, port mappings, and runtime configuration, but does not mention authentication requirements, rate limits, or any side effects. The operation appears to be a safe read, so no contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions 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 with three sentences: purpose, return details, and usage advice. Every sentence adds value, and the structure is front-loaded with the primary function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description adequately covers the return data. It could mention error scenarios or prerequisites (e.g., project must exist), but for a simple listing tool, it is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the description does not add any meaning beyond what the schema already provides (e.g., 'virtualMachineId' and 'projectName'). The description restates schema concepts without additional clarification.
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 a list of containers for a specific Docker Compose project. It uses the specific verb 'Retrieves' and resource 'containers', distinguishing it from other project tools like VPS_getProjectContentsV1, though not explicitly.
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 a use case ('monitor health and state of all services') but does not specify when not to use this tool or mention alternatives among siblings, such as VPS_getProjectLogsV1 or VPS_getProjectContentsV1.
Agents often have multiple tools that could apply. Explicit usage guidance like "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 does not mention side effects, authentication requirements, rate limits, or behavior on invalid templateId. It only states the retrieval nature.
Agents need to know what a tool does to the world before calling it. Descriptions 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 with two sentences, front-loading the action and purpose. No superfluous 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 retrieval tool with one parameter and no output schema, the description adequately explains purpose and usage context. However, it does not describe what the response contains, which would be helpful given the lack of 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 describes templateId as a required integer. The description adds context that the template is 'OS template for virtual machines', but does not improve parameter understanding beyond the schema. With 100% schema coverage, 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 'Retrieve detailed information' and the resource 'specific OS template'. It differentiates from the sibling tool VPS_getTemplatesV1, which likely lists all templates, by focusing on a specific template.
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 context for usage ('before deployment') but does not explicitly specify when to use this tool versus alternatives like VPS_getTemplatesV1 or when not to use 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 provided, so description must disclose behavioral traits. It states 'setup' and 'initialize' but does not explain side effects, prerequisites, or whether it resets the VM. The term 'initial state' is vague and not elaborated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with purpose, no unnecessary words. Highly concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 11 parameters and no output schema or annotations, the description is too minimal. It lacks detail on initialization process, expected outcomes, and how it differs from sibling tools like VPS_recreateVirtualMachineV1.
Complex tools with many parameters or behaviors need more documentation. Simple tools 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 baseline is 3. The description adds no additional meaning beyond the schema; it only restates the general 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 tool sets up a newly purchased virtual machine with 'initial' state, using specific verbs and resource. It distinguishes from purchase and other management tools by emphasizing 'newly purchased' and 'initial'.
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 indicates usage after purchase ('newly purchased') but does not explicitly list when to avoid or mention alternatives. It provides clear context but lacks 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?
With no annotations provided, the description must fully disclose behavior. It states the tool returns settings (a read operation), but does not mention side effects, authentication requirements, rate limits, or whether the data is live or cached. The description is adequate but lacks detailed behavioral context beyond the listed items.
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 efficiently lists the returned settings, with no wasted words. It is front-loaded and direct. However, it could be more structured (e.g., using a bulleted list) to improve readability, but it is not verbose.
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 has low complexity (one parameter, no output schema). The description covers the tool's purpose and the items returned. However, it lacks details on the return format (e.g., data types) and does not clarify that this is specific to Agency Plan websites (though implied by the name). Siblings that return individual settings also hint at alternative granularity. Overall, mostly complete but with minor 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 one parameter 'website_uid' with a clear description. The tool description adds no additional meaning beyond the schema, and since schema coverage is 100%, the description adds no value for parameter semantics. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns current WordPress settings and lists four specific items (core version, LiteSpeed Cache plugin status, object cache status, maintenance mode status). It distinguishes from siblings that return individual settings (e.g., hosting_showWordPressCoreVersion) by being a consolidated 'get all' tool.
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 getting a summary of key WordPress settings, but provides no explicit guidance on when to use this versus calling individual getter tools. There is no mention of alternatives or when not to use it, leaving the agent to infer usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries the burden. It mentions pagination and inclusion of non-system users, which provides some transparency. However, it does not disclose behavior for invalid website_uid, rate limits, or that the operation is read-only (implicit from 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 very concise with two sentences. The first sentence clearly states the primary function, and the second adds a key detail. 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?
Given no output schema, the description provides a starting point (paginated list, includes non-system users). However, it lacks details on other fields returned for each database entry, which would help an agent understand the complete response. It is 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?
Schema coverage is 100% with all parameters described in the schema. The description adds no additional meaning beyond the schema; it only restates that the list is paginated. Baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: returning a paginated list of MySQL databases for an Agency Plan website, with a specific detail about including non-system users. It distinguishes from sibling tools like create/delete database 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 listing databases for an agency plan website, but lacks explicit guidance on when to use this tool versus other similar list tools (e.g., hosting_listAccountDatabasesV1) or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility. It explains the fields (ID, type, status) and suggests polling behavior, but omits details about pagination, rate limits, response format, or error conditions. The transparency is adequate but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two short paragraphs, front-loaded with the core purpose in the first sentence, followed by supporting details and usage guidance. Every sentence adds value 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?
For a simple list tool with one parameter and no output schema, the description covers the basics (what is listed, key fields, usage scenario). However, it lacks details about the return structure (e.g., is it an array? any additional fields?), which is a gap given 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 has one parameter (website_uid) with 100% description coverage via the schema's own description 'Agency Plan website UID'. The description adds no additional meaning for this parameter, so 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 lists 'active and recently completed asynchronous processes' for an Agency Plan website, specifying the verb 'lists', the resource 'processes', and the scope. It does not explicitly differentiate from sibling tools like getAgencyPlanWebsiteSetupStatus, but the purpose is clear and specific.
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 tells agents to 'Poll this endpoint after initiating async operations (SSL setup, backups, cloning) to track progress.' This provides clear guidance on when to use the tool, though it does not mention alternatives or exclusion 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 must disclose behavioral traits. It only states 'delete' and 'remove', implying destruction, but does not detail consequences (e.g., irreversibility, permission requirements, or impact on domain). This is insufficient for a mutation without 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 very concise with two sentences, front-loaded with the main action. 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 simple delete tool with one parameter and no output schema, the description is adequate but lacks behavioral context (e.g., irreversible, limited to forwarding only). It covers the core functionality but misses completeness on 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 one parameter 'domain' described as 'Domain name', and coverage is 100%. The description adds no additional 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 'Delete domain forwarding data' and 'remove redirect configuration from domains', specifying the verb (delete) and resource (forwarding data/redirect configuration). It distinguishes from sibling tools like domains_createDomainForwardingV1 and domains_getDomainForwardingV1.
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 says 'Use this endpoint to remove redirect configuration from domains', which indicates when to use it. It does not explicitly mention when not to use or alternatives, but the context among siblings (create, get) makes it 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?
With no annotations provided, the description must fully disclose behavioral traits. It notes that profiles should be 'unused', but it does not describe consequences of deleting a used profile, whether deletion is reversible, or any prerequisites (e.g., ownership). This is insufficient 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long and contains only essential information. No redundant or filler text.
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 param, no output schema), the description provides the basic purpose and usage hint. However, it lacks details on how to determine if a profile is unused, what happens after deletion, and error handling, which would help an agent 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 already describes the single parameter 'whoisId' as 'WHOIS ID'. The tool description adds no additional meaning beyond that. Since schema description coverage is 100%, 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 tool's action: 'Delete WHOIS contact profile.' It uses a specific verb (Delete) and resource (WHOIS contact profile), and it is distinct from sibling tools like create, get, list, and usage tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description indicates when to use the tool: 'Use this endpoint to remove unused contact profiles from account.' This provides clear context, but it does not specify when not to use it or mention alternatives, which is acceptable given the tool's specificity.
Agents often have multiple tools that could apply. Explicit usage guidance like "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 provided; description mentions 'permanently deletes' but lacks details on side effects, authorization, or what happens if the cron job is running. More behavioral context needed 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?
Two efficient sentences with key information front-loaded. 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?
Basic delete operation described, but missing success/error indicators, prerequisites, or immediate effects. With no annotations or output schema, more context could 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 covers 100% of parameters but descriptions are minimal (especially username). The description adds value for uid by stating its source, but username remains vague. 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?
Clearly states the action (delete), resource (cron job), and identifier (uid). Distinguishes from sibling tools like hosting_listAccountCronJobsV1 and hosting_createAccountCronJobV1.
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?
Implies usage after listing cron jobs to obtain uid, but no explicit when-not or alternative instructions. The presence of a sibling list tool clarifies 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?
With no annotations, the description bears full burden for behavioral disclosure. It implies deletion but does not state permanence, required permissions, or any side effects. This is insufficient for a deletion operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no fluff. The action is front-loaded ('Delete an existing parked or alias domain'), followed by usage guidance. Every sentence 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?
Given the simplicity of the tool (3 simple params, no output schema), the description is minimal but lacks behavioral details like permanence or prerequisites. It is adequate for a straightforward delete but could be more 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%, so the schema already describes each parameter as strings. The description adds no additional meaning beyond the schema. 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 verb 'Delete' and the resource 'parked or alias domain from the selected website'. It distinguishes from sibling tools like hosting_createWebsiteParkedDomainV1 and hosting_listWebsiteParkedDomainsV1 by specifying removal of existing domains.
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 ('remove parked domains that are no longer needed'). However, it does not explicitly state when not to use it or mention alternatives like deleting subdomains, which are present in sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses it's a read operation returning list data but omits details like pagination, sorting, auth requirements, or rate limits. With no annotations, the description carries the full burden and is adequate but not thorough.
Agents need to know what a tool does to the world before 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, clearly front-loaded with the action and result, 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?
With no output schema, the description partially describes the return (schedule and command) but lacks mention of other typical fields (ID, status) and does not cover errors or permissions. Adequate for a simple list tool 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?
Schema has 100% coverage but the parameter description is generic ("username parameter"). The description adds context that username identifies the account, which adds some meaning, but not rich detail.
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 returns a list of cron jobs for a specified account, including schedule and command. It distinguishes from sibling tools like create and delete cron jobs.
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?
Implies usage when listing cron jobs, but no explicit when-to-use or when-not-to-use guidance, nor mention of 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?
No annotations are provided, and the description does not disclose potential side effects, permissions needed, or impacts on the website, leaving the agent without crucial safety 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?
Two sentences, front-loaded with purpose, no unnecessary words. Highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers basic purpose and use cases but lacks details on prerequisites, what 'default state' means, or any post-reset effects. Adequate for a simple tool but not fully 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?
Schema coverage is 100% with descriptions for both parameters. The description adds no additional meaning beyond the schema, so 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 the tool resets all PHP extensions to default, using a specific verb and resource. It is distinct from related sibling tools like hosting_updatePHPExtensionsV1.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit use cases: recovering from extension conflicts or restoring original configuration, giving clear context for when to 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 bears the full burden of disclosing behavioral traits. It only states the action (enable/disable) with no mention of side effects, required permissions, idempotency, or what happens if the option is already in the desired state. 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 concise with two sentences: the first clearly states the purpose, and the second provides practical parameter guidance. 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 description covers the main purpose and one key parameter hint, but lacks explanation of the AI options (llmstxt, web2agent) and any return value information. Given no output schema, some description of expected behavior after invocation would improve completeness. 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?
The input schema covers all 4 parameters with descriptions, achieving 100% coverage. The description adds minimal value beyond the schema, only hinting at how to get the software identifier. Baseline 3 is appropriate as the schema already 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?
Description clearly states the tool enables or disables an AI option for the Hostinger Tools plugin on a WordPress installation. The verb 'enable or disable' is specific, and the resource (AI option status) is clearly identified. It distinguishes from sibling hosting_showAIOptionStatusV1 which only shows status.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context on when to use the tool (to enable/disable AI options) and includes guidance on obtaining the required software identifier from another endpoint. However, it does not explicitly state when not to use it or mention the sibling show tool as an alternative for reading status.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavior. It states it 'shows' status, implying a read operation with no side effects, but does not explicitly confirm safety, response format, or error cases. This is adequate for a simple query 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 two sentences with no fluff. It front-loads the purpose and follows with a necessary instruction. Every sentence 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?
Given the tool's simplicity (no output schema, two parameters), the description covers the core purpose and required identifier. However, it omits return value format and any prerequisite conditions, leaving minor gaps. Adequate but not robust.
Complex tools with many parameters or behaviors need more documentation. Simple tools 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 description adds value for the 'software' parameter by explaining how to obtain the identifier. However, the 'username' parameter remains vague ('username parameter') and is not clarified in the description. The baseline is 3 due to high coverage, and the description provides marginal improvement.
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 shows the maintenance mode status for a specific WordPress installation. It includes the verb 'show' and the resource 'maintenance mode status', distinguishing it from many sibling tools like 'hosting_toggleMaintenanceModeV1'.
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 explains how to obtain the required software identifier but does not compare to alternatives or specify when to use this tool versus other status tools. It implies usage for checking status, but lacks explicit 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 must disclose behavioral traits. It only says enables/disables and advises checking current states. It does not mention if changes take effect immediately, require a restart, or have any side effects, which 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 two sentences with no redundancy. It front-loads the action and then provides a useful tip. Every sentence 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?
Given the 4 parameters, no output schema, and missing annotations, the description could be more complete. It mentions checking current states but doesn't cover response format, prerequisites, or error scenarios. Adequate but has 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 parameters are already documented. The description adds minimal context by stating the overall action, but the schema already describes enable/disable as arrays of PHP extensions. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's verb and resource: 'Enables or disables PHP extensions (modules) for the website.' This distinguishes it from sibling tools like hosting_getPHPDetailsV1 (read) and hosting_resetPHPExtensionsV1 (reset vs enable/disable).
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 advises using the Get PHP details endpoint to check current states before changing, which provides context. However, it does not explicitly specify when not to use this tool or name alternatives like hosting_resetPHPExtensionsV1, limiting full 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?
No annotations are provided, so the description bears full burden. It states 'paginated list', indicating paging behavior, and aggregates across mailboxes. However, it does not disclose required permissions, rate limits, or what happens with invalid orderId.
Agents need to know what a tool does to the world before calling it. Descriptions 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 14-word sentence with no filler. The verb is front-loaded, and every word is essential. It is optimally 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?
No output schema exists, yet the description does not mention return fields, pagination details, or how to navigate pages. It is adequate for purpose but incomplete for full autonomous usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with each parameter described. The description adds context for orderId ('across all mailboxes of a mail order'), but does not add significant meaning beyond the schema's parameter descriptions. 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 uses the specific verb 'Retrieve' with the resource 'catch-alls' and clarifies the scope ('across all mailboxes of a mail order'). It clearly distinguishes from sibling tools like mail_createCatchAllV1 or mail_listMailboxesV1.
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 listing catch-alls but does not provide explicit when-to-use, when-not-to-use, or mention alternatives. No contrast with other mail list tools is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It mentions pagination and sorting but lacks details on auth requirements, rate limits, 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with front-loaded purpose and no fluff.
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 no output schema, description omits return format details. Adequate for a retrieval tool but could mention log fields or pagination defaults.
Complex tools with many parameters or behaviors need more documentation. Simple tools 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. Description summarizes filters but adds no new meaning beyond the existing parameter descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves paginated inbound delivery logs for a specific domain attached to a mail order, distinguishing it from sibling tools like mail_listOutboundLogsV1.
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 inbound logs via the resource name but does not explicitly compare to alternatives or specify when not to use it.
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?
Discloses rate limiting, but lacks detail on side effects (none expected) or return format. Since no annotations exist, description carries full burden; it is 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, no fluff. Could be slightly restructured for readability (e.g., bullet points), but remains effective and concise.
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 test tool with one parameter and no output schema, the description covers core behavior and constraint (rate limit). Implicitly assumes webhook exists, but acceptable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Single parameter webhookId is already described in the schema. Description adds no extra clarification beyond the existing schema documentation, meeting baseline for 100% 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?
Description clearly states the action: send a test delivery to a webhook URL and return the result. The verb 'test' distinguishes it from creation or deletion tools like mail_createWebhook or mail_deleteWebhook.
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. Mentions rate limiting but does not specify prerequisites or scenarios (e.g., only after creating a webhook).
Agents often have multiple tools that could apply. Explicit usage guidance like "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 only says 'Retrieve' but does not disclose any behavioral traits like idempotency, authentication requirements, rate limits, or side effects. For a read operation, 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 two sentences, no wasted words. It first states the action and then the intended use, providing both clarity and context 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?
The description mentions 'rules associated with it' and 'configuration and rules', giving a general idea of the return content. However, without an output schema, more detail on the response structure would be helpful for 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 single parameter 'firewallId' is covered 100% in the schema with description 'Firewall ID'. The tool description 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 uses the specific verb 'Retrieve' and identifies the resource as 'firewall by its ID and rules'. It clearly distinguishes from sibling VPS_getFirewallListV1 by targeting a single firewall, not a list.
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 states 'Use this endpoint to view specific firewall configuration and rules', which gives clear context for when to use this tool. However, it does not explicitly mention alternatives or when not to use it, such as for listing all firewalls.
Agents often have multiple tools that could apply. Explicit usage guidance like "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 traits such as read-only nature, caching, rate limits, or authentication requirements. The description only explains what the tool does, not how it behaves.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with 4-5 sentences, starting with a clear verb. Some redundancy exists (e.g., 'scan metrics provide detailed information about malware scans performed by Monarx' is repetitive) but overall 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 retrieval tool with one parameter and no output schema, the description adequately explains the data returned (number of scans, threats). It provides sufficient context for an agent to understand the tool's output.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with one parameter described (virtualMachineId). The description does not add additional semantics beyond the schema, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves scan metrics for the Monarx malware scanner on a specified virtual machine, listing specific data types (number of scans, threats). It distinguishes from other VPS tools like VPS_getMetricsV1 which likely provides general metrics.
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 includes a usage directive: 'Use this endpoint to monitor VPS security scan results and threat detection.' It provides clear context but does not explicitly mention when not to use or alternatives among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It states it retrieves information (read-only), but does not mention auth requirements, rate limits, error conditions, or what happens if the VM ID is invalid. Minimal behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the action, and contains no unnecessary words. Every sentence 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 tool with one parameter and no output schema, the description covers the basic purpose but lacks details about what 'detailed information' includes (e.g., configuration vs status). Some guidance on the response content 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% for the single parameter 'virtualMachineId', which is already adequately described in the schema. The description does not add any additional meaning beyond what the schema provides, meeting the baseline for high 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 tool retrieves detailed information about a specified virtual machine, with specific verbs 'Retrieve' and 'view'. It distinguishes from sibling tools like VPS_getVirtualMachinesV1 (list all VMs) and VPS_getMetricsV1 (metrics) by focusing on comprehensive details for one VM.
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 says 'Use this endpoint to view comprehensive VPS configuration and status,' which implies when to use it. However, it does not explicitly exclude other scenarios 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must convey behavioral traits. It mentions resetting to default but omits details about prerequisites, side effects (e.g., whether it causes downtime), 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with front-loaded purpose, no extraneous words. Efficient and clear.
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 parameter and no output schema, the description is minimally adequate but lacks important behavioral context such as idempotency or return values.
Complex tools with many parameters or behaviors need more documentation. Simple tools 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 description adds no additional meaning beyond the schema's 'Virtual Machine ID' description. 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 action (reset) and the resource (hostname and PTR record of a specified virtual machine), distinguishing it from siblings like VPS_setHostnameV1 and VPS_createPTRRecordV1.
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 indicates the use case (restore default hostname configuration), implying when to use the tool but does not provide exclusion criteria or compare with 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 must carry the behavioral burden. It discloses that requests for non-panel OS VMs are processed without effect and references password requirements via link. However, it doesn't mention required VM state or potential side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, front-loaded with purpose, and every sentence adds necessary information: purpose, special behavior, and usage context. 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 tool with 2 required parameters and no output schema, the description covers purpose, behavior, and password constraints. It could mention prerequisites like VM running state, but overall adequately 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?
Schema coverage is 100% with basic descriptions for both parameters. The description adds value by linking password requirements to the recreate endpoint, providing external context 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 tool sets the panel password for a VM, using specific verb and resource. It also notes a special case (no effect if non-panel OS). However, it does not explicitly differentiate from related sibling tools like VPS_setRootPasswordV1.
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 context that this endpoint configures control panel access credentials and mentions the no-effect caveat for non-panel OS VMs. But no when-not-to-use guidelines or mention of alternatives like VPS_setRootPasswordV1 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. The description does not disclose whether the VM must be stopped, whether a restart occurs, or other side effects. It only references password requirements from another endpoint, leaving significant behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no redundancy. It is front-loaded with the action and brief enough to be parsed quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations or output schema, the description lacks detail on effects and return values. The reference to an external endpoint partially compensates, but overall 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 description coverage is 100%, so the schema already documents both parameters. The description adds the link to password requirements but does not enhance meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Set root password for a specified virtual machine,' which is a specific verb+resource. It differentiates from sibling tools like VPS_setHostnameV1 and VPS_setPanelPasswordV1.
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 says 'Use this endpoint to update administrator credentials for VPS instances,' providing clear context. It does not explicitly state when not to use or list alternatives, but the reference to the recreate VM endpoint for password requirements offers some 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 convey behavioral traits. It only states 'update' and 'modify,' which imply a write operation, but fails to disclose side effects, permissions, idempotency, or what happens if the script is in use. The description adds minimal value beyond the 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 two concise sentences with no redundancy or unnecessary information. It is efficient and front-loaded with 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 description provides the basic purpose but lacks details about return values, error conditions, or constraints (e.g., script must exist). For a mutation tool with no annotations or output schema, it is moderately complete but could be more informative.
Complex tools with many parameters or behaviors need more documentation. Simple tools 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% (each parameter has a description), so the baseline is 3. The tool description does not add any additional meaning or context to the parameters beyond what is already in 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 verb 'update' and the resource 'post-install script', and distinguishes itself from sibling tools like create, delete, and get by specifying 'modify existing automation scripts'.
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 says 'Use this endpoint to modify existing automation scripts,' which implies it is for modifying existing scripts, not creating or deleting. However, it does not explicitly mention when not to use it or list alternative tools for creation or deletion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses the revert behavior ('Set domain to null to revert to the temporary domain'), which is a key trait. However, it does not mention authorization needs, rate limits, or side effects like the old domain being freed or propagation delays.
Agents need to know what a tool does to the world before calling it. Descriptions 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 sentences: purpose, parameter instruction, special case. It is front-loaded with the core action, uses no unnecessary words, and every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple mutation with 3 params and no output schema, the description covers the special revert behavior and parameter placement. It lacks context on prerequisites or what happens post-change, but overall it is reasonably 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 documentation covers all three parameters (100% coverage). The description adds minimal value by indicating parameter placement (path vs body) but does not deepen understanding beyond the schema descriptions. 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 and resource: 'Changes the primary domain for an Agency Plan website.' It distinguishes from sibling tools like link/unlink domain, parked domains, and other domain operations by specifying it's for the primary domain of an Agency Plan website.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by stating the action, but it does not explicitly state when to use this tool versus alternatives (e.g., linking a domain vs. changing the primary). No exclusions or context for selection 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?
With no annotations provided, the description covers the basic behavior: clearing all cache types for all domains. However, it lacks details on side effects, asynchronicity, rate limits, or permissions. Minimal but sufficient for a simple cache 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: first defines the action and scope, second reinforces completeness. 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?
For a low-complexity tool with one parameter and no output schema, the description is adequate. It covers what is cleared and for which resource. Missing return value details, but the outcome is implied.
Complex tools with many parameters or behaviors need more documentation. Simple tools 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 one parameter fully described. The description does not add any additional meaning beyond the schema. No mention of parameter format, constraints, or examples.
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 (clears cache), the resource (Agency Plan website), and the scope (all domains including preview domain, all cache types). It distinguishes from siblings like 'hosting_clearWebsiteCacheV1' by specifying Agency Plan context.
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 Agency Plan websites but provides no explicit guidance on when to use this tool versus alternatives (e.g., 'hosting_clearWebsiteCacheV1' for non-Agency Plan sites). No exclusions or prerequisites 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 provided, so description carries full burden. It discloses permanence and idempotence, but lacks details on auth requirements or side effects beyond user access revocation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with main action, 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 deletion tool with no output schema, description covers key behavioral traits (permanence, idempotence). Could mention that only the user is affected, not the database.
Complex tools with many parameters or behaviors need more documentation. Simple tools 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 baseline 3. Description does not add meaning beyond the schema for the parameters; idempotency note is about behavior, not 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 clearly states 'permanently deletes a database user' from an Agency Plan website database, with specific verb and resource. Distinct from sibling tools like create or list database users.
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?
Mentions idempotency, implying safe retry, but does not explicitly state when to use this tool versus alternatives or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses the risk that improper configuration can make the domain unresolvable, which is a key behavioral trait. However, it does not detail whether the operation is idempotent, overwrite behavior, or response format, leaving gaps in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise at three sentences, front-loading the primary action first, then a warning, then usage guidance. Every sentence adds value with no redundant or irrelevant 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?
Despite the warning, the description lacks critical context such as success/error responses, prerequisites (e.g., domain ownership), rate limits, and how to verify the changes. Given no output schema and no annotations, this incomplete context could hinder an agent's effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for all 5 parameters. The description adds no additional meaning beyond what the schema provides, so 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 'Set nameservers for a specified domain,' using a specific verb and resource. It distinguishes from siblings like `VPS_setNameserversV1` by explicitly mentioning 'domain' and 'custom DNS hosting,' making its domain-specific 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 includes a usage guideline: 'Use this endpoint to configure custom DNS hosting for domains.' It also warns about the risk of improper configuration. However, it does not explicitly state when not to use it or mention alternatives, though no direct alternative exists among siblings for domain nameservers.
Agents often have multiple tools that could apply. Explicit usage guidance like "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 disclose behavior. It notes the links are temporary but does not specify duration, prerequisite authentication, or whether the action is reversible. No information about side effects or response format 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 extremely concise (two sentences), front-loaded with the main action, and contains no unnecessary words. Every sentence serves a 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 tool with two parameters and no output schema, the description covers the essential purpose and parameter sourcing. It lacks details about return values or error cases, but the tool is straightforward enough that an agent can infer usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds meaningful context for the 'software' parameter by telling the agent where to get the identifier (from a list endpoint), which goes beyond the schema's description. For 'username', no extra info is provided.
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 creates temporary auto-login links for a WordPress installation, using a specific verb and resource. It also explains how to obtain the required identifier, distinguishing it from sibling tools like those that install or update WordPress.
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 context on providing the WordPress installation identifier and where to obtain it, but does not explicitly state when to use this tool versus alternatives like hosting_getInstallationJWTTokenV1. No when-not-to-use guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 does not mention permissions, side effects, or response characteristics. For a list operation, it is minimally adequate but lacks details about required authentication or limitations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the main purpose. Efficient and clear without 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?
The description covers the main purpose and parameter source but does not describe the output format or any pagination. Given the tool's simplicity, it is mostly adequate but could hint at what the returned data contains (e.g., list of version strings).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% but the schema description for username is vague ('username parameter'). The tool description adds context for the software parameter (source from another endpoint) but does not clarify the purpose of username. Thus, it adds marginal value over 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?
Description clearly states it lists available WordPress core updates for a specified installation. The verb 'List' and noun 'WordPress core updates' are specific. It distinguishes from sibling tools like hosting_updateWordPressCoreV1 and hosting_showWordPressCoreVersionV1.
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?
Description explains when to use: to list available updates. It also instructs where to get the required software identifier from another endpoint. However, it does not explicitly state when not to use or mention alternatives, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must cover behavior. It mentions inspecting configuration and returning 'parent domain and root directory', implying a read-only operation. Lacks explicit disclosure of side effects, authentication requirements, or response format.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences: first states purpose, second adds detail on return data. No redundant or extra information. Efficient and clear.
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?
A simple listing tool with two parameters and no output schema. Description covers purpose and hints at returned fields (parent domain, root directory). Missing details on pagination, limits, or error conditions, but 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.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with basic descriptions. The description adds that the tool works for a 'selected website', but does not clarify the 'username' parameter (e.g., user account or hosting username). Does not add significant meaning beyond 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?
Description clearly states verb 'retrieve' and resource 'parked or alias domains' with scope 'under the selected website'. This distinguishes it from sibling tools like hosting_createWebsiteParkedDomainV1 and hosting_deleteWebsiteParkedDomainV1.
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?
Explicitly says 'use this endpoint to inspect parked domain configuration', providing usage context. However, does not mention when not to use it or compare with alternatives like other hosting listing 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 should disclose behavioral traits such as read-only nature, authentication requirements, or pagination. It only states 'list' and implies no side effects, but fails to explicitly confirm it's a safe, read-only operation. No rate limits or error conditions are mentioned, which is a gap for a listing 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 extremely concise with two short sentences. The first sentence states the core purpose, and the second provides a critical flow hint. Every word earns its place; no filler or repetition.
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 no output schema, the description implies the return includes 'slug' values, which is sufficient for its simple purpose. It does not describe other fields, pagination, or limits, but for a straightforward list tool with only two optional parameters, the context 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?
Schema coverage is 100%, so the baseline is 3. The description does not add any meaning beyond the schema definitions; for example, it does not clarify how 'search' matching works (substring vs exact) or what an 'order_id' represents. The agent must rely solely on the schema for parameter interpretation.
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 WordPress themes available to install', using a specific verb and resource. It distinguishes itself from sibling tools like hosting_listInstalledWordPressThemesV1 by specifying 'available to install'.
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 tells the agent to use the returned slug values with the install endpoint, providing immediate next-step guidance. However, it does not contrast with alternatives like searching or listing installed themes, nor does it specify when not to use this 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?
No annotations provided, so the description must disclose behavior. It states it retrieves logs, which implies a safe read operation. However, it does not discuss potential issues like large log sizes, pagination, or error handling for invalid deployment UUIDs.
Agents need to know what a tool does to the world before calling it. Descriptions 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 concise and front-loaded with the primary purpose. Every word serves a function, with no redundancy 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 three parameters and no output schema, yet the description does not explain the return format (e.g., JSON, plain text), pagination behavior, or how to handle errors (e.g., missing deployment). For a debugging tool, this lack of detail leaves the agent underinformed.
Complex tools with many parameters or behaviors need more documentation. Simple tools 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 are described in the input schema (100% coverage). The description adds no additional meaning beyond the schema, such as explaining that 'buildUuid' comes from hosting_listJsDeployments or that 'fromLine' is for pagination. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Retrieve logs', the resource 'JavaScript application deployment', and the purpose 'for debugging purposes in case of failure'. It distinguishes from sibling tools like hosting_listJsDeployments (list deployments) and hosting_getNodeJSBuildLogsV1 (Node.js build logs).
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 specifies when to use: 'for debugging purposes in case of failure'. This gives clear context, although it does not explicitly state when not to use or mention alternative tools for other scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that the mailbox stops sending automatic replies immediately, which is useful behavioral context. However, it lacks details on idempotency, error handling, or consequences of deleting a non-existent autoreply.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loading the action and effect. No extraneous text; every word adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the essential action and immediate effect for a simple deletion. No output schema exists, but the description is adequate for a one-parameter tool. Could mention success confirmation or behavior on missing ID, but sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with one parameter 'autoreplyId' described as 'Autoreply resource ID'. The description does not add additional meaning beyond the schema; 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 ('Delete') and the resource ('autoreply of a mailbox'), and distinguishes from sibling tools like create, update, and list autoreplies. It provides a specific verb and resource with immediate effect stated.
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 (when an autoreply needs to be removed) but does not explicitly guide when not to use or name alternatives. Sibling tools provide context but no explicit comparison.
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. It discloses the immediate stop of forwarding, but doesn't mention irreversibility, required permissions, or confirmation steps. 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?
Two sentences, no fluff, front-loaded with the action. Every sentence provides value. Ideal 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 simple delete tool with one required parameter and no output schema, the description is mostly complete. It explains the effect. Could mention error states or prerequisites, but not strictly necessary.
Complex tools with many parameters or behaviors need more documentation. Simple tools 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 in the schema is sufficient. The tool description adds no additional meaning to 'forwarderId' beyond what's in 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 'Delete a forwarder' and explains the immediate effect on mailbox forwarding. It distinguishes from sibling tools like create/list/update forwarders.
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 like updating or resending confirmation. The purpose is clear, but an agent would benefit from knowing that this permanently removes forwarding.
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 retrieving data, implying a read-only action, but does not explicitly confirm no side effects, auth requirements, or other behavioral traits.
Agents need to know what a tool does to the world before 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, well-structured sentence that front-loads the purpose and contains no unnecessary words. Every part 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 retrieval tool with one parameter and no output schema, the description is adequate. It explains what is included (quotas, limits, protocol availability), but could be slightly improved by clarifying if pricing is included.
Complex tools with many parameters or behaviors need more documentation. Simple tools 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 orderId, and the description simply repeats the schema's description. It adds no additional meaning or 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 clearly states it retrieves the plan of a mail order, specifying the included details (quotas, limits, protocol availability). The verb 'retrieve' and resource 'plan' are specific, distinguishing it from sibling tools like mail_listOrders or mail_createMailbox.
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 an agent needs plan details for a mail order, but lacks explicit guidance on when to use or not use this tool, and does not mention alternatives or prerequisites.
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 provided, so description carries burden. Mentions forwarder must be unconfirmed, but lacks details on side effects, authorization needs, error states, or behavior if forwarder is already confirmed.
Agents need to know what a tool does to the world before 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, no wasted words. Action verb is front-loaded: 'Resend the confirmation email...'
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, description is largely sufficient. Could mention error conditions (e.g., if forwarder already confirmed) for 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%, so baseline is 3. Description does not add meaning beyond schema's 'Forwarder resource ID' for the forwarderId 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?
Description clearly states the action (resend confirmation email) and target (unconfirmed forwarder). Differentiates from sibling tools like mail_createForwarderV1 (creation) and mail_resendCatchAllConfirmationV1 (different entity).
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?
Implies usage when a forwarder is unconfirmed and needs a confirmation email resent, but no explicit guidance on when not to use or contrast with similar tools like mail_resendCatchAllConfirmationV1.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the core behavior (enable/disable keep copy) but omits details like error handling, permissions required, or side effects (e.g., does it send confirmation?). The description is minimally adequate for a simple toggle.
Agents need to know what a tool does to the world before calling it. Descriptions 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 perfectly concise and front-loaded with the primary 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 toggle with two well-documented parameters and no output schema, the description is largely complete. It explains the effect clearly. However, it lacks any mention of prerequisites (e.g., forwarder must exist) or return behavior, which could be helpful for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so both parameters already have clear definitions in the schema. The tool description adds no additional meaning beyond what is already in the input schema, thus meeting 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 ('Enable or disable') and identifies the resource ('keeping a copy of forwarded messages in the mailbox'). It clearly distinguishes this tool from sibling mail tools like mail_createForwarder or mail_deleteForwarder, which perform different actions on forwarders.
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 toggle the keep-copy setting on an existing forwarder, but it does not explicitly state when to use it versus alternatives (e.g., creating a new forwarder with the setting). No prerequisites or conditions are mentioned.
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 explicitly states the operation is 'Permanently delete' and discloses that the contact is 'removed together with its custom field values and tag assignments.' This provides valuable behavioral context for a destructive operation, though it omits details like permissions or response.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences, front-loaded with the main action and followed by a crucial consequence. Every word earns its place; no redundant or vague language.
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 two parameters, the description sufficiently covers the action and its scope (profile, custom fields, tags). It does not explain return values or permission requirements, but these are less critical when no output schema is present and the operation is destructive. It could be more explicit about the relationship between profileUuid and contactUuid.
Complex tools with many parameters or behaviors need more documentation. Simple tools 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 are present for both parameters but are tautological ('Profile uuid parameter', 'Contact uuid parameter'). The tool description adds no additional meaning about the parameters, so it does not exceed the baseline set by the high schema coverage. Both parameter names are self-explanatory, offering minimal added 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: 'Permanently delete a contact from a profile.' This specifically identifies the resource (contact within a profile) and differentiates it from sibling tools like reach_deleteAContactV1 (delete any contact) and reach_deleteAContactFieldV1 (delete a contact field).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps 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 when to choose this over reach_deleteAContactV1 or other delete-related tools, nor does it provide exclusions or prerequisites. The intended context must be inferred from the name and description alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries full burden. It only states 'Delete' which implies destruction, and adds 'from your account' and 'unused'. It lacks details on permanence, reversibility, or side effects on VMs using the script.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the action and purpose. No superfluous words; each sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple, one-parameter delete operation, the description adequately covers the action and usage context. It lacks prerequisites or response details, but given low complexity, it is fairly 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 clear description of the parameter. The description does not add further 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?
Clearly states the action is deleting a post-install script from the account, using a specific verb and resource. It also distinguishes from sibling tools like update and get, and adds context about removing unused scripts.
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 guidance to use for removing unused automation scripts, implying when to use. However, it does not explicitly mention when not to use or alternatives, though the sibling list includes update and other actions.
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 implies a read-only operation by using 'retrieves' and lists the type of data returned. However, it does not disclose prerequisites (e.g., VM existence), permissions, rate limits, or response format. The absence of an output schema further reduces transparency. The description adds some value by mentioning specific contents but is insufficiently detailed.
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 three sentences, front-loaded with the key information. The first sentence is the most informative. The second sentence is somewhat redundant ('This endpoint provides...' restates the first). It could be trimmed to two sentences without loss. Overall, it is concise and well-structured, earning a 4.
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 (2 params, read-only retrieval), the description covers the main purpose. However, the lack of an output schema means the agent has no information about the return structure. Mentioning specific contents (docker-compose.yml, metadata) helps, but it is not fully complete. The description adequately informs the agent about what the tool does but leaves gaps in expected output format.
Complex tools with many parameters or behaviors need more documentation. Simple tools 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 descriptive names. The tool description does not add additional meaning beyond the schema. For example, 'projectName' is described as a Docker Compose project name in the schema, and the description confirms the tool deals with Docker Compose projects. The description adds no new parameter-level details, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves complete project information including docker-compose.yml, metadata, and deployment status. The verb 'retrieves' combined with the specific resource (project) and scope (complete information) makes the purpose unambiguous. It distinguishes from siblings like VPS_getProjectListV1 (listing) and VPS_getProjectContainersV1 (containers only) by emphasizing completeness.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit use cases: 'inspect project settings, review the compose file, or check the overall project health.' This gives clear context for when to use the tool. However, it does not explicitly state when not to use it or mention alternatives like VPS_getProjectContainersV1 or VPS_getProjectLogsV1 for partial data.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. The description only states the basic action ('Retrieve') without disclosing behavioral traits such as rate limits, authentication requirements, or whether it supports pagination. For a read operation with zero annotations, more detail is needed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise with two front-loaded sentences. No unnecessary information, and each sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list endpoint with no parameters and no output schema, the description is mostly complete. It could mention that it returns a list of virtual machines, but the purpose is clear. Minor gap but acceptable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so the description does not need to add parameter details. The baseline for no parameters is 4, and the description is adequate.
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 ('Retrieve') and the resource ('all available virtual machines' or 'VPS instances'). It distinguishes this tool from siblings like VPS_getVirtualMachineDetailsV1 which retrieves details of a single VM.
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 context for when to use (to view available VPS instances) but lacks explicit guidance on when not to use or alternatives. Among siblings, there is no mention of preferring another tool for filtered or detailed views.
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 changing hostname does not update PTR records automatically and that domain records must be pointed. With no annotations, this provides some behavioral insight but does not mention potential side effects, permissions required, or whether a restart is needed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is relatively concise, gets to the point quickly, and includes important caveats. However, the caveats about PTR and domain records could be more succinct.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with 2 parameters and 100% schema coverage, the description adequately explains the core action and key side effects. It does not specify return values or confirm success, but no output schema provides for that. Missing details like potential delays or reboot requirements.
Complex tools with many parameters or behaviors need more documentation. Simple tools 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 baseline is 3. The description does not explain parameter constraints beyond what the schema provides, such as acceptable hostname formats or length limits.
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: 'Set hostname for a specified virtual machine.' It differentiates from related siblings like VPS_resetHostnameV1 by specifying 'set' vs 'reset' and provides additional context about PTR and domain records.
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 advises when to use the tool ('Use this endpoint to configure custom hostnames for VPS instances') and includes caveats about PTR records and domain A/AAAA records. However, it does not explicitly contrast with alternatives like VPS_resetHostnameV1.
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 containers are started in dependency order and that only stopped services are affected. With no annotations, the description carries the full burden. It lacks details on idempotency, error behavior, or prerequisites like project existence.
Agents need to know what a tool does to the world before calling it. Descriptions 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 superfluous text. The key action and use cases are front-loaded, making it efficient for an AI agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple start operation, the description covers the main functional behavior and use cases. Without an output schema, it could mention return format or that the operation is non-destructive, 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?
Schema description coverage is 100%, with both parameters already well-described. The description does not add any additional meaning or context for the parameters, 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 specific verbs ('starts all services') and identifies the resource ('Docker Compose project'). It clearly distinguishes this tool from sibling tools like VPS_stopProjectV1 and VPS_restartProjectV1 by focusing on starting stopped 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 mentions two use cases: resuming a stopped project and starting after reboot. However, it does not explicitly contrast with alternatives (e.g., VPS_restartProjectV1) or explain when not to use this tool. The guidance is present but minimal.
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 adds one important behavioral trait: that VMs with the firewall will lose sync and require manual sync. However, it does not disclose other aspects like idempotency, authorization needs, or error states, which would be expected 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 three sentences, front-loaded with purpose, and uses concise language. It could be slightly more efficient, but it is not overly 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 tool has no output schema, but the description does not mention the response format or success/failure indication. The sync loss warning is valuable but insufficient for a complete 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 parameters with descriptions. The description adds no additional meaning beyond the schema, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool updates a specific firewall rule within a specified firewall. The verb 'Update' and resource 'firewall rule' are explicit, and it differentiates from sibling tools like VPS_createFirewallRuleV1 and VPS_deleteFirewallRuleV1.
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 use for modifying existing rules, but lacks explicit guidance on when to use vs alternatives or when not to use. The sync loss warning provides context but no exclusion criteria.
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 fully covers behavioral traits: immediate traffic stop, preservation of files/db, accessibility of other domains, and edge case of only domain. However, it does not mention reversibility, permission requirements, or any DNS changes, but overall it's informative.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Four concise sentences, each adding value. The first sentence clearly states the purpose, and subsequent sentences explain consequences. 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?
While the description covers side effects well, it lacks mention of return values (no output schema) and error conditions. For a simple unlink action, it is moderately complete but could include common failure reasons.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with clear parameter descriptions. The tool description adds context but no additional parameter-specific meaning 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 action ('Unlinks a domain') and the resource ('Agency Plan website'). It distinguishes from siblings like linkDomainToAgencyPlanWebsiteV1 and changeAgencyPlanWebsiteDomainV1, and explains immediate consequences.
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 context is implied but not explicit. The description explains what happens after unlinking, but does not specify when to use this tool vs alternatives (e.g., changeDomain or deleteWebsite) nor any prerequisites like the domain being currently linked.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must cover behavioral traits. It implies a safe read operation by using 'Retrieve', but it does not explicitly state that it is read-only, nor does it mention authentication, rate limits, or pagination 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 very concise with two short sentences. It is front-loaded with the main action and provides an immediate use case. No extraneous 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?
No output schema is provided, so the description should convey what the response contains. It says 'list of all subscriptions' but does not specify the fields in each subscription object (e.g., id, status, billing period), which could leave an agent uncertain about the return format.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, so the description does not need to explain parameters. The schema coverage is 100% trivially, and with zero parameters, the description adds no additional meaning but is not required to.
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 retrieves a list of all subscriptions associated with the account. It uses specific verb 'Retrieve' and resource 'list of all subscriptions', and it is distinct from sibling billing tools like billing_getPaymentMethodListV1 or billing_getCatalogItemListV1.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes a usage hint ('Use this endpoint to monitor active services and billing status'), which provides context. However, it does not specify when not to use it or mention alternatives among sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. It explains the core behavior (restore DNS to snapshot) but does not disclose side effects (e.g., overwriting current records), authorization requirements, or propagation delays. The description is minimal but not misleading.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description consists of two short, front-loaded sentences with no wasted words. It efficiently conveys the tool's purpose and usage.
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 low complexity (2 required parameters, no output schema). The description covers the basic operation but lacks guidance on prerequisites (e.g., needing a snapshot from DNS_getDNSSnapshotListV1) or what happens after restoration.
Complex tools with many parameters or behaviors need more documentation. Simple tools 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 both parameters (domain and snapshotId), so the baseline is 3. The description adds no additional context or format details beyond what the schema 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 action ('Restore DNS zone') and the target resource ('selected snapshot'). It also explains the purpose: 'revert domain DNS to a previous configuration'. This distinguishes it from sibling tools like DNS_getDNSSnapshotListV1 and DNS_getDNSSnapshotV1.
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 tells when to use this tool: 'Use this endpoint to revert domain DNS to a previous configuration.' It provides clear context but does not mention when not to use it or provide alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It discloses the primary effect (hiding personal info) but does not mention potential side effects, prerequisites (e.g., domain status), 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with three short sentences. The first sentence states the action, the second explains the effect, and the third provides usage guidance. 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 tool with no output schema, the description covers the main purpose. However, it lacks details on return values, domain requirements, or scope of effect.
Complex tools with many parameters or behaviors need more documentation. Simple tools 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 parameter description 'Domain name'. The description adds no additional meaning beyond what the schema provides (e.g., format or validation). 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 ('enable privacy protection') and the resource ('domain'), and explains the effect (hide personal info from WHOIS). It is distinct from the sibling tool 'disablePrivacyProtection'.
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 'Use this endpoint to protect domain owner's personal information from public view,' providing clear when-to-use guidance. It implies the alternative (disable) but does not explicitly state prerequisites or when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/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 transparency. It implies a read-only operation ('Retrieve... view...'), but does not disclose any side effects, authentication needs, rate limits, or specific aspects of 'comprehensive domain configuration and status.' It is adequate but lacks depth.
Agents need to know what a tool does to the world before calling it. Descriptions 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: the first states the core purpose, and the second provides a usage rationale. Every word adds value without 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?
Given the lack of an output schema, the description should hint at what details are returned. It says 'comprehensive domain configuration and status,' which is vague. It could mention categories like registrar, expiration, nameservers, etc. This is a gap for a details-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 already describes the only parameter (domain: 'Domain name') with 100% coverage. The 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Retrieve detailed information') and the resource ('specified domain'). It distinguishes itself from sibling tools like domains_getDomainListV1 (listing domains) and domains_checkDomainAvailabilityV1 (checking availability) by focusing on obtaining comprehensive details for a single domain.
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 advises using this endpoint to 'view comprehensive domain configuration and status,' which provides clear context for when to use it. However, it does not explicitly mention alternatives or when not to use it, though the distinction from siblings is implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It correctly identifies this as a read operation (retrieval) but does not disclose any prerequisites, permissions, or potential side effects. This is adequate for a simple get but could be more informative.
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?
Two sentences with no extraneous words. However, the second sentence is somewhat redundant with the first; they could be merged into one concise statement.
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 get tool with one parameter and no output schema, the description is sufficient. It explains what the tool does and what it returns conceptually (redirect configuration). Could be improved by mentioning what fields are included in 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?
Schema coverage is 100% with a single parameter 'domain' described as 'Domain name'. The description adds context about domain forwarding data and redirect configuration but does not enhance understanding of the parameter beyond the schema's description.
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 verb 'retrieve' and resource 'domain forwarding data', and clarifies it's for viewing current redirect configuration. It distinguishes from siblings like create/delete which are write operations.
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?
Description says to use this endpoint to view current redirect configuration, providing clear usage context. However, it does not explicitly mention when not to use it or alternatives like create/delete for modifications.
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 bears full responsibility. It describes a read operation to retrieve a list, but doesn't disclose response format, pagination, or any side effects. It adds basic behavioral context but could be more detailed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loading the purpose and then adding usage context. Every sentence is necessary and 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?
Given no output schema, the description could hint at what the response contains (e.g., domain names or IDs). It only says 'domain list', which is adequate but not fully complete for a simple 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 only parameter 'whoisId' is described in the schema as 'WHOIS ID', and the description adds no further meaning. With 100% schema coverage, baseline is 3, and no extra value is provided.
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 'Retrieve domain list where provided WHOIS contact profile is used', specifying the verb, resource, and condition. This distinguishes it from sibling tools like domains_getWHOISProfileListV1 (lists profiles) and domains_getWHOISProfileV1 (gets single 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 says 'Use this endpoint to view which domains use specific contact profiles', indicating the appropriate scenario. While it doesn't explicitly list when not to use or provide alternatives, the context of siblings implies the proper use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility. It reveals that the tool performs a password change (a write operation) and notes a downstream dependency: website configurations must also be updated. However, it does not disclose other important behaviors such as whether existing connections are terminated, authorization requirements, or side effects like triggering cache refreshes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with only two sentences. The first sentence states the purpose, and the second provides critical usage notes. No redundant information, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the moderate complexity (3 parameters, all required, no output schema), the description covers the core action and important usage guidance. However, it lacks information about the result of the operation (e.g., success/failure response) and does not address potential errors or prerequisites beyond the database name format.
Complex tools with many parameters or behaviors need more documentation. Simple tools 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 some value by reiterating that the 'name' parameter must be the full database name from the list databases endpoint and that the password change requires updating website configurations. However, it does not provide additional constraints or context beyond what the schema already conveys for each 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 clearly states that the tool changes the password for a specified database user. It distinguishes the tool from sibling database tools like create/delete/list by specifying the action and providing a prerequisite (database name must be full name from list databases).
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 usage: it requires the full database name from the list databases endpoint. It also advises that the password must be updated in any website configuration using the database. However, it does not explicitly mention when not to use this tool or suggest alternative tools for other database 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 provided, so the description carries full burden. It discloses that the tool returns a JWT for authentication but lacks details on expiration, side effects, or error behavior (e.g., what happens if the installation ID is invalid). The description is adequate but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise and well-structured: two sentences, first states purpose, second provides usage guidance. 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?
Given no output schema, the description does not detail the JWT token format or how to use it. It also omits prerequisites (e.g., user permissions). The guidance on obtaining the installation ID is helpful, but overall completeness is moderate for a token-generation 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%, baseline 3. The description adds value for the 'software' parameter by explaining it's the WordPress installation identifier and how to obtain it, but the 'username' parameter only repeats the schema's description. Overall, it provides marginal additional 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?
Clearly states that the tool returns a JWT token for authenticating against a WordPress installation, specifying the MCP endpoint. This distinguishes it from all sibling tools, as no other tool appears to generate authentication tokens.
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 explicit context on how to use the tool: 'Provide the WordPress installation (software) identifier in the path' and even directs the user to another endpoint to obtain that ID. However, it does not explicitly state when not to use it or mention any 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?
No annotations are provided, so the description must disclose all behavioral traits. It mentions pagination but does not describe pagination behavior (e.g., page size, total counts, navigation). It also omits details about authentication requirements, rate limits, or response 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?
Two efficient sentences: the first states the core purpose, the second adds filter usage advice. No 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 description covers the basic purpose and filter usage but lacks details on pagination mechanics, output format, and any prerequisites. For a list tool, it is minimally adequate but could be more 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 covers 100% of parameters with descriptions. The description adds value by explaining how to use the domain and is_assigned filters together, which provides a semantic usage pattern beyond the schema definitions.
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 that the tool returns a paginated list of databases for a specified account, and mentions specific filters (domain, is_assigned) to find databases assigned to a domain. This distinguishes it from sibling tools that create, delete, or modify databases.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on using the domain and is_assigned filters together to find databases assigned to a specific domain. However, it does not mention when not to use this tool or alternatives, though the sibling names imply different 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 must disclose behavioral traits. It implies a read operation with 'Returns', but does not explicitly state it is non-destructive or mention any side effects, rate limits, or response 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 concise with two focused sentences: the first defines what the tool returns with format details, and the second provides a usage hint. No 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 description is adequate but lacks details on pagination, response format (no output schema), and clarification of the username parameter's context (e.g., hosting account). It covers the core functionality but leaves gaps for a list tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with parameter descriptions. The description adds limited value by reiterating the domain filter's purpose, but does not explain the username parameter beyond what the schema provides ('username 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 clearly states the tool returns remote-access rules for the account, specifying the resource (remote hosts) and format (IPv4/IPv6 or '%'). It distinguishes itself from siblings like hosting_createDatabaseRemoteConnectionV1 and hosting_deleteDatabaseRemoteConnectionV1, which deal with managing rather than listing rules.
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 guidance on using the domain filter to narrow results. However, it does not explicitly state when not to use the tool or mention alternatives, though the context of a list operation is straightforward.
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 discloses authentication requirement and pagination, but lacks details about rate limits, sorting, read-only nature, or response structure. Adequate but not thorough.
Agents need to know what a tool does to the world before 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 concise sentences that front-load the main purpose, then add scope and usage guidance. No fluff.
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 adequate for a list tool with no output schema, covering core purpose and filtering. However, missing pagination defaults, field details, and sorting options reduce 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 covers all 4 parameters with descriptions. Description adds context about filtering for targeted results, which is helpful but does not substantially extend beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'retrieve a paginated list' and the resource 'orders', specifying the scope (own and shared accounts). It uniquely identifies this tool among siblings.
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 using query parameters for filtering by statuses or order IDs, providing clear guidance. No alternative tool exists for order listing, so exclusion advice is not 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?
No annotations provided, so the description carries full burden. It discloses pagination, source (own and shared accounts), and filterability. However, it does not describe response structure, limits, or potential side effects. For a read-only list tool, this is adequate but not exceptional.
Agents need to know what a tool does to the world before calling it. Descriptions 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 sentences with the key action and scope upfront. Every sentence adds value: retrieval, source, and filtering. No fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Description covers source (own and shared accounts), pagination, and filtering. Missing: response structure (no output schema), typical usage examples, or implicit constraints. For a 6-parameter list tool with no output schema, it is moderately complete but could be more helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema covers all 6 parameters with individual descriptions (100% coverage). The description adds 'Use the available query parameters to filter results...' which groups them but adds no new semantic meaning beyond the schema. 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 'Retrieve a paginated list of websites (main and addon types) accessible to the authenticated client.' It specifies the verb (retrieve), resource (list of websites), and scope (paginated, types, accessible client). This distinguishes it from siblings like hosting_listOrdersV1 or hosting_listAccountCronJobs.
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 advises using query parameters for filtering, providing explicit context for targeted use. While it doesn't explicitly mention when not to use or contrast with alternatives, the distinct sibling tool names and the clear purpose make usage intuitive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that the operation is asynchronous, which is a key behavioral trait. However, it does not describe potential side effects (e.g., locking, downtime), the nature of the repair (idempotent?), or what the response looks like. This leaves the agent without a complete mental model.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: three sentences, no filler. The first sentence front-loads the action. Every sentence adds necessary information. 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?
The tool performs a repair operation asynchronously, but without an output schema, the description fails to specify what the tool returns (e.g., job ID, success status). It also omits guidance on re-calling or checking status. Given the tool's complexity, this gap lowers completeness to 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?
Schema coverage is 100% (both parameters have descriptions in the schema). The description repeats the schema's info about the name parameter ("Full database name as returned by the list databases endpoint"), adding no new semantic value. Baseline 3 is appropriate; no extra credit.
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 "Repairs corrupted database tables asynchronously." using a specific verb (repairs) and resource (corrupted database tables), and includes the asynchronous nature. It distinguishes this from sibling tools like create, delete, or list databases, as it addresses a specific repair use case.
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?
Explicitly says "Use when database errors, crashes, or corruption are reported." This provides clear context for when the tool is appropriate. It also gives a prerequisite: database name must be the full name from list databases endpoint. No exclusion or alternative guide, but clear enough for a focused 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?
No annotations provided. Description implies read-only behavior but does not explicitly state no side effects, auth requirements, or rate limits. Minimal behavioral disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences: purpose, filtering, ID source. No extraneous information, front-loaded with main 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?
Describes input and source of required ID but does not hint at output format or possible status values. No output schema, so description should compensate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage 100% but username parameter has generic description. Description adds value by explaining filtering behavior for 'option' and source for 'software' ID. Username remains unexplained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states verb 'show', resource 'AI option status', and context 'for Hostinger Tools plugin on specified WordPress installation'. Distinguishes from sibling tools like 'set' and other 'show' 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?
Explains how to filter by optional 'option' parameter and how to obtain the required 'software' identifier. Missing explicit mention of when not to use or alternatives like 'set' 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 provided, the description carries the full burden. It discloses that the operation is asynchronous, which is valuable, but does not mention permissions, idempotency, error conditions, or what happens if the plugin is already up-to-date.
Agents need to know what a tool does to the world before calling it. Descriptions 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 sentences, front-loaded with purpose, and each sentence adds essential information: purpose, parameter guidance, and async behavior. No fluff.
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 3 parameters and no output schema, the description covers purpose and async behavior but lacks return value details or guidance on tracking the update job after queuing. It is 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?
Schema coverage is 100%, so baseline is 3. The description adds value by explaining the 'software' parameter (WordPress installation identifier) and providing a source, but 'username' remains vague ('username parameter'), and 'slug' is fully covered by the enum.
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 'Update' and the resource 'Hostinger plugin to its latest version on a WordPress installation'. It distinguishes this tool from the sibling 'hosting_updateWordPressPluginsV1' by being specific to Hostinger plugins.
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 explains how to obtain the software identifier and notes the asynchronous nature. However, it does not explicitly state when to use this tool versus alternatives like 'hosting_updateWordPressPluginsV1'.
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 discloses read-only behavior, pagination, and sorting, but lacks details on authorization, rate limits, or side effects. It adequately covers basic behavioral traits but could be more comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: first front-loads purpose and resource, second adds filtering and sorting. No filler words, efficient and clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema or annotations, the description covers purpose, filtering, and pagination. However, it omits details on the return format or field composition, which could help an agent understand the result structure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (baseline 3). The description adds value by summarizing filtering capabilities and stating result sorting (not in schema). This enhances semantic understanding beyond individual parameter descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Retrieve' and the resource 'account action logs for the given mail order', distinguishing it from other mail log tools (e.g., access, inbound, mailbox action). It also specifies sorting by timestamp descending.
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 fetching account action logs of a mail order but does not explicitly compare to sibling tools like mail_listMailboxActionLogsV1 or provide when-not-to-use guidance. The filtering options are stated but not in a decision-making context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided. The description adds that the list is paginated and includes fields like status, plan, domain, and expiration, which is useful. However, it does not disclose rate limits, side effects, or default pagination behavior beyond what the schema 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 two sentences, efficiently stating the purpose and usage context without unnecessary words. Every sentence 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?
Without an output schema, the description mentions the included fields but does not specify the full response structure (e.g., total count, pagination metadata). For a paginated list tool, this is a notable gap, though the core functionality 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 schema already documents all parameters. The description adds no additional meaning beyond the parameter names and types, providing no extra context for their use.
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 'Retrieve' and the resource 'paginated list of mail orders associated with your account.' It distinguishes from sibling mail tools like mail_getOrderPlanV1, which focuses on a single order plan.
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 'Use this endpoint to monitor your mail services,' providing a clear use case. However, it does not mention when not to use or compare to alternative list endpoints among siblings, though the context is sufficiently clear.
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 description discloses key behavioral traits: immediate invalidation of the previous secret, that the new secret is returned only in this response, and its use as a bearer token. With no annotations, this adds significant context, though it could mention potential side effects like breaking active deliveries.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded, with no unnecessary words. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and no output schema or annotations, the description is complete—it explains the action, the behavioral implications, and the response. No further information is necessary.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description does not add meaning beyond the input schema for the single parameter 'webhookId'. The schema already documents it sufficiently (100% coverage), so 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 ('Regenerate') and the resource ('the secret of a webhook'), distinguishing it from sibling tools like mail_createWebhookV1, mail_deleteWebhookV1, etc.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps 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 guidance on when to use this tool versus alternatives, nor does it mention when not to use it. Missing context like prerequisites or comparison with other tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure. It correctly indicates PATCH-like semantics by stating 'partial update' and 'omitted fields retain values'. However, it omits details about authorization requirements, rate limits, side effects, or response format, which are important for an update operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, consisting of two sentences that clearly convey the core behavior and a usage example. Every word serves a purpose with no redundancy or unnecessary 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 description covers the essential partial update semantics but lacks information about prerequisites (e.g., webhook must exist), expected response shape (no output schema), and potential errors. Given the complexity of update operations, more context on validation or idempotency would be beneficial, though the core functionality is adequately described.
Complex tools with many parameters or behaviors need more documentation. Simple tools 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 each parameter already has a clear description in the schema. The tool description adds value by explaining the partial update behavior (fields omitted unchanged) and how to clear the description, but does not provide additional parameter-level detail beyond what the schema offers. 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 'Partially update a webhook', specifying the verb (update) and resource (webhook). It distinguishes from sibling tools like create, delete, get, and list by focusing on partial modification, which is a unique operation among mail webhook tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly explains that only included fields are changed and omitted fields retain values, guiding the agent to use this for partial updates. It also provides an example for clearing the description. However, it does not mention when a full update or alternative tool (e.g., create or delete) 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description takes on the burden of behavioral disclosure. It reveals that the operation is asynchronous ('queued') and that a success response only means acceptance, which is critical for agent expectations. It also assures that the tag and contacts are not deleted. These are meaningful behavioral insights beyond the structured 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 three sentences, front-loaded with the main purpose. The targeting options and queued behavior are stated succinctly, with no redundant phrasing. Every sentence adds essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has moderate complexity due to bulk operation and async processing, and no output schema or annotations are present. The description covers the main behavior but misses details such as whether contact_uuids and all_contacts are mutually exclusive, what the response body looks like, and potential validation rules. It is adequate but leaves gaps that an agent would need to infer.
Complex tools with many parameters or behaviors need more documentation. Simple tools 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 lists only profileUuid and tagUuid with minimal descriptions ('Profile uuid parameter', 'Tag uuid parameter'), while the description introduces targeting parameters (contact_uuids, all_contacts) that are not in the schema. This adds value by explaining how to select contacts, but also creates a mismatch with the declared schema. Since schema coverage is 100% (though tautological), a baseline of 3 is appropriate; the description neither fully compensates nor becomes misleading enough to lower 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 clearly states the action: 'Remove a tag from many contacts at once.' This is a specific verb+resource and distinguishes from the sibling tool reach_removeAContactFromATagV1 that handles a single contact. It also clarifies that the tag and contacts are not deleted, further defining 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear targeting instructions by mentioning 'contact_uuids' and 'all_contacts' options. However, these parameters are not present in the input schema, creating confusion. It does not explicitly differentiate when to use this bulk tool versus the single-contact remove sibling, nor does it state any exclusions.
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?
Discloses that the tool performs a full stop and start, and handles the case where the VM is already stopped. With no annotations, this is reasonable disclosure, though additional safety notes are 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?
Three concise sentences, each adding value: definition, edge case handling, and usage directive. 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?
Lacks mention of return values or expected response (e.g., action ID). For a simple restart, this is a gap but not critical given the tool's nature.
Complex tools with many parameters or behaviors need more documentation. Simple tools 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 description adds no extra meaning beyond the schema's 'Virtual Machine ID'. 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?
Description uses specific verb 'Restart' and resource 'virtual machine', clearly indicating a full stop and start. It distinguishes from sibling start/stop tools by implying a reboot, 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states 'Use this endpoint to reboot VPS instances', providing clear usage context. However, lacks guidance on when not to use it or mention of alternative sequences like stop then start.
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 cover behavioral traits. It warns about potential DNS resolution issues but does not disclose whether the operation is synchronous, requires permissions, or affects existing settings. More detail on side effects would improve 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 three clear sentences with no extraneous text. It starts with the action, adds a warning, then states usage. Efficiently conveys key 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 description covers basic purpose and a risk but lacks explanation of parameter behavior (e.g., what if only ns1 is provided) and does not describe return values. For a simple mutation tool with 4 params and no output schema, additional context on expected input formats 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?
Schema coverage is 100%, but parameter descriptions in the schema are minimal (e.g., 'ns1 parameter'). The description does not add explanation of expected formats (IP addresses vs domain names) or the role of optional ns2/ns3 fields. Baseline is 3 due to high coverage, but no added 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 it sets nameservers for a virtual machine. It distinguishes from sibling tools like VPS_setHostnameV1 or DNS_updateDNSRecordsV1 by focusing specifically on nameserver configuration for VPS instances.
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 includes 'Use this endpoint to configure custom DNS resolvers for VPS instances,' specifying when to use it. It also warns of consequences from improper configuration. However, it lacks explicit alternatives or when not to use it.
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 discloses that the tool returns the created cron job including its uuid for deletion, which is a behavioral trait. However, it lacks details on side effects, permissions, or constraints beyond the schema's restrictions on the command parameter.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loaded with the main action, and every word serves a purpose. No unnecessary 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 no output schema, the description adequately explains the return value (uuid for deletion). For a simple CRUD creation tool, it covers the essentials, though it omits details like validation of the schedule expression or the command restrictions, which are in 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 already provides 100% coverage with descriptions for all three parameters. The description loosely references 'schedule expression and a command' but does not add new meaning beyond the schema's parameter descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Creates' and the resource 'cron job for an Agency Plan website', with the inputs 'schedule expression and a command'. It distinguishes itself from sibling tools like delete and list by specifying the creation action and the returned uuid needed for deletion.
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 implicitly guides usage by stating that the returned uuid is required to delete the cron job, indicating a lifecycle. However, it does not explicitly provide when-to-use or when-not-to-use contexts compared to alternatives like listing or deleting cron jobs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry full burden. It discloses the creation action and the failure condition when a user already exists, but does not mention permissions, side effects, or return values. The constraint is useful, but more behavioral detail (e.g., idempotency, auth requirements) would improve transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the action, and zero wasted words. Every sentence adds value, 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.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 5 parameters (4 required), no output schema, and no annotations, the description adequately covers the core purpose and a key constraint. It does not explain prerequisite steps (e.g., listing databases), but the schema descriptions compensate. The contextual note about single user per database is valuable.
Complex tools with many parameters or behaviors need more documentation. Simple tools 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-specific details beyond the schema, such as format constraints on password or database_name. The schema already handles this, so the description does not need to repeat.
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 creates a user for an existing database on an Agency Plan website, using a specific verb and resource. It distinguishes from sibling tools like 'createAgencyPlanWebsiteDatabaseV1' by focusing on user creation and mentioning the constraint of a single non-system user per database.
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 warns that creating a user for a database that already has one fails, providing a clear when-not-to-use condition. It implicitly requires an existing database and website_uid, though it does not explicitly mention alternatives or prerequisites like listing databases.
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 full burden. It discloses two key behaviors: the deletion is permanent (irreversible) and the operation is idempotent. This is good, though it lacks information about prerequisites or side effects on the website.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise: two sentences, no wasted words. The first sentence states the action, the second adds idempotency. Information 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 low complexity (2 params, no output schema, no annotations), the description is fairly complete. It covers the action and idempotency. However, it could mention what the tool returns on success (e.g., empty response) or any required context like permissions, but overall it is 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 description coverage is 100%, with both parameters well-described in the schema. The tool description itself does not add additional meaning beyond what is already 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 the action (permanently deletes), the resource (cron job identified by uuid), and the scope (from an Agency Plan website). It also mentions idempotency, which adds clarity. This distinguishes it from sibling tools like creation or listing.
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 wants to delete a cron job, but it does not provide explicit guidance on when to use versus alternatives (e.g., when not to delete, or if modifying is better). No exclusionary context is given, which is acceptable but not exemplary.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It transparently discloses key behavioral traits: permanent deletion, asynchronous processing, immediate transition to a deleting state, and background removal of server resources. This provides strong context beyond the raw 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 two concise sentences, front-loaded with the core action and immediately providing important operational context (permanence, async behavior). No wasted words or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a delete operation with one parameter and no output schema, the description covers critical aspects: permanent, asynchronous, state transition, and background resource removal. It does not mention potential side effects on dependent resources or how to verify completion, but these are not essential for basic usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage with a single parameter 'website_uid' described as 'Agency Plan website UID'. The description adds no additional parameter-level detail beyond what the schema already provides, so the schema 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?
Clearly states the action: 'Permanently deletes an Agency Plan website.' The verb 'deletes' and resource 'Agency Plan website' are specific, and 'permanently' adds irreversibility. This distinguishes it from sibling delete tools for cron jobs, databases, and other resources.
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, such as hosting_deleteWebsiteV1 or other agency-hosting delete operations. The usage is implied by the tool name and description, but no exclusions or alternatives 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?
There are no annotations provided, so the description should indicate if the operation is read-only. While 'Returns a paginated list' implies no side effects, it does not explicitly confirm non-destructiveness for a 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 two short sentences, front-loaded with the main purpose and a single usage tip. Every word adds value with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with optional parameters and no output schema, the description covers the main behavior and a key filter. It could mention default page size or that results are limited, but overall it is sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the description does not need to add much. It restates the website_uuids filter purpose, matching the schema description without adding new 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 it returns a paginated list of domains for Agency Plan websites accessible to the authenticated client. It distinguishes from sibling list tools by focusing on domains specifically.
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 advises using the website_uuids filter to narrow results, giving clear context on when to apply it. However, it does not explicitly state when not to use this tool or compare it to alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It adds important behavioral detail about price representation in cents as integers (e.g., 17.99 as 1799). This is beyond schema and helps agents interpret output correctly. However, missing details on pagination or limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is three sentences, front-loaded with purpose, followed by key price format detail and usage context. Every sentence adds value; 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?
For a simple list tool with no output schema, the description provides essential purpose and price format. It lacks explanation of return fields or pagination, but remains adequate for agent invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with both parameters (name and category) fully documented. The description adds no new parameter information beyond the schema, meeting the baseline for high 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 tool retrieves catalog items available for order. It uses specific verb 'Retrieve' and resource 'catalog items'. Among siblings, no other tool serves this purpose, making it easily distinguishable.
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 before placing orders ('Use this endpoint to view available services and pricing before placing orders.'). However, it does not explicitly state when not to use it or mention alternatives like billing_getSubscriptionList, leaving some ambiguity.
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 is the sole source for behavioral traits. It implies a read-only operation with 'retrieve' and 'view', but lacks explicit statements about side effects, permissions, or limitations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise with two short sentences, no unnecessary words, and front-loads the action. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read tool with one parameter and no output schema, the description adequately explains what it does and how to use it. It could mention that it returns all records or requires domain ownership, 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?
Schema coverage is 100% for the single parameter 'domain', which has a description of 'Domain name'. The description adds no additional meaning beyond what the schema provides, earning 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 clearly states the tool retrieves DNS zone records for a specific domain, using specific verb and resource. It distinguishes from sibling tools like DNS_deleteDNSRecordsV1 and DNS_updateDNSRecordsV1.
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 using this endpoint to view current DNS configuration, providing context for when to use it. However, it does not explicitly state when not to use or mention alternatives, though the sibling tools imply them.
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 indicates a read operation ('Retrieve'), but doesn't disclose potential side effects or authorization requirements. For a simple list operation, this is 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?
Two sentences, zero waste, front-loaded with the main action, meeting conciseness criteria perfectly.
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 one parameter, no output schema, and no annotations, the description adequately covers the tool's purpose and use case. It lacks details like pagination or result format, but those may be implicit 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% with a single 'domain' parameter descriptively listed as 'Domain name.' 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 it retrieves DNS snapshots for a domain, distinguishing it from siblings like DNS_getDNSSnapshotV1 (single snapshot) and DNS_restoreDNSSnapshotV1 (restoration).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly says 'Use this endpoint to view available DNS backup points for restoration,' providing clear context for listing snapshots before restoration, but doesn't mention when not to use or 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, the description carries the burden of behavioral disclosure. It discloses the precondition (not yet accepted) and a key effect ('The domain stays in your account'). However, it does not mention potential side effects, error cases, or required permissions, leaving some behavioral ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three short sentences, each delivering a distinct piece of value: the action, the condition, and the effect. It is front-loaded with the core purpose and contains no redundant or fluff content.
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 cancel operation with no output schema or annotations, the description covers the essential context: what it does, when it can be used, and what happens to the domain. It could mention error behavior or response format but is otherwise complete for 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 has one parameter 'domain' fully described as 'Domain name' with 100% schema coverage. The description adds no additional parameter semantics beyond referring to 'a specified domain,' so the schema carries the full meaning. 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 a specific action ('Cancel an outgoing move') and a specific resource ('for a specified domain'). This directly distinguishes it from sibling tools like domains_startOutgoingDomainMoveV1 and domains_acceptIncomingDomainMoveV1.
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 condition for use ('only be cancelled while the receiving account has not accepted it yet') and a stated purpose ('withdraw a move you no longer want to complete'). It implies a when-not (after acceptance) but does not explicitly name alternative tools or scenarios.
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 that the tool disables domain lock and prepares for transfer, implying a write operation. However, it lacks details on prerequisites, reversibility, or side effects, which are not critical for this simple tool but could be expanded.
Agents need to know what a tool does to the world before calling it. Descriptions 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 with three short sentences, front-loading the action and purpose. Every sentence 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 simple, single-parameter tool with no output schema, the description adequately covers the purpose, usage, and effect. It could mention ownership/authentication requirements, but these may be assumed in the domain management 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 the 'domain' parameter described as 'Domain name'. The description does not add any additional meaning or 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 clearly states the tool disables domain lock, a specific action on a specific resource. It distinguishes itself from siblings like 'domains_enableDomainLockV1' by explicitly mentioning transfer preparation.
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 explains that domain lock must be disabled before transfer and that this endpoint is used to prepare domains for transfer. It provides clear context for usage, though it does not explicitly state when not to use it or list 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?
Discloses primary effect (personal info becomes visible) but does not mention other behavioral traits like ownership requirements, irreversibility, or side effects. No annotations to supplement.
Agents need to know what a tool does to the world before 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 concise sentences, front-loaded with 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 action with one parameter and no output schema, the description is fairly complete. It could mention ownership prerequisite but overall 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% and parameter 'domain' is adequately described as 'Domain name'. 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the action (disable privacy protection) and the resource (domain). It explains the effect (personal info visible in WHOIS) and distinguishes from sibling enable tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Describes when to use ('make domain owner's information publicly visible'), but lacks explicit when-not or alternatives. Context is clear, no 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 must fully disclose behavior. It explains that the lock prevents transfer until disabled, but lacks details on side effects or prerequisites like domain ownership verification.
Agents need to know what a tool does to the world before calling it. Descriptions 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 with three focused sentences: purpose, consequence, and usage recommendation. No redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool and lack of output schema, the description sufficiently covers purpose, effect, and use case. Some minor gaps like response format are acceptable.
Complex tools with many parameters or behaviors need more documentation. Simple tools 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 'domain' parameter has 100% schema coverage with a basic description. The tool description adds no extra semantic details beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Enable domain lock for the domain' and explains the effect: prevents unauthorized transfers. It distinguishes from sibling 'domains_disableDomainLockV1'.
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 says 'Use this endpoint to secure domains against unauthorized transfers,' providing clear usage context. It doesn't explicitly exclude other scenarios but implies when to use.
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 discloses an important behavioral trait: 'Requesting a new code invalidates any code retrieved previously.' This adds value beyond the schema. It does not describe other side effects or safety, but the key mutation aspect is communicated.
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 concise with three sentences that front-load the purpose and include a behavioral note. It avoids fluff and is easily 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?
Given the simplicity of the tool (one parameter, no output schema), the description covers the core functionality and key behavior. However, it omits details about the response format or any error cases, which could help an agent make better use of the output.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage with a clear description for the single parameter. The description does not add additional meaning beyond 'domain name,' so it meets the baseline but does not enhance 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 verb 'Retrieve' and the specific resource 'authorization (EPP) code for a specified domain' for the purpose of transferring a domain away from Hostinger. This is unique among sibling tools, which mostly concern VPS, hosting, or other 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states the use case: 'obtain the code required to transfer a domain to another registrar.' It also warns that requesting a new code invalidates previous ones, providing context for when to use this tool. However, it does not mention when not to use it or provide 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, but description implies a read-only operation by saying 'retrieve renewal information.' Lacks details on authentication, rate limits, or other behavioral traits, but 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?
Two sentences efficiently convey purpose and usage. No redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and single parameter, description covers what the tool does and when to use it. Could mention domain ownership requirement, but overall complete for a simple read 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?
Only one parameter (domain) with schema coverage 100% and description 'Domain name.' Tool description adds no extra meaning beyond the schema, so baseline score 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?
Clearly states the tool retrieves renewal information for a domain, including status and expiration date. Distinguishes from sibling tools like domains_getDomainDetailsV1 by focusing specifically on renewal info.
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 explicit use cases: 'build renewal automation and expiry monitoring for a single domain.' Does not explicitly state when not to use or compare with alternatives, but context is 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 full burden. It discloses a key behavior: 'Returns 404 when the domain has no move in progress,' and clarifies the move is 'you have initiated.' However, it does not describe the success response shape, other error conditions, or whether any special permissions or prerequisites are needed.
Agents need to know what a tool does to the world before calling it. Descriptions 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 sentences long, each earning its place: the first states the action, the second communicates a critical error condition, and the third gives usage context. It is front-loaded, clear, and free of 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?
For a simple single-parameter GET tool with no output schema, the description covers the core purpose, the 404 edge case, and the intended usage scenario. It does not detail the response structure, but since no output schema exists, this is less critical. Overall, it provides sufficient context 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 only parameter 'domain' is fully described in the schema as 'Domain name,' giving 100% schema coverage. The description adds the context of 'a specified domain' and 'single domain' but provides no additional format or validation details, so it 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 opens with 'Retrieve the outgoing move for a specified domain,' providing a specific verb and resource. It clearly distinguishes this single-domain retrieval from siblings like domains_getOutgoingDomainMoveListV1 by emphasizing 'a specified domain' and 'single domain.'
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 'Use this endpoint to track the status of a move you have initiated for a single domain,' giving clear operational context. It does not explicitly name alternatives or exclusions, but the 'single domain' wording separates it from the list variant, and the context is sufficient for selection.
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 description clearly discloses that this is a soft-delete operation: data is preserved and only the store is marked as deleted. This is transparent about the mutation's effect. Without annotations, the description adequately conveys the behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, consisting of two short sentences. Every word adds value: 'Soft-delete', 'owned by your account', 'data preserved', 'marked as deleted'. No extraneous 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 simplicity of the tool (one required parameter, no output schema), the description is fairly complete. It explains the soft-delete behavior, data preservation, and ownership constraint. It could mention reversibility or that the store can be restored, but this is not 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?
Schema description coverage is 100% for the single parameter 'store_id'. The description adds no additional semantics beyond what the schema already provides (e.g., 'The ID of the store to delete.'). The baseline score is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly specifies the verb 'soft-delete' and the resource 'a store owned by your account'. It distinguishes itself from a hard delete by stating that the underlying data is preserved and only the store is marked as deleted. Among siblings, it is the only store deletion tool, so differentiation is implicit.
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 indicates that the store must be owned by your account, but it does not provide explicit guidance on when to use this tool versus alternatives, such as a hard delete if one exists. No when-not-to-use or 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 discloses that output is Markdown and mentions sync aspects, but does not clarify whether instructions are general or store-specific, nor does it discuss side effects or authentication. The tool is read-only, but the scope is ambiguous.
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 action. It could add a bit more detail on scope, but it is efficient and clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters, output schema, or annotations, the description is the sole guide. It explains the basic purpose but lacks clarity on scope (general vs. store-specific) and output format details, leaving some ambiguity for a simple tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has no parameters, and schema coverage is 100% (vacuous). The description adds no parameter info, but none is needed. A baseline of 4 is appropriate given zero 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 tool retrieves step-by-step setup instructions in Markdown format for connecting a custom sales channel, listing specific sync aspects (catalog, orders, shipping, payments). It is specific and distinct from 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 description implies usage during custom sales channel setup, but does not explicitly state when to use or mention alternatives. Given context, it is clear enough for an agent.
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 provided, so the description carries full burden. It describes the tool as a read operation without side effects, but does not mention error handling (e.g., what happens if store_id is invalid) or any auth requirements. The description is adequate 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?
Two sentences, front-loaded with the core purpose. No wasted words. Efficient and clear structure.
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 getter with one parameter and no output schema, the description is fairly complete. It explains what the tool returns (payment methods, shipping, currency). Could mention the return format explicitly, but overall 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 description coverage is 100%, so the input schema already documents the parameter. The description does not add additional meaning to the parameter 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 it retrieves 'readiness metadata' including payment and shipping configuration and default currency. The phrase 'verify prerequisites before building a storefront' distinguishes it from other ecommerce tools like createStore or setStoreShipping.
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 it is 'useful to verify prerequisites before building a storefront,' providing a clear usage context. It does not mention when not to use it, but siblings don't offer an exact alternative for this metadata.
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 provided, so description carries full burden. It states the tool returns a link, implying a read operation, but does not disclose error conditions, auth requirements, or the format of the link. 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?
Three concise sentences, front-loaded with the main purpose, followed by usage guidance and a constraint. No redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple retrieval tool with one parameter and no output schema, the description covers purpose, usage, and a key constraint. Lacks details on response format or error scenarios, but is otherwise 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 clear description of 'websiteId'. The description adds context that it's for editing an existing website, but does not expand on 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 clearly states the tool returns a link for editing a website in Hostinger Horizons, with a specific verb ('Get') and resource ('link for editing website'). It distinguishes from siblings like horizons_createWebsiteV1.
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?
Explicitly says 'Use this tool when user wants to modify, edit or add new features to an existing website,' providing clear context. Implicitly excludes creation, but does not mention when not to use or alternative tools explicitly.
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 description discloses that the operation is asynchronous and a success response only means the job is queued. This is valuable beyond the lack of annotations. However, it does not mention potential side effects, permissions needed, or reversibility, which would increase transparency further.
Agents need to know what a tool does to the world before calling it. Descriptions 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 with three short paragraphs, front-loaded with the key action. Every sentence adds value: action, prerequisite, async note. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description adequately addresses the async nature and provides a prerequisite. It could mention error handling or response format, but for a simple activation tool, this is mostly 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 clear descriptions for each parameter. The description adds minimal extra meaning beyond the schema (e.g., 'slug of the installed theme'). Baseline 3 applies as 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 'Activate an installed theme on a WordPress installation' with a specific verb and resource. It distinguishes from sibling tools like hosting_installWordPressThemeV1 and hosting_listInstalledWordPressThemesV1 by focusing on activation of already installed themes.
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 a prerequisite (obtaining the software ID from a list endpoint) and mentions asynchronous behavior, but lacks explicit guidance on when to use this tool versus alternatives like installing or listing themes. No direct comparison with siblings is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must fully disclose behavioral traits. It explains automatic prefixing, which is helpful, but omits details like whether the tool checks for existing databases, required permissions, or any irreversible actions. The disclosure is adequate but not thorough.
Agents need to know what a tool does to the world before 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 with a clear first sentence stating the main purpose and a second sentence adding an important note about prefixing. No redundancy, front-loaded, and every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the number of database-related sibling tools and the lack of an output schema, the description covers the essential purpose and a key behavioral nuance. It is sufficient for an AI agent to understand when and how to use this tool, though could mention what happens on success or failure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, providing a baseline of 3. The description adds semantic value by noting automatic prefixing for 'name' and 'user' parameters, which is not fully explained in the schema descriptions. This enhances understanding beyond the schema alone.
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 creates a database with a user and password for an account, specifying the automatic prefixing behavior of database name and user. This distinguishes it from sibling tools like delete, repair, or 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for creating databases but does not explicitly state when to use this tool versus alternatives like hosting_changeDatabasePasswordV1 or hosting_deleteAccountDatabaseV1. No exclusions or context are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description compensates by disclosing that creation takes a few minutes, that datacenter_code is required for the first website on a new plan, and that subsequent websites use the same datacenter. It also advises checking the websites list endpoint for availability.
Agents need to know what a tool does to the world before calling it. Descriptions 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, front-loading the purpose, and each sentence adds value without redundancy. It covers purpose, required parameters, special condition, timing, and how to verify completion.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description provides necessary context: purpose, required/conditional parameters, asynchronous nature, and how to check results. It is sufficient 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.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds value by explaining the condition for datacenter_code (required for first website on new hosting plan) and that subsequent websites use the same datacenter, which is not in the schema description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates a website, listing the required inputs (domain, order ID) and mentioning the optional datacenter_code. However, it does not explicitly differentiate from the sibling tool 'horizons_createWebsiteV1', which may have a similar purpose.
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 guidance on when to use datacenter_code (first website on new hosting plan) and suggests checking the websites list endpoint for completion. It does not mention when not to use the tool or alternatives like 'horizons_createWebsiteV1'.
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 states the action is permanent, which is good. However, it omits details like required permissions, side effects beyond removal, or whether the operation can be undone (implied permanent). Lacks depth 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the primary action, no filler. Every sentence is informative and concise.
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?
No output schema, so description should hint at return value. It doesn't mention what the response looks like (e.g., success confirmation). However, it implicitly guides the user to use list endpoints to get the correct parameters, which aids context. Missing a note on prerequisites or error handling.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds value for 'ip' and 'name' by specifying they must be exact matches from list endpoints. However, 'username' is only described as 'username parameter' with no added context, which is minimal improvement.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it 'permanently removes a remote-access rule' and 'revoking the given host's remote access.' The action (delete) and resource (remote connection) are specific, and it distinguishes from siblings like create or list.
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?
Explains when to use: to remove a remote-access rule. Provides clear instructions on identifying the rule using the IP parameter exactly as returned from the list endpoint. However, it does not explicitly state when not to use it or mention alternatives, though for a deletion tool this is less critical.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It clearly discloses the asynchronous behavior and the need to poll for results. However, it omits details like error handling, permissions, or typical delays.
Agents need to know what a tool does to the world before 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 that efficiently convey the core action and the asynchronous nature. Front-loaded with the verb 'trigger', making it easy to parse.
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 is an async trigger with no output schema, the description adequately explains the flow. It could mention why the username parameter is needed, but it's not critically 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?
The input schema has 100% coverage and describes the parameter as 'username parameter', which is minimal. The tool description does not add any additional meaning to the parameter. Per the baseline rule for high 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 clearly states the action: trigger a background scan to detect WordPress installations. It distinguishes from sibling tools like hosting_listWordPressInstallationsV1 by indicating that this tool initiates the scan and results are fetched via polling.
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 explains that the operation is asynchronous and requires polling a different endpoint, but it does not explicitly state when to use this tool versus alternatives, nor does it mention 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It mentions returning 'output captured from the last execution', which is key, but does not mention side effects, auth needs, or error handling. The read-only nature is implied but 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?
Two sentences, front-loaded with purpose, no unnecessary words. Efficiently communicates the core action and prerequisite.
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 (get output, two parameters), the description is mostly complete. However, it lacks details on what 'output' includes (e.g., stdout, stderr) and handling of missing executions.
Complex tools with many parameters or behaviors need more documentation. Simple tools 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 uid parameter description is helpful, but username is simply 'username parameter', adding no meaning beyond the name. The tool description does not add additional parameter context.
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 ('Returns the output captured') and the resource ('cron job identified by its uid'). It distinguishes from sibling tools like hosting_listAccountCronJobsV1 by specifying it gets output of the last execution, not the list of jobs.
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 indicates prerequisite: 'The uid is returned by the list cron jobs endpoint.' It provides context on when to use this tool, but lacks explicit guidance on when not to use 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?
With no annotations, the description carries the full burden. It states it returns HTML, which implies a read operation, but does not explicitly confirm non-destructive behavior, authentication needs, or rate limits. The format disclosure is helpful but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the key action and resource. Every sentence adds value, containing no extraneous 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 lack of an output schema, the description adequately indicates the return format (HTML). It implies the full php info, but does not mention potential prerequisites or error conditions. Slightly above average completeness for a simple read tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds no additional meaning to the parameters beyond what the schema already provides (e.g., 'Domain name' and 'username 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 clearly states it returns the full phpinfo page in HTML format, which is a specific verb and resource. It also provides use cases for debugging PHP issues and inspecting the PHP environment, distinguishing it from similar tools like hosting_getPHPDetailsV1.
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 when to use the tool ('to debug PHP issues or inspect the complete PHP environment'), providing clear context. However, it does not include when not to use it or mention 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 provided, so description carries full burden. It discloses that the tool returns a link (not the database itself) and requires the full database name. It implies the link provides direct access but does not mention expiration, authentication requirements, or side effects. Adequate but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences. The first sentence states the core purpose, and the second provides usage guidance and a constraint. No wasted words, front-loaded with 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?
Covers main use case and parameter constraints. For a simple link generation tool without output schema, it explains what is returned (a link) and when to use. Missing details like link expiration or format, but still fairly complete given the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema already describes both parameters (name and username) with 100% coverage. The description reinforces the database name constraint, adding value. However, it does not add information about the username parameter beyond what the schema provides (which is minimal). 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 it returns a direct sign-on link to phpMyAdmin for a specified database. It uses specific verb 'Returns' and resource 'direct sign-on link to phpMyAdmin'. Among siblings with many database management tools, this uniquely provides a visual interface link, distinguishing itself well.
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?
Explicitly states when to use (visual database interface needed for SQL queries, imports, exports, table management) and provides a constraint (database name must be full name from list databases endpoint). However, it does not mention when not to use or suggest alternatives, which could improve guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It adds behavioral context by stating that the list is filtered by 'available datacenter capacity and hosting plan of your order' and that the first item is the best match. However, it does not disclose error conditions, rate limits, or output format.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no unnecessary words. The first sentence defines the purpose, and the second adds an important behavioral detail about the first item being the best match. Every sentence is essential 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 single-parameter tool with no output schema, the description adequately explains what the tool returns (list of datacenters) and the important nuance of the first item being the best match. It is missing details like the structure of each datacenter, but overall it is sufficiently complete for an agent to understand functionality.
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 only describes 'order_id' as 'Order ID'. The description adds meaning by explaining that the datacenter list is filtered based on the order's capacity and hosting plan, and that the first result is the best match for that specific order. This surpasses the minimal schema description.
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 'Retrieve' and the resource 'list of datacenters available for setting up hosting plans', with specific context about capacity and plan matching. It distinguishes itself from sibling tools like VPS_getDataCenterListV1 by focusing on hosting plan and 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when setting up hosting plans and needing datacenter recommendations, but does not explicitly state when not to use it or provide alternatives like VPS_getDataCenterListV1. The guidance is implied but not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that the response includes status, updates, and vulnerabilities, which is good. However, it does not mention whether the operation is read-only, any authentication requirements, or potential side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (two sentences) and front-loaded with the main purpose. Every sentence is necessary and informative 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?
Given the lack of output schema, the description gives a reasonable overview of what the response includes (status, updates, vulnerabilities). It does not mention pagination or ordering, but for a list tool with a straightforward purpose, it is fairly 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%, so baseline is 3. The description adds value by explaining where to get the 'software' identifier, but does not elaborate on 'username' or 'category' beyond what the schema provides. The added context is marginal.
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 plugins), the resource (WordPress installation), and the scope (installed plugins). It distinguishes itself from sibling tools like 'listAvailableWordPressPlugins' and 'listInstalledWordPressThemes' by specifying 'installed' and including 'status, available updates and known vulnerabilities'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on how to obtain the required 'software' identifier from another endpoint. While it does not explicitly list alternatives or when not to use the tool, the context is clear and the instruction is helpful.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses that the output includes status, updates, and vulnerabilities, implying a read operation. However, it does not explicitly state that the tool is safe and non-destructive, nor does it describe any side effects. The description 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 clear, front-loaded sentences with zero wasted words. The description is efficient and to the point.
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 no output schema, the description adequately covers output content (status, updates, vulnerabilities). Input parameters are explained. While sibling differentiation could be stronger, the overall context is sufficient for an agent to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds value by explaining the 'software' parameter and how to get it, but the 'username' parameter is only described as 'username parameter' with no additional context. Overall, minimal extra meaning beyond 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 it lists installed themes on a WordPress installation, including status, updates, and vulnerabilities. The verb 'List' and resource 'installed themes' are specific. The tool name and description distinguish it from siblings like hosting_listWordPressThemesV1 (likely for available themes).
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 guidance on how to obtain the required software identifier from another endpoint. However, it does not explicitly state when to use this tool versus alternatives like hosting_listWordPressThemesV1, though the distinction is implied by the name and context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must convey behavioral traits. Describes a read operation ('Show') and mentions output (version and vulnerabilities). Does not elaborate on side effects, authentication needs, or rate limits, which is acceptable for a simple 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?
Two concise sentences. First sentence states purpose; second sentence provides parameter sourcing advice. No redundant or unnecessary 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?
No output schema is present, but description indicates the return includes core version and known vulnerabilities. For a simple retrieval tool, this is sufficient. Lacks details about return format or potential errors, but overall 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?
Schema covers both parameters with descriptions (100% coverage). Free-text description adds value for 'software' by explaining how to obtain the identifier, but does not enrich 'username' beyond the schema. Thus, description adds some additional context but not extensively.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states verb 'Show' and resource 'WordPress core version' and 'known vulnerabilities'. Distinguishes from sibling tools like hosting_updateWordPressCoreV1 or hosting_listAvailableWordPressCoreUpdatesV1 by focusing on current version and vulnerabilities.
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 explicit guidance on how to obtain the required software identifier from another endpoint. Implies usage context for checking version and vulnerabilities, but does not explicitly exclude alternative scenarios.
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 provided, so description carries full burden. It describes the action but does not disclose side effects (e.g., site downtime), permissions needed, rate limits, or response format. The behavior is straightforward but lacks complete 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?
Two sentences, front-loaded with main purpose, no redundant information. Every sentence serves a purpose: stating the action and providing the key prerequisite.
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 toggle with no output schema, the description covers essential aspects: purpose, required parameter source, and dependency. Missing response details (e.g., status code, confirmation message) but acceptable for this 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 covers all three parameters with descriptions (100% coverage). The description adds value for the 'software' parameter by explaining how to obtain it, but does not clarify 'username' beyond the schema's vague 'username parameter'. Baseline 3, marginal improvement.
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 specifies the verb (enable/disable), resource (maintenance mode for WordPress installation), and the condition (based on enabled flag). It distinguishes from sibling tools like hosting_showMaintenanceStatusV1 by focusing on toggling vs. viewing status.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context: provide the WordPress installation identifier obtained from a specific endpoint. It implies when to use (when toggling maintenance mode) but does not explicitly state when not to use or mention alternatives like showMaintenanceStatus.
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?
Discloses that the operation is asynchronous and successful response only means job queued. No annotations provided, so description adds some behavioral context but lacks details on side effects or error handling.
Agents need to know what a tool does to the world before 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 concise sentences, each adding value: action, ID source, async behavior. 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?
Covers main aspects: action, required identifier, async nature. Lacks details on error handling or what happens if plugin doesn't exist, but sufficient for 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 coverage is 100%, so baseline 3. Description does not add significant additional meaning beyond the schema definitions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the action (uninstall plugins) and target (WordPress installation). Distinguishes from sibling tools like install, activate, deactivate, etc.
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?
Explains how to obtain the required software identifier from a specific endpoint. Notes the async nature but does not provide when-to-use versus alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses that the operation is asynchronous and the response only indicates job queuing. This is valuable behavioral context missing from annotations (none provided).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Concise at four sentences with clear front-loading of purpose, followed by essential procedural details. 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?
Explains async behavior but lacks information about the response structure (e.g., job ID). The username parameter remains unclear. Adequate for a straightforward uninstall tool but could be more complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, but the description does not add meaning beyond the schema. The 'username' parameter is poorly described in both schema and description ('username parameter'), leaving ambiguity.
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 using a specific verb 'Uninstall' and resource 'themes from a WordPress installation', effectively distinguishing it from sibling install and 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance on obtaining the required software identifier via a GET endpoint and notes the asynchronous nature. No explicit alternatives or exclusions are given, but the context is sufficient for typical use.
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 discloses the asynchronous nature of the operation, but lacks details on potential destructive impact, authentication requirements, or rate limits. This is adequate but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with three focused sentences covering purpose, identifier source, and async behavior. Every sentence adds value with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given moderate complexity (4 params, no output schema), the description covers the core action, identifier retrieval, and async queuing. Missing details about response format or error handling, but these are not critical for a queued 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%, baseline 3. The description repeats the software identifier guidance already present in the schema and does not add meaningful semantics beyond the schema descriptions. No significant value added.
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 'Update' and the resource 'WordPress core' with scope 'for the specified installation'. It distinguishes this from sibling tools like hosting_installWordPressV1 and hosting_listAvailableWordPressCoreUpdatesV1 by specifying the action 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?
The description provides clear context on how to obtain the software identifier via a GET endpoint and indicates two update modes (minor or specific version). However, it does not explicitly exclude alternatives or provide 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.
Behavior4/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 notably reveals that the operation is asynchronous, meaning a success response only indicates queuing. This is a critical behavioral trait that helps the agent set correct expectations, though it could mention potential error scenarios.
Agents need to know what a tool does to the world before calling it. Descriptions 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 sentences with no wasted words. The first sentence states the purpose, the second provides essential guidance, and the third adds an important behavioral note. Information is front-loaded and easy to parse.
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 and absence of an output schema, the description covers the core purpose, resource identification, and async behavior. It is sufficient for an admin task, though it could include details about expected results or failure modes 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 coverage is 100%, but the description adds value mainly for the 'software' parameter by explaining how to obtain the identifier. For 'plugins', it largely repeats the schema description. For 'username', neither the schema nor the description provides meaningful clarification, leaving a gap.
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) and resource (installed plugins on a WordPress installation), using specific verbs and nouns. It distinguishes from sibling tools like install or deactivate by focusing on updating to latest versions.
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 guidance on obtaining the software identifier from a GET endpoint, which helps the agent locate the correct resource. However, it does not explicitly state when to use this tool versus alternatives (e.g., install vs update), nor does it list conditions or prerequisites beyond the identifier.
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 effectively discloses key behavioral traits: confirmation requirement, email to mailbox, and activation only after confirmation. It adds value by explaining the activation process and domain limit, though it does not detail error conditions or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three concise, well-structured sentences that front-load the purpose. Every sentence provides necessary information without waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a creation tool with moderate complexity and no output schema, the description covers the core action, confirmation flow, and domain limit. It lacks explanation of return values or prerequisites, but is largely complete for an agent to understand the tool's function.
Complex tools with many parameters or behaviors need more documentation. Simple tools 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 parameters with a clear description of mailboxId as 'Mailbox resource ID'. The description adds no additional meaning beyond the schema, so baseline score 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'create' and the resource 'catch-all', specifying it routes messages to unknown addresses to a given mailbox. It distinguishes from sibling tools like mail_deleteCatchAllV1 and mail_listCatchAllsV1 by detailing the creation and confirmation process.
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?
It implies usage when setting up a catch-all for a domain and mentions the one-per-domain constraint. However, it does not explicitly state when not to use it or name alternatives, leaving usage guidance somewhat implied.
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?
Discloses key behavioral aspects: destination gets confirmation email, forwarding only active after confirmation. Without annotations, this is good transparency, though missing details like whether existing forwarders are affected.
Agents need to know what a tool does to the world before 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, no fluff, critical information front-loaded. 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?
Covers purpose, creation behavior, and activation requirement. For a tool with no output schema, this is nearly complete. Lacks details on error scenarios or what happens if destination is invalid.
Complex tools with many parameters or behaviors need more documentation. Simple tools 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%, description adds no new information beyond the parameter names and existing descriptions. 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?
Clearly states action (create), resource (forwarder from mailbox to destination), and includes confirmation process. Distinguishes from sibling tools like list/delete/forwarder.
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?
Implies usage context for creating forwarders but does not explicitly contrast with alternatives like mail_createAliasV1 or mail_createCatchAllV1. No 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.
Behavior3/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 plaintext tokens are never returned in the list, only at creation. This is important but missing other behavioral traits like read-only nature or authentication 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 two sentences, front-loaded with the main action, and every word adds value. 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?
For a simple list tool with optional parameters, the description covers purpose, filtering, pagination, and a security note. It does not explain the return format or error handling, but given no output schema and typical list tool expectations, it is reasonably 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%, so the schema already documents all three parameters. The description adds context about optional filtering by order and pagination, but no additional semantics beyond what the schema 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 retrieves a paginated list of API tokens, with optional filtering by order. It distinguishes from token creation and revocation siblings by focusing on listing, and includes a security note about plaintext tokens not being included.
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 use (listing tokens, optionally filtered by order) but does not explicitly state when not to use it or mention alternatives like create/revoke. However, the sibling tool names imply 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?
No annotations are provided, so the description carries the full burden. It discloses that the list is paginated and that usage numbers may lag behind live values. It does not mention what happens if the orderId is invalid or any potential errors, which would add transparency. Overall, it's 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 two sentences long. The first sentence clearly states the action and resource; the second elaborates on the use case and data included. No unnecessary words, and it is front-loaded with the core 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?
Given 5 parameters and no output schema, the description explains what the returned data includes (status, enabled protocols, attached resource counts, usage numbers). It is complete for a list endpoint, though it could explicitly mention pagination parameters (already in schema).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters. The description adds context about pagination and usage lag but does not add new meaning beyond the schema descriptions. 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 'Retrieve a paginated list of mailboxes belonging to a mail order,' which specifies the verb (retrieve), resource (list of mailboxes), and scope (belonging to a mail order). Among sibling tools like mail_listAliases and mail_listForwarders, this uniquely identifies a list of mailboxes.
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 advises using this endpoint 'to monitor mailboxes of your mail service,' providing clear context on when to use it. However, it does not explicitly mention when not to use it or suggest alternative sibling tools, though the context is sufficient for an agent.
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 discloses that the webhook secret is never included in the list response—a key behavioral detail. It also implies pagination and filtering, but does not cover authorization or rate limits.
Agents need to know what a tool does to the world before 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: purpose (paginated list), filtering, and a behavioral note. No fluff, front-loaded 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?
Adequately covers the tool's behavior, parameters, and pagination. Lacks details like default page size or sort order, but no output schema is needed. Sufficient for a simple list endpoint.
Complex tools with many parameters or behaviors need more documentation. Simple tools 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 parameters are already documented. The description reiterates filtering by mailbox and status but adds no new semantic meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves a paginated list of webhooks for a given mail order, with specific verb and resource. It distinguishes from sibling webhook tools like mail_getWebhookV1 (single) and mail_createWebhookV1.
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 listing webhooks but does not explicitly mention when to use alternatives (e.g., mail_getWebhookV1 for a single webhook). No when-not guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses that the tool targets unconfirmed catch-alls, which is a behavioral constraint. However, it does not mention side effects, idempotency, permissions, or what happens if the catch-all is already confirmed, limiting transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence of 14 words with no redundant information. Every word contributes to clarity.
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 parameter and no output schema, the description sufficiently covers the main action and target state (unconfirmed). It could mention prerequisites or error conditions, but the core information is present. Given the low complexity, this 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 input schema has 100% description coverage for the single parameter 'catchallId'. The tool description adds no additional meaning beyond the schema's 'Catch-all resource ID', so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Resend' and the resource 'confirmation email to the mailbox address of an unconfirmed catch-all'. It distinguishes from sibling tools like mail_resendForwarderConfirmationV1 by specifying the resource type (catch-all vs 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 implies when to use the tool: when there is an unconfirmed catch-all needing a resend of the confirmation email. It does not explicitly mention when not to use it, but the condition 'unconfirmed' provides a clear scope. Lack of explicit alternatives or exclusions prevents a higher score.
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 must convey behavioral traits. It states immediate loss of access and irreversibility, which are critical for a revocation action. However, it does not detail 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 two sentences long with no superfluous text. It front-loads the action and immediately addresses key consequences.
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 action with no output schema, the description adequately covers the core behavior and consequences. It could mention that the token ID must match an existing token, but the schema already indicates it is required.
Complex tools with many parameters or behaviors need more documentation. Simple tools 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 the tokenId parameter with 100% coverage. The description does not add further meaning or context about the parameter beyond what the schema 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 action ('Revoke an API token') and specifies the resource (Hostinger Email API). It distinguishes from sibling tools like create or list by indicating this is a destructive operation that cannot be undone.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description notes the action cannot be undone, implying caution, but does not explicitly state when to use (e.g., compromised tokens) or when not to use (e.g., tokens still needed). No alternatives are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure. It explicitly states that membership changes as contacts change and that creating a segment does not modify any contact, which is valuable beyond the basic 'create' action. It doesn't cover every edge but provides solid transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two sentences that front-load the action and then add one clarifying concept. No filler or redundant detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is conceptually complete for a create operation: it defines the resource, explains its dynamic nature, and reassures that contacts aren't modified. Given the rich parameter schema, only the return value and any permission requirements are left unspecified, which is a minor 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 coverage is 100%, so the parameters are well-documented in the input schema itself. The description adds general context about conditions but doesn't provide additional parameter-level semantics beyond what the schema already specifies.
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 segment in a profile', using a specific verb and resource. It further clarifies that a segment is a saved set of conditions rather than a fixed list, which distinguishes it from related tools that create contacts, tags, or static lists.
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 explains the concept of a segment and when you'd conceptually use it (creating a dynamic, condition-based segment). However, it does not explicitly compare with sibling tools like reach_createANewContactSegmentV1 or indicate when NOT to use this tool, so usage guidance remains implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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. It usefully discloses that tags and custom contact field values are included, but it does not mention error behavior, permissions, or explicitly confirm read-only semantics. No contradictions with annotations (none provided).
Agents need to know what a tool does to the world before 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 main purpose. The second sentence adds relevant return-value detail without redundant phrasing.
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-contact getter with two parameters and no output schema, the description adequately explains the main return content. It could be more explicit about error handling or the UUID relationship, but overall is complete for typical use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, so a baseline of 3 applies. However, the parameter descriptions are tautological ('Contact uuid parameter'), and the tool description adds no additional meaning about the relationship between profileUuid and contactUuid.
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 opens with 'Get the full details of a single contact,' clearly stating the specific verb and resource. It further specifies the response includes tags and custom contact field values, which distinguishes it from list/update/delete contact tools among siblings.
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 'single contact' implies use when you need one contact's full details rather than a list. This provides clear context, though it does not explicitly name alternative tools or exclusion scenarios.
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 provided, so description carries burden. Mentions attaching existing keys and enabling SSH auth, but lacks details on side effects, prerequisites (e.g., VM state), or behavior if keys already attached.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Very concise: two short sentences and a final line. Front-loaded with action, no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given low complexity and no output schema, covers essential purpose and use case. Lacks details like prerequisites or error handling, but acceptable for a simple attachment 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%, so baseline is 3. Description adds context that keys are from account and multiple can be attached, but doesn't add new meaning beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the action: attach existing public keys to a specified VM. Distinguishes from sibling tools like VPS_createPublicKeyV1 and VPS_getAttachedPublicKeysV1 by focusing on attaching existing keys.
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 explicit use case: to enable SSH key authentication. However, does not mention when not to use or compare with alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses an important side effect: VMs with this firewall activated will lose sync and must be synced manually. This goes beyond basic function. However, it does not mention other behavioral traits like rate limits, immediate effect, or authentication requirements.
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 mostly concise with 4 sentences, front-loading the purpose. The last sentence ('Use this endpoint to add new security rules to firewalls') is slightly redundant with the first, but overall it is well-structured and to the point.
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 there is no output schema, the description should explain return values or confirmations, but it does not. It also does not mention the need to use VPS_syncFirewallV1 after creation, although it implies manual sync is required. For a medium-complexity tool, some gaps remain, making it moderately 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 covers 100% of parameters with descriptions. The description does not add any additional meaning beyond what is already in the schema. Baseline score of 3 is appropriate since the schema already provides clear 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's purpose: 'Create new firewall rule for a specified firewall.' It distinguishes from sibling tools like VPS_createNewFirewallV1 (which creates the firewall itself) and VPS_deleteFirewallRuleV1 or VPS_updateFirewallRuleV1 by focusing on rule creation.
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 explains when to use the tool: to add accept rules for ports because the default firewall drops all incoming traffic. It also warns about VMs losing sync and needing manual sync. However, it does not explicitly mention when not to use it (e.g., for modifying existing rules) or compare with VPS_updateFirewallRuleV1, but the context is clear enough.
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 exist, so description carries burden. It explains the effect (reverse DNS no longer returns hostname) but lacks details on permissions, reversibility, or potential side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences with no redundancy: purpose, effect, and usage guidance are front-loaded and 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?
Given no output schema, the description adequately explains the outcome and purpose. Missing only minor details like error handling or prerequisites, but sufficient for a simple delete operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with basic descriptions. Description adds minimal context by linking 'virtualMachineId' to 'specified virtual machine', but doesn't elaborate on 'ipAddressId' or how to obtain these IDs.
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 deletes a PTR record for a specified VM, and distinguishes from the create counterpart (VPS_createPTRRecordV1) among siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly says 'Use this endpoint to remove reverse DNS configuration', providing clear usage context, but does not explicitly mention when not to use it or list 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 full burden. It implies a read operation ('retrieve'), which is safe, but does not disclose any additional behavioral traits such as authentication requirements, rate limits, or data consistency guarantees. The lack of contradiction and basic safety inference keeps it at a mid 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 two sentences: first defines the purpose concisely, second provides usage guidance. No redundant words, every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity (2 parameters, no output schema, no annotations), the description adequately covers the tool's purpose and use case. It could mention pagination or response format, but it's not severely incomplete for a straightforward read operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema coverage is 100%, with both parameters (virtualMachineId, page) described. The description does not add any meaning beyond the schema, so 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 'Retrieve public keys attached to a specified virtual machine', specifying the action (retrieve), resource (public keys), and scope (attached to a specified virtual machine). This distinguishes it from sibling tools like VPS_getPublicKeysV1 (likely all keys) and VPS_attachPublicKeyV1.
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 second sentence 'Use this endpoint to view SSH keys configured for specific VPS instances' provides clear context for when to use this tool. However, it does not explicitly mention when not to use it or name alternatives like VPS_getPublicKeysV1 for listing all keys.
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 fully disclose behavior. It states 'Retrieve' and 'view', indicating a read-only operation. But it does not mention authentication, error handling, or response structure. 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?
Two sentences, concise and front-loaded. No redundant 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 retrieval tool with one parameter and no output schema, the description is sufficient. It covers the core action. Missing some behavioral details but adequate for the 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% with one parameter fully described. The description adds 'by its ID', which matches the schema but does not add new detail beyond the schema's description. 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 clearly states the verb 'Retrieve' and resource 'post-install script by its ID', and adds 'view specific automation script details'. This distinguishes it from sibling tools like VPS_createPostInstallScriptV1 and VPS_getPostInstallScriptsV1.
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 says 'Use this endpoint to view specific automation script details', which implies when to use. However, it does not explicitly mention when not to use or suggest alternatives like listing scripts. The context from sibling tools partially compensates.
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 that logs are aggregated from all services, recent, organized by service name with timestamps, and limited to 300 entries. It does not mention side effects, rate limits, or whether logs are cleared, but the description is sufficient for a read-only log retrieval 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 three sentences, front-loaded with the main action. Each sentence earns its place: definition, output details, use cases. No redundant or superfluous text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description adequately describes the return format (log entries, service name, timestamps, last 300). It covers the core what and why, but could mention prerequisites (e.g., project must exist, VM running) or whether logs are from Docker.
Complex tools with many parameters or behaviors need more documentation. Simple tools 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 described). The description adds no additional semantics beyond the schema; it does not explain the relationship between virtualMachineId and projectName or provide formatting details. 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: 'Retrieves aggregated log entries from all services within a Docker Compose project.' It specifies the resource (Docker Compose project logs) and distinguishes from siblings like VPS_getProjectContainersV1 by focusing on logs rather than containers or contents.
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 states when to use: 'for debugging, monitoring application behavior, and troubleshooting issues across your entire project stack.' It provides clear context but does not specify when NOT to use it or name specific 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 carries the full burden. It indicates a read-only operation ('Retrieve'), but does not disclose any additional behaviors like authentication requirements, rate limits, or return format. The description is adequate but lacks extra context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences. The first sentence states the purpose, and the second provides usage context. There is no unnecessary text, and every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one optional parameter, no output schema), the description is nearly complete. It could mention that the result is a list of public keys or that pagination may be needed, but the current description is sufficient for an agent to understand basic functionality.
Complex tools with many parameters or behaviors need more documentation. Simple tools 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 is 'page' with schema description 'Page number', and schema coverage is 100%. The description does not add any further meaning or usage guidance beyond what the schema already provides, so 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 explicitly states 'Retrieve public keys associated with your account', which is a specific verb-resource pair. It distinguishes from sibling tools like VPS_getAttachedPublicKeysV1 (which retrieves keys attached to a specific VM) and VPS_createPublicKeyV1/VPS_deletePublicKeyV1.
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 includes 'Use this endpoint to view available SSH keys for VPS authentication', providing clear context for when to use. However, it does not explicitly exclude alternatives or mention when not to use, such as when needing keys attached to a specific virtual machine.
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 provided, so description must cover behavior. It discloses idempotency but lacks details on async execution, permissions, or response format. Adequate but could be more comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences: purpose, idempotency clarification, and usage directive. No wasted words, front-loaded with key info.
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 low complexity (1 param, no output schema), the description covers core action and idempotency. Lacks context on what happens after starting (e.g., how to check status), but sibling tools likely cover that.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The sole parameter is documented in the schema (100% coverage). The tool description adds no extra meaning beyond what the schema 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 action: 'Start a specified virtual machine' and specifies it's for 'power on stopped VPS instances'. It distinguishes from siblings like VPS_stopVirtualMachineV1 and VPS_restartVirtualMachineV1.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly directs to 'Use this endpoint to power on stopped VPS instances' and mentions idempotency. While it doesn't contrast with siblings, the context is clear for typical use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses that the operation fails if the VM is not in recovery mode, but does not elaborate on other behavioral traits such as auth requirements, whether it is asynchronous, or if other side effects occur.
Agents need to know what a tool does to the world before calling it. 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 three concise sentences, each adding value: the action, a precondition, and the purpose. No extraneous 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 has one parameter and no output schema, the description sufficiently covers the context: it explains when it works, when it fails, and what it achieves. It could mention potential asynchronous behavior or expected response, but is not 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 already describes the parameter 'virtualMachineId' as 'Virtual Machine ID' with 100% coverage. The description adds no additional semantic value beyond referencing 'specified virtual machine', which is redundant.
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 'stop recovery mode' for a specified VM, and distinguishes it from sibling tools like VPS_startRecoveryModeV1. It also explains the failure condition and the outcome of returning to normal 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 explicitly indicates when to use: to exit system rescue mode and return to normal. It also states that the operation fails if the VM is not in recovery mode, implying it should only be used when appropriate. However, it does not mention alternatives or when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 idempotency (no effect if not installed) but does not detail permissions, side effects, or whether all Monarx data is removed.
Agents need to know what a tool does to the world before 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 concise sentences: purpose, idempotency, and context. No redundant information, earning top marks 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 uninstall tool with one parameter and no output schema, the description is largely complete. It could mention it is the inverse of installMonarx, but overall 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 sole parameter virtualMachineId is fully covered by the schema description. The description adds minimal extra meaning beyond specifying the VM, meriting 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 specifies the verb 'Uninstall,' the resource 'Monarx malware scanner,' and the context 'on a specified virtual machine.' The counterpart VPS_installMonarxV1 exists among siblings, making differentiation 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 notes that if Monarx is not installed, the request has no effect, implying safe usage. However, it lacks explicit guidance on when to use versus alternatives and does not mention prerequisites like VM existence.
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?
Describes preserving data volumes and applying changes from compose file. Without annotations, it lacks details on downtime, error handling, or effect on existing containers. 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?
Three sentences, focused and front-loaded with the main verb. 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?
Covers the action, use cases, and data preservation. No output schema, so return values not required. Minor gap: no mention of what happens after update (e.g., container restart).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers both parameters with descriptions (projectName and virtualMachineId). Description does not add additional meaning to these parameters beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it updates a Docker Compose project by pulling latest images and recreating containers. It distinguishes from related sibling tools like create, delete, restart, start, stop.
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?
Explicitly mentions use cases: deploy updates, apply config changes, refresh images. Does not include explicit when-not-to-use or alternatives, but the context is clear given sibling names.
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 discloses that the endpoint only places orders and uses default payment method if none provided. It does not mention idempotency, rate limits, or error handling, which are important 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 multiple sentences but each adds meaning: purpose, catalog reference, default behavior, and separation of concerns. It is front-loaded and not verbose.
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 3-parameter tool with no output schema, the description covers purpose, parameter sources, default behavior, and post-order actions. It lacks response format details but is adequate for agent use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions, but the description adds value by explaining how to find item_id via the catalog endpoint and clarifying payment_method_id optionality and default behavior.
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 creates a purchase order for any Hostinger product, distinguishing it from product-specific purchase endpoints among siblings (e.g., VPS_purchaseNewVirtualMachineV1, domains_purchaseNewDomainV1). It uses specific verbs and resources.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says to use this endpoint to purchase any product and provides context: it only places the order, not provisioning. It references the catalog endpoint for item IDs. However, it does not explicitly exclude specific scenarios or name alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the responsibility. It discloses the requirement for both old and new registrant confirmation and indicates this is a read-only status check. It does not detail permissions or response format, but the key behavior is communicated.
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 consists of three concise sentences. The first states the purpose, the second explains the verification process, and the third reinforces the use case. Slight redundancy between the first and third sentences, but overall efficient 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?
Given the tool's simplicity (one parameter, no output schema), the description provides sufficient context: what the tool does, the two-party confirmation rule, and when to use it. It lacks explicit return value details, but for a status-check tool this is a minor 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 coverage is 100%: the only parameter 'domain' is described as 'Domain name'. The description adds no additional parameter 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 clearly states the action ('Retrieve a pending IRTP verification for a domain') and explains the context of IRTP verification (both registrants must confirm). This distinguishes it from related tools like cancelPendingIRTPVerificationV1.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage guidance: 'Use this endpoint to check the status of a WHOIS change awaiting registrant confirmation.' It does not name alternatives or explicitly say when not to use it, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden of behavioral disclosure. It does add useful context: the default is TLD-specific and pre-selected during registration. However, it does not disclose what happens when a default already exists (e.g., whether it is overwritten), nor does it mention any permissions or side effects. This is adequate but not rich, so a 3 is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions 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: one main sentence followed by two short explanatory sentences. It is front-loaded with the primary action and includes only relevant context about TLD association and the benefit of avoiding repetitive contact selection. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and no output schema, the description is complete. It explains the core action, the concept of the default and TLD, and the practical benefit. It does not need to explain return values (none specified) or provide additional details that would be redundant in such a simple 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 single parameter whoisId, though its description is minimal ('WHOIS ID'). The tool description adds context by referring to 'WHOIS contact profile', which helps clarify the parameter's role, but it does not add additional syntax or constraints beyond the schema. The baseline is 3 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 starts with a specific verb+resource: 'Set WHOIS contact profile as default.' It further clarifies the behavior by explaining that the default is pre-selected for the TLD it belongs to when registering new domains. This clearly distinguishes it from sibling tools like domains_unsetDefaultWHOISProfileV1 and domains_deleteWHOISProfileV1.
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 this endpoint to avoid picking contact information for every registration.' This explains when to use the tool, but it does not explicitly mention alternatives or exclusions (e.g., when to use the unset sibling). Therefore it has clear context but lacks explicit exclusions/alternatives, matching a 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?
No annotations provided, so description must carry the burden. It discloses basic behavior but omits side effects, permissions, or error handling.
Agents need to know what a tool does to the world before 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 redundant information, efficiently conveying purpose and key usage 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?
Without output schema or annotations, the description provides basic completeness but lacks details on return values, permissions, or error conditions.
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?
All parameters are described in schema; description adds valuable context like '%' for any host and full database name from list databases endpoint.
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 'allows a remote host to connect' and the resource 'specified database', distinguishing it from sibling tools like hosting_listDatabaseRemoteConnectionsV1.
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 (need to allow remote host connection) and gives constraints on IP and database name, but does not explicitly exclude alternatives or scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the archive upload, auto-detection, size limit, exclusion advice, and polling use of the returned uuid. Lacks details on failure handling or permissions, but overall transparent.
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 well-structured and front-loaded with the core action. It includes an example, which adds value but slightly increases length. No unnecessary sentences.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 10-parameter tool with no output schema, the description explains the overall process, output use, and archive preparation. It could mention whether builds are overwritten or versioned, but is generally 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%, so baseline is 3. The description adds context about overrides taking precedence and archive preparation, but no per-parameter details 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 uploads an archive, auto-detects build settings, and starts a Node.js build. It emphasizes this as the recommended single-step approach, distinguishing it from other deployment methods like hosting_deployJsApplication.
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 using this tool (recommended for Node.js deployment) and includes practical advice on excluding directories. However, it does not explicitly state when not to use it or compare with 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 full burden. It describes the return value but does not explicitly state that it is a read-only operation with no side effects. However, 'Returns' implies no modification, so it is adequate but not fully 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?
Two sentences: first enumerates the output, second gives usage guidance. No wasted words, front-loaded with key information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (2 params, no output schema), the description is complete: it explains what is returned, what is included in the output, and when to use it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the description does not add meaning beyond the schema for the parameters domain and username. It provides context about the output but not parameter-specific 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 it returns the full PHP configuration, including specific elements like current version, available versions, extensions, and options. This distinguishes it from sibling tools like hosting_updatePHPVersionV1 or hosting_getPHPInfoV1.
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 advises to use it before updating PHP version, extensions, or options, providing clear usage context. It does not mention when not to use or differentiate from hosting_getPHPInfoV1, which might be similar.
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 is the sole source. It reveals pagination and filtering but does not mention authorization needs, rate limits, or non-destructive nature. The phrase 'each build represents a single run' adds context, but more behavioral details could be 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?
Four sentences, front-loaded with the main purpose. No redundant information. Every sentence contributes meaningfully.
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 purpose, filtering, and next steps (logs). However, it lacks details on pagination behavior (page/per_page usage), expected response fields (beyond uuid), and error conditions. For a list tool with no output schema, 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?
Schema coverage is 100% with basic descriptions. The description adds value by explaining the 'states' parameter's filtering capability and linking the 'uuid' from builds to the logs endpoint, providing workflow context beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Retrieve' and the resource 'paginated list of Node.js build processes for a specific website'. It distinguishes from sibling tools like 'hosting_getNodeJSBuildLogsV1' and 'hosting_listJsDeployments' by specifying 'build processes' and linking to logs endpoint.
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 explains how to use the 'states' parameter to filter and directs to 'Get Node.js Build Logs' for output polling. This provides clear context on when to use this tool and when to use an alternative, though explicit exclusions are not stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It implies a read-only listing operation, but does not disclose any permissions, rate limits, or potential side effects. The behavior is straightforward, but lacking full transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with two sentences. The first states the purpose, the second tells how to use the output. No unnecessary words, earning its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description explains the output format (slug values) and how to use them with the install endpoint. It also mentions grouping by website type. With no output schema, this is sufficiently complete for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the parameter 'order_id' is already described in the input schema. 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 it lists curated plugin suggestions grouped by website type. It uses specific verb 'List' and identifies the resource as 'curated plugin suggestions', distinguishing it from sibling tools like listAvailable or listInstalled.
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 instructs to use the returned slug values with the install endpoint, providing a clear usage instruction. However, it does not explicitly state when to use this tool versus alternatives like search or list available, though the context of 'curated' implies 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?
Description defines operation as read-only (retrieve) and lists returned attributes. With no annotations, it adequately communicates scope. Omits pagination or potential empty responses, but acceptable for a simple list.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, front-loaded with action and outcome. 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?
Lacks output schema; description partially covers return fields but doesn't specify if additional fields exist or format. For a list endpoint, this is adequate but could be more 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?
100% schema coverage sets baseline at 3. Description adds minimal detail beyond parameter names and basic schema descriptions (e.g., 'selected website'). Does not clarify 'username' parameter role.
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 it retrieves subdomains for a specific website, specifying included data (parent domain, root directory). Differentiates from sibling create/delete subdomain 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?
Explicitly says 'Use this endpoint to inspect subdomain configuration', providing clear usage context. Lacks explicit when-not-to-use or alternatives, but sibling list/management tools are easily distinguished.
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?
Without annotations, the description carries the full burden. It discloses the irreversible nature (cannot be undone) and the effect (URL stops receiving notifications). This is sufficient behavioral transparency for a delete operation, though it could mention if there are any dependencies 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 concise with two short sentences, front-loaded with the key action. Every word adds value, and there is no unnecessary information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter tool with no output schema, the description is complete. It explains the purpose, the irreversibility, and the consequence. Given the simplicity, no additional context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 100% coverage with a clear description for 'webhookId' (ID returned when created). The description does not add extra meaning beyond the schema, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: permanently delete a webhook. It specifies the resource (webhook) and the verb (delete), distinguishing it from other mail webhook tools like create, update, list, etc.
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 warns that the action cannot be undone, which provides essential context for when to use it. However, it does not explicitly state when to use this tool versus alternatives or when not to use it, leaving some guidance implicit.
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 description discloses critical behavioral details: the import runs in the background (success response only means accepted, not finished), emails already existing in the profile are left unchanged, and if double opt-in is enabled, new contacts start pending and receive a confirmation email. Since no annotations are provided, this description carries the full burden of behavioral disclosure and does so well, though it omits auth or error handling.
Agents need to know what a tool does to the world before calling it. Descriptions 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: a single opening sentence states the core purpose, followed by two tightly focused sentences on async behavior, deduplication, and opt-in implications. There is no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (bulk create with async behavior), the description covers the most important operational aspects: acceptance semantics, deduplication, and double opt-in. It could mention how to verify import completion or error handling, but the core context is sufficient for an agent to understand the tool's behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides descriptions for all parameters, and the tool description adds meaningful behavior for the contacts parameter: deduplication on existing email and double opt-in handling. Some schema descriptions are tautological (e.g., 'contacts parameter'), but the tool-level context compensates for these gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Create many contacts in a profile in a single call.' It specifies the verb (create), resource (contacts), and scope (in a profile). However, it does not explicitly differentiate from sibling contact-creation tools like reach_createNewContactsV1, 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'Create many contacts' and 'in a single call' implies the tool is intended for bulk operations, providing clear context for when to use it. There is no explicit when-not-to-use guidance or naming of alternative tools, but the primary use case is evident.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full transparency burden. It discloses the critical behavioral limitation: the endpoint always falls back to the default profile and cannot target other profiles. It also notes deprecation, which is valuable context beyond simple 'list' semantics.
Agents need to know what a tool does to the world before calling it. Descriptions 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 sentences with the core purpose front-loaded, a brief clarifying sentence, and the deprecation note. Every sentence earns its place with no redundancy or 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?
For a simple, parameterless list endpoint with no output schema, the description covers the main behavior and a key limitation. It could mention response format or pagination, but it is reasonably complete given the tool's simplicity and the available 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 and schema coverage is 100%, so the baseline is 4. The description adds meaning by explaining why there is no profile parameter: the endpoint always uses the client's default profile. This helps an agent understand the lack of 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 tool lists contact segments with a specific verb and resource. However, it does not explicitly differentiate from sibling tools like listContactGroups or listProfileSegments, though the deprecation note adds context about which endpoint this is.
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 marks the tool as deprecated and recommends an alternative endpoint, providing clear when-not-to-use guidance. It does not, however, state a scenario where this tool should still be used, but the deprecation note effectively steers agents away from 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?
The description discloses a critical behavioral trait: 'Creating new snapshot will overwrite the existing snapshot!' This is essential for understanding the tool's impact. With no annotations provided, the description carries the full burden of behavioral transparency, and it adequately warns about the destructive overwrite 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 well-structured with two paragraphs and a bold warning. It is relatively concise, though the third sentence in the first paragraph ('A snapshot captures...') could be shortened slightly. Overall, it is effectively sized 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?
Given the tool has only one parameter, no output schema, and no annotations, the description provides adequate context: purpose, behavioral warning, and usage guidance. It does not explain return values or error conditions, but for a simple creation tool, this is sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage for the single parameter 'virtualMachineId' (described as 'Virtual Machine ID'). The tool description does not add 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 clearly states the tool's verb and resource: 'Create a snapshot of a specified virtual machine.' It distinguishes from sibling tools like VPS_deleteSnapshotV1, VPS_restoreSnapshotV1, and VPS_getSnapshotV1 by focusing on the creation action.
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 states when to use the tool: 'Use this endpoint to capture VPS state for backup and recovery purposes.' It does not provide explicit when-not-to-use scenarios or list alternative tools, but the context implies alternatives like restore or delete snapshots.
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 disclose behavior. It correctly identifies this as a read operation ('retrieve detailed information'), but it does not mention idempotency, authentication requirements, or rate limits. The name 'get' implies read, but the description adds no behavioral context beyond the obvious. Score 3 is appropriate as it meets the minimum but lacks depth.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise: two sentences, no redundancy. The first sentence clearly states the purpose, and the second adds a use case. Every word earns its place. It is front-loaded with the core action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (two required parameters, no output schema, no nested objects), the description is complete. It explains what the tool does and how to use it (monitoring specific actions). There is no missing information that would hinder an AI agent's ability to select and invoke this 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 covers 100% of parameters with descriptions ('Virtual Machine ID' and 'Action ID'). The description does not add extra meaning beyond what the schema provides. Therefore, baseline 3 applies. No additional parameter context is given.
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: 'Retrieve detailed information about a specific action performed on a specified virtual machine.' It specifies the verb 'retrieve,' the resource 'action details,' and the context 'on a specified virtual machine.' This distinguishes it from siblings like VPS_getActionsV1, which 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a use case: 'Use this endpoint to monitor specific VPS operation status and details.' It implies the tool is for getting details of a single action, not a list. However, it does not explicitly state when not to use it or mention alternatives like VPS_getActionsV1. Still, the guidance is clear and adequate for a simple retrieval.
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 description discloses that this is a read-only retrieval of action history, with examples of fields (name, timestamp, status). No annotations are provided, so the description adequately covers the behavior, though it omits details on pagination or rate limits.
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 concise, with three brief paragraphs that front-load the purpose. Every sentence adds value, though it could be slightly more compact.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description mentions return fields (action name, timestamp, status) and implies pagination via the page parameter. It lacks explicit details on ordering, filtering, or limits, but given the simplicity of the tool, it is reasonably 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 covers both parameters with descriptions (virtualMachineId, page). The description does not enhance parameter meaning beyond what the schema provides. With 100% schema coverage, 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 retrieves actions performed on a virtual machine, listing examples (starting, stopping) and emphasizing history viewing. It effectively distinguishes from the sibling VPS_getActionDetailsV1 which likely retrieves a single action's details.
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 advises using this endpoint for viewing VPS operation history and troubleshooting. It does not mention when to avoid it or contrast with other tools, but the context is sufficiently clear.
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 provided, so description carries full burden. It discloses that all data on the virtual machine will be overwritten and notes the process may take time. Lacks details on prerequisites like VM state 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?
Three sentences plus a bold warning, all front-loaded with the main action. No wasted words, efficient and clear.
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?
No output schema and no annotations. The description covers the core behavior but lacks information about response format, asynchronous nature, or prerequisites like VM being stopped.
Complex tools with many parameters or behaviors need more documentation. Simple tools 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 baseline is 3. The description reinforces the parameters' purpose but adds no new semantic detail beyond the schema's field descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'Restore a backup' and the resource 'virtual machine', distinguishing it from sibling tools like VPS_restoreSnapshotV1 by specifying 'backup' and 'backup points'.
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 includes 'Use this endpoint to recover VPS data from backup points', providing clear when-to-use guidance. It does not explicitly contrast with snapshot restore, but 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It explicitly states a destructive side effect: 'Website contents are overwritten by the build result'. It also clarifies the deployment target ('public_html'). This adequately informs the agent of the tool's 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?
Three sentences covering purpose, prerequisite, and outcome with no redundant information. Front-loaded with the main action. Every sentence adds necessary context.
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 complexity of a build-and-deploy tool and the lack of output schema, the description covers the main input, prerequisite, and outcome. It does not mention error handling or build duration, but the core behavior is sufficiently described 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.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides descriptions for both parameters (100% coverage). The description adds value by explaining that 'archive_path' is 'relative to the website document root' and gives a common example ('public_html'), plus instructs to upload first. This enriches the agent's understanding beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Builds and deploys'), the resource ('Node.js application for an Agency Plan website'), and the method ('from an already-uploaded archive'). It distinguishes from sibling tools like generic Node.js build tools by specifying the 'Agency Plan' context and the prerequisite of an uploaded archive.
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 a clear prerequisite ('Upload the archive to file browser first') and implies the step of providing the relative path, but does not explicitly state when to use this tool vs alternatives (e.g., for non-Agency-Plan sites or non-Node.js apps). No mention of when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must carry the full burden. It discloses permanent data loss and idempotency, which are critical behavioral traits. It could mention irreversibility more explicitly, but it is sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences convey the essential purpose and behavior without waste. Every sentence adds meaningful 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 no output schema and simple parameters, the description covers the core behavior. It might benefit from mentioning that this action cannot be undone, but it is otherwise complete for a deletion 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?
Schema coverage is 100%, baseline is 3. The description adds value by noting that database_name should be the full name from the list endpoint, guiding correct parameter 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 clearly states it deletes a MySQL database and its data, including users, from an Agency Plan website. The verb 'deletes' and resource 'database' are specific, and it distinguishes from sibling tools like create or list databases.
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 mentions idempotent behavior but lacks explicit guidance on when to use this tool versus alternatives (e.g., other delete tools for different resources). It does not provide when-not-to-use scenarios.
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 full burden. It discloses that website contents are overwritten (destructive behavior) and lists supported archive types. No mention of authentication or rate limits, but the main behavioral trait is covered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, front-loaded with the main action. Every sentence provides essential information 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?
Given no output schema, the description covers prerequisites, overwrite behavior, and supported types. It is sufficient for an import tool, though some users might want info on response or limitations.
Complex tools with many parameters or behaviors need more documentation. Simple tools 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 baseline is 3. The description adds process context ('upload first') but does not significantly enhance parameter understanding beyond the schema's own descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Imports an Agency Plan website from an already-uploaded archive,' providing a specific verb and resource. It distinguishes from siblings by specifying the Agency Plan context and the archive-based import method.
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 usage context: upload the archive first, then call this with the filename. It does not explicitly mention alternatives or when not to use, but the prerequisite is well explained.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It explains that each datacenter includes a pinger_url for latency measurement, and how to use it to select the nearest datacenter. This provides useful behavioral context beyond basic functionality, though it doesn't detail response structure or limitations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, each serving a distinct purpose: stating the action and providing actionable guidance on the output. No fluff, well-structured, and easy to parse.
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 single required parameter and no output schema, the description provides sufficient context for an AI agent to understand what the tool returns (datacenters with pinger_url) and how to use it. It could be improved by specifying the response structure, but it still connects well to related tools like 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 single parameter order_id is well-described in the schema as 'Agency Plan order ID', and the description reinforces it by mentioning 'given Agency Plan hosting order'. With 100% schema coverage, the description adds marginal value, but it does tie the parameter to the broader 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 tool lists datacenters for provisioning a new website on an Agency Plan hosting order. It uses a specific verb ('Lists') and resource ('datacenters available for provisioning'), distinguishing it from sibling tools like 'hosting_listAvailableDatacentersV1' which is for regular hosting.
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 before creating a website to select a datacenter, and provides guidance on using the pinger_url to pick the nearest one. It does not explicitly state when not to use it or name alternatives, but the context is clear given the sibling tool for regular hosting.
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 provided, so description carries full burden. Indicates read-only behavior but does not disclose rate limits, authentication needs, or caching. Adequate for a simple retrieval 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?
Description is very concise: two sentences and a note. Front-loaded with the main action, 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 no output schema and no parameters, the description covers the purpose and usage context. However, it does not hint at the response structure (e.g., list of method IDs/names), which 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?
Input schema has no parameters, so description does not need to add param info. Baseline score of 4 applies as schema coverage is 100% and no params 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 clearly states the tool retrieves available payment methods for placing orders, with a specific verb and resource. It distinguishes from siblings like billing_deletePaymentMethodV1 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides context to use before creating orders and mentions an alternative for adding methods via hPanel. Does not explicitly exclude other billing tools but gives clear when-to-use 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?
No annotations provided, so description carries full burden. It correctly indicates a write operation ('places a renewal order') and mentions automatic payment method selection. But it lacks details on immediate effects (e.g., charge timing, subscription extension), prerequisites (e.g., active subscription), and error scenarios. Adequate but incomplete.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is four sentences, front-loaded with purpose, and no redundant information. Every sentence adds useful context for the agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 3 parameters, 100% schema coverage, and no output schema, the description covers essential aspects: how to find subscriptionId, coupons usage, and payment method fallback. Missing response details, but not critical for a simple renewal 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 coverage is 100% with basic descriptions for coupons, subscriptionId, and payment_method_id. The description adds value by explaining subscriptionId must come from the subscriptions endpoint and clarifying default payment method behavior, going beyond schema info.
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 renewal order for an existing Hostinger subscription' with a specific verb and resource. It distinguishes from sibling tools like billing_getSubscriptionListV1 (list subscriptions) and billing_enableAutoRenewalV1 (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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context for when to use the tool: to renew a subscription. It advises using the subscriptions endpoint to obtain subscriptionId and explains default payment method behavior. However, it does not explicitly exclude cases or compare with alternatives like auto-renewal.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses an important behavior: returning 404 when no account is moving the domain to you. It also clarifies the tool's role in checking acceptance status. It does not disclose other potential traits like read-only nature, but the retrieval verb and 404 detail add value beyond the 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 three concise sentences, each with a distinct purpose: stating the action, noting the error condition, and providing the use case. There is no redundancy or filler, making it highly efficient 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 retrieval tool with no output schema, the description covers the core purpose, the use case, and an important error case. It does not describe the response structure, but that is likely self-evident from the tool name and context. The description is sufficient for an agent to select and invoke the tool correctly, though naming the list alternative would add a bit more 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 already provides 100% description coverage for both parameters, including a detailed explanation of force_sync and its effect on the 'activating' status. The tool description adds no 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Retrieve' with the resource 'incoming move' scoped to 'a specified domain,' which clearly distinguishes it from sibling tools like the list or accept/reject variants. It also notes the 404 behavior, uniquely identifying this as a singular lookup tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states a use case: 'Use this endpoint to check whether a domain addressed to you is still waiting to be accepted.' This provides clear context for when to invoke it. However, it does not explicitly name alternatives or exclusion scenarios, though the singular scope implies when the list endpoint 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It adds the key filter (only uncompleted moves) and implies read-only via 'Retrieve', but does not disclose pagination, sorting, or response format. This is adequate but leaves room for more 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?
Three sentences total, front-loaded with the core purpose, followed by a critical filter and a use-case sentence. No wasted words 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?
For a simple list operation with no params and no output schema, the description adequately covers what, the status filter, and when to use it. It could mention response shape or link to the singular endpoint, but the tool's simplicity makes this largely sufficient.
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 100% (empty properties). The description does not need to explain parameters, and the baseline for zero-parameter tools is 4. No additional parameter information 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 clearly states it retrieves all domains being moved to other Hostinger accounts, using a specific verb (Retrieve) and resource (outgoing domain moves). It distinguishes from sibling tools like the singular getOutgoingDomainMoveV1 and incoming move list by emphasizing 'all' and the 'not completed yet' filter.
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 by stating that only incomplete moves are returned and recommends using it to track initiated moves and their target accounts. However, it does not explicitly mention alternatives (e.g., use the singular endpoint for a specific move), so there is no exclusions list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. The description implies a read-only operation (retrieve) but does not mention any limitations like pagination or if there are any side effects. For a simple list, this is adequate but not detailed.
Agents need to know what a tool does to the world before 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, no fluff. First sentence states purpose, second gives usage guidance. Highly 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?
Given no parameters, no output schema, and no annotations, the description is fairly complete. It could mention if the result is paginated, but overall it covers the essential information for a list endpoint.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters. The description adds meaning by specifying the scope ('in your portfolio') and the context (monitoring transfers). With 0 parameters, baseline is 4, and the description meets 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 it retrieves all domain transfers in your portfolio and specifies the purpose to monitor incoming and outgoing transfers. It distinguishes from siblings like domains_getDomainListV1 and domains_getTransferV1.
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 usage context: 'Use this endpoint to monitor incoming and outgoing registrar transfers across your domains.' It does not explicitly exclude alternatives or state when not to use, but the guidance is sufficient for a simple list endpoint.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses key behaviors: the domain remains with the initiating account and accepted moves cannot later be rejected. It does not discuss error states or reversibility, but the essential state change is clearly communicated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded. The first sentence states the action, the second explains the postcondition, and the third offers usage direction. No redundant 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 single-parameter tool with no output schema and no annotations, the description covers the action, when to use it, and a critical state constraint. Minor gaps like expected response format or handling of invalid domains do not significantly detract from 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 already describes the only parameter as 'Domain name' with 100% coverage. The description adds 'specified domain' but no additional format, constraints, or examples. Baseline 3 is appropriate because the description adds little 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 opens with 'Reject an incoming move for a specified domain,' a specific verb-resource pairing that clearly distinguishes this from the sibling accept tool. The additional effect ('The domain stays in the account which initiated the move') 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 tells when to use it: 'Use this endpoint to decline a domain you do not want to take over.' It also notes a constraint ('Moves you have already accepted cannot be rejected anymore'), offering practical guidance. It does not name the alternative accept endpoint, but the context makes it obvious.
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 full responsibility for behavioral disclosure. It explicitly states the profile is kept and only no longer pre-selected, preventing a mistaken assumption that the tool deletes the profile. It also notes the effect on new registrations.
Agents need to know what a tool does to the world before calling it. Descriptions 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 short sentences with no filler. Each sentence adds essential information: the action, the non-destructive nuance, and the practical use case.
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 is largely complete. It covers the action, the side effect (profile retained), and the reason to use it. Minor gaps such as response behavior or idempotency are not critical given the tool's simplicity, but they prevent 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 schema already covers the single whoisId parameter with 100% coverage, including its type and a clear 'WHOIS ID' description. The tool description adds no additional parameter-specific guidance, 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 opens with a specific verb and resource: 'Unset WHOIS contact profile as default.' It clearly distinguishes this from the sibling setDefaultWHOISProfile tool and from profile deletion, making the tool's purpose unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The final sentence, 'Use this endpoint to stop reusing contact information for new registrations,' provides an explicit use case. It implies the alternative is setting a default profile via the sibling tool, though it does not name that tool or state when not to use it.
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. The description adds behavioral context: the url is returned as channel domain and null clears values. However, it does not disclose whether other fields are unaffected or if there are side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: first states the core action, second details the modifiable fields and null behavior. No wasted words, front-loaded 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?
Given no output schema, the description adequately covers the mutation. It could mention return behavior or success signals, but the sibling context helps. Mostly complete for the task.
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 already describes all parameters. The description adds value by explaining the relationship between 'url' and 'domain', and the null-clearing behavior, which goes beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Update' and the resource 'custom sales channel'. It distinguishes from sibling tools like create and list by specifying it is an update 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 explains what fields can be changed ('name' and 'url') and how to clear values with null. It implicitly indicates this tool is for existing channels, but does not explicitly state when to use versus alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses the asynchronous behavior explicitly, which is crucial for an activation tool. No annotations were provided, so the description carries the full burden and handles it well.
Agents need to know what a tool does to the world before 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 wasted words. Information is front-loaded and efficiently covers key points.
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?
Adequately covers the tool's purpose, parameter sources, and async behavior. Lacks details on error responses or return values, but is sufficient given the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema already describes all parameters. Description adds value for the 'software' parameter by explaining how to obtain its value, but does not elaborate on the 'username' parameter beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states 'Activate an installed plugin on a WordPress installation' with specific verb and resource. Differentiates from siblings like deactivate, install, and list plugins.
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 context on how to obtain the WordPress installation identifier and notes the asynchronous nature. Lacks explicit when-not or alternatives, but the purpose is clear enough for usage.
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 discloses the asynchronous nature of the operation, warning that a successful response only means the job is queued. No other behavioral traits are mentioned, but the async disclosure is 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?
Three sentences, front-loaded with the action, no unnecessary words. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple 3-parameter tool with no output schema, the description covers the purpose, parameter sourcing, and async behavior. It lacks return value details but is sufficient for an agent to use 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%, and the description adds context for the 'software' parameter by explaining how to obtain its value. However, the 'username' parameter is not elaborated beyond the schema's vague 'username 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 clearly states 'Deactivate an installed plugin on a WordPress installation,' with a specific verb and resource. It is distinguishable from sibling tools like hosting_activateWordPressPluginV1 and hosting_installWordPressPluginsV1.
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 guidance on obtaining the WordPress installation identifier via another endpoint. However, it does not explicitly state when to use this tool versus alternatives, though the action is self-explanatory.
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?
Without annotations, the description discloses permanent destruction and cascading deletion of remote connections, making the tool's irreversible nature explicit. No contradictions.
Agents need to know what a tool does to the world before 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 states purpose, second delivers critical requirement. No wasted words; 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 delete tool with two parameters and no output schema, the description covers key aspects: action, permanence, parameter constraint. Missing aspects like error behavior or permissions are not critical for a basic delete.
Complex tools with many parameters or behaviors need more documentation. Simple tools 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 baseline is 3. The description repeats the schema's advice for 'name' but adds no new semantic depth for 'username'. Adequate but not exceptional.
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 permanently deletes a database and its remote connections, using a specific verb (deletes) and resource (database). It is distinct from sibling hosting tools like create, update, or list.
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 states that the database name must be the full name from the list databases endpoint, guiding the agent to retrieve the correct name first. No alternative tools are mentioned, but the context is clear.
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 provided, so description carries full burden. It discloses that logs may contain ANSI escape sequences and explains the polling strategy. Lacks details on authentication or error responses but is sufficient for a read-only logging 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?
Two brief paragraphs with no filler. First sentence states purpose, second provides actionable usage instructions. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers polling mechanism and potential ANSI codes. Lacks explanation of response format or error handling, but given the tool's simplicity (4 parameters, no output schema), it is mostly 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 descriptions for each parameter. The description adds context for from_line in the polling flow but does not elaborate on required parameters beyond what schema provides. 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 'Retrieve logs from a specific Node.js build process' with a specific verb and resource, distinguishing it clearly from sibling tools like hosting_listNodeJSBuildsV1 or hosting_showJsDeploymentLogs.
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 explicit guidance on when to poll (while build state is running) and how to use from_line for incremental fetching. Does not explicitly exclude alternatives but offers a clear usage pattern.
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 exist, so description carries full burden. It discloses time expectations, auto-extraction, and automatic username resolution. However, it does not mention if the operation is destructive (overwrites existing content) or required permissions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Five sentences, well-organized: purpose, steps, timing, auto-resolution. No redundant information. Each sentence serves a 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?
No output schema, but description explains expected outcome (extraction, availability in minutes). Missing explicit return value or status, but covers main flow adequately for a 3-param 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?
Schema coverage is 100%, but description adds valuable context: instructions for creating archive from directory with naming pattern, and that username is resolved from domain. This exceeds schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (import), resource (WordPress website), and method (from archive file). It distinguishes from siblings like fresh install or static deploy by specifying 'from an archive file' and mentioning database dump.
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 use: importing an existing WordPress site with archive and SQL dump. It lacks explicit when-not-to-use or alternatives (e.g., for static sites use other tools), but 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Discloses paginated list retrieval, domain requirement, and optional state filtering. Does not detail auth or side effects, but for a read-only list tool this is sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences with front-loaded purpose, a usage directive, and behavioral detail. No redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequately describes tool behavior given 4 parameters and no output schema. Covers pagination, domain requirement, and state filter. Could mention return format omission but acceptable for a list tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, baseline 3. Description adds meaning to 'states' by mentioning 'filtering by deployment states' and specifies domain is required, but otherwise does not enrich beyond schema specs.
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 JavaScript/Node.js application deployments for status checking, with specific verb and resource. It distinguishes from sibling tools like hosting_listNodeJSBuildsV1 (builds) and hosting_deployJsApplication (deployment creation).
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?
Explicitly states 'Use this tool when customer asks for the status of the deployment,' providing clear context for invocation. Does not mention when not to use or compare to alternatives, but the use case is well-defined.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It discloses that each installation has a `valid` flag and `validationError`, and notes that a new installation appears in the list when ready. It does not mention side effects or authentication details, but the read-only nature is implied by 'list' and 'accessible'.
Agents need to know what a tool does to the world before 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 concise sentences with no superfluous text. The purpose is front-loaded, followed by usage guidance and parameter details. Each sentence serves a clear 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?
No output schema exists, but the description mentions the `valid` flag and `validationError`, providing key return value context. Pagination or ordering is not covered, but for a list tool with good schema coverage, this is 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 description coverage is 100%, so the baseline is 3. The description only mentions filtering by username and domain, adding no new meaning beyond the schema. It does not compensate for the ownership parameter's default value, which is already in 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 starts with 'List WordPress installations accessible to the authenticated client', clearly specifying the verb (list) and resource (WordPress installations). It also mentions filtering capabilities and the `valid` flag, distinguishing it from other listing tools like `hosting_listWebsitesV1`.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly states two use cases: 'discover existing WordPress installations' and 'poll for installation status after calling the install endpoint'. It also describes filtering, but does not explicitly mention when to avoid using it or reference alternative tools among siblings.
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 full burden. It indicates a read operation with no side effects, which is sufficient for a simple status display. However, it could mention any required permissions or error 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 two concise sentences, front-loaded with the purpose, then providing needed guidance. No unnecessary 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?
The description adequately explains the input and how to get the identifier, but does not describe the output format. Since there is no output schema, a hint about the return value 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?
Schema coverage is 100%, and the description adds value by explaining how to obtain the software identifier from another endpoint, which is not in the schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Show the LiteSpeed Cache status', specifying the verb (Show) and resource (LiteSpeed Cache status for a WordPress installation). It distinguishes from sibling tools like hosting_purgeLiteSpeedCacheV1.
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 explains how to obtain the required software identifier via another API call, but does not provide when to use this vs alternatives (e.g., other cache status tools) or when not to use it.
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, description explains that enabling turns off all caching, but lacks details on side effects, persistence, or prerequisites. Meets basic transparency but could be more thorough.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with action, no redundant information. Efficient and clear.
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?
Covers main aspects: purpose, when to use, and effect. Lacks output description but acceptable given no output schema. Slight gap on prerequisites but overall 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?
Schema coverage is 100%, so baseline is 3. Description adds value by explaining the effect of the 'enabled' flag beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool turns cacheless mode on or off, using a specific verb and resource. It distinguishes from other caching tools by focusing on development mode.
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?
Explicitly states when to enable (during development, testing, debugging) and when to disable (after development). Does not explicitly mention alternatives but context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It explicitly states the operation is asynchronous and that a success response only indicates queuing. Additional details like access requirements or side effects are not given, but the async disclosure is 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?
The description is three sentences: purpose, how to get software ID, and async behavior. It is front-loaded, concise, and contains no unnecessary 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?
With no output schema, the description notes the asynchronous nature but does not specify the exact return format (e.g., job ID). It covers essential usage context but could be improved with details on error handling or update status.
Complex tools with many parameters or behaviors need more documentation. Simple tools 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 baseline is 3. The description adds value by explaining how to retrieve the software ID, but does not clarify the username parameter or the nuances of the themes array. Overall, adequate but not enhanced.
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 one or more installed themes to their latest version on a WordPress installation.' It uses a specific verb and resource, and distinguishes from siblings like install or uninstall theme tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains how to obtain the software ID and notes asynchronicity, providing context for use. However, it does not explicitly contrast with sibling tools like hosting_updateWordPressPluginsV1 or specify when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses cascading deletion of all field values and options for choice types, and explicitly states contacts themselves are unaffected. With no annotations provided, this is essential behavioral context that goes 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?
Two brief sentences, front-loaded with the primary action, followed by a concise consequence statement. Every sentence adds value with no redundancy or clutter.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the essential behavior: deletion, cascading effects, and the non-effect on contacts. It could mention irreversibility or permission requirements, but for a simple delete tool with clear parameter descriptions, it is fairly 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 descriptions cover 100% of parameters (profileUuid, fieldUuid). The description does not add parameter-specific semantics beyond the schema, but the overall context of deleting a field helps interpret the fieldUuid parameter. 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 states 'Delete a custom contact field' with a clear verb and resource, distinguishing it from sibling tools like reach_createAContactFieldV1 and reach_updateAContactFieldV1. Adding 'custom' clearly separates it from contact deletion (reach_deleteAContactV1).
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 when to use the tool (to delete a contact field), but it does not explicitly name alternatives or exclusion criteria. The description gives context about consequences but no direct 'use this instead of X' guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the transparency burden. It discloses that the tool returns UUIDs for updating contacts and that choice fields include options, which informs the agent about the response structure. It does not mention potential errors or permissions, but the read-only nature is implied by 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences, the first clearly stating the purpose and the second providing valuable context about usage and return values. Every sentence contributes useful information with 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?
For a simple list tool with one parameter and no output schema, the description adequately covers what the tool does and how to interpret the returned data. It could mention if there are any limitations such as only custom fields or no pagination, but the scope 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?
The schema has a description for profileUuid ('Profile uuid parameter') which is generic, and the description adds only that fields are defined in a profile. This provides some context but does not fully explain the parameter format or validation. According to the rubric, high schema coverage gives a baseline of 3, and the description adds minimal extra 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 a specific action: 'Get the custom contact fields defined in a profile.' It identifies the resource (custom contact fields) and scope (profile), distinguishing it from sibling tools like listContacts or createContactField.
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 by explaining that the returned UUIDs are used with the contact update endpoint and that choice fields list available options. However, it does not explicitly state when to use this tool over alternatives, though the context implies 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 full burden of behavioral disclosure. It provides two key traits: immediate execution (not queued) and non-destructive behavior (neither tag nor contact is deleted). This meaningfully informs the agent about side effects and timing. However, it omits details like idempotency, error conditions, or required permissions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is exactly two sentences: the first states the core action, the second provides important caveats (immediate vs queued, non-deletion). Every sentence earns its place with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple operation, three well-schema'd parameters, and no output schema, the description adequately covers purpose, usage distinction, and side effects. It is sufficient for an agent to select and invoke the tool correctly, though it could mention return behavior or prerequisite 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?
Schema description coverage is 100%, but each parameter description is minimal ('Tag uuid parameter', etc.) and adds little beyond the parameter name. The tool description offers no additional parameter semantics, 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: 'Remove a tag from a single contact.' This is a specific verb+resource+scope combination. It also distinguishes itself from the bulk endpoint by emphasizing 'single contact' and from tag deletion by clarifying 'Neither the tag nor the contact is deleted.'
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 contrasts with the bulk endpoint: 'Unlike the bulk endpoint this is applied immediately rather than queued.' This tells the agent when to prefer this tool (immediate application for a single contact) over the bulk alternative, though it does not name the alternative explicitly or provide comprehensive 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description only states the basic operation. It does not disclose any behavioral traits such as whether existing keys are overwritten or the response format.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences, front-loaded with the main purpose, with no unnecessary 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 create operation with two parameters and no output schema, the description is adequate. However, it could benefit from specifying the expected key format (e.g., ssh-rsa).
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 descriptions are minimal ('name parameter', 'key parameter'), but the description adds context by mentioning SSH keys, improving understanding beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (add), resource (public key), and purpose (VPS authentication), distinguishing it from sibling tools like VPS_deletePublicKeyV1.
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 tells when to use the tool ('register SSH keys for VPS authentication') but does not specify when not to use it or mention alternatives like VPS_attachPublicKeyV1.
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?
Discloses that any VM with the firewall will have it deactivated. Without annotations, this adds necessary 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?
Three concise sentences: action, side effect, usage guidance. 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?
Adequate for a simple delete operation with one parameter and no output schema. Could mention irreversibility or 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 covers 100% of the parameter (firewallId), and description adds no extra meaning beyond the schema's 'Firewall ID'.
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 it deletes a specified firewall, distinct from sibling tools like deleteFirewallRule or createFirewall.
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?
Says to use for removing unused firewall configurations, providing a clear usage context. Could mention alternatives like deactivate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It clearly states the operation is irreversible and deletes all project data, including networks, volumes, and images. It could be improved by mentioning permissions or confirmation requirements, but the core destructive nature is well communicated.
Agents need to know what a tool does to the world before calling it. Descriptions 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 with three sentences, front-loading the primary action. Every sentence adds value: the first explains what it does, the second emphasizes irreversibility, and the third provides usage guidance. 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?
For a simple delete tool with two parameters and no output schema, the description is largely complete. It covers the outcome, irreversibility, and cleanup. It could be slightly more complete by hinting at the return value (e.g., success status), but that is not 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 input schema has 100% description coverage, so the baseline is 3. The description does not add any additional meaning beyond what the schema provides for the two parameters (projectName, virtualMachineId). No extra context is given for parameter values 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 removes a Docker Compose project, stopping containers and cleaning up resources. It uses a specific verb ('removes') and resource ('Docker Compose project'), and the scope is well-defined. This distinguishes it from sibling tools like VPS_createNewProjectV1 or VPS_updateProjectV1.
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 'Use this when you want to permanently remove a project and free up system resources,' providing clear context for when to use it. However, it does not mention when not to use it or any alternatives, though no alternative delete tool exists for projects.
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 explicitly states the key behavioral trait: 'Deleting public key from account does not remove it from virtual machine.' This is critical for an agent to understand side effects. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions 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 plus a bolded warning, all front-loaded. Every sentence adds value: purpose, critical behavioral note, and usage advice. No extraneous text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple delete operation with one parameter and no output schema, the description is nearly complete. It covers purpose, critical behavioral detail, and usage scenario. It could mention error cases or confirmation but is 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 input schema has 100% coverage with description 'Public Key ID.' The tool description does not add further meaning about the parameter beyond the schema. 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 'Delete a public key from your account' with a specific verb and resource. It also distinguishes from sibling tools like VPS_createPublicKeyV1 and VPS_attachPublicKeyV1 by noting it removes unused keys from account.
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 says 'Use this endpoint to remove unused SSH keys from account,' providing clear usage context. It also warns that deletion does not remove from VM, implying when not to use (if key is still attached). However, no explicit alternative tool is named.
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 description discloses important behavioral details: graceful shutdown, reverse dependency order, and preservation of data/volumes. However, it lacks details on authorization requirements, rate limits, or whether the operation is synchronous. Given no annotations, this is still 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?
The description is three sentences, front-loaded with the core action. It is efficient and contains no superfluous text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description adequately explains the tool's behavior and result. It could mention reversibility via VPS_startProjectV1, but given sibling context and no output schema, it is reasonably 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 clear parameter descriptions. The tool description does not add extra meaning beyond what the schema provides for projectName and virtualMachineId. 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 ('Stops') and clearly identifies the resource ('running services in a Docker Compose project'). It distinguishes itself from sibling tools like VPS_stopVirtualMachineV1 and VPS_deleteProjectV1 by emphasizing that data and configurations are preserved.
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 guidance on when to use this tool ('temporarily halt a project without removing data'). While it does not explicitly mention when not to use it or list alternatives, the context of siblings like VPS_startProjectV1 and VPS_deleteProjectV1 implies proper usage.
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 alone informs about behavior. It discloses that provisioning runs in the background and returns a setup UUID, which is key. It does not mention potential failures or side effects (e.g., billing), but the async nature is well-communicated.
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 well-structured with a clear introductory statement, parameter overview, and a 'Common setups' section. It is not overly long, though some repetition exists (e.g., explaining domain omission). Overall, 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?
Given the tool's complexity (9 parameters, nested objects, no output schema), the description is fairly complete. It covers the main use cases and explains key parameters. It could mention that an order_id must correspond to an Agency Plan order, but overall it provides sufficient context for an AI agent to use 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?
While the input schema already provides 100% coverage with descriptions, the tool's description adds significant extra context, such as explaining the 'flavor' parameter with examples ('php-fpm' vs 'wp-7.0'), the 'domain' omission behavior, and the interaction between 'type' and 'flavor' for static sites. This goes beyond the schema's basic type descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Provisions a new website on one of your Agency Plan hosting orders.' It uses a specific verb ('provisions') and resource ('website on Agency Plan hosting order'), and its differentiation from sibling tools (e.g., delete, change domain) 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage scenarios for three common setups (plain PHP, WordPress, static/Node.js), helping users select parameters. However, it does not explicitly state when not to use this tool or mention prerequisites (like having an existing order), which would improve guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses important behaviors: the receiving account must already exist and accept the move, domain must be active, subscription is resolved automatically, and specific error codes for missing subscription (404) and premium protection (428). This gives the agent a solid understanding of preconditions and failure modes, though it stops short of describing the pending state or subsequent steps.
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 five sentences, each adding distinct value: purpose, recipient requirement, domain condition, subscription resolution, and premium protection. It is front-loaded with the main action and avoids redundancy with the schema. Could be slightly tighter, but 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 tool's moderate complexity, no output schema, and absent annotations, the description covers essential context: what the action does, prerequisites, and failure modes. It implies a pending state via 'before the domain changes hands' and provides enough information for correct invocation. Some details like how to monitor or cancel the move are not mentioned, but they are handled by sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and both parameters have basic descriptions. The tool description adds behavioral context beyond the schema: 'new_customer_email' is tied to a receiving account that must already exist and accept the move, and 'domain' must be active. This adds meaningful semantics that help parameter interpretation.
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 starts with a specific verb+resource: 'Initiate a move of a specified domain to another Hostinger account.' It clearly distinguishes this from sibling operations like cancelOutgoingDomainMove and acceptIncomingDomainMove by stating its role in handovers. The closing sentence 'Use this endpoint to hand a domain over to another Hostinger user' reinforces the unique 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 provides clear usage context: prerequisites (receiving account must exist and accept, domain must be active), automatic subscription resolution, and rejection cases (404/428). It explicitly says 'Use this endpoint' for handovers. It does not explicitly name alternative tools, but the conditions and purpose make when-to-use clear enough without exclusions.
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?
Although no annotations are provided, the description discloses several behavioral traits: it toggles server-side caching, is idempotent (no-op if already in state), and recommends cacheless mode for debugging. It does not detail the exact caching layers affected or confirm if the change is immediate, but it provides sufficient transparency for a toggle 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 compact (four sentences) and front-loaded with the primary action. It structures information logically: purpose, benefit, guidance, idempotency. A minor improvement could be combining the benefit and guidance into fewer words, but it remains clear and 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 toggle operation with no output schema, the description covers the essential aspects: when to use (production vs. debugging), idempotency, and alternative. It does not describe the return value or confirmation, but that is acceptable given the simplicity of the tool and the lack of an output schema. It is complete enough for an agent to use 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 already describes all three parameters (username, domain, enabled) with descriptions. The description adds only that the toggle is 'based on the enabled flag', which is implicit from the parameter. Schema coverage is 100%, so the description adds minimal extra meaning beyond what is in 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 tool's action ('turns server-side caching on or off') and specifies the resource ('website'). It distinguishes itself from the sibling `hosting_toggleCachelessModeV1` by explicitly mentioning cacheless mode as an alternative for debugging.
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?
Provides explicit guidance: 'Enable it for faster page loads... recommended for production websites.' Also gives a clear alternative for temporary bypass (cacheless mode) and notes idempotency ('Does nothing if caching is already in the requested state'), helping the agent decide when to call this tool.
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 description discloses key behavioral constraints: the uniqueness of autoreplies per mailbox and the activation/expiration behavior of starts_at and ends_at. It does not mention error handling (e.g., what happens if one already exists) or permissions, but with no annotations provided, it covers the most critical aspects.
Agents need to know what a tool does to the world before 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, well-structured sentences with no redundancy. The key 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?
The description lacks details on return value (no output schema) and error cases (e.g., what if a mailbox already has an autoreply). For a creation tool with a constraint, some completeness is missing.
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?
Given 100% schema coverage, the description adds value by explaining the semantic effect of omitting starts_at (immediate activation) and ends_at (indefinite duration), going beyond the schema's description.
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) and resource (automatic reply for a mailbox), and adds a uniqueness constraint ('A mailbox can have only one autoreply'), which distinguishes it from siblings like mail_updateAutoreplyV1.
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 guidance on when to use this tool (to set up an autoreply) and explains the effect of omitting optional parameters. However, it doesn't explicitly contrast with mail_updateAutoreplyV1 or advise checking for an existing autoreply first.
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 bears the full burden. It discloses pagination, filtering options, and descending sort order. It does not explicitly state it is read-only, but that is implied. Missing rate limits or authentication notes, but acceptable for a simple query 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?
Two sentences: the first states the core action and scope, the second lists filtering and sorting. No wasted words, front-loaded, and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given full schema coverage and no output schema, the description adequately covers the tool's behavior (pagination, filtering, sorting). It is complete enough for an agent to understand what to expect and how to use it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so each parameter has a description. The description's mention of filtering by account, date range, etc., merely summarizes the schema without adding new detail. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Retrieve'), identifies the resource as 'outbound (sent mail) delivery logs', and scopes it to 'the domain attached to the given mail order'. It clearly distinguishes from siblings like 'mail_listInboundLogsV1' (inbound logs) and other log tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use when outbound log data is needed and mentions filtering capabilities, but lacks explicit exclusions or references to alternative tools (e.g., 'for inbound logs, use mail_listInboundLogsV1'). Still, the purpose is clear enough for an agent to select appropriately.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses the deprecation status, the fallback to the default profile, and the inability to create segments in other profiles. These are meaningful behavioral details beyond the schema. However, it does not mention response behavior, idempotency, or authentication, so it is 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and front-loaded with the core action. The first sentence is a concise summary, but the second sentence repeats much of the same information, creating minor redundancy. The deprecation note is clear and purposeful. Overall, it is appropriately sized without unnecessary 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?
The description covers the main purpose, the criteria configuration, and the crucial deprecation limitation with a direct alternative. There is no output schema and no annotations, so the description could be expected to explain return values or error scenarios, but the deprecation warning reduces the need for full detail. It is reasonably complete for a deprecated 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 baseline is 3. The description adds a high-level hint that segments can be configured with 'criteria like email, name, subscription status', which relates to the attribute enum, but it does not explain the `conditions` structure or `logic` parameter beyond what the schema already provides. The generic schema descriptions ('name parameter', 'logic parameter') are not enhanced substantially.
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 opens with 'Create a new contact segment' and expands on the purpose: organizing contacts with configurable criteria. It clearly distinguishes itself from the sibling tool `reach_createAProfileSegmentV1` by explicitly noting it is deprecated and cannot target a profile, which differentiates its scope.
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?
The description provides explicit usage guidance: it states the endpoint is deprecated, cannot target a profile, and falls back to the client's default profile. It also gives a direct alternative: `POST /api/reach/v1/profiles/{profileUuid}/segmentation/segments`. This clearly explains when not to use the tool and what to use instead.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full transparency burden. It clearly discloses idempotency (existing tags are not duplicated), safety (safe to repeat), and the exact return behavior (every tag in the request is returned, whether created or already existed). This gives an agent a confident mental model of the tool's effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three focused sentences. The main purpose is front-loaded, and the additional sentences add essential behavioral nuance without unnecessary detail or repetition.
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?
This is a simple two-parameter tool with no output schema, and the description is fully sufficient. It explains the purpose, the idempotent behavior, safety, and what is returned, leaving no critical gaps for an agent selecting or 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?
Schema coverage is 100% with types and required fields, but the parameter descriptions ('names parameter', 'Profile uuid parameter') are empty placeholders. The tool description does not elaborate on the parameters, so it adds no meaning beyond the basic schema. Baseline 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 opens with 'Create tags in a profile,' clearly stating the verb and resource. It further explains the create-or-find semantics and that existing tags are returned, distinguishing it from related tag tools like reach_listProfileTags, reach_deleteATag, and reach_renameATag.
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 through its idempotency note ('safe to repeat') and return behavior, but it does not explicitly state when to use this tool instead of alternatives, nor does it mention any excluded scenarios. The guidance is present but only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the disclosure burden. It discloses the permanent removal and the profile fallback behavior, which are critical. It doesn't mention response format or error behavior, but for a simple delete operation with deprecation warnings, the disclosure is sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficient, front-loaded with purpose, and includes a necessary deprecation note. Minor redundancy between the first two sentences, but overall well-structured 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 1-parameter delete tool with no output schema and no annotations, the description covers the essential behavioral aspects (permanence, deprecation, profile limitation). It could mention expected response codes, but the provided context is adequate 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 coverage is 100% with a clear description 'UUID of the contact to delete'. The description's mention of 'specified UUID' adds no additional semantics 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 ('Delete a contact with the specified UUID') and explicitly notes the tool's limitation (falls back to default profile), distinguishing it from the sibling tool reach_deleteAProfileContactV1 that can target a specific profile.
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?
Provides explicit deprecation notice with a concrete alternative endpoint (DELETE /api/reach/v1/profiles/{profileUuid}/contacts/{contactUuid}), and explains the exact limitations (cannot target a profile, only default profile). This is strong when-to-use vs 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of conveying behavior. It clearly states what the tool returns (segment definition/conditions) and explicitly states that it does NOT return contacts, pointing to the appropriate endpoint. The verb 'Get' implies a read-only operation, but the description does not explicitly mention permissions, idempotency, or other side effects, which is acceptable for a simple getter but not fully comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences. The first sentence delivers the core purpose and return value, while the second provides a valuable alternative for a different use case. Every sentence earns its place, with no redundancy or irrelevant detail.
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 getter with two parameters and no output schema, the description is complete. It tells the agent what the tool returns (segment conditions), and the pointer to the contacts endpoint covers the main alternate need. No further behavioral context is necessary.
Complex tools with many parameters or behaviors need more documentation. Simple tools 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 parameters described as 'Profile uuid parameter' and 'Segment uuid parameter'. The description adds no additional meaning beyond the schema; it does not explain the relationship between the parameters or provide format/context. Baseline 3 is appropriate since the schema already covers 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 clearly states the function: 'Get a single segment of a profile, including the conditions that define it.' This uses a specific verb ('Get'), names the resource ('single segment of a profile'), and specifies the return content ('conditions that define it'). The second sentence distinguishes it from the segment contacts endpoint, further clarifying its unique 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 NOT to use this tool: 'To retrieve the contacts currently matching those conditions, use the segment contacts endpoint instead.' It provides an alternative for a common use case. However, it does not contrast with sibling tools like reach_listProfileSegmentsV1 or reach_getSegmentDetailsV1, leaving some ambiguity about when to choose this over similar read 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 disclosure. It clearly discloses the deprecated status, the fallback to default profile, and the inability to read segments of other profiles. This provides meaningful behavioral context, though it does not describe response format or error 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 concise and front-loaded with the main purpose. The background sentence about segments is useful context, and the deprecation notice with alternative is essential. No wasted words, though the initial sentence is slightly redundant with the tool name.
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 no output schema, the description does not detail what 'details' are returned, but for a simple get-by-ID operation this is acceptable. The deprecation warning and explicit alternative make it complete enough for an agent to decide whether to use this tool or a sibling.
Complex tools with many parameters or behaviors need more documentation. Simple tools 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 of 'segmentUuid' as 'Segment uuid parameter'. The description adds that segments are identified by UUID and are used to organize/group contacts, but this is minor and does not substantially enhance 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 'Get details of a specific segment' and further explains it retrieves information about a single segment by UUID. It distinguishes from sibling tools by noting the deprecation and pointing to the profile-scoped 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?
Explicitly states when not to use this tool (deprecated, cannot target a profile, falls back to default profile) and provides a specific alternative endpoint: 'GET /api/reach/v1/profiles/{profileUuid}/segmentation/segments/{segmentUuid}'. This gives clear guidance versus sibling tools like reach_getProfileSegmentDetailsV1.
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, but the description implies a non-destructive read operation. Lacks details on authentication or rate limits, but for a simple list, this is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, front-loaded with the action, no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list with no parameters and no output schema, the description fully covers what the tool does and when to use it.
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?
No parameters exist, so schema coverage is 100%. Description adds no parameter info, but with zero parameters, baseline 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 the tool retrieves all available data centers with a specific verb and resource. It distinguishes from siblings by mentioning the VPS deployment context.
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?
Explicitly says to use before deploying VPS instances, providing clear context. Does not compare directly with hosting_listAvailableDatacentersV1, but the VPS-specific mention is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility and does so excellently. It discloses that the operation is idempotent, that it is compute-only and does not affect billing, and that stopping charges requires disabling auto-renewal. These are important behavioral traits beyond the basic 'stop' semantics.
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 concise and front-loaded with the main purpose, followed by idempotency and billing notes. Each sentence adds value, though the billing note could be seen as slightly tangential. Overall, it is well-structured and 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 and no annotations, the description covers the essential context: what it does, idempotent behavior, billing implications, and when to use it. It lacks minor details like whether the operation is asynchronous or returns an action ID, but these are not critical for basic usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage: the single parameter 'virtualMachineId' is described as 'Virtual Machine ID'. The description refers to 'a specified virtual machine' but adds no extra meaning beyond the schema. Baseline 3 applies since schema covers the parameter 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 clearly states the tool's function with a specific verb and resource: 'Stop a specified virtual machine' and 'Use this endpoint to power off running VPS instances.' It distinguishes the stop operation from sibling tools like VPS_startVirtualMachineV1 and VPS_restartVirtualMachineV1 by explicitly mentioning powering off.
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 usage context: 'Use this endpoint to power off running VPS instances.' It also notes idempotency (if already stopped, no effect), which helps agents decide when to call it. However, it does not explicitly contrast with start or restart tools, so the guidance is good but not fully exhaustive.
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 full burden. It discloses polling behavior and the condition for completion, as well as the resulting website_uid. Could mention error handling or rate limits, but for a simple status check, it's sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with zero wasted words. First sentence states purpose, second explains usage pattern. Information is front-loaded and 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 low-complexity polling tool with well-covered parameters, the description is nearly complete. It explains the return values (status, website_uid). Lacks list of possible status values or an example, but adequate overall.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds value by explaining that setup_uuid comes from the provisioning request. This contextual linkage goes beyond the schema's brief descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Returns' and the resource 'current status of an Agency Plan website setup', with specific context linking to a provisioning request. It distinguishes from sibling tools by its polling nature.
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 instructs to poll using the setup_uuid until status becomes completed, and mentions when website_uid is available. It does not mention when not to use or alternatives, but provides clear context for its polling use case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses the effect (cancel verification, back out of a WHOIS change) and the specific scenario (confirmation email cannot be received). However, it does not mention side effects, whether the action is reversible, or the expected outcome after cancellation, so it falls short of a perfect 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 concise, using two sentences with the action stated first. It is front-loaded with the core purpose and includes a brief, relevant example of when to use it. 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 cancellation tool with a single parameter, the description covers the purpose, usage context, and rationale. It lacks an output schema, but the given information is sufficient for an agent to select and invoke it appropriately, though it could mention expected outcomes or errors.
Complex tools with many parameters or behaviors need more documentation. Simple tools 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 'domain' parameter described as 'Domain name'. The description does not add any additional semantics beyond that, so the schema alone adequately documents the parameter, yielding 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 clearly states the tool's action: 'Cancel a pending IRTP verification.' It also explains the context (backing out of a WHOIS change stuck on registrant confirmation), which distinguishes it from related tools like domains_getPendingIRTPVerificationV1.
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?
Explicit usage guidance is provided: 'Use this endpoint to back out of a WHOIS change that is stuck waiting on registrant confirmation... without waiting out the 5-day expiry.' This tells when to use and implies the alternative of waiting, offering clear decision-making context.
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 were provided, so the description carries the full burden. It discloses the rate limit, the ability to check multiple TLDs at once, and the format requirement for TLDs (no leading dot). It also explains the alternative domain feature. More details on the response format would be helpful, but the description 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 only five sentences, front-loaded with the main purpose. Each sentence provides unique information: purpose, multi-TLD capability, alternatives usage, TLD format, rate limit, and use case. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity and complete parameter schema, the description covers usage, rate limits, and parameter nuances. It does not describe the response format, but no output schema exists, so this is not critical. A mention of what the response contains (e.g., availability status) would make it more 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?
Schema description coverage is 100%, so parameters are already well-documented. The description adds value by explaining the usage of `with_alternatives` (single TLD) and reinforcing the TLD format. It does not add new meaning for the `domain` parameter, but the schema already covers 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 tool checks availability of domain names across multiple TLDs. It uses specific verbs ('check availability') and resources ('domain names'), and distinguishes itself from sibling tools like domain forwarding, WHOIS, and lock operations.
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 to use this endpoint to verify domain availability before purchase. It also provides instructions for when to set `with_alternatives` to true (single TLD) and notes the rate limit of 10 requests per minute. It does not explicitly state when not to use it, but the purpose is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. The description correctly implies a read-only operation with no side effects. It adds no behavioral details beyond the basic action, but for a straightforward list tool, it is sufficient. No contradictions.
Agents need to know what a tool does to the world before 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, no wasted words. Essential information is front-loaded.
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 tool with no parameters, no output schema, and no annotations, the description fully captures its purpose and usage. Complete for the simplicity of the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has zero parameters, so no parameter description is needed. Schema coverage is 100% by definition.
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 'Retrieve all domains associated with your account' with a specific verb and resource. It distinguishes itself from sibling tools like 'domains_getDomainDetailsV1' which retrieves details of a specific domain, and 'domains_checkDomainAvailabilityV1' for availability.
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?
States 'Use this endpoint to view user's domain portfolio,' providing clear context for when to use. Does not explicitly mention alternatives or when not to use, but the sibling tool names imply the distinction.
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. It discloses that moves of every status are returned, including completed ones, which is a non-obvious behavior. It does not describe response format or pagination, but for a simple list tool this is sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, front-loaded with the main action, no redundant information. Every sentence adds value: the first states the core purpose, the second clarifies scope, and the third gives usage guidance.
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 relatively simple (no parameters, no output schema), and the description adequately covers the purpose and usage. However, it does not mention any potential response structure or pagination, which could leave an agent slightly uncertain about what to expect.
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 cannot add parameter-specific meaning. The input schema is empty, and the description doesn't need to compensate.
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 ('Retrieve') and resource ('all domains other Hostinger accounts are moving to your account'), distinguishing itself from sibling tools like the singular 'getIncomingDomainMove' by being a list operation. It also clarifies scope (all statuses) and 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 'Use this endpoint to find domains waiting for you to accept them,' which gives an actionable use case. It doesn't explicitly mention alternatives or exclusions, but the context is clear enough for an agent to understand when to choose this over the singular variant.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully covers behavioral traits: asynchronous generation, returns URL and ID, editing requires going to Hostinger Horizons interface, and detailed technology stack constraints. This leaves no ambiguity about tool 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 excessively long, largely due to the extensive technology stack constraints. While valuable, this information could be moved to separate documentation. The description is not concise and includes many lines that could be summarized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity and lack of output schema, the description covers all necessary aspects: purpose, usage, behavior, parameter semantics, post-invocation actions, and error handling. It leaves no 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% description coverage for its single parameter (message), which is already well-documented. The description adds no further detail about the parameter beyond what is in 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 'Create new Hostinger Horizons website from the given message' and specifies when to use it ('when user asks you to create a website, landing page, blog or any other type of application'). This distinguishes it from sibling tools like hosting_createWebsiteV1.
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?
The description provides explicit guidance on when to use (user requests website creation), what to do after invocation (exact reply format, provide URL, do not write code), and how to handle failures (clear explanation, no code generation). This is comprehensive and actionable.
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 explains the permanent cache clearing and CDN cache purge. It adds value by detailing the WordPress subdirectory case, though it omits auth and rate limit info.
Agents need to know what a tool does to the world before 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 concise sentences: purpose, when to use, and a special case for WordPress subdirectory. No wasted words, front-loaded with key 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 cache-clearing tool without output schema, the description covers the main action, CDN effect, and a special case. Lacks mention of irreversibility or timing, but sufficient for the task.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds meaning to the 'directory' parameter by explaining its use for WordPress subdirectories, improving beyond schema alone.
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 permanently clears all server-side cache for a website, differentiating it from cache-related siblings like disable/enable cache tools. It also mentions CDN cache purging when enabled.
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 explicit when-to-use scenarios: after content updates or major changes. Lacks explicit when-not or alternatives but gives clear context for usage.
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 description discloses that the operation is asynchronous, typical duration (1-2 minutes), and the need to poll the installations endpoint to confirm completion. It also explains what happens when overwrite is false and WordPress already exists. However, it does not mention possible failure reasons (e.g., incompatible PHP version) or authentication requirements, which are minor gaps given no 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 well-structured and front-loaded with the main action, followed by prerequisites, pre-checks, and async behavior. Every sentence adds value, and the length is appropriate for the tool's complexity. No redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (10 parameters, nested objects, async operation, preconditions), the description covers key aspects: prerequisites, pre-check steps, async behavior, and polling instructions. It also describes the response meaning (job queued). It does not mention error scenarios or rate limits, but for a tool without output schema, this is adequate. Slight gap in not explaining how to handle the overwrite parameter more deeply.
Complex tools with many parameters or behaviors need more documentation. Simple tools 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 description is not required to add much per-parameter detail. It does provide context for how parameters like 'username' and 'domain' are used in pre-checks and polling, and explains 'overwrite' behavior. However, the schema description for 'username' is vague ('username parameter'), and the description does not significantly enhance the schema's understanding of parameters beyond what is already stated.
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 'Install WordPress on an existing website,' using a specific verb and resource. It distinguishes from sibling tools like hosting_createWebsiteV1 (creating a website) and hosting_importWordpressWebsite (importing an existing site), making the tool's 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 Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states prerequisites (website must exist), provides step-by-step guidance (create website if needed, check for existing installation, call GET installations before proceeding), and explains the overwrite parameter behavior. This helps an agent decide when to use this tool versus alternatives like creating a website first.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description fully carries burden. Discloses data from periodic scans, potential lag, and that empty list doesn't guarantee safety. Also explains patchability and in-progress patches.
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?
Description is informative without being overly verbose. Front-loaded with main purpose, each sentence adds value. Could be slightly more concise, but structure is good.
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?
No output schema, but description explains result contents (severity, CVSS, CVE, advisory URL) and sorting. Covers edge cases and plan requirements. Complete for a list 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 has 100% coverage as all 3 parameters have descriptions. The description adds context for severities (filtering) but does not significantly expand meaning beyond 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 it lists npm package vulnerabilities for a Node.js website, enriched with advisory metadata. It distinguishes from sibling tools like hosting_patchNode_jsVulnerabilitiesV1 by mentioning the patch endpoint.
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 guidance on using severity filter and explains the meaning of empty results. Lacks explicit when not to use or alternative tools, but context is sufficient.
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?
Given no annotations, the description explains the effect of the tool (activate/deactivate) and the mechanism (enabled flag). It adds value beyond the input schema by clarifying the action. However, it could mention any prerequisites or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences with no unnecessary information. Every sentence serves a purpose: stating the action and providing a prerequisite location.
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 toggle operation with no output schema, the description is adequate. It covers the main action and where to get identifiers. However, it lacks details on return values or whether the change is immediate, which could be useful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for all parameters. The description adds context by linking the `software` parameter to a GET endpoint for obtaining the ID, and clarifies the role of `enabled`. This adds meaning beyond the schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'activate or deactivate' and the specific resource 'Memcached object cache for the specified WordPress installation'. It distinguishes itself from siblings like hosting_showMemcachedObjectCacheStatusV1, which is for viewing status.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear usage context: toggling cache based on the `enabled` flag, and instructs where to obtain the required identifier. However, it does not explicitly mention when not to use or name alternative tools for related tasks.
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?
Discloses silent capping of values above plan limits, which is critical behavioral information. Without annotations, this adds necessary transparency about operation semantics.
Agents need to know what a tool does to the world before 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, no fluff, front-loaded with purpose. 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?
Covers purpose, usage, and post-call action. Lacks output details, but compensated by advising a read-back call. Adequate for an update tool without 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?
Adds examples of PHP options and reiterates to only include changed options, enhancing the schema's generic description. With 100% schema coverage, this provides useful context beyond structure.
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 updates PHP options for a website, with specific examples (memory_limit, etc.), distinguishing it from read-only tools like getPHPDetails and other update 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?
Explicitly instructs to only provide options to change and advises calling getPHPDetails to verify applied values. Slightly lacking explicit when-not-to-use guidance, but sufficient for differentiation.
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?
Given no annotations, the description carries full burden and explains key behavioral traits: omitted optional fields are cleared, with specific effects on activation and duration. This is transparent, but does not cover potential side effects like whether the update is instantaneous or requires the autoreply to exist.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, concise and front-loaded with the action. Every sentence adds value without repetition or unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description adequately covers the tool's purpose and key input behavior. Although there is no output schema or mention of return values, for an update tool, the input focus is reasonable. It might benefit from noting the expected response, but it is sufficient given the 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?
Schema coverage is 100% with each parameter described. The description adds value by explaining the clearing semantics for 'starts_at' and 'ends_at', which goes beyond the schema's basic descriptions. This extra information aids correct parameter 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 clearly states the tool replaces an autoreply with given content and schedule. It uses a specific verb ('Replace') and identifies the resource (autoreply). It distinguishes from create/delete by focusing on modification, and adds detail on clearing omitted fields.
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 usage context by explaining the behavior when optional fields are omitted, which guides the agent on how to set immediate or indefinite autoreplies. However, it does not explicitly contrast with alternatives like create or delete, but the context is sufficient for most use cases.
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 covers two key behavioral traits: immediate execution (rather than queued) and idempotency ('succeeds without duplicating it'). It does not mention permissions, errors, or return format, but the disclosed behaviors are valuable and relevant 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 two sentences long, front-loaded with the primary purpose, and includes only relevant behavioral details. Every sentence earns its place with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple mutation with three parameters and no output schema, the description provides the core context: single-contact scope, immediate execution, and idempotency. It adequately differentiates from the bulk sibling and covers the most important behavioral edge case (duplicate assignment). It could be more thorough about errors or permissions, but is sufficient for this simplicity 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?
Schema description coverage is 100%, with each parameter having a basic description (e.g., 'Tag uuid parameter'). The tool description does not add additional parameter-level semantics beyond clarifying the roles of tag and contact in a single contact assignment. Baseline 3 is appropriate given the high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with 'Assign a tag to a single contact,' clearly stating a specific verb and resource. It distinguishes itself from the bulk endpoint by emphasizing 'single contact' and 'Unlike the bulk endpoint,' which sets it apart from sibling tools like reach_assignContactsToATagV1.
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 explicitly contrasts with the bulk endpoint ('Unlike the bulk endpoint this is applied immediately rather than queued'), giving the agent a clear behavioral reason to choose this tool for single, immediate assignments. This directly addresses when to use this tool versus alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It transparently notes that work is queued, so success means accepted rather than finished, and that already-tagged contacts are left alone (idempotency). This is valuable behavioral context beyond a simple mutation description.
Agents need to know what a tool does to the world before calling it. Descriptions 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 sentences with no filler. It front-loads the purpose, then explains parameter usage and behavioral nuances, each sentence earning 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 tool with 4 parameters and no output schema, the description covers the core usage modes (specific vs. all contacts), queue semantics, and idempotency. It could mention potential errors or that exactly one of contact_uuids/all_contacts should be provided, but the essential information is present.
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?
While the schema already covers all parameter names and basic descriptions, the tool description adds semantics by clarifying the relationship between contact_uuids and all_contacts: one targets specific contacts, the other targets all, and contact_uuids is required unless all_contacts is true. This goes beyond the schema's individual field descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action: 'Assign a tag to many contacts at once.' It specifies the resource (contacts) and the scope (many at once), distinguishing it from the singular sibling reach_assignAContactToATagV1 and other contact-management tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage context: pass contact_uuids for specific contacts or all_contacts to target every contact. It does not explicitly name alternatives for single-contact assignment, but the 'many contacts at once' phrasing implies the bulk-use case and separates it from the singular sibling.
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 and does well by emphasizing 'count' and 'without listing them,' implying a read-only operation. It also discloses a performance trait ('Cheaper'), which is useful behavioral context. It does not explicitly state that no data is modified or describe the return format, but the behavior is sufficiently clear for a simple count 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: the first states the core function, the second gives a usage tip. No filler, front-loaded, and every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description explains what the tool does and why to use it, and the tool name clarifies the profile-segment context. It does not explicitly mention the return format (a count) or explain what profileUuid/segmentUuid refer to, but for a simple count operation, this is a minor omission. Overall, it is complete enough 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 schema provides descriptions for both parameters ('Profile uuid parameter' and 'Segment uuid parameter'), but they are generic and merely restate the names. The tool description adds no extra parameter guidance. Since schema description coverage is 100%, 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 'Count the contacts currently matching a segment' with a specific verb and resource, and explicitly notes 'without listing them,' distinguishing it from list endpoints. The tool name also aligns perfectly with counting profile segment contacts.
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 explicitly states when to use this tool: 'Cheaper than paging through the segment contacts endpoint when only the size is needed.' This gives a clear use case and implies the alternative of paging/list endpoints, without naming a specific sibling but providing sufficient context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It reveals that the slug is derived from the label and that both slug and type cannot be changed later, which are significant non-reversibility details. It also notes the returned uuid for setting values, giving workflow context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded, and each sentence earns its place. The first states the purpose, the second provides critical lifecycle details. No filler 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?
The description covers the core workflow: define field, receive uuid, set values on contacts. It also warns about immutability. With the schema documenting option requirements, this is sufficient, though it lacks explicit guidance on when not to use and edge cases like label uniqueness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds meaning by explaining that label derives the slug and that type is immutable, which are not captured in the schema descriptions (which are mostly tautological like 'label parameter'). This adds 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 clearly states the tool defines a new custom contact field in a profile. It uses a specific verb ('Define a new') and identifies the resource ('custom contact field') and scope ('in a profile'). This distinguishes it from sibling update/delete/list field tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the use case (creating a new field) and instructs the user to use the returned uuid for setting values on contacts. However, it does not explicitly mention alternatives like updating or deleting fields, nor does it state when not to use this tool. The context is clear but lacks exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/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 transparency. It explicitly discloses that the segment definition is removed but contacts are left untouched, which is the key side effect of this delete operation. This provides essential context about what gets destroyed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences with the primary action front-loaded in the first sentence and the important caveat in the second. There is no filler or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple delete tool with two parameters and no output schema, the description covers the essential behavior: the segment definition is deleted and contacts remain. It does not specify whether the operation is reversible or what the exact relationship between profileUuid and segmentUuid is, but these are minor gaps given the simple 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?
Both parameters have schema descriptions that are merely tautological ('Profile uuid parameter', 'Segment uuid parameter'), and the description adds no additional parameter semantics. However, the parameter names are self-explanatory, and the schema coverage is 100%, 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.
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' with resource 'segment', clearly distinguishing it from sibling tools that create, update, or list segments. The tool name further specifies 'AProfileSegment', and the description's clarity avoids ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly states that only the segment definition is removed and contacts are left untouched, providing an implicit when-not-to-use: if the goal is to delete contacts, this is not the tool. However, it does not explicitly name alternative tools or specify conditions for use, so it falls short of the highest level.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that the endpoint is paginated, returns basic contact information, supports filtering by group UUID and subscription status, and has the important limitation of falling back to the default profile. However, it does not detail page size, response shape, or authentication expectations, leaving some transparency gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and well-structured: one sentence for the core purpose, one for pagination, and one paragraph for deprecation with an alternative. Every sentence adds value, and the deprecation notice is clearly separated.
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 has no output schema and no annotations, but the description covers the core usage, filters, pagination, and deprecation status. It does not describe the exact response structure (e.g., contact fields returned), which would be useful absent an output schema, but it effectively guides an agent to prefer the alternative endpoint. Overall, it is adequately complete for a deprecated, simple 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?
All three parameters are described in the schema with 100% coverage. The description only repeats that filtering by group UUID and subscription status is possible, adding no extra semantics beyond the schema. The page parameter is not elaborated beyond 'Page number' in either place, so the description does not compensate beyond the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get a list of contacts, optionally filtered by group and subscription status,' specifying the resource (contacts) and the action (get list). It also notes pagination and marks the endpoint as deprecated, which differentiates it from sibling tools like reach_listProfileContactsV1 and reach_listSegmentContactsV1.
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?
The description explicitly states the tool is deprecated, cannot target a specific profile, and always falls back to the client's default profile. It provides a direct alternative ('Use `GET /api/reach/v1/profiles/{profileUuid}/contacts` instead') and explains the improvement, giving clear when-not-to-use and when-to-use guidance.
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 takes on the disclosure burden. It reveals pagination behavior, the filtering mechanism, and the meaning of meta.total, including the edge case of no filters giving the total count. However, it doesn't mention error handling, default page size, or rate limits, which would elevate transparency further.
Agents need to know what a tool does to the world before calling it. Descriptions 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 sentences, each earning its place: purpose, filtering options, and response semantics. It is front-loaded with the core function and avoids fluff. No unnecessary details or repetition of schema fields.
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 no output schema, the description provides essential context about the response (meta.total) and filter behavior, which helps the agent understand the tool's capabilities. It doesn't describe the contact object fields, but sibling tools likely share a common structure. Some missing details like default pagination limits could make it more complete, but overall it's solid.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds value beyond the schema by explaining how filters interact and that meta.total reflects the filtered count, which is not stated in the schema. It also clarifies that the search parameter is an email search, reinforcing the schema description. This is meaningful supplementary 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 opens with 'Get a paginated list of contacts belonging to a profile,' which is a specific verb+resource statement. It clearly distinguishes from sibling tools like reach_listContactsV1 (all contacts) and reach_listSegmentContactsV1 (segment contacts) by scoping to a profile. The mention of filtering options further clarifies 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 explains the primary context: retrieving profile-specific contacts with optional filters. It doesn't explicitly name alternative tools or exclusion criteria, but the profile scope and filter list imply when to use it. It could be stronger by contrasting with reach_listContactsV1, but the provided context is adequate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It adds valuable context: 'the number of contacts currently matching it, which is recalculated on read rather than stored,' and explains the count_type parameter's behavior. This goes beyond what the schema states, though it does not detail other aspects like error handling or response 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 extremely concise: two sentences covering purpose and key behavioral nuances. There is no redundancy or extraneous information. Every sentence earns its place, making it easy for an agent to parse and act upon.
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 paginated list tool with fully described parameters, the description covers the essential aspects: what it returns (a list of segments with contact counts), the pagination aspect, and the non-obvious count behavior. It does not explicitly describe the response format beyond the count, but this is sufficient given the tool's simplicity. The lack of an output schema is mitigated by the clear description of the entries.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds meaning by elaborating on count_type: 'Use count_type to count either every matching contact or only the subscribed ones,' which clarifies the enum values beyond their schema descriptions. The other parameters (page, per_page, profileUuid) are adequately described in the schema and do not need further explanation.
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 a paginated list of the segments defined in a profile.' This specifies the verb (Get), the resource (segments), and the scope (defined in a profile), distinguishing it from sibling tools like reach_listSegmentsV1 that may not be profile-scoped.
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: use this tool to retrieve segments belonging to a specific profile. It does not explicitly name alternatives or exclusions, but the profile-scoped wording implicitly differentiates it from broader segment list tools. This is sufficient 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 provided, the description fully discloses the critical behavioral trait: the endpoint is deprecated, cannot target a profile, and falls back to the default profile. It also notes that it cannot read segments of any other profile, which is important context. It does not cover output format, but the most impactful caveat is transparently 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 two short paragraphs, starting with a clear purpose statement followed by essential deprecation context. Each sentence adds value—there is no filler or redundancy. The structure is front-loaded and easy to scan.
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 a simple list endpoint with pagination parameters, and the schema covers parameter semantics. The description provides the crucial deprecation warning and directs users to the correct replacement. While it doesn't describe the response format, the tool's purpose of retrieving contacts is clear, making it 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 input schema already provides descriptions for all three parameters (100% coverage), so the tool description doesn't need to add much. It only reinforces that the segment is identified by UUID, which the schema already implies. No additional parameter semantics are provided, 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 opens with 'Retrieve contacts associated with a specific segment,' clearly stating the action and resource. It explicitly identifies the segment by UUID and distinguishes this deprecated tool from the recommended alternative endpoint, 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 Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly labels the tool as 'Deprecated' and explains the key limitation: it 'cannot target a profile' and 'always falls back to the client's default profile.' It provides a direct replacement endpoint, giving clear when-to-use versus 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description takes on the full burden of behavioral disclosure. It does an excellent job by explicitly stating two important side effects: contacts assigned to the tag remain unaffected, and duplicate names are rejected. This goes beyond just saying 'Rename a tag' and informs the agent about the tool's non-destructive nature and validation behavior, which is critical 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 compact and front-loaded. The first sentence states the core action, and the two subsequent sentences each add necessary behavioral information. No words are wasted, and the structure is easy to scan. This is exactly the right size for this simple tool.
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 rename operation with three required parameters and no output schema, the description covers the essential behavioral aspects and constraints. It explains side effects on contacts and the uniqueness rule, which are the key contextual details an agent needs. It could potentially mention the result or return format, but that is not required given the absence of an output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides 100% coverage for all three parameters, so the baseline is 3. The description adds meaningful extra context for the 'value' parameter by explaining the uniqueness constraint within a profile, which directly affects how the agent should set that parameter. This elevates the score above the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the action with a specific verb and resource: 'Rename a tag.' This unambiguously distinguishes it from the many sibling tag-related tools, such as assigning contacts, deleting tags, or listing tags. The follow-up sentences add relevant scope, confirming the tool is purely for renaming.
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 primary use case obvious — renaming a tag. It provides clear context by stating that tag names are unique within a profile, implying a validation constraint. However, it does not explicitly describe when this tool should be preferred over alternatives like deleting and recreating a tag, 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It transparently discloses destructive behavior: 'any existing option left out of the list is deleted along with the values contacts hold for it,' and also notes immutability of field type/slug. This gives clear insight into side effects, though it omits details like required permissions or error 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 two concise sentences, front-loaded with the primary purpose. The second sentence provides essential nuances about option replacement and constraints without unnecessary detail, making it efficient 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?
The tool has 4 parameters and complex option replacement behavior. The description covers the key semantics, constraints, and destructive consequences, providing enough context for correct invocation. It lacks explicit return value information, but given no output schema and the nature of update operations, this is not a major 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 schema has 100% coverage with minimal descriptions (e.g., 'label parameter'), baseline 3. The tool description adds meaning by explaining that 'label' is the new name via 'Rename a custom contact field,' and the options parameter's replacement semantics are emphasized in both schema and description. This enriches understanding beyond the schema's terse labels.
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: 'Rename a custom contact field and, for the choice types, replace its option set.' It identifies the specific verb (rename/replace), resource (custom contact field), and scope (option set), making it distinct from sibling create/delete/list operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/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 (needing to rename a field or replace its option set) and provides an exclusion by stating 'The field type and slug cannot be changed.' However, it does not explicitly mention alternatives like reach_createAContactFieldV1 or reach_deleteAContactFieldV1, so it falls short of full explicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and discloses key behavioral traits: only properties in the body are changed, null clears values, and the response only includes core attributes. This goes beyond a generic 'update' and gives the agent concrete expectations.
Agents need to know what a tool does to the world before 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 short, front-loaded sentences with no redundancy. Purpose first, followed by critical behavioral details and a pointer for additional data retrieval.
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 9-parameter tool without output schema or annotations, the description covers partial update behavior, null handling, response scope, and directs to a GET method for full data. It lacks error handling and validation details but is otherwise complete enough for an agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaningful semantics for the `fields` parameter (omit vs empty array) and explains that null clears scalar properties. The schema descriptions are largely tautological ('name parameter'), so the description's added value is significant despite 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 tool updates a contact's attributes and custom field values, with a specific verb and resource. It distinguishes from related siblings like reach_createANewContactV1 and reach_deleteAContactV1 by 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear context for partial updates and null clearing, helping the agent understand when to use this tool. It does not explicitly name alternative update tools, but it does point to a GET endpoint for reading back extended data, offering reasonable guidance.
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?
Despite no annotations, the description discloses key behaviors: the tool can accept raw YAML content or a URL (with automatic GitHub resolution) and will replace an existing project with the same name. This is important destructive behavior. It could add details about what 'replaced' entails, but the current disclosure is sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, with two sentences plus a clarification about GitHub URLs. It front-loads the primary action and avoids unnecessary details. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description adequately covers input semantics and replacement behavior. It could mention typical return values or confirmation, but given the context, it is sufficiently complete for an AI agent to understand the operation's scope.
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 describes all 4 parameters (100% coverage). The description adds significant value by explaining the 'content' parameter in detail: it can be raw YAML, a URL to docker-compose.yaml, or a GitHub repository URL with auto-resolution. This goes beyond the schema description. The other parameters are not enhanced, but the overall addition is meaningful.
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: deploying a new project from docker-compose.yaml content or URL. It uses specific verbs (Deploy) and resources (new project), and distinguishes from sibling tools like VPS_updateProjectV1 and VPS_deleteProjectV1 by focusing on initial deployment from compose files.
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 on when to use this tool (for deploying from docker-compose) and explains URL handling for GitHub repositories. However, it does not explicitly compare with the sibling VPS_updateProjectV1 tool for updating existing projects, nor does it state when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses key behaviors: script saved to /post_install, executable attribute set, execution after VM install, output to /post_install.log, and maximum size of 48KB. This provides comprehensive 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 concise with three clear sentences: purpose, behavior details, and usage. No unnecessary words, well-structured, and front-loaded with the main 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?
Given the tool's simplicity (2 params, no nested objects, no output schema), the description covers core functionality, constraints, and use case. Minor gaps (e.g., error handling, execution user) are not critical for basic 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%, so the schema already defines parameters. The description does not add significant new meaning beyond what the schema provides, offering only general context about content. Score is baseline 3 as per guidelines.
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 "Add" and the resource "post-install script", explaining its purpose for automation after VM installation. It distinguishes from sibling tools like VPS_deletePostInstallScriptV1 and VPS_updatePostInstallScriptV1 by focusing on creation.
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 "Use this endpoint to create automation scripts for VPS setup tasks", indicating when to use. It lacks explicit when-not-to-use or comparison with alternatives, but the context implies creation vs. update or deletion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description fully bears the burden of behavioral disclosure. It explicitly warns about a non-obvious side effect: 'Any virtual machine that has this firewall activated will lose sync with the firewall and will have to be synced again manually.' This is critical information for an AI agent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences: purpose, consequence, and a slightly redundant usage instruction. It is efficient but not perfectly concise; the last sentence could be omitted. No unnecessary fluff.
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 delete operation with a notable side effect, the description is complete. It explains what the tool does, the consequence of its action, and its usage. There is no output schema, but none is needed for this operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers both parameters (firewallId, ruleId) with descriptions, so schema coverage is 100%. The description does not add any additional semantics beyond what is already 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 'Delete a specific firewall rule from a specified firewall,' using a specific verb ('Delete') and resource ('firewall rule'). It is easily distinguishable from sibling tools like VPS_createFirewallRuleV1 or VPS_updateFirewallRuleV1.
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 indication of when to use this tool ('Use this endpoint to remove specific firewall rules') but does not explicitly exclude alternatives or mention when not to use it. The mention of the manual sync consequence gives context.
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 discloses key behavioral details: preserves data volumes and network configurations, and refreshes containers. This informs the agent about safety (non-destructive to persistent data) and scope. However, it does not mention potential downtime 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 concise with two sentences in the first paragraph explaining the operation, and a short second sentence for use cases. Every sentence is informative with 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?
Given no output schema, the description does not explain return values but covers the operation and intended usage. It implicitly requires a virtual machine and project but does not explicitly state prerequisites. Overall, it provides sufficient context for an agent to decide when to use this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions. The description adds validation context for 'projectName' (alphanumeric, dashes, underscores) beyond the schema. 'virtualMachineId' is not further elaborated, but overall the description adds value beyond 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 ('restarts') and the resource ('all services in a Docker Compose project') with specific behavior ('stopping and starting containers in correct dependency order'). It distinguishes from sibling tools like VPS_startProjectV1 and VPS_stopProjectV1 by focusing on restarting.
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?
Explicit guidance is given: 'Use this to apply configuration changes or recover from service failures.' This provides clear use cases but does not explicitly state when not to use it or compare with alternatives like VPS_startProjectV1 or VPS_stopProjectV1.
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?
Since no annotations are provided, the description carries the full disclosure burden. It states that a successful response confirms registration, mentions error codes like 2037 for no free domain, and notes WHOIS prerequisites and additional_details validation. It does not cover idempotency or post-failure effects on the free domain, so it is 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description uses multiple paragraphs but every sentence contributes information such as TLD-specific requirements and error handling. It is somewhat longer than necessary but not redundant, and the main action 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?
The description covers what success means, failure handling, prerequisites, and TLD-specific behavior. However, it does not describe the success response structure beyond confirming registration, and there is no output schema to fill that 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 schema already describes all parameters (100% coverage), but the description adds context: WHOIS defaults if no contact info is provided, and some TLDs require additional_details which are validated. This goes 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 opens with 'Claim a free domain available on your account and register it,' a specific verb and resource. It distinguishes from purchasing by noting this consumes a free domain and requires no payment.
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?
The final sentence explicitly says 'Use this endpoint to register a domain using a free domain from your account.' It also contrasts with purchasing, establishing when to choose this tool over domains_purchaseNewDomainV1.
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 provided, so description must cover behavioral traits. It discloses archive content constraints and automatic build trigger. Does not mention destructive potential (overwrites?) or auth needs, but adequately explains the process for a deployment 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?
Four sentences, each adding value: purpose, critical archive constraints, build process, and post-deployment action. No redundancy, front-loaded with key info.
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?
Covers everything needed: what the tool does, archive preparation rules, automatic build, and follow-up tool for status. Without output schema, description compensates by guiding 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 coverage is 100% with clear parameter descriptions. The description reinforces the archivePath constraint already in schema, adding no new semantic meaning beyond what schema provides. Baseline score 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?
Clearly states it deploys a JavaScript application from an archive, distinguishing it from static site deployment (hosting_deployStaticWebsite) and Node.js build creation (hosting_createNodeJSBuildFromArchiveV1). The verb 'deploy' and resource 'JavaScript application' are specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly specifies archive contents requirements (source files, no build output, skip node_modules, respect .gitignore) and directs to use hosting_listJsDeployments for status tracking. Provides clear when-to-use and post-deployment guidance.
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, so description carries burden. Discloses that subdomain is free, unique, and allows later custom domain connection. Missing details on prerequisites but adequate for a simple generation 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?
Two sentences, no extraneous words. Front-loaded with main action, followed by benefit.
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?
Complete for a zero-parameter generation tool. Explains purpose and future flexibility. No missing information given 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?
No parameters; schema coverage 100%. Baseline of 4 applies as description need not add 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?
Clear verb 'Generate' and specific resource 'free subdomain'. Distinguishes from siblings like createWebsiteSubdomain by emphasizing it's free and unique.
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?
Explicitly states it's for starting hosting without purchasing custom domains, providing immediate use and future custom domain connection. Implies when to use but lacks explicit alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully bears behavioral disclosure. It correctly notes the async nature and prerequisite of an existing installation. It does not cover error scenarios or permissions, but the key async behavior is well-communicated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is four sentences, front-loaded with the primary action, followed by parameter retrieval guidance and async behavior. Every sentence serves a purpose with no redundancy.
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 tool with 3 required parameters and no output schema, the description fully covers how to obtain each parameter and explains the response (async job queued). It leverages prerequisite endpoints effectively, ensuring agents have sufficient context to invoke the tool 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?
Schema coverage is 100%, but the description adds value by telling how to retrieve the software ID and discover plugin slugs, going beyond what the schema alone provides. This helps agents correctly populate 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 verb 'Install' and the resource 'plugins on an existing WordPress installation'. It distinguishes from sibling tools like hosting_activateWordPressPluginV1 or hosting_uninstallWordPressPluginsV1 by focusing solely on installation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit instructions on obtaining the required software identifier and plugin slugs via linked endpoints. It sets async expectations but lacks explicit when-not-to-use guidance or comparisons to other tools like hosting_updateWordPressPluginsV1.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explicitly states the asynchronous nature: 'This operation is asynchronous: a successful response only means the install job has been queued.' It also clarifies that optional fields are ignored for non-Hostinger themes. No annotations were provided, so the description carries full burden and handles it well.
Agents need to know what a tool does to the world before calling it. Descriptions 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: one sentence for purpose, one for obtaining the ID, one for special theme behavior, and one for async nature. Every sentence adds value and is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the essential aspects: how to get the required software ID, the conditional handling of optional fields, and the async behavior. No output schema exists, but the description adequately explains the queued response. It is complete for the given 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 description coverage is 100%, and the schema already provides detailed descriptions for each parameter, including the conditional behavior for Hostinger themes. The description adds little beyond confirming the async nature and the source of the software ID, so it meets the baseline but does not significantly 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 'Install a theme on an existing WordPress installation.' It specifies the verb (install), resource (theme), and context (existing WordPress installation). This distinguishes it from sibling tools like activate, deactivate, list, etc.
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 explains when to use the tool (install a theme) and provides guidance on obtaining the software ID. It also notes the special behavior for Hostinger themes. However, it does not explicitly mention when not to use it or compare with alternatives like activation.
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 full burden for behavioral disclosure. It states the tool restarts without rebuilding/redeploying, applies only to server-side Node.js apps, and returns success even without a server process. However, it does not specify if the restart is immediate or causes temporary downtime, or if it is a graceful restart. Minor gap, but still 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 highly concise and well-structured. First sentence states the action, second clarifies exclusions, then provides use cases, applicability constraints, and a behavioral note. Every sentence earns its place with no redundancy. Information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (2 params, no output schema), the description is complete. It covers purpose, when to use, when not to use, limitations, and return behavior. With no annotations or output schema, the description provides all necessary context for an AI agent to correctly invoke this tool among a large set of siblings.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description does not add any additional meaning beyond the schema's parameter descriptions ('Domain name', 'username parameter'). No examples, formats, or constraints are provided. The description meets the minimum by not contradicting the schema but adds 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 tool restarts the Node.js server process for a website and explicitly distinguishes it from rebuild/redeploy operations. It uses a specific verb ('restarts') and resource ('Node.js server process'), making the purpose unambiguous and differentiating it from sibling tools like hosting_deployJsApplication or hosting_listJsDeployments.
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?
The description provides explicit 'when to use' scenarios (applying environment/config changes, recovering a hung app) and clear 'when not to use' guidance (static front-ends, non-server-side apps). It also notes that the tool returns success even when no server process exists, setting correct expectations. This level of detail fully addresses usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that the plaintext token is returned only once and is never retrievable again, as well as the 10-token limit. This adds important behavioral context beyond the 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?
Three well-structured sentences; concise and front-loaded. No unnecessary words. The scope advice is presented clearly.
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?
Despite no output schema, the description covers creation purpose, token usage, unrecoverability, limits, and scope choices. Sibling tools are related but irrelevant to completeness. All essential context is provided.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, providing baseline. The description adds meaning by explaining the scope options (`has_all_mailboxes` vs `mailbox_ids`) and that `name` is a human-readable label. This goes slightly beyond what the schema 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 creates an API token for a mail order and explains the token's purpose (access to Hostinger Email API for mailbox management). It distinguishes from sibling tools like mail_revokeAPITokenV1 and mail_listAPITokensV1.
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 guidance on when to use `scope.has_all_mailboxes` versus listing specific mailboxes in `scope.mailbox_ids`. Mentions the maximum token limit per order (10). Does not explicitly state alternatives or when not to use, but context is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It reveals key traits: the tag is removed from every contact, contacts are preserved, and the operation is idempotent (deleting a non-existent tag succeeds). This is strong transparency for a simple deletion tool, though it doesn't mention reversibility or return values.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the primary action ('Delete a tag and remove it from every contact carrying it'), followed by two critical clarifications (contacts not deleted, idempotency). Every sentence earns its place with no redundancy.
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 two-parameter tool with no output schema, this description is complete: it defines the main operation, the cascade effect to contacts, the non-deletion of contacts, and idempotent behavior. No essential information is missing for an agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, providing basic 'uuid parameter' descriptions. The description adds meaning by contextualizing 'tag' and 'profile' (e.g., 'in the profile'), clarifying that tagUuid is the tag to delete and profileUuid is the profile context. This goes beyond the schema but isn't exhaustive.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool deletes a tag and removes it from every contact carrying it, distinguishing it from sibling tools like removing a contact from a tag or deleting a contact. The verb 'Delete' is specific and the resource is a tag, with the scope clarified as 'every contact carrying it'.
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 deletes a tag, removes it from all contacts, and clarifies that contacts themselves are not deleted. This implicitly warns against using it for contact deletion or single-contact removal, though it doesn't explicitly name alternative tools. Idempotency is noted, aiding usage understanding.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries full burden. It explicitly states 'Retrieve' and 'view', making it clear this is a read-only operation with no destructive effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences: one stating the action, one stating the usage recommendation. No redundant or unnecessary information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one required parameter and no output schema. The description sufficiently explains what the tool does and when to use it. No missing information 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?
The single parameter 'virtualMachineId' is already fully described in the input schema with 'Virtual Machine ID'. The description does not add extra meaning beyond schema. Since schema description coverage is 100%, baseline score 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 'Retrieve snapshot for a specified virtual machine', which is a specific verb+resource. Among siblings, there are create, delete, and restore snapshot tools, so this one is distinctly the read 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 says 'Use this endpoint to view current VPS snapshot information', which gives clear context for when to use it. It implies not to use it for creating or deleting snapshots, but does not explicitly mention alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that the transfer is validated first to avoid consuming the free transfer on invalid domains, that a successful response only means the transfer started, that default WHOIS contacts are used if none are provided, and that failures return error codes. It is rich on side effects and sequencing.
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 verbose but well-structured and front-loaded. Each paragraph carries meaningful context, though the final sentence is somewhat redundant with the first. Overall, it earns its length given the complexity of the operation.
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 complex operation with no output schema and no annotations, the description is exceptionally complete. It covers side effects, validation, default WHOIS behavior, error handling, and how to track the transfer progress, including a link to the transfer list endpoint.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds extra context beyond the schema by explaining the meaning of auth_code (get it from the current registrar) and the default behavior for domain_contacts when not provided. This elevates the value beyond the bare parameter descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: claim a free domain transfer and start a transfer. It explicitly contrasts with purchasing a transfer, which distinguishes it from the sibling tool domains_purchaseNewDomainV1.
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 explains when to use this endpoint (when you have a free domain transfer) and contrasts it with purchasing. It also provides concrete preconditions: unlock the domain, get the auth code, and ensure WHOIS information exists, which guides the agent on prerequisites.
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 explains that the archive is extracted and deployed directly without build steps, and that the username is auto-resolved. However, it could be more transparent about prerequisites (e.g., domain must exist, hosting account needed) and potential failure scenarios. Still, it adds meaningful behavioral context beyond the 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 concise and well-structured. It front-loads the purpose, uses clear language, and includes important caveats in all caps. Every sentence adds value without unnecessary 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?
Given the tool's simplicity (3 parameters, no output schema), the description is largely complete. It covers when to use, how to use, and parameter nuances. However, it does not mention what happens after deployment (e.g., URL or status) or any required domain ownership verification. Still, it is sufficient for an agent to use 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?
Schema coverage is 100%, so baseline is 3. The description adds value by detailing how to handle a directory path for the archivePath parameter, including a specific naming pattern. The other parameters are adequately described in the schema and repeated in the description. This extra guidance justifies a 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 the tool's purpose: 'Deploy a static website from an archive file to a hosting server.' It specifies that it works only for static websites with no build process, and distinguishes it from the sibling tool 'hosting_deployJsApplication' which handles JS applications with build steps.
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?
The description explicitly states when to use this tool ('This tool only works for static websites with no build process') and provides a clear alternative: 'If the website has a package.json file or requires a build command, use hosting_deployJsApplication instead.' It also gives archive format requirements and notes that the username is automatically resolved from the domain.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/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 explicitly reveals that omitting conditions preserves them, supplying conditions replaces the entire set (not merges), and that contact membership can change immediately. It also clarifies the tool does not modify contacts directly. These are critical side-effect behaviors beyond the 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 concise and front-loaded with the primary purpose. It consists of two short paragraphs, with the first sentence stating the function and the second paragraph providing essential behavioral details. Every sentence contributes value, with no filler or repetition of schema content.
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 moderate complexity (5 parameters, nested condition objects, no output schema), the description covers the most important contextual aspects: the rename/replace semantics, the side effect on contacts, and the behavior of omitting conditions. It does not explicitly mention the `logic` parameter's requirement when conditions are provided, but that is documented in the schema. Overall, the description 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.
Parameters4/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 meaningful parameter semantics, particularly for `conditions` and `name`: it explains the 'replace entire set' behavior, the always-required nature of `name`, and the option to omit `conditions` for renaming only. This goes beyond the schema's basic descriptions by clarifying the relationship between 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 tool's function: 'Rename a segment and/or replace the conditions that define it.' This uses a specific verb ('rename', 'replace') and identifies the resource ('segment'), distinguishing it from sibling tools like create, delete, or get. The scope 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage context: it explains when to omit conditions (rename-only) versus supplying them (replace entirely). It also clarifies that contacts are never modified, setting expectations. However, it does not explicitly name alternatives or state 'use this instead of create/delete,' though the update semantics are implied.
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 full burden. It implies a read-only retrieval with no destructive effects. While it doesn't detail rate limits or auth, the operation is simple and 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?
Two front-loaded sentences with no wasted words. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters and no output schema, the description fully covers purpose and context. It is complete for a simple retrieval tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, and schema coverage is 100%. The description adds meaning by specifying the output is about OS templates, which is exactly what is 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 the tool retrieves available OS templates for virtual machines and specifies the use case: viewing options before creating or recreating VPS instances. This differentiates it from sibling VPS tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly advises using this endpoint to view OS options before creation or recreation, providing clear context. It does not list when not to use it or mention alternatives, but the guidance is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explicitly states irreversibility, data loss, deletion of snapshots, password checking against leaked databases, and password requirements. No annotations provided, so description carries full burden and does so thoroughly.
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 well-structured with clear sections (main description, password requirements, warning). It is comprehensive but slightly verbose; could be tightened while retaining all critical 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?
No output schema exists. The description explains the effect, side effects, and prerequisites well. However, it does not explicitly describe the response format or what happens after operation (e.g., async action details).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions. The description adds value by detailing password requirements (leaked check, length, character classes) and notes that panel_password is ignored if unsupported, beyond what the schema 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 recreates a virtual machine from scratch, reinstalling the OS and resetting to initial state. It distinguishes from siblings like VPS_restartVirtualMachineV1 or VPS_restoreSnapshotV1 by specifying it's a destructive rebuild.
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 says 'Use this endpoint to completely rebuild VPS instances with fresh OS installation.' It provides clear context for when to use, but does not explicitly mention alternatives or when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It discloses asynchronous processing, the IRTP verification trigger for owner-contact changes, the automatic resolution of the current profile, and the failure condition when roles are not on the same profile. This is rich, non-obvious behavior that goes well beyond the 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 concise and well-structured. The first sentence states the purpose, followed by the key mechanism, constraints, and usage note. Every sentence provides useful information without 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?
The tool is well-explained for its complexity. It covers the change action, automatic resolution, failure conditions, IRTP verification, asynchronous behavior, and when to use it. Without an output schema, it could mention response format, but the descriptive text is sufficiently complete for an AI 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.
Parameters4/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 meaning by clarifying the relationship between parameters: roles are repointed to a new profile, and there is a constraint that all given roles must already be on the same profile. This goes beyond the parameter descriptions in 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 a specific action: 'Change WHOIS contact profile for a domain.' It also explains the mechanism ('Repoints the given contact roles to a new WHOIS profile') and distinguishes itself from related domain/profile tools by focusing on reassignment of a domain to an existing 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 explicitly says 'Use this endpoint to move a registered domain onto different contact information,' providing clear context for when to use it. It does not explicitly name alternatives or exclusions, but the purpose is specific enough to avoid confusion with sibling tools like setting a default profile.
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 provided, so description carries full burden. It explains the verification process, the response field 'is_accessible', and the need for DNS propagation (up to 10 minutes). Does not mention any destructive behavior, which is appropriate for a read-like operation. Could clarify that no changes are made to the domain, but overall 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?
Three sentences plus a note, all front-loaded with the main purpose. Each sentence serves a clear function: purpose, usage context, and skip condition. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple verification tool with one parameter and no output schema, the description covers the action, expected response, failure recovery steps, and an exception. It is sufficient for an agent to understand 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?
Schema coverage is 100% with one parameter 'domain' already described. The description adds practical context: what the domain is used for (to check ownership) and the special case of free subdomains, enhancing understanding beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'verify ownership' and the resource 'single domain', distinguishing it from sibling tools that handle domains differently (e.g., domains_getDomainDetailsV1, DNS_* tools). It explicitly mentions the purpose of checking accessibility before using for new websites.
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?
Provides explicit when-to-use guidance (before using domain for new websites) and when-not-to-use (skip for Hostinger free subdomains). Also describes the verification flow: check accessibility, if not accessible add TXT record and retry, noting DNS propagation delay.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses behavior: it returns a list of projects with specific fields, explicitly states that container stats are omitted, and points to another endpoint for detailed info. No contradictions with annotations (none provided).
Agents need to know what a tool does to the world before calling it. Descriptions 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, front-loaded with the main action, and includes only relevant details. Every sentence serves a purpose: stating the action, listing returned data, noting omission, and providing an alternative. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has one parameter and no output schema, the description is complete. It explains what the tool returns, what is excluded, and how to get the excluded information. It covers the essential context for an agent to use 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 has 100% description coverage (parameter 'virtualMachineId' is described). The description does not add additional meaning beyond what the schema provides, so it meets the baseline of 3. No extra semantic value is added.
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 retrieves a list of all Docker Compose projects, specifies the returned information (name, status, file path, containers with details), and omits container stats. It distinguishes from the sibling tool VPS_getProjectContainersV1 by noting the omission and directing users to that endpoint for stats.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'Use this to get an overview of all Docker projects on your VPS instance.' Also provides a when-not-to-use condition: 'If you need to get detailed information about container with stats included, use the `Get project containers` endpoint.' This gives clear guidance on alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully carries the burden. It details the full workflow: domain resolution, archive upload via TUS, import-archive trigger, synchronous execution, and immediate live state after success. It explicitly warns about irreversible overwrite. No behavioral traits are hidden.
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 paragraph that is thorough but somewhat lengthy. While each sentence adds value, it could be more structured (e.g., bullet points for warnings and workflow). It front-loads purpose and warning effectively, but the density reduces scanability slightly.
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?
No output schema exists, but the description covers the outcome (synchronous, website live on success). It explains the destructive nature and the steps involved. Missing details about potential error handling or return format, but for a deployment tool, the essential context is present. It adequately compensates for missing output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%. The description adds significant value beyond schema: it explains the workflow for archivePath (creating an archive from a directory with a specific naming pattern), supported formats (zip, tar, tar.gz, tgz), and default behavior for removeArchive. This extra context aids correct selection and invocation.
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 deploys a PHP (or other non-build) Agency Plan website from an archive. It distinguishes itself from the sibling tool agencyHosting_deployNodeStaticWebsite, which is for node-static websites requiring a build step. The verb 'deploy' combined with specific resource and conditions makes 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 Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use (Agency Plan websites, no build step), when not to use (node-static requiring build step), and provides the alternative tool. It also warns about destructive overwrite and the need for user confirmation, giving clear usage boundaries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations, but description fully discloses destructive nature, async processing, confirm field requirement, and 404 on invalid domain.
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?
Well-structured with critical warning first, but slightly verbose. Every sentence adds value though.
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?
Complete for a single-param destructive tool: covers purpose, constraints, async behavior, error responses.
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 covers domain with 100% coverage; description adds constraint that domain must be exact, not alias or preview.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it permanently deletes a website and all data. Distinguishes from siblings like create, parked domain deletion, etc.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly requires explicit user confirmation, lists supported/unsupported website types, and clarifies domain must be exact.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses important behaviors: it modifies package.json, opens a PR, triggers deployment on merge, and lists error conditions (404, 403, 422) and plan limitations. This provides comprehensive understanding of the tool's actions and 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 paragraph that is well-structured, starting with the main purpose then providing details on constraints and edge cases. It is thorough without being verbose, though it could be slightly more concise by combining some related sentences.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description effectively explains the output (pull request creation, deployment trigger) and all important preconditions and error scenarios. It covers plan requirements, GitHub connectivity, mutation behavior, and concurrency limits, making it complete for an agent to decide when and how to use the 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?
Schema coverage is 100% so baseline is 3. The description adds value by explaining that vulnerability_ids should come from the list endpoint and that only patchable IDs are processed, and non-patchable ones are skipped. This enriches parameter understanding beyond the schema's brief descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it patches Node.js vulnerabilities by updating package.json and creating a pull request. Distinguishes from sibling tools like hosting_listNode_jsVulnerabilitiesV1 which lists vulnerabilities, 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 Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly specifies when to use: only for patchable vulnerabilities (is_patchable=true), requires connected GitHub repo with write access, and plan restrictions (Business/Cloud). Also clarifies behavior for non-patchable IDs and archive deployments, and that only one open PR per website is allowed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description fully discloses the destructive overwrite behavior, synchronous nature, and the process steps (resolves domain, uploads archive, triggers build-assets).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Every sentence serves a purpose, from purpose to warning to process to synchronous guarantee. Front-loaded and well-structured with no waste.
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?
Covers all essential aspects: what it does, how it works, behavioral traits, and results. No gaps given tool complexity and no 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?
Schema coverage is 100%, but the description adds valuable context: supported archive formats, naming pattern for directory input, and explains removeArchive default. High value beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool deploys a node-static Agency Plan website from an archive file, specifies the resource type, and distinguishes from the sibling tool agencyHosting_deployPhpApplication.
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 explicitly says when to use (node-static websites) and when not to (PHP applications), and includes a warning about overwriting and the need for user confirmation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses key behavioral traits: WHOIS profiles must belong to the account and satisfy TLD requirements, accepting does not complete the move, a confirmation email is sent, and the move enters 'activating' status.
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 relatively long but every sentence adds value. It is front-loaded with the action, then explains constraints and follow-up. Structure is logical, though a bulleted list for requirements would improve skimmability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description fully covers the expected flow: prerequisites, state requirement, the fact the move is not immediately complete, the resulting 'activating' status, and the endpoint to track progress. It is complete for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is complete, but the description adds crucial semantics: the WHOIS profiles become the domain's contacts, must belong to your account and satisfy TLD requirements, and all four IDs must be provided even though only applicable contact types are used. This goes beyond the schema's per-field descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb+resource: 'Accept an incoming move for a specified domain.' It clearly distinguishes from sibling tools like rejectIncomingDomainMoveV1 by framing it as taking ownership of an offered domain.
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?
Explicit usage is given: 'Use this endpoint to take ownership of a domain offered to you.' It also states when not to use (already accepted moves cannot be accepted again) and clarifies the partial nature of the action, which implies alternatives for following up.
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:

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

Score Badge

Copy to your README.md:

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

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/hostinger/api-mcp-server'

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