hostinger-api-mcp

Official

by hostinger

Overview Schema Related Servers Score Discussions(1)

TypeScript

Remote

Server Quality Checklist

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

Latest release: v1.57.0
Disambiguation1/5
Several tools are effectively duplicates or near-duplicates (e.g., reach_createANewContactV1 vs reach_createNewContactsV1, hosting_deployWordpressPlugin vs hosting_deployWordpressPluginV1, deprecated vs profile-scoped segment/contact endpoints), so an agent cannot reliably pick between them. Even where descriptions differ slightly, the overlapping names and legacy variants create persistent ambiguity.
Naming Consistency2/5
Naming mixes VPS_ PascalCase with lowercase-camel prefixes for other services, has inconsistent V1 suffixes, and includes odd forms like v2_getDomainVerificationsDIRECT and hosting_startNode_jsBuildV1. A broad service_action pattern is recognizable, but casing and suffixes are not predictable.
Tool Count1/5
372 tools is an extreme count for a coherent MCP surface; it includes deprecated variants, duplicates, and many near-identical operations that could be consolidated. The size alone makes selection and discovery impractical.
Completeness3/5
The set covers an impressively wide range of Hostinger domains (VPS, hosting, domains, DNS, mail, billing, ecommerce, Reach, Horizons), but there are notable lifecycle gaps in several areas (e.g., no VPS deletion, no discount update/delete, no mailbox settings update beyond password) and deprecated endpoints create dead ends. Core workflows are present, but the surface is uneven.
Average 4/5 across 372 of 372 tools scored. Lowest: 2.8/5.
See the Tool Scores section below for per-tool breakdowns.
- 14 of 21 community issues answered or closed in the last 6 months
- 116 commits in the last 12 weeks
- Last stable release on September 4, 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?
The annotations already indicate a non-read-only, destructive, idempotent operation, and the description adds no behavioral context beyond the obvious effect. It does not explain consequences such as stopping future renewals or any side effects, though it does not contradict the annotations.
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 first sentence is compact and clear, but the second sentence is redundant and grammatically flawed. Not every sentence earns its place, and no additional structure or useful detail is provided.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter mutation with annotations and full schema coverage, the description is minimally adequate. However, with no output schema, it gives no indication of the response or error behavior and lacks the usage guidance that would make it fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter, subscriptionId, is already described in the input schema, so schema description coverage is 100%. The description adds no extra meaning about the parameter's format, constraints, or usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource: 'Disable auto-renewal for a subscription.' It clearly states what the tool does and matches its title. It does not explicitly contrast with the sibling billing_enableAutoRenewalV1, but the action is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
'Use this endpoint when disable auto-renewal for a subscription' simply restates the purpose and gives no real selection guidance. It does not mention when not to use it, prerequisites, or alternatives such as enabling auto-renewal or renewing a subscription.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate a non-read-only, idempotent, destructive state change; the description adds no behavioral detail on top. It does not warn that enabling auto-renewal commits the user to recurring future charges or clarify what state the subscription should be in.
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 first sentence is crisp, but the second sentence is redundant and grammatically garbled ('when enable auto-renewal'), adding no information. A single clean sentence would earn a higher score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter billing mutation the core is simple, but the description omits the consequential behavior (recurring charges), any eligibility constraints, and how it differs from renew/disable. The annotations carry some weight, but the description alone would not let an agent safely advise a user on whether to call this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%: subscriptionId is documented as 'Subscription ID' with type string and required. The description adds no semantic meaning beyond that, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The first sentence states a concrete operation: enabling auto-renewal on a subscription, with the target resource matching the sole parameter. However, the second sentence merely restates the first, and no distinction is drawn from billing_disableAutoRenewalV1 or billing_renewSubscriptionV1, though the name already does much of that work.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps 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 only usage guidance is 'Use this endpoint when enable auto-renewal for a subscription,' which circularly restates the purpose and offers no decision criteria. It fails to mention that this is the counterpart to billing_disableAutoRenewalV1 or that billing_renewSubscriptionV1 handles immediate renewal rather than ongoing renewal.
Agents often have multiple tools that could apply. Explicit usage guidance like "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 annotations already declare readOnlyHint=false, destructiveHint=true, and idempotentHint=true, so the safety profile is known. The description adds no behavioral context beyond restating the operation, such as whether active sessions are invalidated, whether the change is immediately effective, or how the mailbox is affected.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single focused sentence with no wasted words and places the action first. It is concise and easy to parse, though it is so minimal that it does little more than mirror the tool's title.
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 mutation, the schema plus annotations cover the core input and safety expectations. The description is complete enough to identify the intended operation, but it omits behavioral consequences and any retrieval guidance for mailboxId, which would strengthen an agent's confidence.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%: the password parameter already has a detailed policy, and mailboxId is described as 'Mailbox resource ID'. The description adds no additional parameter 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 names the specific verb ('Change') and resource ('the password of a mailbox'), which is clear and unambiguous. However, it is essentially a restatement of the title and does not explicitly differentiate itself from sibling mail tools, even though no sibling offers the same operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus alternatives, no prerequisites, and no exclusions. It is inferable from the operation name, but the description itself provides no explicit usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate a non-read, non-destructive write; the description adds no behavioral detail beyond that (e.g., whether the firewall starts activated, whether rules must be added separately, or what is affected). It does not contradict the annotations, but it does not disclose side effects or follow-up 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 short and front-loaded with the core action. The second sentence largely restates the first, adding only 'for VPS security,' so it is concise but not perfectly information-dense.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no mention of the firewall lifecycle, an agent cannot tell what the response will contain or whether creating a firewall requires subsequent rule-creation/activation steps. For such a sibling-rich domain, this is a noticeable 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 baseline is 3; however, the only parameter description is the tautological 'name parameter,' and the tool description does not clarify what name should represent (firewall label, VPS association, etc.).
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?
States a specific action and resource: 'Create a new firewall' / 'set up new firewall configurations for VPS security.' It is clear enough to distinguish a firewall-level operation from rule-level siblings such as VPS_createFirewallRuleV1, though it never explicitly contrasts 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 instead of VPS_createFirewallRuleV1, VPS_activateFirewallV1, or VPS_syncFirewallV1. The only context is 'Use this endpoint to set up new firewall configurations,' which restates the purpose rather than providing selection criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false and destructiveHint=false, which align with the add operation. The description adds only that it's for SSH keys. It doesn't disclose side effects like duplicate key handling, response structure, or whether the key is account-wide. Given the non-destructive nature indicated by annotations, the lack of additional behavioral detail is acceptable but not enhanced.
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 concise sentences, with the primary action front-loaded. No redundant information. The second sentence adds relevant context (SSH keys for VPS) but could be integrated into the first. Overall efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a create operation with no output schema, the description doesn't explain what a successful response looks like (e.g., key ID, status) or any error conditions. It also doesn't clarify whether keys are account-scoped or need to be attached separately. Given the tool's simplicity, the core purpose is covered, but an agent would benefit from knowing the expected outcome and usage flow.
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 descriptions are purely tautological ('key parameter', 'name parameter'), providing no meaning. The description hints that 'key' is an SSH key but doesn't specify format (e.g., RSA, Ed25519), required encoding, or how 'name' should be used. Since the schema itself is unhelpful, the description fails to compensate, leaving the agent uncertain about parameter expectations.
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 'Add a new public key to your account' – a specific verb and resource. It adds context by specifying 'SSH keys for VPS authentication,' which helps differentiate from attachment operations like VPS_attachPublicKeyV1. However, it doesn't explicitly contrast with the attach tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The second sentence says 'Use this endpoint to register SSH keys for VPS authentication' – more of a purpose than usage guidance. It provides no conditions for when to use this over VPS_attachPublicKeyV1 (which presumably attaches keys to a VM), no exclusions, and no prerequisites. The agent is left to infer the appropriate context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true and readOnlyHint=false, so the destructive nature is conveyed by structured data. The description adds that this resets the DNS zone to default/original records, which clarifies scope, but it does not mention side effects such as email record handling or irreversibility beyond what the annotations imply.
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 short and the main action is front-loaded. However, the second sentence largely paraphrases the first ('restore domain DNS to original configuration' vs 'reset DNS zone to default records'), making it slightly redundant.
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 core action is clear and the schema covers parameter meanings, while annotations cover destructiveness. Still, for a destructive DNS operation with no output schema, the description omits when to use it relative to snapshot restore/update/delete and does not explain how reset_email_records or whitelisted_record_types affect the reset behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so every parameter (sync, domain, reset_email_records, whitelisted_record_types) already has a documented meaning. The description adds no parameter-level details or relationships, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('Reset') and resource ('DNS zone'/'DNS records'), and clarifies the intended outcome: restore records to default/original configuration. It clearly differentiates from update/delete operations, though it does not explicitly name a sibling tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to use this tool versus alternatives like DNS_restoreDNSSnapshotV1, DNS_updateDNSRecordsV1, or DNS_deleteDNSRecordsV1. The phrase 'Use this endpoint' restates the purpose rather than providing selection criteria, 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?
Annotations already mark this as a write operation (readOnlyHint=false, destructiveHint=false). The description adds a meaningful side effect — a primary sales channel is auto-created — but does not disclose other behavioral details such as store limits, naming constraints, or whether creation is immediate or asynchronous.
Agents need to know what a tool does to the world before 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, both informative. The first states the operation and scope, and the second adds a relevant side effect. No filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a create operation with six parameters, a nested sales_channel object, an empty required array, and no output schema, two sentences are insufficient. The agent is not told which parameters are effectively required, what a successful response contains, or what creating a primary sales channel implies for further setup.
Complex tools with many parameters or behaviors need more documentation. Simple tools need 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 applies. The description adds no parameter-level meaning beyond the schema, and several schema parameter descriptions are tautological ('name parameter', 'company_name parameter'), so there is no bonus for clarity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb and resource: 'Create a new store for your account.' It also mentions that a primary sales channel is created, which helps distinguish it from sales-channel-specific tools. However, it does not explicitly name an alternative, so it stops short of full sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus related siblings such as ecommerce_createASalesChannelV1, ecommerce_getStoresV1, or ecommerce_updateSalesChannelV1. There are no prerequisites, exclusions, or decision criteria for choosing 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?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds a small amount of scoping context ('associated with your account') but does not disclose pagination behavior, response format, or other operational details beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded, with the core action in the first sentence. The second sentence adds minor redundant context about using the endpoint, but overall it is concise 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?
For a simple read-only list operation with one optional parameter and annotations covering safety, the description is adequate. It does not explain what the response looks like or how pagination behaves, but the missing details are minor 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?
The schema documents the only parameter, 'page', with the description 'Page number', giving 100% coverage. The description does not add any meaning beyond the schema, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb and resource: 'Retrieve public keys associated with your account.' It is distinct enough from create/delete/attach public key siblings, though it does not explicitly distinguish itself from VPS_getAttachedPublicKeysV1.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps 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 says 'Use this endpoint to view available SSH keys,' which gives basic context, but it provides no guidance on when to prefer this over VPS_getAttachedPublicKeysV1 or how it differs from the other public key operations. 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?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the tool's safety profile is covered. The description adds that the operation retrieves all VMs, but does not explain response format, pagination, or what 'available' means. It does not contradict the annotations.
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 first sentence is clear and front-loaded, but the second sentence ('Use this endpoint to view available VPS instances') is redundant repetition of the first. Two sentences could be collapsed into one without loss.
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 parameterless list, the basic action and resource are covered, and the read-only annotations cover the behavioral profile. However, with no output schema, the description leaves ambiguous what fields each VM entry contains and whether 'available' means all VMs or only those in a certain state.
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, so there is nothing for the description to add; the schema is trivially complete. The description correctly makes no parameter claims.
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 ('Retrieve') and resource ('virtual machines'/'VPS instances') and specifies scope ('all available'). It distinguishes from sibling VPS_getVirtualMachineDetailsV1 by emphasizing the list/plural nature, though it doesn't explicitly name 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 instead of alternatives like VPS_getVirtualMachineDetailsV1. The sentence 'Use this endpoint to view available VPS instances' merely restates the purpose and offers no exclusions or selection criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false and destructiveHint=false, so the agent knows this is a non-destructive write operation. The description adds minimal behavioral context by explaining it sets up redirects, but it does not disclose side effects like whether existing forwardings are overwritten, or any permission requirements. It neither contradicts nor significantly enriches the 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 extremely concise, consisting of two short sentences. The first sentence states the primary action, and the second clarifies the purpose, with no redundant information. It is efficiently 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 tool is simple (3 required params, no output schema), but the description lacks important context such as whether the domain must be owned/verified, what happens if the domain already has a forwarding, or what the response will be. It does not reference the existence of related endpoints like update or delete. Given its simplicity, a minimal description is acceptable, but there is room for more practical guidance.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully documents all three parameters (domain, redirect_url, redirect_type) with descriptions, and the schema description coverage is 100%. The description does not add any additional meaning about parameter values or formats, such as explaining the difference between 301 and 302 redirects, which is left to the enum. 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 ('Create domain forwarding configuration') and the resource, and clarifies it's about setting up domain redirects. It distinguishes from get/update/delete by virtue of the verb 'create', though it doesn't explicitly differentiate from the update variant. It is specific enough for an agent to understand the tool's core function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide any guidance on when to use this tool versus alternatives like domains_updateDomainForwardingV1 or websites redirect tools. It merely restates that it is for setting up redirects, which is the purpose, not usage context. No mention of prerequisites, conflicts, or when the update endpoint should be used instead.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=false and destructiveHint=false, so the agent knows it is a mutation. The description adds that it creates a redirect, but no side effects, overwrite behavior, or error conditions are disclosed. It does not contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single, efficient sentence with the verb first. No fluff, but could briefly mention the website selection requirement.
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, key context is missing: idempotency, duplicate handling, whether the website must exist, or what the response contains. No output schema and no extra context. Leaves the agent to guess failure cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need 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 slight clarity by explaining 'from' as source and 'to' as destination, but it does not elaborate on 'username' or 'domain' semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (creates) and resource (redirect) and specifies the source and destination. It distinguishes from list and delete siblings by implying a create operation, but does not explicitly name the sibling alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied by the verb 'creates' and the tool name, but there is no explicit guidance on when to use this vs. the list/delete redirect tools. 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.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description warns that success 'overwrites the website's existing contents and cannot be undone', which is a destructive behavior. However, the annotations declare destructiveHint=false, directly contradicting this warning. This is a serious inconsistency that undermines an agent's ability to gauge the tool's safety.
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 organized into short, purposeful paragraphs: an overview, a critical warning, source requirements, and follow-up workflow. It is longer than strictly necessary, but every section adds operational value and the key destructive warning is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For an 11-parameter, 9-required tool with no output schema, the description covers the critical preconditions, the destructive consequence, and how to follow up using the returned build UUID. It does not describe the full response shape, but the mention of the UUID and log endpoint gives enough guidance for an agent to proceed.
Complex tools with many parameters or behaviors need more documentation. Simple tools 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 schema already documents parameters like source_type, source_options, and node_version. The description adds a bit of context by clarifying that source_type must be 'archive' and that archive_path must point to an existing archive file relative to the document root, but this largely overlaps with schema wording.
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 that this tool starts a Node.js build using files already on the website's file storage, which identifies the action and resource precisely. It names related endpoints like 'Generate Upload URL', 'Get Node.js Build Settings from Archive', and 'Get Node.js Build Logs', helping an agent understand where this tool fits, though it does not explicitly differentiate it from sibling build/deploy 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 workflow context: upload the archive first via 'Generate Upload URL', optionally detect settings via 'Get Node.js Build Settings from Archive', and use the returned build UUID with 'Get Node.js Build Logs' to poll progress. It lacks explicit 'when not to use' guidance or comparisons to alternatives, but the sequential context is strong enough for correct usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish the safety profile: readOnlyHint=false and destructiveHint=false, so the agent knows this is a non-destructive mutation. The description adds the useful fact that the domain is sourced from the order while the local part is supplied, but it does not disclose failure behavior (e.g., duplicate local_part), idempotency, or response contents. Adds modest context above the annotations but not rich behavioral detail.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two compact sentences with zero filler: the first names the action and scope, the second explains the address derivation rule. The most important verb-resource information is front-loaded and every clause 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 3-parameter operation with 100% schema coverage and no nested objects, the description is adequate for invoking the tool. The main gap is that there is no output schema and the description gives no indication of the response shape or success/failure signals, and duplicate-handling behavior is unmentioned; these are moderate gaps but do not make the tool uncallable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need 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 each parameter already carries a detailed description, including the password complexity rule and the local_part format constraints. The description only restates the domain-from-order relationship already present in the local_part schema description, so it adds essentially nothing beyond the schema 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?
States a specific verb-resource pair ('Create a mailbox') and grounds it in the mail-order context, with the second sentence clarifying that the full address is composed from the local part plus the order's domain. It does not explicitly differentiate itself from sibling creation tools like mail_createAliasV1 or mail_createForwarderV1, but the mailbox concept is delineated clearly enough to be recognizable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps 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. The description is purely mechanical and never mentions that aliases, forwarders, or catch-alls exist as lighter-weight alternatives for address routing without full mailbox storage, so an agent choosing among the many mail_* creation siblings gets no decision support.
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 adds valuable behavioral context beyond the readOnlyHint=false and destructiveHint=false annotations: if double opt-in is enabled, the contact is created with pending status and a confirmation email is sent. It does not cover duplicate handling or profileUuid requirements, but the disclosed behavior is meaningful 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loads the core purpose. The second sentence is slightly redundant with the first, but it adds concrete field examples and the double opt-in note is relevant. Overall, it is concise with 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?
With no output schema, the description does not explain what is returned on success or failure. It also does not clarify how this relates to reach_createANewContactV1 or bulk creation, and it omits important operational context such as duplicate emails, required profile semantics, and tag handling. The description is not complete enough for polished agent invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description mentions name, email, and surname as basic info, but does not clarify the meaning of the required profileUuid, the behavior of optional fields like note or phone, or how tag_uuids interacts with contact creation. The schema descriptions are largely tautological, so no additional semantic value is provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Create a new contact in the email marketing system.' This is a specific verb and resource. However, it does not distinguish this tool from the sibling reach_createANewContactV1 or the bulk variant reach_createContactsInBulkV1, both of which appear nearby.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus the similar sibling tools. The description only restates what the endpoint does, with no exclusions, prerequisites, or alternatives, so an agent cannot decide between this and related contact-creation 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?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds scoping and filtering context but does not disclose additional behavioral details such as pagination limits, response format, authentication needs, 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short, but the second sentence largely restates the first: both mention fetching contacts, a specific segment, and profile scoping. The added 'identified by its UUID' detail is minor, so the description could be reduced to one efficient sentence.
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 required inputs and read-only nature are clear, and pagination parameters are present in the schema. However, with no output schema, the description does not explain the return shape or pagination behavior, and it does not differentiate this tool from closely named sibling list tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with each parameter having a basic description. The tool description reinforces that segmentUuid identifies the segment and profileUuid scopes the request, but this is only marginally more informative than the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb and resource: 'Retrieve contacts associated with a specific segment for a given profile.' It identifies the profile and segment scoping, which distinguishes it from more general list tools, though it does not explicitly name or contrast 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives context by explaining that contacts belong to a segment identified by UUID and are scoped to a profile, implying when this tool is appropriate. However, it does not explicitly say when to use this instead of closely related siblings like reach_listSegmentContactsV1 or reach_listProfileContactsV1.
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?
Annotations indicate this is not read-only and not destructive, and the description's 'remove firewall protection' clarifies the practical effect. It does not add deeper behavioral context such as whether the operation is reversible, whether the firewall object remains available, or what response the agent should expect.
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 short and front-loaded with the main action. However, the second sentence largely restates the first, making it somewhat redundant without adding new decision-relevant 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 two-parameter mutation with no output schema, the description is minimally adequate. Missing context includes the security implications of removing firewall protection, how this differs from deleting a firewall, and whether any confirmation or follow-up action 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 input schema already covers both parameters with clear descriptions: 'Firewall ID' and 'Virtual Machine ID.' The description adds no additional parameter-level meaning, which is acceptable because schema coverage is 100%.
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 identifies the action ('Deactivate'), the resource ('a firewall'), and the target ('a specified virtual machine'). It also clarifies the effective outcome as 'remove firewall protection from VPS instances.' It does not explicitly name sibling alternatives, but the wording distinguishes it from activate, delete, and sync 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 phrase 'Use this endpoint to remove firewall protection' provides a basic use case and implies when to call it. However, it does not explicitly contrast with closely related siblings like VPS_activateFirewallV1 or VPS_deleteFirewallV1, nor does it mention 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, covering the safety profile. The description adds little beyond restating the purpose ('detailed information' and 'specific template specifications') and does not disclose response contents, error behavior, or any other operational details. With no output schema, this omission weakens transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences, front-loaded with the purpose and usage context. Every phrase 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.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with one required integer parameter and annotations covering safety, the description is adequate. However, it lacks details about what 'detailed information' includes (fields, structure) or any prerequisites, which is noticeable since no output schema exists. It is functional but not rich.
Complex tools with many parameters or behaviors need more documentation. Simple tools need 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% as templateId has a description. The tool description adds no additional meaning about the parameter, such as where to obtain it or its format, relying entirely on the schema. This is acceptable given full coverage, but no extra value is contributed.
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 detailed information about a specific OS template for virtual machines, using the verb 'Retrieve' and specifying the resource. It distinguishes from the likely sibling VPS_getTemplatesV1 by emphasizing 'specific' versus a list, though it does not explicitly name the alternative.
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 usage context: 'Use this endpoint to view specific template specifications before deployment.' This indicates when to use it, but it does not mention alternatives (e.g., VPS_getTemplatesV1 for listing) or scenarios where this tool should not be used, 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?
Annotations already convey that the operation is mutating (readOnlyHint=false) and non-destructive (destructiveHint=false). The description adds a useful edge case: 'If the virtual machine was stopped, it will be started.' It does not explain timing, service interruption, or error behavior, but the main behavioral nuance is disclosed.
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?
Three sentences, but the last one ('Use this endpoint to reboot VPS instances.') is largely redundant with the first sentence and the tool name. The first two sentences are informative and front-loaded; trimming the final sentence would improve structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-parameter restart endpoint with annotations covering mutation and non-destruction, the description covers the core action and the stopped-VM behavior. It omits asynchronous behavior and error details, but given the low complexity and no output schema, this is minimally 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% coverage with virtualMachineId described as 'Virtual Machine ID.' The description refers only to 'specified virtual machine' and adds no extra meaning about how to obtain or format the ID. The baseline score of 3 applies because the schema already documents the single parameter fully.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Restart a specified virtual machine') and defines the operation as 'fully stopping and starting' it. This distinguishes it from sibling tools VPS_startVirtualMachineV1 and VPS_stopVirtualMachineV1 by making it explicit that a restart is a full stop/start cycle.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Offers no decision guidance about when to use this tool versus the sibling start/stop tools. The sentence 'Use this endpoint to reboot VPS instances' restates the purpose rather than describing conditions, prerequisites, or alternatives. An agent gets no help choosing between restart, start, or stop.
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 aligns with the annotations: it is a mutating operation (readOnlyHint=false) but not destructive (destructiveHint=false). It adds useful context that the VM must be newly purchased and in 'initial' state, but it does not disclose whether the operation is asynchronous, what side effects it has, or what response the caller should expect.
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 short and front-loaded with the key lifecycle qualifier ('newly purchased', 'initial' state). The second sentence is slightly redundant—'use this endpoint' repeats the first sentence—but it is still concise and scannable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This tool has 11 parameters, nested input, and no output schema, yet the description gives no information about return values, async behavior, polling needs, or prerequisites beyond 'newly purchased' and 'initial' state. The annotations do not fill these gaps, so an agent would still be unsure what to expect after calling 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?
With 100% schema description coverage, the schema already documents each parameter's basic meaning. The description adds no parameter-level guidance about relationships or constraints (e.g., password vs. public_key, or required template/data_center combination), so it stays at the 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 identifies the operation as setting up/initializing a newly purchased VPS instance, which is distinct from purchasing or starting a VM. It is specific about the resource and action, but it does not explicitly name or contrast a sibling tool such as VPS_purchaseNewVirtualMachineV1.
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 explicitly says to use this endpoint to configure and initialize purchased VPS instances, which gives clear context. However, it does not state when not to use it, what conditions must be met (beyond 'initial' state), or how it differs from related VPS lifecycle tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses a significant side effect: 'Website contents are overwritten by the build result.' This directly contradicts annotations where destructiveHint is false. Because the description conflicts with the structured metadata, behavioral transparency is severely undermined.
Agents need to know what a tool does to the world before 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 paragraphs deliver purpose, prerequisite, and consequence without wasted words. The most important caveat—overwriting website contents—is included prominently.
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 two-parameter tool with full schema coverage, the description covers the workflow, destination, and destructive effect. The lack of an output schema is acceptable here, though details like build status or failure behavior are not disclosed. The main completeness issue is the annotation contradiction already flagged.
Complex tools with many parameters or behaviors need more documentation. Simple tools need 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 both parameters. The description adds some operational context ('relative path from document root,' 'public_html,' 'file browser first'), but this largely restates what the schema conveys about paths and does not add meaning for website_uid.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Builds and deploys a Node.js application') and a clear resource ('Agency Plan website') from an already-uploaded archive. This distinguishes it from generic hosting deploy tools, though it does not explicitly name sibling 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?
The description clearly frames when to use the tool: after uploading the archive to the file browser, with the relative path provided. It gives a concrete prerequisite and deployment target, but does not explicitly contrast with related deploy tools like deployNodeStaticWebsite or deployJsApplication.
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 destructive behavior by explaining that overwrite=true replaces existing records, which complements the destructiveHint=true annotation. It also notes the merge behavior when overwrite is not set. This adds specific mechanistic detail beyond what readOnlyHint/idempotentHint/destructiveHint convey.
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 core behavior explanation is concise and front-loaded, but the first sentence duplicates the title and the final 'Use this endpoint...' sentence adds no new information. The middle two sentences carry the actual content, so the description could be trimmed without loss.
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 mutation tool with rich annotations and a fully described schema, the description provides the key behavioral distinction (overwrite vs merge). It doesn't cover usage alternatives or return values, but no output schema exists to require the latter; given annotations, this is a reasonably complete description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All parameters are fully described in the input schema (100% coverage), so the description needs to add little. It does reiterate the meaning of overwrite, but the schema already contains the same semantics, so the added value is marginal.
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?
States a clear action ('Update') and resource ('DNS records for the selected domain'), making it distinct from siblings like DNS_getDNSRecordsV1 and DNS_deleteDNSRecordsV1 by verb alone. It doesn't explicitly call out the distinction from DNS_resetDNSRecordsV1, but the update intent is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not discuss when to use this endpoint versus alternatives such as DNS_resetDNSRecordsV1 or DNS_deleteDNSRecordsV1. The only usage-like sentence, 'Use this endpoint to modify domain DNS configuration,' restates purpose rather than giving selection criteria 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?
Annotations already declare readOnlyHint=true and destructiveHint=false, covering the safety profile. The description adds minimal behavioral context—it mentions the purpose but does not disclose filtering behavior, pagination, or output format. Since annotations handle the read-only nature, the description's added value is limited, but it does not contradict annotations. A score of 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 extremely concise—two short sentences that state the purpose and a usage note. It is front-loaded with the key action ('Retrieve WHOIS contact profiles') and contains no unnecessary words. Every word earns its place, and it is well-structured for quick reading.
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 filter, no output schema, no nested objects), the description is sufficiently complete. It explains the purpose and the domain context. It does not mention what happens when 'tld' is omitted (likely returns all profiles), but that is inferable from the schema. The absence of an output schema means the return format is not described, but for a list operation, this is acceptable. Overall, it covers the essential information for an agent to call 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 100% coverage of the single 'tld' parameter with a clear description ('Filter by TLD (without leading dot)'). The tool description does not add any extra meaning to the parameter—it only restates the overall purpose. With high schema coverage, the baseline is 3, and the description adds no additional value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Retrieve WHOIS contact profiles' which is a clear verb+resource. It adds context with 'Use this endpoint to view available contact profiles for domain registration', clarifying the intent. However, it does not explicitly differentiate from the sibling 'domains_getWHOISProfileV1' which fetches a single profile, leaving some ambiguity about the list vs. single distinction beyond the tool name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives a general usage context ('for domain registration') but provides no explicit guidance on when to choose this over alternatives. There is no mention of the sibling 'domains_getWHOISProfileV1' for retrieving a single profile, nor any exclusions or prerequisites. The guidance is implied at best and does not help an agent decide between closely related domain 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?
Annotations show readOnlyHint=false and destructiveHint=false, so a write operation is expected. The description adds that it 'returns the created discount,' which is useful return-behavior context. However, it does not disclose side-effect-relevant details such as code uniqueness requirements, store existence prerequisites, or whether an existing discount with the same code is rejected. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three short sentences, front-loaded with the core purpose and followed by the most nuanced parameter behavior and then the return value. It contains no filler, though the middle sentence repeats information already present in the schema.
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 11 parameters, no output schema, and minimal annotations, the description plus schema is mostly sufficient. It covers the trickiest value-format semantics and the return value. It omits practical context like code uniqueness, required store existence, or how optional time-related fields behave, leaving the agent to infer some operational constraints.
Complex tools with many parameters or behaviors need more documentation. Simple tools need 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 documents all 11 parameters. The description's explanation of fixed versus percentage versus free-shipping value semantics largely duplicates the schema's own value parameter description, adding no new parameter-level meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action and resource: 'Create a discount for a store.' This clearly identifies what the tool does. It does not explicitly differentiate from sibling tools like ecommerce_listDiscountsV1, but the create/list distinction is obvious from the verb, and no competing create-discount sibling exists.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The intended use is implied by the action and store scope, but there is no explicit when-to-use or when-not-to-use guidance, nor any mention of alternatives. For an agent choosing among many ecommerce tools, the description could more directly state when this tool should be selected over list-only or other create 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?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds the account-scoping context but does not disclose pagination behavior, return format, or any rate-limit considerations, leaving the agent to infer these details from the optional 'page' parameter.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. Every word earns its place, stating the verb, resource, and scope efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only list operation with one optional parameter and no output schema, the description is largely sufficient. It clearly identifies the resource and scope, and the annotations cover the read-only nature, though a brief mention of pagination would make it fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%: the only parameter, 'page', is described as 'Page number' in the schema. The description does not add further 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 uses a specific verb ('Retrieve') and a clear resource ('stores associated with your account'), making the purpose easy to identify. It is distinguishable from ecommerce siblings like ecommerce_getStoreMetadataV1 by focusing on the collection of stores, though it does not explicitly contrast itself with those alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no explicit guidance on when to use this tool versus sibling tools such as ecommerce_getStoreMetadataV1 or ecommerce_listProductsV1. The context 'associated with your account' implies a scoped list operation, but no alternatives or exclusions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=false and destructiveHint=false, so it's neither read-only nor destructive. The description adds that this is a create operation, which aligns with the annotations. It does not disclose what happens to the existing website, whether subdomain creation may overwrite existing configurations, or any prerequisites like domain verification. However, given annotations already signal a safe-ish mutation, the description being brief but accurate is adequate; no contradiction.
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 short (two sentences) and front-loads the core action. It avoids repeating the title verbatim and adds one useful detail about optional parameters. It could be more structured (e.g., listing parameter choices), but it earns its place and has 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?
For a create tool with 5 parameters (3 required, 2 optional) and no output schema, the description covers the main purpose and optional choices. It doesn't mention what the response will contain (e.g., new subdomain details) or any side effects (e.g., propagation delays). It also doesn't clarify the precedence or mutual exclusivity of directory vs is_using_public_directory, which is a practical gap for correct invocation. 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 description coverage is 100%, so the baseline is 3. The description adds meaning to two parameters (directory: 'custom directory ... relative to website root'; is_using_public_directory: 'use the website public directory as the subdomain root') by explaining their purpose in subdomain root selection. However, it does not clarify the relationship between directory and is_using_public_directory (e.g., are they mutually exclusive? What happens if both are set? Which takes precedence?). The schema descriptions are fairly self-explanatory, so the description's extra value is marginal.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the specific action ('Create a new subdomain') and the resource ('selected website'), with a clear verb and object. It distinguishes itself from related subdomain tools like hosting_listWebsiteSubdomainsV1 (listing) and hosting_deleteWebsiteSubdomainV1 (deletion), and from hosted-domain tools like hosting_createWebsiteParkedDomainV1. However, it doesn't explicitly name those siblings, so differentiation is clear from context but not 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 this tool: when you need to create a subdomain for an existing website, and mentions optional customization (directory or public directory). It does not provide explicit exclusions or alternatives, such as using hosting_generateAFreeSubdomainV1 for a free subdomain instead. The context signals from sibling names and the description's scope give some guidance, but there is no explicit 'use X instead' 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?
Annotations already flag the operation as non-readOnly and destructive, so the description only needs to add context. It provides some useful context about the source directory and optional post-deployment activation, but doesn't disclose what deployment changes on disk, whether it overwrites an existing theme, or other side effects. This is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences, front-loads the main action, and contains no filler. Every phrase contributes to understanding the action, and the structure is clear and scannable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive deployment action, the description lacks workflow context—it doesn't mention that the theme must have been uploaded first (e.g., via an upload URL), what happens to the existing theme, or what a successful response looks like. The sibling set includes several theme-related tools, but the description doesn't help the agent choose or sequence them, and there is no output schema to fill the gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description's references to an uploaded directory and optional activation mirror the schema descriptions for theme_path and is_activated without adding new detail, so there is no uplift.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear action ('Deploy a WordPress theme') and a specific source condition ('from an already uploaded directory'), which helps distinguish it from theme installation or activation tools. It doesn't explicitly contrast with sibling tools like hosting_deployWordPressPlugin or hosting_activateWordPressThemeV1, so it stops short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage 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 themes already present in the website's directory and mentions the optional activation flag, but it doesn't state when to prefer this over install/activate variants or mention prerequisites like uploading the theme first. There is no explicit when-to-use or 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?
The description discloses a meaningful behavioral trait beyond the annotations: when double opt-in is enabled, the contact is created with pending status and a confirmation email is sent. This is useful and not available from the readOnlyHint/destructiveHint annotations. It does not cover response shape or duplicate handling, but the disclosed behavior adds real value.
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 short and front-loaded with the core purpose. However, the second sentence restates the first ('Create a new contact' vs. 'This endpoint allows you to create a new contact'), which is mild redundancy. Overall it is still appropriately sized and 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?
For a create operation with no output schema, the description omits what the endpoint returns or how success is indicated. It also does not address duplicate emails or other edge cases, and it does not help distinguish this tool from bulk/similar create siblings. The double opt-in behavior is helpful, but the description is not fully complete for an agent choosing and 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 description coverage is 100%, so the baseline is 3 even though the description does little parameter-level explanation. The description only mentions name, email, and surname as examples, and many schema descriptions are tautological ('name parameter'). The schema itself does provide meaningful info for phone format and tag_uuids, so the description does not need to compensate heavily.
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 and resource: 'Create a new contact in the email marketing system.' It also gives a sense of scope with 'basic information like name, email, and surname.' However, it does not distinguish this singular create tool from the similarly named siblings reach_createNewContactsV1 and reach_createContactsInBulkV1.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps 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 about when to use this tool versus alternatives. The double opt-in note is behavioral context, not usage direction, and no exclusions or alternative tool names are mentioned. An agent must infer from the tool name that this is for a single contact creation rather than bulk creation.
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?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is clear. The description adds that it returns a list of all contact groups, but it does not disclose additional behavioral details such as pagination, rate limits, or response shape. This is acceptable for a simple read-only tool but adds little beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded with the core action. The second sentence partially repeats 'returns a list' but adds useful context about contact groups being for organizing contacts, so it is not wasted. Overall it is concise 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?
With no parameters, a read-only annotation, and a simple listing purpose, the description is largely complete for invoking the tool correctly. Minor gaps like pagination or output format are not addressed, but the low complexity and zero-parameter surface make this a minor issue.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and 100% schema description coverage, so there is nothing for the description to explain at the parameter level. Per the baseline for zero-parameter tools, a score of 4 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 operation and resource: 'Get a list of all contact groups.' It is distinguishable from sibling reach_* list tools by naming the specific resource type, though it does not explicitly contrast itself with reach_listContactsV1, reach_listSegmentsV1, or reach_listContactFieldsV1.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance about when to use this tool versus alternatives. The sibling list includes several similar reach_* list tools, and the description does not explain why an agent should choose contact groups over contacts, segments, or fields. The phrase 'can be used to organize contacts' is only domain context, not a usage guideline.
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?
Annotations already mark the operation as read-only and non-destructive. The description adds the status scope ('pending and completed') and signals a collection result, but discloses nothing further such as pagination, ordering, or what a verification record contains. This is adequate but minimal given annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, efficient sentence that front-loads the action and object. There is no filler or redundant restatement of the title.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter read-only list, the description covers the essential task, and annotations cover safety. However, with no output schema and a related sibling (domains_getPendingIRTPVerificationV1), it would benefit from clarifying what counts as a domain verification and when to use the DIRECT variant.
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, so there are no parameter semantics to explain; baseline for zero-parameter tools is 4. The description nonetheless adds relevant output scope by naming the statuses returned.
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 action ('Retrieve a list') and names the exact resource ('domain verifications') with status scope 'pending and completed.' It is clear at face value but does not explicitly differentiate this from sibling tools like domains_getPendingIRTPVerificationV1, so it stops short of full sibling distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No sentence explains when to call this tool instead of the other verification/domain tools. The phrase 'pending and completed' implies broad status coverage, but there is no explicit when/when-not guidance or mention of alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true and idempotentHint=true, so the safety profile is covered. The description adds that the target is a specific existing script, but it does not disclose what happens to the script content, whether changes affect running VPS instances, or how destructive the update is beyond the annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short, front-loaded, and contains no filler. The first sentence names the operation and resource, and the second usefully clarifies that it modifies existing scripts. There is slight redundancy between 'post-install script' and 'automation scripts', but it remains 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?
For a three-parameter update tool with full parameter documentation and annotations indicating destructive and idempotent behavior, the core calling information is present. However, there is no output schema and the description does not explain the effect of an update or whether existing installations are affected, leaving some contextual gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and all three parameters are documented. The description adds no parameter-level details beyond what the schema already provides, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb ('Update') and resource ('post-install script') and adds that it applies to existing automation scripts. This distinguishes it from create/get/delete sibling tools, though it never names those alternatives 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 phrase 'modify existing automation scripts' implies the tool is for updating scripts that already exist, which hints at when to use it versus creating a new script. However, there is no explicit when-not-to-use guidance or mention of alternative tools such as VPS_createPostInstallScriptV1 or VPS_deletePostInstallScriptV1.
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?
Annotations already declare readOnlyHint=false and destructiveHint=false, so the description is not burdened with the full safety profile. It adds modest behavioral context by noting the effect applies to future orders, but it does not disclose side effects such as overriding the current default or any required authentication.
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 only two sentences, with the core action front-loaded. The second sentence adds useful scope ('primary payment method for future orders') without significant 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, non-destructive configuration endpoint with no output schema, the description is largely sufficient: it identifies what the call does and the effect. It could be more complete by explicitly noting that the current default is replaced and that the paymentMethodId must already exist on the account, but these are minor for such 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?
Schema description coverage is 100%, so the integer paymentMethodId parameter is already documented by the schema. The description adds no additional meaning about the parameter beyond 'payment method,' which aligns with the schema's 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 names a specific action and resource: set the default payment method for the account. It makes the scope explicit with 'for your account' and 'for future orders,' though it does not contrast itself with sibling billing tools like billing_getPaymentMethodListV1 or billing_deletePaymentMethodV1.
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?
'Use this endpoint to configure the primary payment method for future orders' gives some context for when the setting applies, but it does not state when to choose this tool over alternatives or mention prerequisites such as a valid, existing payment method. The usage guidance is mostly implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations, the description discloses that the operation is asynchronous and that a successful response only means the activation job has been queued. It does not describe job status tracking afterward, but it adds real behavioral context not available from the schema or 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 three short sentences with the main action front-loaded and every sentence adding a distinct fact: what the tool does, how to identify the WordPress installation, and the async behavior. No filler 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?
For a state-changing async tool with no output schema, it covers the core purpose, the software ID source, and the queued-job caveat. It leaves notable gaps: the meaning of the required username and how to check the eventual result of the activation job.
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?
theme and software have meaningful schema descriptions, but username is described only as 'username parameter' — a tautology. The tool description does not clarify what username is expected, and username is required, so an agent cannot confidently supply this parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Activate an installed theme on a WordPress installation,' naming the verb, resource, and precondition ('installed'). It is clear and specific, though it does not explicitly contrast with sibling theme operations like install/deploy/update/uninstall.
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 about what is being activated and where to find the software ID, but it does not explicitly say when to use this tool versus alternatives or what to check before activation. Usage conditions are implied rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only say readOnlyHint=false and destructiveHint=false. The description adds meaningful behavioral context: it creates three connected artifacts (database, user, password) and automatically prefixes names with the account username when needed. This goes beyond the structured hints, though it omits collision or failure behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences: the first states the core operation and the second adds the key prefixing behavior. No filler or redundant restatement of the tool name.
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 five-param create operation with no output schema and minimal annotations, the description covers the main side effects and the notable prefix behavior. However, it does not describe return behavior, failure conditions, or account prerequisites, and it leaves the schema's tautological 'username parameter' unresolved.
Complex tools with many parameters or behaviors need more documentation. Simple tools need 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 reinforces the auto-prefix rule already present in the schema but does not clarify the weak 'username parameter' schema text or add meaning beyond what the schema fields already state.
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 and object: 'Creates a database with a database user and password for the specified account.' The account-level framing and automatic prefixing behavior help distinguish it from website-level database creation siblings, though it never names an alternative 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?
The description implies account-level usage ('for the specified account') but provides no explicit when-to-use or when-not-to-use guidance, no prerequisites, and no named alternatives. An agent gets little help deciding between this and sibling database-creation 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?
Annotations indicate this is a mutating but non-destructive operation. The description adds that it grants remote access, which is helpful context, but it does not disclose side effects, such as whether existing connections are affected or whether a database user must already exist. No contradiction with 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: one short line states the purpose, and a second line provides the essential constraints for IP and database name. No filler or redundant repetition of the tool name.
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 three-parameter tool the description covers most of what an agent needs, but the required username parameter is not explained anywhere. There is also no mention of prerequisites such as the database user existing or how the connection interacts with existing database settings. This 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 schema already describes 'ip' and 'name' with meaningful detail, and the description reinforces those meanings. However, the required 'username' parameter is effectively unexplained both in the schema ('username parameter') and in the description, leaving an important gap. Since schema coverage is high, the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: allowing a remote host to connect to a specified database. The resource and action are understandable from the name and description, though it does not explicitly differentiate itself from sibling tools like hosting_deleteDatabaseRemoteConnectionV1 or 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives useful context about how to specify the IP and database name, but it does not state when to use this tool versus alternatives, nor when not to use it. The 'list databases endpoint' reference provides a prerequisite, but there are no explicit exclusions or sibling routing.
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?
Annotations already mark this as a mutating but non-destructive operation; the description adds that the parked domain will serve the same content as the parent domain, which is useful context. It does not disclose potential side effects like DNS propagation, duplicate-domain behavior, or verification requirements. The description provides modest added context beyond the annotations but not rich behavioral detail.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two compact sentences with no filler; the main action is front-loaded and the explanatory consequence follows. It could be slightly more detailed, but it is appropriately sized for the tool's simplicity.
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 three-parameter create action with no output schema and no nested objects, the description plus schema gives an agent enough context to attempt the call. The main gap is that 'selected website' is never operationalized — how username and domain identify the site is left implicit — but the behavior itself 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 description coverage is 100%, so the baseline applies; the description's 'same content as the parent domain' reinforces the effect of parked_domain but adds no syntax or format beyond what the schema provides. Notably, 'username' remains only 'username parameter' in both schema and description, so no extra semantic insight is offered for that parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The first sentence uses a specific verb ('Create') and resource ('parked or alias domain for the selected website'), and the second sentence clarifies the functional effect: the parked domain serves the same content as the parent domain. This makes the tool's purpose clear, though it does not explicitly distinguish it from sibling tools like hosting_createWebsiteSubdomainV1.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this tool is for aliasing a domain or IP address to an existing website's content, but it never explicitly states when to use this over creating a subdomain or when it should not be used. There are no stated alternatives or preconditions such as domain ownership or verification. This is an implied usage context, not explicit 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?
Annotations already flag destructiveHint=true, so the safety profile is covered by structured data. The description adds value by stating that the plugin will be activated and made available in the WordPress admin panel. It does not describe overwrite behavior or failure modes, but it does not contradict the annotations.
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 short and front-loaded with the key action, but the second sentence largely repeats the first sentence's meaning. It is not bloated, though it contains some redundancy and filler such as 'This endpoint allows you to'.
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 absence of an output schema and the presence of destructiveHint=true, the description could have provided more context about potential destructive effects or prerequisites beyond the uploaded directory. It covers the main purpose and outcome but leaves some operational details to 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 description coverage is 100%, so all four parameters already have meaningful descriptions in the schema. The description adds only a general notion of an uploaded directory and does not provide additional semantics for plugin_path or slug beyond what the schema already offers.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb ('Deploy'), resource ('WordPress plugin'), and the prerequisite that the plugin must already be uploaded to the website directory. It also clarifies the outcome (activation and availability in admin panel). However, it does not explicitly distinguish this from closely related sibling tools such as hosting_activateWordPressPluginV1 or 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 gives clear contextual guidance: this endpoint is for deploying an already-uploaded plugin directory, implying the upload step must have happened separately. It does not explicitly state when not to use this tool or point to alternatives, but the prerequisite is stated clearly enough to guide selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark this as destructive, and the description adds some context by specifying exactly what is destroyed (LiteSpeed Cache) and at what scope (the specified WordPress installation). It stops short of describing side effects such as cache regeneration impact or whether the purge is irreversible.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences with no filler. The action is front-loaded and the parameter sourcing hint is relevant and compact.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple and mostly adequate for an agent to invoke: the action is clear and the software ID source is provided. However, the required username parameter is semantically unexplained ('username parameter' in the schema), and with no output schema the description does not clarify what the agent should expect in 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%, so the baseline is 3. The description adds meaningful guidance for the software parameter by explaining where to obtain the identifier (the id field from the installations endpoint), but the username parameter remains opaque in both schema and 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 uses a specific verb ('Purge') with a clear resource ('LiteSpeed Cache') and target ('specified WordPress installation'). It is unambiguous, though it does not explicitly contrast itself with sibling tools such as hosting_showLiteSpeedCacheStatusV1 or hosting_clearWebsiteCacheV1.
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?
Use is implied: call this when you need to purge the LiteSpeed cache of a WordPress installation. It also gives a helpful prerequisite by pointing to GET /api/hosting/v1/wordpress/installations for the software ID, but it does not state when to choose this tool over alternative cache-related tools or provide 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?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds minimal behavioral context (debugging purpose) but does not describe pagination behavior, output format, or any rate limits. With annotations present, this meets the baseline but adds little beyond them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence that immediately states the action and purpose. There is no redundant wording or fluff; every part contributes to understanding the tool's function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only log retrieval tool with no output schema, the description covers the core use case adequately. However, it doesn't mention how to obtain the buildUuid (e.g., from a listing tool) or that fromLine is for pagination, which are practical details an agent would benefit from. Given the schema covers parameters and annotations cover safety, this is average 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% — all three parameters (domain, buildUuid, fromLine) have individual descriptions. The tool description does not add any additional parameter context 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 states a specific action ('Retrieve logs') and a specific resource ('specified JavaScript application deployment'), and includes a clear purpose ('for debugging purposes in case of failure'). It distinguishes from similar log tools like hosting_getNodeJSBuildLogsV1 by explicitly targeting JavaScript deployment logs, though it could be even more explicit about the distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool (when debugging a failed JavaScript deployment) but does not explicitly name alternative tools or specify when not to use it. It also doesn't mention that the buildUuid typically comes from a prior listing operation (e.g., hosting_listJsDeployments), leaving that context implicit.
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?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds that it returns 'all profiles available to the client' and 'basic information', which gives some scoping context but doesn't disclose rate limits, pagination, or return format (though no output schema is present).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence with no waste. It front-loads the key action and scope, making it easy to read and understand quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless list tool with no output schema, the description is sufficient. It states what is returned (all profiles with basic info) and the client scope. While it could mention pagination or the exact fields, the low complexity makes this adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and schema description coverage is trivially 100%. With no parameters, the description need not explain any inputs; the baseline of 4 applies per the rubric.
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 ('returns all profiles') and the resource ('profiles'), and adds 'available to the client' to indicate scope. It distinguishes itself from sibling list tools like reach_listContactsV1 by focusing on profiles, but doesn't explicitly name any alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. With many sibling list tools (contacts, segments, tags), the agent might wonder which list to call. No exclusions or contextual hints are provided.
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 materially enriches the generic annotations: it discloses that 'The work is queued, so a success response means it was accepted rather than finished' — asynchronous semantics not captured by any annotation — and precisely scopes the destruction: 'The tag itself and the contacts are not deleted,' which clarifies what destructiveHint=true actually destroys. No contradiction with readOnlyHint=false, idempotentHint=true, or destructiveHint=true.
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?
Four short sentences, purpose front-loaded, with each sentence earning its place: the bulk operation, the two targeting modes, the queued async behavior, and the precise destructive scope. No padding or repetition of the title. The only blemish is that the targeting-mode sentence references phantom parameters, but as a matter of conciseness the size and ordering are strong.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive, queued bulk operation with no output schema, the description covers the essential behavioral context (async acceptance semantics, what is and isn't deleted) — that is the strongest part. But it is incomplete in the dimension that matters most for invocation: the targeting parameters it instructs the agent to pass do not exist in the schema, there is no explanation of how contact_uuids should be obtained or formatted, and the required/optional relationship between contact_uuids and all_contacts is never clarified.
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%, which normally earns a baseline 3, but the two schema parameters (profileUuid, tagUuid) have only tautological descriptions ('Tag uuid parameter', 'Profile uuid parameter'). Worse, the description instructs passing contact_uuids and all_contacts — parameters that are entirely absent from the input schema. An agent reading both would not know whether to send a third parameter, making parameter semantics actively confusing rather than merely thin.
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 first sentence, 'Remove a tag from many contacts at once,' states a specific verb, resource (tag-contact associations), and scope ('many contacts') that distinguishes it from the single-contact sibling reach_removeAContactFromATagV1. Minor deduction: the title frames it as 'Remove contacts from a tag' while the description frames it as 'Remove a tag from many contacts' — functionally the same operation but worded in opposite directions.
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 an explicit operational choice: 'Pass contact_uuids to target specific contacts, or all_contacts to target every contact in the profile.' This is genuine usage guidance. However, it never names sibling alternatives (e.g., using reach_removeAContactFromATagV1 for a single contact), and the two targeting parameters it instructs the agent to pass are absent from the input schema, which makes the guidance potentially misleading rather than purely 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?
Annotations already declare readOnlyHint=false, idempotentHint=true, and destructiveHint=true, which cover the destructive and idempotent nature. The description's 'Delete a snapshot' is consistent with these annotations but adds no additional behavioral context, such as reversibility, permission requirements, or what occurs if the snapshot doesn't exist. With annotations present, the bar is lower, and the description does not contradict them, 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with two short sentences. The first sentence states the core action, and the second rephrases the purpose. While efficient, the second sentence is somewhat redundant ('Use this endpoint to remove VPS snapshots' overlaps with the first). It is front-loaded with the key information and has no unnecessary fluff, earning a 4.
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 well-documented parameter and annotations covering destructive and idempotent behavior, the description is largely sufficient. It doesn't mention error handling or return format, but given the low complexity and that the output schema is absent, the missing details are minor. The existing coverage is adequate for an agent to call the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides 100% coverage for the single required parameter 'virtualMachineId' with description 'Virtual Machine ID.' The tool description merely references 'a specified virtual machine' without adding formatting, constraints, or additional meaning beyond the schema. Thus the description adds minimal value, warranting the baseline 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: 'Delete a snapshot of a specified virtual machine.' It identifies the specific resource (snapshot) and the target (virtual machine), and distinguishes it from sibling operations like create, restore, or get snapshots. The verb and resource are unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes 'Use this endpoint to remove VPS snapshots,' which restates the purpose but does not provide guidance on when to use this tool versus alternatives. No explicit conditions, exclusions, or comparisons with related snapshot operations (create, restore, get) are given. The agent has to infer the use case from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds that results are account-scoped and represent available automation scripts, which is mildly useful but does not disclose pagination behavior, return shape, or any additional 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 and front-loads the primary action and resource. The second sentence is slightly redundant with the first but adds the 'VPS deployment' context, so it earns its place without excessive verbosity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only list operation with one optional pagination parameter and annotations covering safety, the description is mostly sufficient. It mentions account scoping and the domain of the scripts, though it does not explain pagination behavior or return fields, which would be helpful if the response format is non-obvious.
Complex tools with many parameters or behaviors need more documentation. Simple tools need 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 only parameter 'page' is already documented in the schema as 'Page number.' The description adds no extra meaning beyond what the schema provides, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Retrieve') and resource ('post-install scripts associated with your account'), making the basic purpose clear. It does not explicitly differentiate itself from the singular sibling VPS_getPostInstallScriptV1, relying on the plural 'scripts' to signal listing behavior.
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 available automation scripts for VPS deployment,' which gives some usage context. However, it does not state when to prefer this over the singular retrieval tool or mention any exclusions 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?
Annotations already indicate destructiveHint=true, so the destructive nature is captured structurally. The description adds that restoring reverts the VM to a previous state, which implies overwriting current state, but it does not warn about data loss, VM downtime, or irreversibility beyond the annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded with the core action in the first sentence. The later sentences add context but are somewhat repetitive with the opening, so not every sentence fully earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive operation, the description lacks critical operational details: it does not clarify which snapshot is restored when no snapshot identifier parameter is provided, nor does it mention effects on the running VM. The description is not complete enough for an agent to fully understand the consequences of invoking this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the single parameter 'virtualMachineId' is already documented. The description adds no extra meaning about how the target snapshot is selected, which is notable because no snapshot identifier parameter exists.
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: restore a specified virtual machine to a previous state using a snapshot. It distinguishes this from backup-related tools by using 'snapshot' terminology, though it does not explicitly contrast with 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear use cases: system recovery, undoing changes, and testing. It tells the agent when this endpoint is appropriate, though it does not mention exclusions 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?
Annotations already convey readOnlyHint=true and destructiveHint=false, so the safety profile is established. The description adds value by naming the categories of information returned (configuration, status, metadata, hosting plan details, resource quotas), but it does not disclose potential error conditions, authorization needs, or whether the response is paginated or complete.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that conveys the action, the target resource, and the scope of returned data without redundancy. Every phrase contributes useful information, and there is 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?
For a simple read-only tool with one fully documented parameter and no nested objects, the description is largely sufficient: it names the resource type and the categories of details returned. It could be slightly more complete by pointing to the list endpoint for discovering website_uid or by clarifying how this differs from getWebsiteSetupStatusV1, but these gaps are minor given the simplicity of the operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the single required parameter website_uid documented as 'Agency Plan website UID'. The tool description does not add further parameter semantics, such as how to obtain the UID or expected format, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the operation ('Retrieves detailed information') and the specific resource ('a specific Agency Plan website'), and enumerates what is included (configuration, status, metadata, hosting plan details, resource quotas). However, it does not explicitly distinguish itself from sibling tools like agency-hosting_getWebsiteSetupStatusV1 or agency-hosting_listAgencyPlanWebsitesV1.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'a specific Agency Plan website' implies this is for single-website detail lookups rather than listing or status-only checks, but the description does not state when to use it over alternatives, nor does it mention any exclusions or prerequisite steps such as first obtaining the website_uid from a list endpoint.
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?
Annotations already mark this as a non-read-only mutation (readOnlyHint=false), and the description adds the behavioral effect that the domain can serve traffic for the website. However, it does not disclose whether linking overwrites an existing association, whether ownership/DNS verification is required, or what happens after the operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. Every part contributes to understanding the operation's purpose and effect.
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 two-parameter, no-output-schema mutation with clear annotations, the description is nearly complete: it states the resource, the action, and the intended outcome. It omits usage alternatives and potential side effects, but the low complexity makes this 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 description coverage is 100%, so the input schema already documents both parameters (domain and website_uid). The description does not add extra parameter meaning beyond restating that a domain is linked to a website.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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 ('specified Agency Plan website') and explains the intended effect ('so it can serve traffic for that domain'). It is clearly distinct from sibling operations like unlinkDomainFromWebsiteV1 or changeWebsiteDomainV1.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance about when to use this tool versus alternatives such as unlinkDomainFromWebsiteV1, changeWebsiteDomainV1, or DNS/domain-verification tools. The only implied context is that linking is for serving traffic, but there are no explicit conditions, 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?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds that results are paginated and filtered to the authenticated client's accessible Agency Plan websites, but it does not disclose response shape, pagination defaults, or domain item 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?
The description is two sentences long with no filler. The main purpose is front-loaded, and the filter guidance is provided in a separate, clear sentence.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only list tool, the description covers what the tool returns, its scope, and the available filter. There is no output schema, so an explicit mention of the response item structure would improve completeness, but nothing essential to calling the tool is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so page, per_page, and website_uuids are already documented. The description adds the useful intent of website_uuids as a narrowing filter, but does not add detail about pagination semantics or expected value formats 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 returns a paginated list of domains tied to Agency Plan websites accessible to the authenticated client. The verb and resource are specific, and the 'Agency Plan' qualifier helps differentiate it from generic domain list tools, though it does not name a sibling alternative.
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 scope is implicitly clear: use this for domains associated with Agency Plan websites. The description also instructs when to use the website_uuids filter, but it does not explicitly state when to choose this tool over alternatives such as domains_getDomainListV1 or other hosting list tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true, idempotentHint=true, and readOnlyHint=false. The description adds 'unused' and account scope but does not disclose deeper behavioral details such as permanence or side effects, though the destructive hint partially covers risk.
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 short with no filler, but the first sentence largely restates the tool title/name while the second sentence carries the additional guidance. This slight redundancy prevents a higher score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter destructive delete operation, the annotations plus the single well-described parameter provide sufficient safety and input context. The 'unused' use case adds useful guidance, and no output schema is expected.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema fully documents paymentMethodId as 'Payment method ID', giving 100% schema description coverage. The description adds no further meaning about how to obtain or validate the ID, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the explicit verb 'Delete' with the resource 'payment method from your account', making the operation unambiguous. Among the siblings it is the only billing delete-payment-method tool, so it is easily distinguished from get/set payment method 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 second sentence provides a use case: 'remove unused payment methods from user accounts.' However, it does not name alternatives or explicitly state when not to use the tool, such as when the payment method is in use or set as default.
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?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds only a small amount of context by specifying that the profile contains domain registration contact information; it does not disclose response structure, which profiles are retrievable, or any authentication/prerequisite details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences with no filler. The core action is front-loaded, and the clarifying use-case sentence earns its place by explaining what the returned data represents.
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 read-only tool with no output schema, the description is mostly sufficient: it names the resource, explains the data in plain terms, and the required whoisId parameter is straightforward. Slightly more explicit distinction from the profile-list sibling would make it 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%: the sole parameter whoisId is already documented as 'WHOIS ID'. The description does not add any extra meaning about the parameter format, where to find the ID, or how it relates to a profile, so the schema carries the full explanatory burden.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: it retrieves a WHOIS contact profile and clarifies this is domain registration contact information. It is distinguishable from sibling list/update/delete tools at a basic level, though it does not explicitly contrast with domains_getWHOISProfileListV1 or explain that it fetches a single profile by 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 says 'Use this endpoint to view domain registration contact information,' which gives a clear use case. However, it does not mention when not to use it or point to alternatives such as domains_getWHOISProfileListV1 for listing profiles, so the routing guidance is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already communicate destructiveHint=true and idempotentHint=true. The description adds no behavioral context beyond restating that it modifies existing configuration, such as overwrite semantics, prerequisites, validation behavior, or what happens when no forwarding exists.
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 short and front-loaded with the core action. The second sentence adds the 'existing' qualifier but is largely redundant with the first, so it is not maximally tight.
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 three-parameter tool with full schema coverage, the description covers the basic purpose. It lacks useful context about how updating interacts with existing forwarding rules, how it differs from create/delete behavior, or what the result of the update is.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all three parameters are already documented with descriptions and the redirect_type enum is provided. The description adds no parameter-level detail beyond what the schema already supplies, so the 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?
States a specific verb and resource: 'Update domain forwarding configuration' and 'modify existing redirect configuration for domains.' This clearly distinguishes it from sibling tools like domains_createDomainForwardingV1, domains_getDomainForwardingV1, and domains_deleteDomainForwardingV1.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives a direct usage directive: use this endpoint to modify existing redirect configuration. The context of 'existing configuration' is clear, though it does not explicitly name alternatives 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?
Annotations already declare readOnlyHint=false and destructiveHint=false. The description adds useful context by noting the optional customer email and that the updated order summary is returned, but it does not disclose irreversibility, failure conditions, or permission 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?
Two short sentences, front-loaded with the primary action and no filler. Every clause contributes useful information about the operation, side effect, or return 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 low-complexity tool, the description covers the core operation, optional notification, and return value, which is enough to make a basic call correctly. It would be richer with a note about order state constraints, but nothing essential is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully documents all three parameters with 100% coverage, so the description does not need to repeat them. The description adds only that emailing is optional, which is already captured by the notify_customer parameter 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 states the exact operation, 'Cancel the order', and identifies the resource (an order) plus an optional side effect (emailing the customer). It is clearly distinguished from sibling tools like ecommerce_fulfilAnOrderV1, ecommerce_retrieveAnOrderV1, and ecommerce_listStoreOrdersV1.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance is given on when to use this tool, when not to use it, or what alternatives exist. Usage is only implied by the verb 'cancel', with no mention of prerequisites such as order state or restrictions on cancelling fulfilled/already-cancelled orders.
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?
Annotations already cover destructiveHint=true, idempotentHint=true, and readOnlyHint=false, so the safety profile is established. The description adds 'single' to clarify scope but no further behavioral context such as permanence or side effects, which is acceptable given the 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?
A single, short sentence with no unnecessary words. It is front-loaded with the action and object, making it immediately understandable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a straightforward delete operation with three well-documented required IDs and annotations covering idempotency and destructiveness, the description is sufficient. It lacks alternative routing and response information, but these are minor constraints for a simple delete tool without an 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 schema provides 100% coverage with descriptions for store_id, product_id, and variant_id. The description adds no parameter-level meaning beyond what the schema already supplies, matching the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the verb 'Delete' and the resource 'single variant from the product', making it specific and unambiguous. The word 'single' distinguishes it from batch variant operations, and 'variant' differentiates it from product-level deletion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus alternatives such as ecommerce_updateProductVariantsInBatchV1 or ecommerce_deleteAProductV1. There is no mention of exclusions, prerequisites, or when a different tool would be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish readOnlyHint=true and destructiveHint=false, covering the safety profile. The description adds useful behavioral detail about free-text/disabled filtering and the unit semantics for discount amounts, but it does not mention pagination behavior or response shape.
Agents need to know what a tool does to the world before calling it. Descriptions 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 core purpose appears in the first sentence, followed by concise filter and value-semantics details. No filler or redundant restatement of the tool name/schema is present.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only list tool with fully documented parameters and safety annotations, the description covers purpose, filters, and value formats. It omits pagination details despite the page parameter, but overall it is adequately complete for an agent to invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents store_id, q, page, and is_disabled. The description largely restates the filter semantics for q and is_disabled, adding little beyond the schema; the amount-unit note concerns output values rather than 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?
Description opens with 'List a store's discounts,' which identifies a specific verb and resource. It is clear but does not explicitly distinguish itself from sibling list tools like ecommerce_listProductsV1 or ecommerce_listStoreOrdersV1, so it stops short of full differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description conveys that this is the read-only listing operation for discounts and enumerates available filters, implying when it should be used. It does not provide explicit selection criteria, exclusions, or point to create/update alternatives such as ecommerce_createADiscountV1.
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?
Annotations already indicate readOnlyHint=false and destructiveHint=false, so the description is not responsible for basic mutation disclosure. The word 'temporary' adds a small behavioral trait, but there is no detail about link expiration, consequences for existing links, or any required permissions. It does not contradict the 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?
Two sentences with no fluff. The main action is front-loaded, and the supplementary instruction about obtaining the identifier is placed where it is most useful. 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 two-parameter tool with a clear action, the description is mostly sufficient to make a call. However, there is no output schema, and the description does not indicate what the response will contain (i.e., the generated links) or clarify what kind of username is expected. An agent can invoke it but may not know how to interpret the result.
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, but the description adds meaningful provenance for 'software' by explaining it is the WordPress installation identifier and pointing to the exact endpoint and field where it can be found. The 'username' parameter remains weakly described as 'username parameter' even in the schema, but the description does compensate for the key parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Create temporary auto-login links for the specified WordPress installation.' This clearly states what the tool does and on what entity. It does not explicitly differentiate itself from the similar-sounding sibling hosting_getInstallationJWTTokenV1, so it stops short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives useful context by telling the user that the WordPress installation identifier belongs in the path and can be obtained from a specific GET endpoint. However, it does not state when to choose this tool over alternatives or when not to use it; the usage is only implied by the action name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds that results are paginated, which is useful, but it does not disclose default page sizes, ordering, or what fields are returned. No contradiction with 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?
Two sentences deliver the core purpose and the most important filtering use case with no filler. The primary action is front-loaded and each sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only list endpoint with full schema descriptions and annotations, the description is sufficiently complete: it states pagination, account scope, and the key filter combination. The lack of an output schema is mitigated by the straightforward nature of the tool, though return field details would add further 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 description does not need to re-document parameters. It does add a small amount of intent by explaining that domain and is_assigned filters are used to find databases assigned to a specific domain, but this largely mirrors the schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns a paginated list of databases for a specified account, and the title reinforces the account-level scope. It is distinguishable from create/delete database siblings, though it does not explicitly contrast with website-level database listing 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 gives concrete guidance on using the domain and is_assigned filters together to find databases assigned to a domain. However, it does not state when to prefer this tool over alternatives such as agency-hosting_listWebsiteDatabasesV1 or list database tools for other scopes.
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?
Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds that the result is paginated and scoped to the selected website, which is useful, but it does not disclose response shape, default page size, or ordering. No contradiction with 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?
A single front-loaded sentence conveys action, resource, scope, and pagination without filler. 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?
For a simple read-only list tool, the definition plus schema and annotations is nearly complete: parameters are documented, safety is covered, and pagination is mentioned. It only lacks a clearer statement that the domain parameter selects the website and an explicit note about response contents, though no output schema exists.
Complex tools with many parameters or behaviors need more documentation. Simple tools need 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 four parameters. The description adds no parameter-specific meaning beyond the phrase 'selected website,' which weakly implies the required domain 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?
States a specific action ('Returns a paginated list'), specific resource ('redirects'), and scope ('configured for the selected website'). This clearly separates it from the create/delete redirect siblings and from other website-level list tools such as hosting_listWebsiteParkedDomainsV1 and hosting_listWebsiteSubdomainsV1.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps 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 choose this tool over alternatives, when not to use it, or how the 'selected website' is identified. A tool that could be confused with other website-list operations would benefit from an explicit selector such as 'Use this to inspect redirects; use hosting_createWebsiteRedirectV1 to add one.'
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 non-obvious behavior: values above the account plan limit are silently capped, so a successful request may apply a smaller value. It also advises reading the applied value via the Get PHP details endpoint, which compensates for the lack of output schema. This meaningfully extends the annotations without contradicting them.
Agents need to know what a tool does to the world before calling it. Descriptions 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, the second gives the key usage instruction, and the third provides the critical cap warning and follow-up. Every sentence earns its place with no 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?
Despite having no output schema, the description tells the caller exactly how to verify the applied value, addressing the most important ambiguity. It does not document option value types or valid option keys, but the examples and schema coverage are sufficient for typical 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 already documents all three parameters with 100% coverage. The description adds useful examples of PHP option names and reinforces the partial-update behavior, but it does not define the value types or valid option keys inside the nested options object, leaving some ambiguity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description states a specific verb and resource: 'Updates PHP options for the website' with concrete examples like `memory_limit`, `max_execution_time`, and `upload_max_filesize`. It also clarifies a partial-update semantic ('Only provide the options you want to change'), but it does not explicitly distinguish itself from similarly named siblings such as agency-hosting_replaceWebsitePHPOptionsV1.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps 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 instead of alternative PHP-related tools like hosting_updatePHPExtensionsV1, hosting_updatePHPVersionV1, or agency-hosting_replaceWebsitePHPOptionsV1. The only usage context is about which options to include and a recommendation to call the Get PHP details endpoint afterwards.
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?
Annotations already signal mutation and destructiveness, so the description does not need to restate that. It adds a useful prerequisite by pointing the agent to Get PHP details for available versions, but it does not clarify other behavioral aspects such as side effects on the running site or expected confirmation.
Agents need to know what a tool does to the world before calling it. Descriptions 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 with no filler. The main action is front-loaded and the prerequisite instruction is separated cleanly.
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 three-parameter mutation with no output schema, the description gives the action and the key prerequisite (check available versions). It is nearly complete, though it would be stronger if it mentioned the difference from agency-hosting_updateWebsitePHPVersionV1 or the destructive consequence of switching versions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need 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 carries the parameter documentation. The description adds no new detail about username, domain, or version; it only reiterates the overall action at the parameter level, which is adequate but not additive.
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 and resource: 'Changes the PHP version of the website.' It clearly identifies the tool's core operation, though it does not differentiate it from the sibling agency-hosting_updateWebsitePHPVersionV1 or from related PHP 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides one explicit usage instruction: call the Get PHP details endpoint to discover available versions before switching. However, it does not discuss when to prefer this tool over related PHP tools (options, extensions, agency variant) or state any 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?
Annotations only indicate readOnlyHint=false and destructiveHint=false, so the description carries the behavioral burden. It adds the key constraint that a mailbox can have only one autoreply and clarifies activation/indefinite behavior, but it does not disclose what happens if an autoreply already exists, whether the call fails, or what the response contains.
Agents need to know what a tool does to the world before calling it. Descriptions 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 filler. The core action is front-loaded, and the uniqueness constraint plus the key parameter behaviors are conveyed efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description plus schema gives enough information for a straightforward create operation: required fields, timing semantics, and the one-autoreply constraint. It is slightly incomplete regarding conflict behavior when an autoreply already exists, but that is a minor gap for this 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?
Schema description coverage is 100%, so the baseline is 3. The description does add meaningful activation semantics for starts_at and ends_at, but those are mostly restatements of the schema's parameter descriptions rather than substantial new information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Create') and resource ('automatic reply for the given mailbox'), making the tool's purpose obvious. It does not explicitly name sibling tools, but the create semantics are distinct from the update/delete/list siblings in the tool list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides useful context such as 'A mailbox can have only one autoreply' and explains how to control activation and end times. However, it does not explicitly say when to use this tool over mail_updateAutoreplyV1, mail_deleteAutoreplyV1, or mail_listAutorepliesV1; the guidance is implied rather than direct.
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?
Annotations already mark this as read-only and non-destructive. The description adds a meaningful behavioral caveat: the webhook secret is never included in the response and is only available at creation or regeneration. This goes beyond the annotations and helps set correct 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?
Two sentences with no waste: the first states the core operation, and the second adds a single high-value caveat about the secret. Everything included 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 one-parameter, read-only tool, the description covers the essential purpose and the most important response behavior. It does not enumerate exact returned fields, but with no output schema and a simple get operation, this is sufficient for an agent to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides full coverage for webhookId, including where it comes from ('returned when the webhook was created'). The description does not add parameter-level meaning, but none is necessary given the 100% schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a precise action ('Retrieve the details') and a specific resource ('a single webhook'), clearly identifying this as a get-detail operation distinct from list, create, update, delete, and regenerate webhook siblings. It does not explicitly name a sibling, but the singular scope is enough for an agent to differentiate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool or when to prefer an alternative such as mail_listWebhooksV1. It simply states what the tool does, leaving the agent to infer that it should only be used with an already-known webhookId.
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?
Annotations already declare readOnlyHint=true and destructiveHint=false, covering the safety profile. The description adds useful context by mentioning pagination, delivery outcome, duration, retry counts, and mailbox filtering. It does not disclose pagination defaults, ordering, or possible response quirks, but for a read-only list with annotations this is acceptable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no filler. It front-loads the action and resource, then immediately provides the key returned fields and the filtering option. 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?
For a low-complexity read-only list endpoint with a fully documented schema, the description is complete enough: it states the resource, scope, key returned fields, pagination, and an optional filter. The only minor gap is that no output schema exists and the exact response envelope isn't described, but the description still gives sufficient detail for an agent to select and call the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all four parameters are already documented. The description only restates the role of orderId and mailbox_id ('given mail order', 'filtering by mailbox') without adding extra format, constraints, or edge-case meaning. Baseline 3 applies because the schema carries the parameter documentation burden.
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 ('Retrieve') and clearly identifies the resource ('webhook delivery logs') and scope ('for the given mail order'). It also lists the fields returned, which goes beyond the title. However, it does not explicitly differentiate this from sibling log-list tools like mail_listOutboundLogsV1 or mail_listInboundLogsV1, so it stops short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The intended use case is implied clearly: call this when you need webhook delivery logs for a mail order, optionally filtered by mailbox. But the description gives no explicit guidance about when not to use it or which sibling log tools to choose instead, so the agent must infer the distinction from the resource name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already signal a non-read-only, idempotent, destructive write, and the description does not contradict them. It adds little beyond that: it does not clarify whether disabling keep-copy deletes existing copies, whether the forwarder must be verified, or what side effects the destructive flag 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?
A single, direct sentence with no filler. The action is front-loaded and the rest of the needed detail is delegated to the schema and annotations.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter operation with no output schema and no nested objects, the description plus the fully documented schema and annotations are sufficient for an agent to invoke it correctly. The only gap is side-effect details around disabling keep-copy, but that is not essential for making the call.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already documents both parameters with 100% coverage: forwarderId is 'Forwarder resource ID' and is_keep_copy_enabled is 'Whether to keep a copy of forwarded messages in the mailbox'. The description restates the boolean's purpose but does not add format, default, or behavioral details.
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 action ('Enable or disable') and names the precise resource ('keeping a copy of forwarded messages in the mailbox'), so an agent can tell this toggles a forwarder's retention setting. It is clear but does not explicitly differentiate from sibling forwarder operations such as mail_createForwarderV1 or mail_deleteForwarderV1, so it stops short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The intended use is implied: call this when you need to change whether a forwarder keeps copies of forwarded messages. However, there is no explicit statement of when not to use it, no mention that the forwarder must already exist, and no reference to alternative forwarder-related 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?
The description adds meaningful behavioral context beyond the annotations: it explains that membership is dynamic and changes as contacts change, and it explicitly promises that creating a segment does not modify any contact. This is useful safety-relevant information for a mutation tool. It does not cover auth, rate limits, or failure modes, but annotations already convey the non-destructive write 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 extremely efficient: an opening statement followed by one densely informative sentence. Every phrase earns its place, with the key side-effect guarantee and dynamic-membership semantics packed into two sentences. There is no fluff, repetition, or irrelevant 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?
For a creation tool with four required parameters and a rich input schema, the description provides enough conceptual grounding to invoke it correctly: it defines what a segment is and clarifies the side-effect boundary. The absence of an output schema means the return value is not described, but the schema and the concise behavioral definition are sufficient for selection and invocation in most agent workflows.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema carries the full parameter documentation burden. The tool description adds no parameter-level meaning beyond the schema, but the schema already provides a rich description for attributes, operators, and logic. This matches the baseline of 3 for fully covered schemas.
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 and resource: 'Create a segment in a profile.' It also adds conceptual precision by explaining that a segment is a saved set of conditions rather than a fixed list. However, it does not differentiate itself from the sibling reach_createANewContactSegmentV1, leaving the distinction between profile segments and contact segments implicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus alternatives such as reach_createANewContactSegmentV1, reach_updateAProfileSegmentV1, or reach_previewContactsMatchingConditionsV1. There is no mention of prerequisites, exclusions, or conditions that would make another tool 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?
The description adds meaningful behavioral context beyond the annotations: the deletion is permanent AND cascades to custom field values and tag assignments. This tells the agent what collateral effects occur. It does not contradict the destructiveHint or idempotentHint 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?
Two concise sentences with no filler. The core destructive action is front-loaded, and the second sentence provides the most valuable additional behavioral detail without becoming 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 simple two-parameter delete operation, the description, schema, and annotations together provide sufficient information: required UUIDs, destructive safety profile, idempotency, and cascade behavior. It only lacks explicit sibling differentiation, but that is not essential to invoking 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?
Schema coverage is 100%, so both parameters are already documented in the input schema. The description reinforces that one parameter identifies a contact and the other a profile, but it adds no deeper semantic detail such as formats, sources, or validation rules.
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: permanently delete a contact from a profile. The phrase 'from a profile' distinguishes this from sibling tools like reach_deleteAContactV1, though it does not explicitly name or contrast the alternative.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus reach_deleteAContactV1 or other contact-related deletion tools. The description implies this is profile-scoped contact deletion, but it never states when this is the right choice or when another sibling would be 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?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the read-only nature is covered. The description adds some context by scoping results to a profile and explaining what tags are used for, but it does not disclose response format, pagination, ordering, or error behavior. With annotations covering the safety profile, this is adequate but not richly transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no wasted text. The first sentence is front-loaded with the exact action and resource, and the second sentence provides useful context about why tags matter. It is appropriately sized for a simple one-parameter read-only 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 read-only list operation with one required parameter and no output schema, the description provides enough information to select and invoke the tool correctly. The profileUuid parameter is clear from the schema, and annotations cover the safety profile. It could be more complete by mentioning the shape of the returned tag list, but that is not necessary for invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the single parameter profileUuid is documented, though minimally as 'Profile uuid parameter.' The description adds a little meaning by saying tags are defined in a profile, which implies profileUuid identifies the profile whose tags should be listed. This meets the baseline for high schema coverage without adding significant new detail about the parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action and resource: 'Get all tags defined in a profile.' It is specific enough to distinguish from tag mutation tools like reach_createOrFindTagsV1 or reach_deleteATagV1, and the second sentence clarifies that tags are profile-level contact groupings. However, it does not explicitly differentiate itself from related list tools such as 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 the tool is useful by explaining that tags group contacts and can be used to filter contact lists or build segments. This gives contextual purpose but does not explicitly state when to choose this tool over alternatives or mention any exclusions. The guidance is mostly conceptual rather than procedural.
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?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the read-only behavioral profile is covered. The description adds useful context about what an action is and example return fields (action name, timestamp, status), but it does not disclose pagination behavior or any other operational caveats beyond the schema's page parameter.
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 the core purpose front-loaded in the first sentence. The second paragraph adds helpful domain context and return-value examples, but some phrasing is mildly redundant (e.g., 'This endpoint allows you to view the history').
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 relatively simple read-only list endpoint with one required parameter, the description covers the purpose, use case, and expected return content. Since there is no output schema, the mention of action name, timestamp, and status is valuable. Pagination semantics for page are not explained explicitly, but the parameter schema covers the basics.
Complex tools with many parameters or behaviors need more documentation. Simple tools need 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 virtualMachineId and page are already documented. The description only implicitly references virtualMachineId as 'a specified virtual machine' and adds no meaning for the page parameter 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 action: 'Retrieve actions performed on a specified virtual machine' and adds that it yields operation history. However, it does not explicitly differentiate this from the sibling VPS_getActionDetailsV1, relying on implication via 'history' rather than naming the alternative.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives a clear usage context: 'Use this endpoint to view VPS operation history and troubleshoot issues.' It does not mention when not to use it or compare it to alternatives such as VPS_getActionDetailsV1, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already signal mutation, idempotency, and destructiveness. The description adds value by warning that improper nameserver configuration can break domain name resolution on the VM, which is a meaningful behavioral risk beyond the structured hints. This is consistent with the destructiveHint flag rather than contradicting it.
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 short and front-loads the core action. The warning sentence earns its place because it conveys important risk. Minor awkward phrasing ('Be aware, that') does not hurt 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 4-parameter mutation tool with no output schema, the description covers the basic purpose and a key risk but omits what response to expect, whether the operation replaces or merges existing nameservers, and how missing optional parameters behave. It is adequate but leaves meaningful gaps for an agent deciding whether to call 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 the schema carries most parameter documentation. The description adds no detail about how ns1, ns2, and ns3 are used, their format, or the fact that only ns1 is required. It does not improve on the schema's weak per-parameter descriptions like 'ns1 parameter'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the operation: setting nameservers for a specified virtual machine. It names the resource (virtual machine/VPS) and the action, which is enough to distinguish it from domain nameserver tools like domains_updateDomainNameserversV1, though it does not explicitly reference a sibling.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states the endpoint configures custom DNS resolvers for VPS instances, giving a clear purpose. However, it lacks explicit guidance on when to use it instead of related DNS or domain nameserver tools, and it does not mention any prerequisites or conditions that would make this tool the correct choice.
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 concrete behavioral effects: 'Virtual machine will boot recovery disk image and original disk image will be mounted in /mnt directory.' This adds value beyond the annotations (readOnlyHint=false, destructiveHint=false) by explaining what actually happens to the VM. It does not contradict the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose and then provides necessary context about recovery mode and the mount behavior. It is somewhat verbose with the use-case enumeration (repairing file systems, recovering data, troubleshooting), but each sentence contributes useful context and the length is appropriate for an operation of this significance.
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 effect (booting recovery disk, mounting /mnt) and the endpoint's purpose. However, it does not mention important operational details such as whether the VM will be rebooted/stopped, potential downtime, how to exit recovery mode (sibling tool exists), or what the response will look like. Given the absence of an output schema, these gaps leave the agent with some uncertainty about the full impact of the call.
Complex tools with many parameters or behaviors need more documentation. Simple tools need 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 'virtualMachineId' and 'root_password' are documented in the input schema. The description adds minimal parameter-specific meaning beyond the schema, only clarifying that recovery mode is a special state. This meets the baseline of 3 for full schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Initiate recovery mode for a specified virtual machine.' It explains the resource (virtual machine) and the action (start recovery mode), and elaborates on the use cases. However, it does not explicitly differentiate from the sibling tool VPS_stopRecoveryModeV1, though the verb 'start' versus 'stop' 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 says 'Use this endpoint to enable system rescue operations on VPS instances,' providing general guidance on when to use it. It does not mention alternatives or exclusions, such as when the VM should be stopped or when recovery mode should not be used, leaving the usage context 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?
Annotations already flag readOnlyHint=false and destructiveHint=false, so the description's job is to add context. It does add the useful behavioral detail that firewalls lose sync when rules are added/removed/updated, and that the endpoint 'applies updated firewall rules.' However, it doesn't disclose whether the sync is synchronous or asynchronous, whether it executes immediately, or what happens to an already-synced firewall; annotations still carry the safety profile.
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 four sentences are compact and helpful, with the most decision-relevant content (deprecation warning) front-loaded. There is minor redundancy between 'Sync a firewall for a specified virtual machine' and 'Use this endpoint to apply updated firewall rules,' but no padding or fluff beyond that. Earns a near-top score rather than a 5 due to that 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?
For a mutating tool with no output schema and no rich annotations, the description gives the essential trigger conditions and deprecation strategy, which is a solid middle effort. However, it never covers expected result shape, whether the operation is asynchronous, or failure modes (e.g., firing VM not found, firewall already in sync), leaving the agent to guess at completion semantics.
Complex tools with many parameters or behaviors need more documentation. Simple tools need 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 `firewallId` and `virtualMachineId` have inline descriptions — so the baseline applies. The description implicitly ties `virtualMachineId` to the single-VM sync scope, but adds no additional format or behavioral detail beyond what the input schema already encodes. Adequate without being additive.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: syncing a firewall for a specified virtual machine. It also adds deprecation context, pointing to the replacement endpoint that syncs to all assigned VMs, which helps distinguish it from `VPS_syncFirewallToAllAssignedVMsV1`. A dedicated sentence could remove the slight ambiguity around per-VM vs all-VM sync, but the intent is clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The deprecation notice gives explicit guidance to use the successor endpoint instead, which is strong when-to-use direction. It also explains the trigger condition (firewall rules added, removed, or updated causing loss of sync) so the agent knows when this operation is appropriate. It stops short of explicitly naming alternatives or stating when to prefer `VPS_syncFirewallToAllAssignedVMsV1`, but the deprecation note largely covers it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=true and idempotentHint=true, but the description does not clarify the critical default behavior when no filters are provided. It says 'To filter which records to delete, add the name and type' but never states what happens if no filter is given—whether all records are deleted or no deletion occurs. This ambiguity is a major transparency gap for a destructive, idempotent 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 reasonably concise with key points front-loaded: the action, the filtering mechanism, and the alternative. It avoids fluff but has some redundancy (e.g., 'Use this endpoint to remove specific DNS records from domains' restates the first line). Overall, it is structurally sound and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the basic usage and provides an alternative for a specific scenario, but it misses essential context for a destructive tool: the default behavior without filters, whether deletion is permanent/reversible, and any confirmation requirements. The absence of an output schema increases the need for these details, making the description incomplete for safe and correct usage.
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 description explicitly mentions 'name' and 'type' filter parameters, but the input schema only defines 'domain'. This creates a mismatch: the agent sees a schema with one parameter yet the description implies additional parameters that are not defined in the schema. Though the description adds semantic meaning, it fails to align with the schema and leaves the agent uncertain about how to supply those filters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid 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 DNS records') and the resource ('for the selected domain'), and distinguishes it from siblings by explaining it deletes specific records based on filters, with an explicit pointer to 'Update zone records' for partial deletions of duplicate records. The purpose is unambiguous and distinct.
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 on when to use this endpoint: to delete specific DNS records via filters, and gives a clear alternative (Update zone records) for a specific case where only some duplicates should be deleted. This directly addresses when-not-to-use and points to an alternative, satisfying the highest bar.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description directly contradicts the annotation 'idempotentHint: true'. The description states that 'already accepted moves cannot be accepted again', implying the operation is not idempotent (repeated calls will fail). The description otherwise provides helpful behavioral detail (doesn't complete move, sends email, status becomes 'activating'), but the contradiction with the annotation is a serious inconsistency.
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 multi-sentence and covers several aspects, but each sentence contributes unique information: prerequisites, contact requirements, post-acceptance behavior, and final use-case. It is reasonably front-loaded with the purpose. However, it could be tightened, and some redundancy exists (e.g., requirements repeated).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with a nested object and 4 required sub-fields, the description explains all parameter requirements, the acceptance state, the email confirmation step, and the resulting status. It even points to the incoming move endpoint for following status. This is nearly complete; only explicit error cases or return format are missing, but there is 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%, so parameters are documented. The description adds meaningful context: the WHOIS profiles become contacts, must belong to the account, abide by TLD requirements, and only the contact types used are applied while all four IDs must still be provided. This clarifies the semantics beyond the raw 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: 'Accept an incoming move for a specified domain.' It specifies the resource (domain move) and the operation (accept), and distinguishes it from the sibling reject tool. The closing sentence clarifies the intended use case. No ambiguity about what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly states a prerequisite: the move must still be waiting for your decision, and already accepted moves cannot be accepted again. It also explains the post-action flow (confirmation email, status activation). It does not explicitly compare with the reject sibling, but the purpose is clear. The guidance is sufficient for correct usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark this as non-read-only and non-destructive, and the description's 'Create' and 'add new' wording aligns without contradiction. It adds minimal behavioral context—contact profiles are used for domain registration—but does not discuss side effects, relationship to domains, or whether the profile is reusable, which is acceptable given the annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences with no unnecessary filler. The first sentence restates the title, but the second adds useful domain-registration context. It is appropriately sized for a straightforward creation endpoint.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has two nested objects with empty property definitions and no output schema, and the description does not specify what whois_details or tld_details should contain. An agent would struggle to construct a valid request body, especially without knowing whether the created profile is automatically tied to a domain or is just a stored reusable profile.
Complex tools with many parameters or behaviors need more documentation. Simple tools need 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 only a general hint that 'contact information' is involved, but does not detail the structure of the nested whois_details or tld_details objects, whose schemas are empty. The description does not need to repeat all parameter names, but it 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 uses the specific verb 'Create' with a clear resource, 'WHOIS contact profile,' and elaborates with 'add new contact information for domain registration.' This clearly distinguishes the operation from sibling WHOIS tools that get, delete, change, or set default profiles.
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 endpoint: 'Use this endpoint to add new contact information for domain registration.' It provides clear context for the creation action, though it does not name alternative tools or explicitly exclude updating or deleting existing profiles.
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?
Annotations already mark this as read-only and non-destructive. The description adds valuable behavioral context: symlinked entries are listed but never traversed or resolved, and directory paths are relative to the document root. This is useful beyond what annotations provide.
Agents need to know what a tool does to the world before calling it. Descriptions 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 purpose, and the second adds essential behavioral and parameter context. There is no filler or redundant restating of 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?
For a read-only listing tool with 7 parameters and no output schema, the description supplies the key operational context: document-root anchoring, subdirectory browsing, and symlink handling. Pagination and return-shape details are not described explicitly, but the parameter schema largely covers the remaining invocation details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description enriches the `directory` parameter by clarifying it is relative to the document root, which is not fully explicit in the schema. Other parameters like offset, max_depth, and file_types are left to the schema, but that is acceptable given full 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 and resource: 'List files and directories under a website's document root.' It defines the scope precisely and distinguishes itself from content-reading tools, though it does not explicitly name any sibling alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives such as hosting_getWebsiteFileContentV1 or other hosting tools. The 'Use directory' sentence explains parameter usage, not tool selection, so the description lacks exclusion or selection 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?
The description adds valuable behavioral context beyond the minimal annotations: it reveals that the slug is derived from the label and cannot be changed later, that the field type is likewise immutable, and that the response includes a uuid to be used for setting contact values. This meaningfully informs the agent about side effects and response content.
Agents need to know what a tool does to the world before 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 compact sentences, with the core purpose stated first, followed by an important constraint and a usage pointer. Every sentence earns its place; there is 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?
For a create operation with four parameters and no output schema, the description covers the essential behavioral facts: it defines a field, notes immutable attributes, and tells the agent how to use the returned uuid. The remaining gaps (such as the meaning of profileUuid or option requirements) are already covered by the schema, so this is sufficiently complete for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds semantic value by explaining that the slug derives from the label and that the field type is immutable, which enriches the otherwise thin schema descriptions ('label parameter'). The options and profileUuid parameters remain adequately covered by the schema, though not further explained.
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 operation: 'Define a new custom contact field in a profile.' This is a specific verb + resource, and the title matches. While it doesn't explicitly name a sibling like reach_updateAContactFieldV1, the create intent is unambiguous and distinct from the surrounding list/update/delete siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool versus alternatives such as update or list. The instruction 'Use the returned uuid to set values on contacts' is post-usage, not tool-selection guidance. No exclusions or alternatives are mentioned, leaving the agent to infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (readOnlyHint false, idempotentHint true, destructiveHint true), the description adds important behavioral details: only properties present in the request are changed, null clears a field, and the response carries only core attributes while other data must be fetched via a GET endpoint. This is consistent with the annotations and provides useful additional 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 compact and well-structured: a one-sentence purpose, followed by two concise paragraphs covering partial-update behavior and response scope. No filler or redundant repetition of schema data. Information is front-loaded with the core purpose first.
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 mutation tool with no output schema, the description covers key operational semantics: partial updates, null clearing, response scope, and how to retrieve full contact data. It does not mention error cases or permissions, but those are not essential for calling the tool. Given the parameter complexity and annotations, this is sufficiently 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%, but many parameter descriptions are generic (e.g., 'name parameter'). The description explains the global partial-update semantics that apply to all parameters, clarifying how omitting vs sending null affects values. It also reinforces the fields array's behavior (already in schema) and the phone format. This adds meaningful interpretation 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 updates a contact's attributes and custom field values, a specific verb+resource. It does not explicitly differentiate from similar sibling tools like reach_updateAContactFieldV1, but the wording makes it clear it targets contact field values, not field definitions. The purpose is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no explicit guidance on when to use this tool versus alternatives such as reach_createANewContactV1 or reach_updateAContactFieldV1. It explains partial update semantics but does not mention exclusions or define the boundary with sibling tools, 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations only declare readOnlyHint=false and destructiveHint=false; the description adds meaningful behavioral context by disclosing the one-active-firewall-per-VM constraint. This helps the agent understand the state-changing impact of calling the tool, including the implicit replacement of an existing active firewall.
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 short and front-loaded with the core purpose. The final sentence, 'Use this endpoint to apply firewall rules to VPS instances,' is somewhat redundant with the first sentence, but the overall structure is efficient 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?
For a simple two-parameter endpoint with no output schema, the description is reasonably complete. It covers the action, the target resource, and the most important constraint (only one active firewall per VM). Missing details like what happens if no firewall exists or whether the operation is idempotent are minor for this complexity level.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already documents both parameters with 100% coverage: firewallId and virtualMachineId. The description adds no additional parameter-level meaning, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Activate') and resource ('firewall for a specified virtual machine'), making the core purpose clear. It does not explicitly name sibling tools like VPS_deactivateFirewallV1 or VPS_syncFirewallV1, but the verb and resource are specific enough to identify the operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a key usage constraint: 'Only one firewall can be active for a virtual machine at a time.' This implies the activation will replace any existing active firewall, which is valuable. However, it does not explicitly state when to prefer this tool over related firewall tools or note prerequisites such as creating a firewall first.
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?
Annotations already declare the operation is not read-only and not destructive, so the description only needs to add context. It adds that only existing account keys can be attached and that multiple keys can be attached to a single VM, but it does not disclose whether attachment is additive or whether duplicate or overwrite behaviors exist.
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 short sentences with no filler. The core action is front-loaded, and the remaining sentences add useful context about scope, multiplicity, and intended use.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter attach operation with complete schema coverage and annotations covering the safety profile, the description provides the essential information needed to call the tool. It could mention prerequisites such as key and VM existence, but these are reasonably implied by the wording.
Complex tools with many parameters or behaviors need more documentation. Simple tools need 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 'ids' described as 'Public Key IDs to attach' and 'virtualMachineId' as 'Virtual Machine ID'. The description adds no additional parameter-level detail, so it meets the baseline for schema-driven parameter clarity without enriching it 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 opens with the specific verb 'Attach' and the resource 'existing public keys from your account' to a specified virtual machine, which clearly differentiates it from related operations like VPS_createPublicKeyV1 or VPS_getPublicKeysV1. The final sentence reinforces the purpose by stating it enables SSH key authentication 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the use case: use this when you want to enable SSH key authentication by attaching keys already present in the account. It does not explicitly name alternatives such as VPS_createPublicKeyV1 for creating new keys or VPS_getAttachedPublicKeysV1 for listing attachments, so selection guidance is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations declare destructiveHint=false, but the description explicitly states 'If project with the same name already exists, existing project will be replaced.' Replacing an existing project is a destructive side effect, directly contradicting the annotation. This is an Annotation Contradiction and makes the behavioral disclosure unreliable.
Agents need to know what a tool does to the world before calling it. Descriptions 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: the first sentence states the core purpose, followed by compact, relevant details about URL resolution and replacement behavior. Every sentence earns its place and there is no redundant filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the main input modes and replacement behavior, but it omits some context an agent might need: there is no output schema, so response/return values are unexplained; the 'environment' parameter format is not elaborated; and the contradiction about destructive behavior weakens overall completeness. It is minimally viable but has clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds meaningful semantics beyond the schema, especially for the 'content' parameter: it explains GitHub repository URL resolution, the requirement that other URLs return docker-compose.yaml contents, and that raw YAML is accepted. Other parameters are not expanded further, but the content details justify 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 opens with a specific verb and resource: 'Deploy new project from docker-compose.yaml contents or download contents from URL.' It clearly distinguishes this creation/deployment tool from siblings like VPS_updateProjectV1, VPS_deleteProjectV1, and VPS_getProjectListV1, and even clarifies replacement behavior for existing projects.
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 operational context: use this tool to deploy a new project from raw compose content or a URL. It details acceptable URL forms and the replacement behavior, but it does not explicitly name alternatives or state when not to use it, such as pointing to VPS_updateProjectV1 for modifying an existing project.
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?
Annotations already communicate readOnlyHint=true and destructiveHint=false. The description adds useful context by specifying that the metrics are historical and enumerating CPU, memory, disk, network, and uptime, but it does not disclose response structure, time-series granularity, date format, 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 core action is stated in the first sentence, followed by a compact bullet list of included metrics and a one-sentence use case. There is no redundant or filler content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has only three required scalar parameters, and the description correctly identifies the VM and the date range plus the metrics returned. However, there is no output schema and the description does not describe the response shape or the date string format, leaving some ambiguity for an agent preparing the call.
Complex tools with many parameters or behaviors need more documentation. Simple tools need 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 parameter semantics baseline is 3. The description does not add meaningful details about the date parameters beyond their names; the schema's own date descriptions ('date_to parameter') are tautological, so the agent still has to guess the expected date string format.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Retrieve historical metrics for a specified virtual machine,' and the bullet list clarifies exactly which metrics are included. It does not explicitly contrast itself with sibling VPS tools like VPS_getScanMetricsV1, so it stops short of full sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
'Use this endpoint to monitor VPS performance and resource utilization over time' gives a clear intended use case. It does not mention when to prefer an alternative or state exclusions, but for a read-only metrics endpoint the context is reasonably self-contained.
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's 'view' language aligns with the annotations readOnlyHint=true and destructiveHint=false, with no contradiction. It adds only the 'current' qualifier and does not disclose additional behavioral details such as not-found behavior or snapshot state requirements, though the annotations already cover the safety profile.
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 minimal waste; the first sentence states the core action and resource clearly. The second sentence is slightly redundant but brief and front-loaded enough not to harm 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 one-parameter read-only operation with readOnlyHint and destructiveHint annotations, the description is sufficient for an agent to select and invoke the tool. No output schema exists, so explaining return format is not required; the description covers what the endpoint does and the parameter is fully documented.
Complex tools with many parameters or behaviors need more documentation. Simple tools need 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 virtualMachineId already described as 'Virtual Machine ID'. The description reinforces that the snapshot corresponds to a specified virtual machine but adds no new semantic detail beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Retrieve') and resource ('snapshot for a specified virtual machine'), clearly indicating a read operation. It distinguishes itself from sibling write operations like VPS_createSnapshotV1, VPS_deleteSnapshotV1, and VPS_restoreSnapshotV1 through the 'view' language.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'Use this endpoint to view current VPS snapshot information' gives some usage context but does not explicitly state when to choose this tool over alternatives or mention that create/delete/restore are separate operations. No exclusions or sibling comparisons 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?
The annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds that the tool returns 'comprehensive VPS configuration and status,' which is useful, but it does not disclose return format, error behavior, or other operational details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded with the main action. The second sentence repeats some of the first but adds the useful 'configuration and status' context, so it is not pure redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only single-parameter tool, the description plus annotations provide enough context to select and invoke it correctly. It could be more complete by describing the response shape, but the absence of an output schema and the low complexity keep this gap minor.
Complex tools with many parameters or behaviors need more documentation. Simple tools need 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 sole parameter virtualMachineId is documented in the schema. The description only echoes 'specified virtual machine' without adding parameter-level detail, so the 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 verb and resource: 'Retrieve detailed information about a specified virtual machine.' The word 'specified' plus 'detailed' distinguishes it from sibling list operations like VPS_getVirtualMachinesV1 and from getters for 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?
The description says 'Use this endpoint to view comprehensive VPS configuration and status,' which gives clear context for the call. However, it does not explicitly mention alternatives or when not to use it, such as contrasting with VPS_getVirtualMachinesV1 for listing VMs.
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?
Annotations already identify this as a mutating, non-destructive call (readOnlyHint=false, destructiveHint=false), and the description agrees. It adds the useful context that Monarx is a malware scanner and the endpoint enables protection, but it does not mention installation side effects, prerequisites, or duration. That is acceptable but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The essential first sentence is strong, but the rest is redundant: the second and third sentences repeatedly explain that Monarx is a security tool, and the last sentence restates the first. The description would be improved by keeping one sentence about the endpoint and one about the target.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter mutating endpoint with no output schema and non-destructive annotations, the description provides enough for an agent to call it: the target is the virtual machine ID and the action is installing malware protection. It lacks detail on return behavior or side effects, but those are not required for such a simple 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 schema covers the only parameter, virtualMachineId, with 'Virtual Machine ID'; schema description coverage is 100%. The description refers to 'a specified virtual machine' and 'VPS instances,' which loosely connects the parameter to its meaning but adds little beyond the schema. 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 opens with a specific verb-resource pair: 'Install the Monarx malware scanner on a specified virtual machine.' It also states the practical outcome, 'enable malware protection on VPS instances,' and the contrast with the sibling VPS_uninstallMonarxV1 is implicit in the verb '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 final sentence, 'Use this endpoint to enable malware protection on VPS instances,' gives explicit context for when to call the tool. It does not name alternatives such as VPS_uninstallMonarxV1 or state when not to use it, so it stops just short of 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?
Annotations already declare readOnlyHint=false, destructiveHint=true, and idempotentHint=true, so the safety profile is known. The description adds that it changes the core version, which is a mutation, but does not elaborate on side effects, downtime, or prerequisites. It does not contradict annotations, and the bar is lower due to annotation coverage, 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?
A single, front-loaded sentence contains all necessary information with no filler. It is 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 2-parameter mutation tool with annotations covering safety, the description is nearly complete. It specifies the target (Agency Plan website) and the version constraint. It does not mention explicitly that one should first retrieve available versions, but that is implied by 'available for installation' and the schema. Minor gap, so 4 is appropriate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need 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 (website_uid and version) are already described in the schema. The description repeats that the version must be available, adding little beyond the schema. Baseline 3 applies because the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Changes the installed WordPress core version'), the target resource ('on an Agency Plan website'), and the constraint ('to one of the versions available for installation'). It explicitly scopes to Agency Plan websites, distinguishing it from the similar hosting_updateWordPressCoreV1 tool. This is specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for Agency Plan websites but does not explicitly mention when to use it over alternatives like hosting_updateWordPressCoreV1, nor does it advise listing available versions first (via agency-hosting_listAvailableWordPressVersionsV1). Usage is inferable but not explicitly guided.
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?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the agent knows this is side-effect-free. The description adds useful behavioral context by specifying exactly what is returned and restricting the operation to Agency Plan websites; it does not hide expected side effects or contradict the 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?
A single front-loaded sentence states the verb, object, scope, and all returned categories with no filler. The colon-delimited list is easy to parse and 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?
For a one-parameter, read-only getter with no output schema, the description is nearly complete: it names the required scope and the four returned setting groups. It stops short of indicating whether fields can be null/absent or the response container shape, but that is a minor gap given the low complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the single parameter is already described as 'Agency Plan website UID,' so the schema carries the semantic burden. The description adds no new format, validation, or relationship detail beyond reaffirming the Agency Plan scope, which maps directly to the parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb—'Returns'—with a specific resource—'WordPress settings for an Agency Plan website'—and enumerates the exact settings returned (core version, LiteSpeed Cache, object cache, maintenance mode). This distinguishes it from sibling getters such as agency-hosting_getWebsiteDetailsV1 and the individual hosting_show* status tools without requiring schema inspection.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this aggregate getter versus the individual status tools (e.g., hosting_showWordPressCoreVersionV1, hosting_showLiteSpeedCacheStatusV1, hosting_showMaintenanceStatusV1) or versus agency-hosting_getWebsiteDetailsV1. The only usage signal is the 'Agency Plan website' scope, which is implied rather than contrasted 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?
Annotations already indicate this is read-only and non-destructive, and the description adds a useful note that the current PHP version is available from the website details endpoint. However, it does not describe the response format, availability semantics, or pagination, so it adds only modest behavioral context beyond the 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?
Two short sentences deliver the core purpose and a valuable pointer to related data, with no filler. The main action is front-loaded and the second sentence earns its place by helping the agent locate the current PHP version.
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 read-only list with annotations already covering safety, the description is largely sufficient. A brief mention of the response shape or the order-level sibling tool would make it complete, but nothing essential blocks 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 input schema fully documents the single parameter as an Agency Plan website UID, so the description does not need to add much. The mention of 'Agency Plan website' in the description mostly restates the schema and supplies no examples, constraints, or additional formatting guidance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('lists') and resource ('PHP versions an Agency Plan website can be switched to'), making the purpose immediately clear. It distinguishes itself from extension/option listers through the 'can be switched to' scope, though it does not explicitly contrast with the similar order-level PHP-versions sibling.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives a concrete use case: finding which PHP versions an Agency Plan website can switch to. It does not mention when not to use it or point to the order-level alternative, but the website-specific framing provides clear context without being misleading.
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?
Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds useful behavioral context by specifying pagination and that orders are scoped to the authenticated client, but it does not disclose defaults, limits, or response structure. No contradiction with annotations exists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single front-loaded sentence containing the verb, resource, scope, and pagination behavior with no filler. Every word contributes to understanding the 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 read-only paginated list with no required parameters and full schema coverage, the description is largely complete. The absence of an output schema leaves return-field details unspecified, but that is a minor gap 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?
The input schema describes both parameters with 100% coverage, so the description need not restate them. The word 'paginated' aligns with the page/per_page parameters but adds no new semantic detail beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Returns' and the specific resource 'Agency Plan orders', making the tool's purpose immediately understandable. The qualifier 'Agency Plan' distinguishes it from sibling order-listing tools such as hosting_listOrdersV1 and mail_listOrdersV1.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied by the resource scope: an agent would select this when listing Agency Plan orders. However, the description does not explicitly contrast it with sibling order-list tools, resource-usage metrics tools, or other billing/order endpoints, so guidance on when-not-to-use is missing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark this as read-only and non-destructive. The description adds the context that this lists backup points for restoration, but it does not disclose additional behavioral details such as sort order, pagination, or what snapshot metadata is returned.
Agents need to know what a tool does to the world before calling it. Descriptions 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 with no filler. The core operation is front-loaded, and the second sentence adds practical usage context 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 read-only list operation with one well-documented parameter, the description is largely complete. It clearly indicates the tool's role in the restoration workflow, though the absence of an output schema means it does not describe the exact return shape.
Complex tools with many parameters or behaviors need more documentation. Simple tools 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 description coverage, so the schema fully documents it. The description does not add extra format or meaning beyond 'domain', which is adequate but not enhanced.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb and resource: 'Retrieve DNS snapshots for a domain.' The phrase 'view available DNS backup points for restoration' adds purpose and helps distinguish this from snapshot restoration tools, though it does not explicitly name or differentiate from sibling 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 gives a clear usage context: use this endpoint to view available DNS backup points before restoration. It does not explicitly say when not to use it or name alternatives, but the restoration-focused framing provides enough guidance 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?
The description adds meaningful behavioral context beyond the annotations by explaining what enabling privacy protection does: it hides personal information from the public WHOIS database. The word 'hidden' clarifies that data is not deleted, which is useful given the destructiveHint annotation. It does not mention reversibility or why it is flagged destructive, but the annotations already cover idempotence and mutation.
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 short and front-loaded, with the main action in the first sentence. However, the third sentence 'Use this endpoint to protect domain owner's personal information from public view' largely repeats the rationale already expressed in the first two sentences, so not 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 one-parameter toggle operation, the description is complete enough to invoke correctly: it names the action, the domain scope, and the expected effect. Potential caveats such as reversibility or prerequisites would be nice but are not essential given the low complexity, high schema coverage, and existing 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?
The single parameter 'domain' is fully described in the schema as 'Domain name', giving 100% schema description coverage. The description itself adds no further format, example, or syntax details, so the baseline of 3 applies because the schema does the documentation work.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Enable privacy protection for the domain.' It also explains the core consequence, hiding the owner's personal information from the public WHOIS database. Although it does not explicitly name the sibling disable tool, the action and effect clearly distinguish it from domains_disablePrivacyProtectionV1.
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 when the goal is to protect the domain owner's personal information from public view. It does not explicitly mention the disable counterpart or state when not to use it, but the context is obvious enough for a simple toggle operation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint and destructiveHint annotations already establish that this is a safe read operation. The description adds the account-scoped 'all domains' behavior, but it does not go further to describe response format, pagination, or any other runtime behavior. This is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded with the core action. The second sentence, 'Use this endpoint to view user's domain portfolio,' is slightly redundant with the first but still reinforces the purpose without adding bloat.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless, read-only list operation with no output schema, the description provides sufficient context: it returns domains associated with the account. It could mention pagination or response fields, but given the tool's simplicity and annotation coverage, this is a minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and schema coverage is 100%, so the description is not required to explain parameters. Per the baseline rule for 0-parameter tools, this is handled appropriately; there is nothing missing.
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 and resource: 'Retrieve all domains associated with your account.' It clearly states the tool lists account-level domains. However, it does not explicitly distinguish itself from sibling tools like agency-hosting_listDomainsV1 or domains_getDomainDetailsV1, so it falls short of full differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
'Use this endpoint to view user's domain portfolio' gives clear context for when to call the tool. It does not, however, mention when not to use it or point to alternatives such as domains_getDomainDetailsV1 for individual domain details.
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?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds that the endpoint tracks transfer status and supports incoming/outgoing transfers, but gives no detail about response shape, error conditions, or other behavioral specifics. No contradiction exists.
Agents need to know what a tool does to the world before 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 the core action front-loaded. Every sentence adds useful context: what is retrieved and why an agent would call it. No filler or redundant restatement.
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 read-only endpoint with full schema coverage and clear annotations, the description conveys the essential purpose and hints at the return focus via 'status'. However, without an output schema and with similar sibling tools, a brief note differentiating this from move-specific or list endpoints would make it fully unambiguous.
Complex tools with many parameters or behaviors need more documentation. Simple tools need 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 only parameter, 'domain', is already described as 'Domain name'. The description's 'specified domain' adds no meaningful detail beyond the schema, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Retrieve') and resource ('transfer for a specified domain'), and clarifies it covers incoming or outgoing registrar transfers and their status. However, it does not explicitly distinguish itself from the similar-looking domains_getIncomingDomainMoveV1 and domains_getOutgoingDomainMoveV1 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 clearly instructs when to use the endpoint: to track an incoming or outgoing registrar transfer and its status. It does not provide explicit when-not-to-use guidance or name alternatives, especially relative to the domain move and transfer list siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds useful output context by stating the tool returns an onboarding URL and a deep-link, which is beyond the annotation information. However, it does not disclose potential side effects, whether a connection record is persisted, or whether the link expires, leaving some behavioral ambiguity for a non-read-only 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 with no redundant wording. It front-loads the primary purpose and then immediately states the output, making it efficient 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?
For a tool with only two simple parameters and no output schema, the description covers the core purpose and return values well. It could mention link expiration or whether the operation only generates a link versus creating a persistent provider connection, but the current level is sufficient for basic invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both store_id and provider_id adequately. The description does not add parameter-specific details beyond what the schema provides, so it does not elevate the semantics 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 tool creates an onboarding link for connecting a payment gateway, with a specific verb and resource. It also distinguishes itself from sibling tools like ecommerce_listStorePaymentProvidersV1 by describing the returned artifacts: a gateway onboarding URL and a store admin deep-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?
The description implies the tool is used when a merchant needs to connect a payment gateway, but it does not explicitly mention when to prefer this over related tools or when not to use it. There is no exclusion or alternative routing guidance, leaving the context implicit rather than fully explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only state readOnlyHint=false and destructiveHint=false; the description adds that the tool returns a signed URL and does not upload directly. It mentions the HTTP method (multipart/form-data POST) and the need to call attach-image afterward. However, it doesn't cover expiration of the URL, required permissions, or whether the product must already exist. It provides some extra context but lacks depth that would help an agent understand side effects or constraints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences: the first states the core action (returns signed URL with method), the second gives the essential next step. No filler, and key information is front-loaded. This is 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?
Without an output schema, the description must explain what the tool returns. It does mention the signed URL and the returned object_name, implying a structured response. It also explains the follow-up action. However, it doesn't specify response fields (e.g., URL, object_name structure) or constraints like expiration. For a simple tool, this is nearly complete, but a bit more detail on the response shape would make it fully self-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?
Input schema has 100% description coverage for both store_id and product_id, so the schema already explains their purpose. The description doesn't add any parameter-specific detail beyond what the schema provides—it only ties the overall flow to the parameters. Baseline 3 is appropriate because the schema carries the load and no additional semantics are needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns a signed URL for uploading a product image via multipart/form-data POST, and gives a specific next step (calling the attach-image endpoint). It distinguishes itself from the sibling ecommerce_uploadAndAttachAProductImageV1 by implying this only generates the URL, not performing the upload/attach. The verb 'returns' and the resource 'signed URL' are precise.
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 a workflow (generate URL, then call attach) but does not explicitly mention alternatives or when to use this vs. the combined upload-and-attach sibling. The context is clear (for two-step uploading) but no explicit 'when not to use' or naming of alternatives is given, leaving the agent to infer that the sibling might be a one-step option.
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 annotations only say readOnlyHint=false and destructiveHint=false, so the description carries the burden of explaining side effects. It adds that the product is 'published' and has a 'single variant', which is useful behavioral context. It does not, however, describe the response format or any post-creation implications beyond the published state.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that packs in the essential differentiators: physical, published, single variant, and currency context. There is no filler, and the key terms 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?
Given the simple create operation, fully self-documenting parameter names, and no nested fields, the description is mostly sufficient. The main gap is the lack of any statement about what the tool returns, which matters because there is no output schema, but the core usage context is covered.
Complex tools with many parameters or behaviors need more documentation. Simple tools need 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 every parameter is already documented in the schema. The description's mention of 'priced in the store currency' adds minimal context beyond the optional currency parameter's schema explanation, but it does not meaningfully clarify individual 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 states a specific action ('Create'), a precise resource ('physical product'), and key characteristics ('published', 'single variant', 'priced in the store currency'). This clearly distinguishes it from sibling tools like ecommerce_createDigitalProductV1 and ecommerce_createAProductVariantV1 without needing to open schemas.
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: for physical products rather than digital ones, and for a single-variant product rather than creating variants separately. However, it does not explicitly name alternatives or state when not to use the tool, leaving that inference to the 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?
Annotations already convey readOnlyHint=false and destructiveHint=false, so the description's burden is light. It adds post-condition context (store can accept orders without a provider), which is useful, but it doesn't disclose preconditions, reversibility, or side effects beyond the enabling 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?
A single 18-word sentence that front-loads the verb and object, then explains the purpose. Every word earns its place; there is no filler or repetition of 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?
For a low-complexity tool with fully documented parameters and annotations covering the safety profile, the description answers what the tool does, to which store, and with what effect. The only gap is explicit routing guidance against the payment-provider-connect sibling, which is minor for such a simple action.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema fully documents store_id and title, including title's display-name semantics at checkout. The description adds no additional parameter-level meaning beyond the schema, which matches the baseline 3 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 states a specific verb ('Enable'), a clear resource ('a manual payment method'), and the business effect ('so the store can accept orders without an online payment provider'). This distinguishes it from siblings like ecommerce_createAPaymentProviderConnectLinkV1, which handles online providers instead.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'without an online payment provider' implies the use case — enabling manual payment for stores that lack an online provider — but the description never explicitly names alternatives or states when not to use this tool. Usage context 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?
Beyond the annotations, the description adds useful behavior: virus scanning, content validation, CDN storage, and the is_thumbnail effect on the primary image. It doesn't mention replacement behavior or response details, but the non-readonly/non-destructive annotations set a baseline.
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?
Three well-structured sentences with the core action front-loaded. There is minor redundancy with the image_url parameter description, but no filler or unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description fully covers the URL-fetch flow but omits the object_name path, which is a valid alternative input and is relevant to the sibling upload-URL tool. With no output schema, return behavior is also unspecified, though this is secondary to the tool's purpose.
Complex tools with many parameters or behaviors need more documentation. Simple tools need 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 schemas already describe all parameters. The description re-states some image_url constraints and is_thumbnail semantics but does not add new meaning beyond what the parameter descriptions provide.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action — fetch a raster image from a URL and attach it to a product in a single call — and gives concrete constraints (formats, size). The 'single call' wording and the mention of the object_name alternative clearly separate it from the upload-URL sibling.
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 when to use the tool: when you have a publicly reachable URL and want to attach in one call. However, it never explicitly names the alternative (ecommerce_createAProductImageUploadURLV1) or says when object_name should be chosen over image_url.
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?
Annotations already declare readOnlyHint=true and destructiveHint=false, covering the safety profile. The description adds the behavioral scope (checks across all WordPress installations of a domain, optionally filtered by domain) but does not disclose more (e.g., return format, potential processing time). Given that annotations carry the main transparency burden, the description provides moderate added value, consistent with a baseline 3.
Agents need to know what a tool does to the world before calling it. Descriptions 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 redundant jargon. The core action is front-loaded, and the optional filter is mentioned logically after the primary purpose. Every word earns its place; there is no fluff 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?
For a simple read-only check with one optional parameter and no output schema, the description is sufficient. It clearly states the scope (any WordPress installation of a domain) and the filtering mechanism. The only minor gap is the lack of explicit return value details, but since no output schema is provided and the tool is straightforward, this is acceptable for a 4.
Complex tools with many parameters or behaviors need more documentation. Simple tools need 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%, as the parameter 'domain' already has a clear description. The tool description merely restates the filter ('Optionally filter by domain to scope the check') without adding new semantic detail. With full schema coverage, this meets the baseline without enhancement.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid 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 ('Check whether WooCommerce is installed'), the resource ('any WordPress installation of a domain'), and the optional scoping filter. It is distinct from sibling tools like hosting_checkIfWordPressInstallationsAreValidV1 or hosting_detectWordPressInstallationsV1, which address different concerns (validity, detection). No ambiguity remains about what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the usage context (checking WooCommerce presence on WordPress installations) but does not explicitly state when to prefer this tool over alternatives or mention any prerequisites. It lacks explicit exclusions (e.g., 'use hosting_listWordPressInstallationsV1 for details'), leaving the agent to infer the appropriate scenario. This is adequate but not fully guiding.
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?
Annotations already provide destructiveHint=true, readOnlyHint=false, and idempotentHint=true. The description adds 'permanently' to emphasize irreversibility, which is a useful nuance beyond the raw destructive flag. It does not discuss side effects, permissions, or behavior on repeated/nonexistent uids, but no contradiction with annotations exists.
Agents need to know what a tool does to the world before 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 filler. The deletion action is front-loaded, and the second sentence provides exactly the provenance needed for the uid. 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 two-parameter delete tool, the description and annotations are largely sufficient: the target is identified, the uid source is given, and the destructive nature is covered. Minor gaps remain, such as the meaning of the required username parameter and what the response will look like, but these are unlikely to prevent 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?
Both parameters are covered by schema descriptions, so the baseline is 3. The description reinforces that uid is the identifier from the list cron jobs endpoint, matching the schema. It does not add useful meaning for the username parameter, whose schema description 'username parameter' is essentially a tautology.
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?
States a concrete action ('Permanently deletes') and identifies the exact resource ('the cron job identified by its uid'). The title and tool name clarify it is an account-level cron job, which helps distinguish it from website-level cron job tools. However, the description itself does not explicitly differentiate it from sibling cron deletion endpoints.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives a clear precondition: the uid must come from the list cron jobs endpoint, which tells the agent where to obtain a valid identifier. It does not name alternative tools or state when not to use it, but for this simple deletion operation the usage context is reasonably 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?
Annotations already mark this as destructive and not read-only. The description adds value by stating the deletion is permanent and that remote connections are also deleted, which is useful behavioral context beyond the 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?
Two short sentences convey the core action, scope, and an important prerequisite with no wasted words. The destructive nature is front-loaded, and the constraint on the database name is placed immediately after.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter delete operation, the description covers the action, scope, and required input constraint. It does not describe return behavior or error cases, but no output schema exists and the annotations cover the safety profile.
Complex tools with many parameters or behaviors need more documentation. Simple tools need 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 repeats the 'full database name' requirement already present in the schema. It adds no additional meaning for the parameters, especially 'username', which remains generic in both places.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('permanently deletes') and resource ('a database and its remote connections'), which clearly identifies the tool's purpose. It also distinguishes itself from related siblings like deleting only a remote connection or deleting a website database.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps 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 a prerequisite for the database name but does not explain when to choose this tool over alternatives such as hosting_deleteDatabaseRemoteConnectionV1 or agency-hosting_deleteWebsiteDatabaseV1. No explicit when-to-use or when-not-to-use guidance is given.
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 goes beyond the minimal annotations by disclosing that a successful response only means the scan was queued, not completed. This is important behavioral context that prevents the agent from misinterpreting the response. It could add more detail about scan duration or side effects, but for a queued background operation this is sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact, front-loaded with the core action, and each sentence earns its place. The first sentence states what the tool does; the second explains the asynchronous behavior and follow-up action. 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?
The description provides the necessary context for a background-scan trigger: what it does, that it is async, and how to retrieve results. With only one parameter and no output schema, this is reasonably complete. It could be improved by clarifying the username parameter, but the overall flow is understandable.
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, username, has a schema description of 'username parameter', which is tautological and provides no real semantic meaning. The tool description also does not explain what username refers to or how it relates to 'the account.' Although schema coverage is technically 100%, the quality of that coverage is negligible, so the description fails to add meaningful parameter guidance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Trigger a background scan to detect WordPress installations for the account.' It names a specific verb, resource, and scope, and the asynchronous nature distinguishes it from listing or checking installations. However, it does not explicitly compare itself to sibling tools like hosting_listWordPressInstallationsV1, so the differentiation is implicit rather than named.
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 usage context by stating the operation is asynchronous and instructing the agent to 'Poll GET /api/hosting/v1/wordpress/installations' to retrieve results. This provides a concrete follow-up action. It does not explicitly state when to avoid this tool or mention alternatives, but the polling guidance is strong enough for correct invocation.
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 adds useful facts beyond annotations: the output is a full HTML phpinfo page and the tool is intended for read-only debugging. Annotations already declare readOnlyHint=true and destructiveHint=false. The description does not mention that phpinfo output can be large or expose sensitive configuration details, but the safety profile is covered by 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?
Two concise sentences with no filler. The first sentence states what the tool returns, and the second explains when to use it. Information is front-loaded and every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple, read-only tool with two required parameters, the description is mostly complete: it identifies the output format, the target resource, and the diagnostic use case. The main gap is the absence of any differentiation from hosting_getPHPDetailsV1, which could leave an agent unsure which tool to choose in a PHP-diagnostics workflow.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description reinforces that the output belongs to 'the website' but does little to clarify how username and domain relate or what formats are expected. The username parameter's schema text is essentially a tautology, but the description does not meaningfully compensate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Returns'), a specific resource ('the full phpinfo page (HTML)'), and the target ('the website'). It is clear enough that an agent can understand the core function, though it does not explicitly distinguish itself from the closely named sibling 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 provides clear use cases: 'debug PHP issues' and 'inspect the complete PHP environment of the website.' It lacks explicit exclusions or mention of alternatives such as hosting_getPHPDetailsV1, so it is not a full routing guide, 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.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes well beyond the destructiveHint annotation by explicitly warning that this overwrites the website's existing contents and cannot be undone, and advises verification before calling. This precisely discloses the destructive impact and irreversibility, which is exactly the behavioral context an agent needs.
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 critical warning. It consists of two short paragraphs with no filler. A slight redundancy exists between the title and the opening sentence, but overall it is well-structured and efficiently written.
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 action, prerequisites (uploaded files), and destructive nature. However, it does not explain the relationship to the similarly named sibling hosting_importWordpressWebsite, nor does it describe expected outcomes or return values (no output schema). For an import operation, this is 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?
The input schema provides 100% coverage for all four parameters, with descriptions for domain, sql_path, username, and archive_path. The description adds minimal extra meaning beyond restating that files are archive and database files already uploaded to the directory. The username parameter remains vague ('username parameter') and is not clarified.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb and resource: 'Import WordPress website to the specified domain.' It further specifies that it imports from archive and database files, which adds precision. However, it does not differentiate between this tool and the sibling hosting_importWordpressWebsite (without V1), which appears to be an analogous endpoint.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by stating that files must have been uploaded to the website's directory, but it does not explicitly say when to choose this tool over alternatives like hosting_importWordpressWebsite or agency-hosting_importWebsiteFromArchiveV1. No exclusions or alternative routing 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?
The description adds significant behavioral context beyond the annotations: the operation is asynchronous, a successful response only means the job is queued, and optional fields are only forwarded for Hostinger themes. There is no contradiction with the readOnlyHint=false or destructiveHint=false annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well structured with a clear opening statement followed by path/identifier guidance, conditional parameter behavior, and async semantics. It is appropriately sized for the tool's complexity, though the theme behavior is somewhat duplicated in the schema description.
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 invocation details: existing installation requirement, identifier source, optional Hostinger-specific fields, and async behavior. It could be more complete by suggesting how to verify the install eventually finished, especially since no output schema is present, but it still provides enough to call 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, but the description meaningfully adds value: it tells the agent how to obtain the software identifier and documents default values and conditional behavior for palette, layout, and font. This goes beyond the schema's field-level descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Install a theme on an existing WordPress installation.' This clearly explains what the tool does. However, it does not explicitly differentiate from similarly named siblings like hosting_deployWordPressThemeV1 or hosting_activateWordPressThemeV1, so an agent must infer the boundary.
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 useful usage context: it requires an existing WordPress installation, explains where to get the software identifier, and documents when optional fields apply. It does not explicitly say when to choose this tool over related alternatives such as deploy or activate, leaving some routing to inference.
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?
Annotations already declare readOnlyHint=true and destructiveHint=false, relieving the description of that burden. The description does add that the response includes schedule and command, which is useful context. However, it does not disclose potential pagination, filtering, or error behavior. Given the simplicity and the annotations, this is sufficient but not exemplary.
Agents need to know what a tool does to the world before 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, tight sentence that states purpose and content without any filler. Everything is front-loaded and directly relevant. There is no redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity (1 parameter, no output schema, no nested objects), the description is largely complete. It explains the return includes schedule and command, which gives some insight into the response structure. However, it stops short of describing the full response format (e.g., fields, types). For a simple read-only list, this is adequate but could be slightly enriched.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers 100% of the one parameter, but its description ('username parameter') is uninformative. The tool description clarifies that username refers to the 'specified account', providing some additional meaning. This meets the baseline for full coverage, but doesn't go further to explain format or constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb (Returns), the resource (list of cron jobs), and the scope (for the specified account). It specifies that the list includes schedule and command, which is precise and unambiguous. The name and description together distinguish it from create/delete and output-retrieval cron job tools, though it doesn't explicitly differentiate from the website-level variant.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied: an agent would use this when needing to list cron jobs for an account. However, there is no explicit guidance on when NOT to use it, nor any mention of alternatives such as agency-hosting_listWebsiteCronJobsV1 for website-scoped cron jobs. The sibling list is large and includes a very similar tool, but the description provides no differentiation.
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?
Annotations already mark the tool as non-read-only, idempotent, and destructive, so the safety profile is covered. The description adds the useful precaution of checking current states before changing, but it does not disclose further behavioral details such as whether changes apply immediately, are reversible, or affect other website functionality. No contradiction with 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 two sentences with zero filler. The primary action is front-loaded, and the prerequisite guidance is positioned immediately after it. 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 4-parameter mutation with strong annotations and full schema coverage, the description gives the essential context: what it changes, what the tool acts on, and a recommended pre-check step. The absence of an output schema means return behavior is not described, but this is a minor gap for this tool's 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 explains enable and disable as 'PHP extensions to enable' and 'PHP extensions to disable'. The description adds no further parameter-level meaning such as accepted extension name formats, interaction between enable and disable, or whether both can be sent together. The baseline of 3 applies because the schema carries the semantic weight.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action ('Enables or disables PHP extensions') and target resource ('for the website'), which is specific enough to distinguish it from related tools like hosting_updatePHPOptionsV1 or hosting_updatePHPVersionV1. However, it does not explicitly name or contrast any sibling tool, so it stops short of full differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The second sentence gives a concrete precondition: use the Get PHP details endpoint to check current extension states before modifying them. This provides clear situational guidance. It does not explicitly state when not to use this tool or name alternatives such as hosting_resetPHPExtensionsV1, so it misses the 'exclusions/alternatives' bar for a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate this is not read-only and not destructive. The description adds one useful behavioral constraint: it applies only to an unconfirmed catch-all. However, it does not address potential side effects like duplicate emails, idempotency, or behavior when the catch-all 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?
The description is a single clear sentence with no filler. It front-loads the action and target, and 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?
For a one-parameter tool with a fully documented schema, the description provides enough to call the tool correctly. Minor gaps remain around expected response or errors, but these are less critical given the simplicity of the 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 schema already fully documents the single parameter catchallId as 'Catch-all resource ID' (100% coverage). The description adds only contextual meaning that the catch-all is unconfirmed, not substantial new 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 states a specific action (resend), a precise resource (confirmation email for a catch-all), and the target (mailbox address of an unconfirmed catch-all). This clearly distinguishes it from the similar sibling mail_resendForwarderConfirmationV1, which targets forwarder confirmations instead.
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 resending confirmations to unconfirmed catch-alls, giving some usage context. However, it does not explicitly explain when to use this over the very similar forwarder confirmation tool, nor does it state what happens if the catch-all is already confirmed.
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?
Annotations indicate readOnlyHint=false and destructiveHint=false, so the description's statement that an email is resent adds some behavioral context beyond the annotations. However, it does not disclose potential side effects such as duplicate sends, expiration, or behavior when the 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?
The description is a single, clear, front-loaded sentence with no wasted words. It efficiently conveys the action, target, and condition.
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 adequately covers the action and target. It lacks some detail about edge cases or response behavior, but the simplicity of the tool means 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.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the single parameter forwarderId is described as 'Forwarder resource ID'. The description adds little beyond the schema, mentioning the destination address but not providing additional guidance on obtaining or formatting the 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 states a specific verb and resource: 'Resend the confirmation email' to an 'unconfirmed forwarder'. It also specifies the destination as the forwarder's destination address, which clearly distinguishes it from sibling tools like mail_resendCatchAllConfirmationV1.
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 unconfirmed forwarders where the confirmation email needs to be resent, but it does not explicitly state when to prefer this over alternatives or add exclusions. Usage context is inferred from 'unconfirmed forwarder' rather than directly guided.
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 details beyond annotations: it explicitly states that existing tags are not duplicated, the call is safe to repeat, and every requested tag is returned regardless of whether it was created or pre-existing. This adds meaningful context about idempotency and return behavior, which is valuable given readOnlyHint=false and destructiveHint=false.
Agents need to know what a tool does to the world before calling it. Descriptions 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 opens with a direct purpose statement followed by a brief, informative note on idempotency and return behavior. Every sentence adds value, and there is no redundant wording. The structure is front-loaded with the core function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with only two parameters and no output schema, the description adequately covers the essential behavior: it explains what the tool does, the idempotent nature, and what is returned (all requested tags). It lacks details about error conditions, profile existence requirements, or response format specifics, but those are less critical given the tool's simplicity and the schema's presence.
Complex tools with many parameters or behaviors need more documentation. Simple tools need 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 the schema's parameter descriptions are minimal ('names parameter', 'Profile uuid parameter'). The tool description adds context by indicating that 'names' refers to tag names and that the call operates within a profile, but it doesn't elaborate on formats, restrictions, or how parameters interact. It meets the baseline for high coverage without significantly enriching parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the core action: 'Create tags in a profile.' The title 'Create or find tags' is reinforced by the explanation that existing tags are returned instead of duplicated, making the dual purpose explicit. It distinguishes from sibling tools that assign, delete, or list tags, though it doesn't explicitly name alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool: to create tags or retrieve existing ones within a profile, with idempotency calls. However, it doesn't provide explicit criteria for choosing this over other tag-related tools (e.g., assign, rename, delete), nor does it mention when not to use it. The guidance is implied rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already signal readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds useful behavioral detail beyond the schema: it discloses which record types are inspected (MX, SPF, DKIM, DMARC) and clarifies that both actual and suggested records are returned. This gives the agent a clearer picture of what the operation will do and report.
Agents need to know what a tool does to the world before calling it. Descriptions 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 tight sentences: the first states the core action and target, the second adds valuable detail about the returned record states. There is no repetition of the title or fluff, and the most decision-relevant 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?
For a simple one-parameter, read-only endpoint, the description covers the essential behavioral aspects: what records are checked and what the response will contain (actual and suggested records). It stops short of describing exact response fields or mentioning how to obtain the profileUuid, but the absence of an output schema and the tool's simple nature make this 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 description coverage is 100% for the single parameter, so the schema already documents profileUuid as 'Profile uuid parameter'. The description adds mild context by tying the UUID to a profile's domain, but it does not significantly enhance parameter understanding beyond what the schema 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 uses a specific verb ('Retrieve') and identifies the exact resource ('DNS configuration status for a profile's domain'). It also names the record types covered (MX, SPF, DKIM, DMARC), making the tool's function clear. It does not explicitly distinguish this from siblings, but the tool name and description make its unique role evident.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is used when someone needs to inspect a profile domain's DNS records for email delivery, especially the actual vs suggested records. However, it does not state when to prefer this over related tools like DNS_getDNSRecordsV1 or reach_getConnectedSendingDomainV1, nor does it mention any prerequisites such as domain verification.
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?
Annotations already mark the tool read-only and non-destructive, so the description only needs to add operational context. It adds that the response contains the segment definition/conditions and that contacts are intentionally out of scope, but it does not describe response structure, errors, or pagination.
Agents need to know what a tool does to the world before 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 operation and output, the second routes to the alternative endpoint. No filler or repetition of annotation values.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-UUID read call, the description is largely sufficient: it names the output, scopes it to a profile, and distinguishes contacts retrieval. The lack of an output schema and exact sibling names are minor gaps, but annotations and simple params keep the tool callable without more.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3 even though the schema descriptions ('Profile uuid parameter', 'Segment uuid parameter') are minimal. The tool description does not add any parameter-level detail beyond implying profileUuid scopes the segment.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get'), a specific resource ('a single segment of a profile'), and specifies content ('conditions that define it'). It also signals a boundary by directing contact retrieval to the segment-contacts endpoint, but it does not name sibling tools explicitly, so it stops short of full differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The second sentence gives an explicit when-not: if the goal is retrieving contacts that match the conditions, use the segment contacts endpoint instead. This is useful routing context, though it does not mention other related siblings such as reach_getSegmentDetailsV1 or the list-segments 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?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds that the tool is for monitoring a specific operation, but it does not disclose response shape, error behavior, or any further operational nuances.
Agents need to know what a tool does to the world before calling it. Descriptions 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, front-loaded sentences. The first states the core operation and the second gives the intended use case, with no filler or unnecessary 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?
For a simple read-only two-parameter endpoint, the description is largely sufficient: annotations cover safety and the schema covers parameters. The only gap is that without an output schema, the description could more explicitly enumerate what 'detailed information' includes, but the monitoring context makes the tool's purpose 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 coverage is 100%, with both actionId and virtualMachineId described. The description adds no parameter-level detail such as ID formats or relationships, so it does not improve on what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the operation: retrieving detailed information about a specific action on a specific virtual machine. It is specific enough to be understood, but it does not explicitly contrast itself with sibling VPS_getActionsV1 or other list-oriented 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 phrase 'Use this endpoint to monitor specific VPS operation status and details' provides clear context for when this tool is appropriate. However, it does not state alternatives or exclusions, such as using VPS_getActionsV1 when a list of actions is needed.
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?
Beyond the annotations, the description discloses a critical side effect: any virtual machine with this firewall activated will lose sync and must be manually synced again. This is valuable behavioral context that annotations alone do not provide and directly affects whether an agent should proceed.
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 short and front-loads the core purpose, followed by an important warning. However, the final sentence 'Use this endpoint to modify existing firewall rules' largely repeats the first sentence and does not earn 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 mutating firewall rule operation with six fully documented parameters and annotations indicating destructive behavior, the description covers the essential purpose and the key side effect. It is complete enough for an agent to decide whether to call this tool, even without an 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?
Schema description coverage is 100%, and every parameter already has a meaningful description. The tool description adds no additional parameter-level detail, so the baseline score of 3 is appropriate since the schema carries the semantic weight.
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 first sentence clearly states the action (update), the resource (firewall rule), and the scope (a specific rule from a specified firewall). It does not explicitly distinguish itself from sibling tools like create or delete, but 'modify existing firewall rules' conveys the intended operation well.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states this is for modifying existing firewall rules, which implies when to use it versus creating new rules. However, it does not explicitly mention alternatives like VPS_createFirewallRuleV1 or VPS_deleteFirewallRuleV1, nor does it provide clear when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark this as destructive, non-read-only, and idempotent. The description adds valuable behavioral detail by specifying that all cache types are cleared and that every associated domain, including the preview domain, is affected. This goes beyond the structured annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded, with the core scope stated in the first sentence. The second sentence adds the 'all cache types' detail, though it is slightly redundant with the first sentence's mention of clearing cache.
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 destructive cache-clearing tool, the description sufficiently explains what is affected: all domains, the preview domain, and all cache types. No output schema exists, but return-value details are not critical for this operation. The lack of explicit mention of recovery or post-clear behavior 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 description coverage is 100%, with website_uid already documented as 'Agency Plan website UID.' The tool description does not need to add parameter detail and does not significantly expand on 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 specifies a concrete action ('Clears cache') and a precise resource scope: all domains associated with an Agency Plan website, including its preview domain. This clearly distinguishes it from sibling tools like hosting_clearWebsiteCacheV1 and hosting_toggleWebsiteCacheV1.
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 makes clear that this tool is for Agency Plan websites, which is useful context. However, it does not explicitly state when to use this tool over sibling cache-related tools, nor does it mention any alternatives or 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?
Annotations already indicate non-read-only and non-destructive behavior. The description adds valuable context: a renewal order is placed, and if no payment method is provided, the default one is used automatically. This is meaningful side-effect information beyond the annotations, though it doesn't detail charge timing or impact on the existing subscription term.
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 short and front-loads the main purpose. The phrase 'leveraging the existing billing infrastructure' is mild filler, but it doesn't hurt clarity or distract from the key instructions.
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 the operation, the prerequisite lookup for subscriptionId, default payment behavior, and scope. It doesn't mention response format or error conditions, but those are not essential for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds some guidance on where to find subscriptionId and repeats the default payment method behavior, but it does not add meaning for the coupons parameter beyond the schema's own 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 operation ('Create a renewal order') and the resource ('existing Hostinger subscription'), and specifies single-subscription scope. It doesn't explicitly distinguish this from related billing siblings like billing_createPurchaseOrderV1 or auto-renewal tools, so it lacks full sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly tells the agent to use the subscriptions endpoint to find available subscriptionId values, and says to use this endpoint to renew any available subscription. It doesn't state when not to use it or name alternatives, but the context is clear enough for correct selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already convey readOnlyHint=false, idempotentHint=true, and destructiveHint=true, and the description adds no additional behavioral nuance such as irreversibility or side effects. It does not contradict the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief and front-loaded with the verb and resource. The first sentence is slightly redundant with the title, but the second sentence adds useful clarification by equating domain forwarding data with redirect configuration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one parameter, and the annotations cover the destructive and idempotent behavior. The description adequately captures what the tool does without needing to explain return values or complex side effects.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides 100% description coverage for the single 'domain' parameter, so the description does not need to add parameter-level detail. It provides no additional meaning beyond the schema, which is acceptable given the high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the action ('Delete domain forwarding data') and the resource ('remove redirect configuration from domains'), making the tool's purpose immediately clear. It is easily distinguishable from sibling tools like domains_createDomainForwardingV1 and domains_updateDomainForwardingV1.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context: use this endpoint to remove redirect configuration from domains. It does not explicitly state when not to use it or name alternatives, but the operation is straightforward and the sibling context makes the usage evident.
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?
Annotations already mark the call as destructive, non-read-only, and idempotent. The description supplies the strategic effect of unlocking the domain to prepare for transfer but does not add further behavioral detail such as irreversibility or authorization requirements; that is acceptable given the annotations, so a mid score 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded with the action. The third sentence ('Use this endpoint...') restates the second sentence's purpose, creating slight redundancy, so it is not perfect.
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, annotation-rich tool, the description covers what the call does and when to use it. No output schema exists, and a return-value explanation is not essential here; the only minor gap is not describing result or error conditions, but this does not hinder 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?
There is one required parameter, domain, and the schema already documents it as 'Domain name' with 100% coverage. The description does not need to add semantics because the parameter is self-explanatory.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The first sentence states the exact action and object: disable the domain lock for the domain. The added context that this is for preparing domains for registrar transfer makes the purpose concrete and differentiates it from the sibling enableDomainLockV1.
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 domain lock must be disabled before transferring the domain to another registrar, giving a clear condition for use. It does not explicitly list when not to use it or mention alternatives, but for a direct inverse operation this 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?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds only the scope of the returned information ('configuration and status') and does not disclose additional behavioral traits such as response format or error conditions, but for a simple read this is acceptable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short, front-loaded sentences state the operation and intended use with little waste. The second sentence partly rephrases the first, but it adds the useful 'configuration and status' specificity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter, read-only, get-details endpoint, the description is sufficient for an agent to select and invoke it. The lack of an output schema is partly mitigated by the 'comprehensive domain configuration and status' phrasing, though more specific return information would be ideal.
Complex tools with many parameters or behaviors need more documentation. Simple tools need 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 only parameter, 'domain,' is documented as 'Domain name.' The description merely refers to 'specified domain' without adding format, ownership, or example details, so it does not improve on 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 a specific verb-resource pair, 'Retrieve detailed information for specified domain,' and further characterizes the result as 'comprehensive domain configuration and status.' This distinguishes it from list-style siblings like domains_getDomainListV1 and from specialized domain endpoints like domains_getDomainRenewalInformationV1.
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?
'Use this endpoint to view comprehensive domain configuration and status' gives a clear directive for when the tool is appropriate, though it does not explicitly state when to prefer sibling tools or any exclusions. The context is reasonably clear for a read-only detail 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?
Annotations already indicate destructive and non-read-only behavior, and the description adds a useful consequence: improper nameserver configuration can make the domain unresolvable or unavailable. It does not detail whether existing nameservers are overwritten, but the warning adds meaningful risk context beyond the structured hints.
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 short sentences with the action and warning up front. The first and last sentences are somewhat redundant ('Set nameservers' vs 'configure custom DNS hosting'), which prevents a perfect score.
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 5-parameter operation with full schema coverage and safety annotations, this description is largely sufficient: it states the action, the use case, and the key risk. The absence of an output schema is not a major gap for this kind of write 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 the schema already documents every parameter. The description adds no extra meaning about the format or semantics of domain/ns1/ns2/ns3/ns4, earning the baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Set nameservers for a specified domain', a specific verb plus resource, and adds the DNS-hosting context. It is clear and not tautological, but it does not explicitly distinguish this tool from sibling tools such as VPS_setNameserversV1 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The final sentence gives an explicit use case: 'Use this endpoint to configure custom DNS hosting for domains.' This provides clear context for when the tool is appropriate, though it does not mention exclusions or 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?
Annotations already mark this as destructiveHint=true and readOnlyHint=false, signaling a mutating operation. The description adds behavioral context by warning about the need to update website configurations that use the database, which is exactly the kind of side-effect disclosure beyond annotations that helps an agent. It doesn't mention whether the change is immediately applied, reversible, or what the response format is, but given that annotations cover the mutation flag, the added context is meaningful.
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, front-loaded with the core action, and the additional guidance about the database name and website configuration is directly relevant. Every sentence earns its place, and the structure is easy to scan. Minor deduction for not separating the usage caveats into a clearer 'when to use' note, but overall it's well-sized.
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 required parameters, full schema coverage, and no output schema, the description covers the essential inputs and the main side-effect caveat. It doesn't mention whether this action might fail or require specific permissions, but for a password-change tool the prerequisites are adequately disclosed. The tool's name and sibling list make its scope clear, so nothing critical is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with all three parameters (username, name, password) described concisely. The description reinforces the 'name' parameter's constraint — it must be the full name from list databases — and clarifies that password is the new password. However, the description doesn't add much beyond the schema, which already explains each parameter. 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 states a specific verb and resource: 'Changes the password for the specified database user.' This clearly differentiates it from related tools like creating or deleting database users, and from other password-change tools like mail_changeMailboxPasswordV1 or VPS_setRootPasswordV1. However, it doesn't explicitly name a sibling or contrast itself with the list databases endpoint, so it falls slightly short of full differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear prerequisite: 'The database name must be the full name returned by the list databases endpoint.' It also gives an important operational caution: the password must be updated in any website configuration using the database. It doesn't explicitly state when to use this tool vs alternatives, but the context is sufficient for an agent to know when this is the right action.
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?
Annotations already declare destructiveHint=true and idempotentHint=true, so the destructive nature is covered. The description adds a small behavioral constraint by saying 'existing subdomain' (the target must already exist), but it does not disclose consequences such as permanence or effect on related DNS records. This is adequate given annotation coverage, 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loads the core action in the first sentence. The second sentence, 'Use this endpoint to remove subdomains that are no longer needed,' adds a mild usage note but is largely a restatement, so it is slightly less efficient than it could be.
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 all parameters required and annotations covering destructive and idempotent behavior, the description provides enough context for correct invocation. It does not clarify whether the subdomain value should be a bare label or full hostname, but that gap is more appropriately addressed by parameter documentation than the tool description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description itself adds no parameter-level meaning beyond what the schema provides. The schema descriptions for username and subdomain are weak ('username parameter', 'subdomain parameter'), but the description does not compensate for that, so it stays at 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 states a specific action ('Delete an existing subdomain') and a specific resource ('from the selected website'), which clearly distinguishes it from sibling tools like hosting_createWebsiteSubdomainV1 or hosting_listWebsiteSubdomainsV1. The verb and object are explicit and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives a clear use case: 'remove subdomains that are no longer needed.' It does not explicitly name sibling alternatives or state when not to use this endpoint, so it stops short of a 5, but the context is sufficient for an agent to recognize the intended scenario.
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?
Annotations already mark the operation destructive and non-read-only; the description adds useful behavior: the server automatically triggers a build, upload credentials are generated internally, and the tool is end-to-end. It does not disclose what is overwritten or destroyed (e.g., whether a previous deployment on the domain is replaced), which would have made this a 5, but it gives meaningful workflow context beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Four sentences, each serving a purpose: action, archive constraints, automatic build, upload handling, and post-deploy status tracking. Slight redundancy with the archivePath schema description and the repeated 'IMPORTANT' caps keep it from a 5, but the structure 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 mutation tool with no output schema, the description tells the agent what to do after calling it (use hosting_listJsDeployments) and what prerequisites to satisfy before calling (clean archive). It omits specifics on destructive effects and error paths, but the schema and annotations cover parameters and destructiveness, so the core calling context is complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3, and the description largely repeats the schema constraints rather than adding new parameter meaning. It re-emphasizes the source-only archive rule and supported formats in archivePath, but domain and removeArchive semantics come from 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?
Opens with a specific verb+resource: 'Deploy a JavaScript application from an archive file to a hosting server.' It distinguishes itself from static-site/PHP/WordPress deploy siblings mostly by application type and the mention of an automatic build process, but it never explicitly names a sibling or states the boundary (e.g., static vs Node), so it is clear but not perfectly differentiated.
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?
Gives actionable preparation guidance (source-only archive, skip node_modules, honor .gitignore), explicitly instructs not to call a separate upload-url endpoint, and routes the agent to hosting_listJsDeployments for status. It does not enumerate alternatives like hosting_deployStaticSiteArchiveV1 or hosting_deployPhpApplication, so it falls short of fully explicit when-to-use-this-vs-that guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already mark this as a mutating action (readOnlyHint=false) with no destructive behavior. The description adds useful context that the subdomain is free and unique, and that a custom domain can be connected later, but it doesn't disclose what is returned or any limits/side effects beyond that.
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 short and front-loaded with the core action. The second and third sentences add useful context about immediacy and future custom-domain use, though they are slightly redundant with the first sentence's 'without purchasing custom domains' clause.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter generation action, the description is sufficient: it explains what is generated, why it is useful, and how it fits into the broader hosting workflow. The lack of an output schema is acceptable because the purpose is simple and the generated subdomain is the clear output.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema description coverage is 100%. There is no parameter semantics burden for the description to carry, so a baseline of 4 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Generate') and resource ('a unique free subdomain'), making the tool's purpose immediately obvious. It clearly distinguishes itself from custom-domain purchase flows and website subdomain tools by emphasizing that no purchase is needed.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool: when you want to start hosting immediately without purchasing a custom domain. However, it does not explicitly name alternatives or say when not to use it, leaving sibling differentiation to inference.
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?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds the 'direct sign-on' detail and the full-name requirement, but it does not address link expiry, permissions, or other behavioral traits. No contradiction with 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?
Three sentences, each earning its place: outcome, use case, and a key constraint. No filler or redundant wording.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple and read-only, and annotations cover the safety profile. The main gap is the required username parameter, which is not explained beyond a tautological schema label, so callers may not know which username to supply.
Complex tools with many parameters or behaviors need more documentation. Simple tools need 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 restates the database name requirement already in the schema, but adds nothing about the username parameter, whose schema description is a tautology ('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?
Description states a specific verb 'Returns' and a clear resource: 'direct sign-on link to phpMyAdmin for the specified database'. It is distinct from all sibling tools, as none other generates a phpMyAdmin link.
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: 'Use this when a visual database interface is needed for SQL queries, imports, exports, or table management.' It does not mention exclusions or name alternatives, but the use case is clear enough for an agent to select this tool confidently.
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 a critical behavioral trait beyond the annotations: 'This operation is asynchronous: a successful response only means the install job has been queued, not that the plugins are ready.' This tells the agent not to expect immediate completion. It doesn't cover how to poll for job status, but the most important behavior is clearly 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?
Three short paragraphs with no filler. The main action is front-loaded, the identifier/discovery instructions are compact, and the async caveat is a single sentence. Every sentence adds operational 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?
Covers the key prerequisites and async behavior, but no output schema exists and the description does not explain what the response contains or how to check whether the queued job eventually succeeds. The `username` parameter also remains undefined, and there is no mention of verification via sibling tools like hosting_listInstalledWordPressPluginsV1.
Complex tools with many parameters or behaviors need more documentation. Simple tools need 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 value by explaining where to obtain the `software` identifier, which the schema alone does not provide. However, the `username` parameter is described only as 'username parameter' in both schema and description, leaving its meaning unresolved.
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?
States a specific verb and resource: 'Install one or more plugins on an existing WordPress installation.' It distinguishes from sibling tools like activate/update/uninstall by focusing on installation, and the discovery endpoint reference ('plugin slugs available for installation') clarifies this is catalog-based install. However, it does not explicitly contrast with hosting_deployWordPressPluginV1, leaving some potential 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?
Provides clear operational context: the tool applies to an existing WordPress installation, tells the agent how to get the software identifier ('obtained from GET /api/hosting/v1/wordpress/installations (the `id` field)') and how to discover valid plugin slugs ('Use GET /api/hosting/v1/wordpress/plugins'). It lacks explicit exclusions or alternative routing, such as 'use deploy for custom plugins,' so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, covering the safety profile. The description adds useful behavioral context by noting the result is paginated and that filtering by deployment states is possible, but it does not reveal details about ordering, default page size, or response contents. With annotations doing the heavy lifting, this is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences: purpose, usage trigger, and capability. There is slight redundancy between the first and third sentences ('List javascript application deployments' vs 'retrieves a paginated list of Node.js application deployments'), but the description is short, 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?
For a simple read-only list tool with complete schema documentation and readOnly/destructive annotations, the description covers the core need: what it lists, when to use it, and its filtering/pagination behavior. No output schema exists, so the description could be more explicit about return shape, but this is not a serious gap for a status-listing 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 input schema already documents all four parameters. The description reinforces the role of domain and states filtering and mentions pagination, but it does not add substantive meaning beyond what the schema already provides. Baseline 3 is appropriate here.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action (list/retrieve deployments), a concrete resource (Node.js/JavaScript application deployments), and an explicit purpose ('for checking their status'). It also differentiates from sibling tools like hosting_showJsDeploymentLogs by focusing on status rather than logs, and from hosting_deployJsApplication by being a read/list 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?
It explicitly tells the agent when to use this tool: 'Use this tool when customer asks for the status of the deployment.' This is clear usage context, though it does not explicitly name alternatives or state when not to use the tool, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, and the description consistently describes a read operation. It adds useful context about data scope ('hosting accounts' and 'shared access') and pagination, but does not disclose response shape, pagination defaults, or rate limits. This meets the baseline but is 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, front-loaded with the core action, followed by scope and filter guidance. It is compact and readable, though the final sentence largely restates schema information that is already explicit in the input schema.
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 read-only list operation with fully documented optional parameters, the description covers the essential selection context: hosting orders, shared access, pagination, and filtering. It does not describe the response structure, and no output schema is available, but this is a minor gap for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so page, per_page, statuses, and order_ids are already fully documented. The description only advises using these filters and adds no new 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 opens with a specific verb and resource: 'Retrieve a paginated list of orders.' It further distinguishes itself by scoping the result to the authenticated client's hosting accounts plus orders from shared access, which separates it from sibling order-list tools such as ecommerce_listStoreOrdersV1 and mail_listOrdersV1.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use the tool: when listing hosting-account orders, including those shared with the client. It does not explicitly name alternative tools or state 'do not use when...', so it stops short of full routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds no behavioral detail beyond 'show' — such as whether the cache status can be unavailable, what values may appear, or whether any plugin dependency exists. This is acceptable but not deeply 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 short, focused sentences with no filler. The core purpose is front-loaded, and the additional guidance about obtaining the software identifier is placed where it is most useful.
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 read-only status tool, the description covers the target resource and how to find the key identifier. However, the required `username` parameter is not contextualized, and with no output schema, the description does not indicate what the status response looks like.
Complex tools with many parameters or behaviors need more documentation. Simple tools need 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 helpful meaning for `software` by pointing to GET /api/hosting/v1/wordpress/installations and the `id` field, but it leaves `username` essentially unexplained beyond the schema's tautological '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 states a specific verb ('Show') and a precise resource: the LiteSpeed Cache status for a specified WordPress installation. This clearly identifies which operation is being exposed and distinguishes it from related siblings like purgeLiteSpeedCacheV1 or showMemcachedObjectCacheStatusV1.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context: use this tool to check LiteSpeed Cache status for a particular WordPress installation, identified via the software parameter. It does not explicitly list alternatives or exclusions, but the target use case is unambiguous enough for an agent to select it correctly.
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?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safe read-only nature is established. The description adds useful output context by mentioning known vulnerabilities and the path-based identifier, but it does not detail response format or any other behavioral traits, so it does not exceed the annotation baseline substantially.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded: the first sentence states the primary purpose and output, and the second gives the essential parameter-source guidance. There is no redundant filler or repetition of the title.
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 two-parameter read-only tool, the description is mostly sufficient, but it leaves the required `username` parameter unexplained and does not describe the return shape despite there being no output schema. These are meaningful gaps for an agent deciding how to call the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is listed at 100%, but the `username` parameter description ('username parameter') is tautological and unhelpful. The description adds meaningful guidance for `software` by explaining it is an installation identifier obtainable from a list endpoint, but leaves `username` semantically 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?
The description clearly states the tool 'Shows the WordPress core version for the specified installation' and adds that known vulnerabilities are included. This distinguishes it from sibling tools like hosting_listAvailableWordPressCoreUpdatesV1 or hosting_updateWordPressCoreV1, which are about updates rather than displaying the current version.
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 on how to invoke the tool: it requires the WordPress installation identifier in the path and tells the agent where to obtain it (GET /api/hosting/v1/wordpress/installations, the `id` field). It does not explicitly discuss alternatives or when not to use it, but the usage 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the key behavioral trait that this is an asynchronous operation, so a successful response only means the job was queued. This goes beyond the annotations, which only state that the operation is not read-only and not destructive.
Agents need to know what a tool does to the world before calling it. Descriptions 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: it states the operation in the first sentence, then gives the identifier sourcing detail, then the asynchronous behavior. Every sentence earns its place with no repetition or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no output schema, the description covers the essential invocation details: what operation is performed, how to find the required software identifier, and how to interpret a successful response. It could additionally explain how to check job status or clarify mutual exclusivity of minor and version, but these are not blocking.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already documents all four parameters, providing a high baseline. The description adds useful meaning by explaining that the software identifier can be retrieved from GET /api/hosting/v1/wordpress/installations and by clarifying that the update is either a minor update or a specific version.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (Update), the resource (WordPress core), and the scope (minor update or specific version). It does not explicitly name sibling alternatives like plugin/theme updates, but the resource noun and scope are sufficiently specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool by stating its purpose, and it provides a useful prerequisite: how to obtain the software identifier from the installations endpoint. However, it does not explicitly distinguish this tool from close alternatives such as agency-hosting_changeWordPressVersionV1 or from plugin/theme update 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?
Annotations already declare destructiveHint=true and readOnlyHint=false, so the mutation is known. The description adds useful behavioral context beyond annotations by stating that forwarding stops immediately, which clarifies the direct consequence of the 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 short and front-loaded. The first sentence is somewhat redundant with the tool title, but the second sentence adds meaningful behavioral detail. Overall, it is efficient and readable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter delete operation with annotations covering destructive and idempotent behavior, the description is sufficient. It lacks explicit guidance on retrieving the forwarderId, but the schema and sibling tool context (mail_listForwardersV1) make that discoverable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already fully documents the only parameter 'forwarderId' with a clear description ('Forwarder resource ID'). The description adds no additional parameter-level 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?
States a specific action ('Delete a forwarder') and clearly identifies the resource being operated on. The added effect ('mailbox stops forwarding messages') distinguishes it from other mail deletion tools like mail_deleteAliasV1 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies its use case: deleting a forwarder when its forwarding behavior is no longer desired. However, it does not explicitly mention when to avoid using it or point to alternatives such as mail_updateForwarderKeepCopySettingV1 for modifying forwarder behavior instead.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is clear. The description adds useful context about what the response covers (quotas, limits, protocol availability), but it does not disclose output shape, error behavior, or whether the plan can be missing for certain orders.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one focused, front-loaded sentence that states the action, the target resource, and the key contents of the returned plan. There is no redundant phrasing or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only getter with one required parameter, this description is sufficiently complete. It explains what the tool returns, the annotations cover safety, and the schema fully documents the only input, so an agent can select and invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter orderId is fully documented in the schema as 'Order resource ID', so schema coverage is 100%. The description only refers to it indirectly as 'the given mail order' and adds no new format, source, or prerequisite 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 uses a specific verb 'Retrieve' and identifies the exact resource: the plan a mail order was purchased with. It further clarifies the scope by enumerating what the plan includes (domain-level and mailbox-level quotas, limits, protocol availability), making it clearly distinct from sibling list/retrieval tools such as mail_listOrdersV1.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The usage context is implied: call this when you need the plan details for a specific mail order. However, there is no explicit guidance about when not to use it, prerequisites such as obtaining the orderId first, or how it compares to related mail order 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?
Beyond the annotations (readOnlyHint=false, destructiveHint=true), the description adds meaningful non-obvious behavior: existing contact assignments are preserved, and duplicate names are rejected. It does not cover every edge case, but it adds useful operational context beyond structured metadata.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences with the main action front-loaded and no filler. Each sentence earns its place by adding either the core purpose or an important constraint.
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 three-parameter rename with full schema coverage and annotations, the description is sufficiently complete: it states the purpose, the preservation side effect, and the uniqueness rejection rule. No output schema exists, but the absence of return-value explanation is a minor gap for this simple mutation.
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 covers all three parameters, but the description adds semantics: 'contact assignments unaffected' clarifies the effect of renaming, and 'names are unique within a profile' clarifies the relationship between value and profileUuid. This goes beyond the schema's terse 'New tag name' and 'Profile uuid parameter.'
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Rename a tag,' a specific verb and resource, and adds context that contacts are unaffected and names are unique within a profile. It is clearly not a delete, create, or assignment operation, though it does not explicitly call out sibling alternatives.
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 is self-explanatory and the uniqueness/affected-contacts details imply the operation on an existing tag. However, there is no explicit guidance on when to choose this tool over related tag operations such as reach_deleteATagV1 or reach_createOrFindTagsV1.
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?
Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds no new behavioral details such as pagination behavior, rate limits, or response shape; it only echoes the safe read-only nature of the 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 brief and front-loaded, with the core purpose in the first sentence. The second sentence is somewhat redundant with the first, but it does reinforce the usage intent without adding meaningful bloat.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list operation with one optional page parameter and read-only annotations, the description is adequate. An agent can infer the call's purpose and safety. It could clarify pagination behavior, but the schema already covers the 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 description coverage is 100%, and the only parameter, 'page', is already documented as 'Page number'. The description adds no extra meaning about pagination semantics, defaults, or how pagination interacts with 'all available firewalls'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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 and resource nouns: 'Retrieve all available firewalls' and 'view existing firewall configurations.' The word 'all' and the plural 'list' orientation clearly distinguish this from sibling creation/update/delete/detail endpoints like VPS_getFirewallDetailsV1.
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 it: 'Use this endpoint to view existing firewall configurations.' It does not name alternatives or edge cases like retrieving a single firewall's details, so it stops short of a full when-to-use/when-not-to-use guide.
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?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds useful behavioral context about what will be returned (compose file, metadata, deployment status) but does not disclose additional details like response format, error conditions, 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded with the core purpose. The second sentence is somewhat redundant with the first, but the overall structure remains efficient 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?
For a read-only retrieval tool with a fully documented two-parameter schema, the description provides enough context about what is returned. It lacks an explicit response format, but the listed artifacts (compose file, metadata, deployment status) give adequate grounding 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 are already documented in the schema. The description does not add new parameter-level meaning but reinforces that the tool targets a specific project.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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 ('Retrieves') and a concrete resource ('complete project information for a specific Docker Compose project'), listing the included artifacts: docker-compose.yml contents, metadata, and deployment status. This clearly distinguishes it from sibling tools like getProjectList or getProjectLogs.
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 when to use the tool: 'Use this to inspect project settings, review the compose file, or check the overall project health.' It provides clear context but does not explicitly mention 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?
Annotations already indicate this is a non-read-only, non-destructive mutation, and the description adds the side effect of creating a dedicated user. It does not mention prerequisites, duplicate handling, or other behavioral details, but the annotation coverage lowers the burden.
Agents need to know what a tool does to the world before calling it. Descriptions 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 with the primary action front-loaded. The second sentence adds useful emphasis about caller-provided values without unnecessary detail or repetition of the schema.
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 full schema coverage, the description conveys the core purpose, scope, and caller responsibility. A brief note about the website_uid parameter or duplicate existing resources would improve completeness, but nothing essential for invocation is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters. The description adds little beyond the schema and actually omits website_uid from the list of caller-provided values, though it does emphasize that credentials must be supplied.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid 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 ('Creates a MySQL database with a dedicated user') and the target scope ('for an Agency Plan website'). This distinguishes it from sibling tools like agency-hosting_createWebsiteDatabaseUserV1 and hosting_createAccountDatabaseV1.
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 scoping the operation to Agency Plan websites, which helps an agent choose between agency-hosting and general hosting database tools. It does not explicitly name alternatives or exclusions, so it misses the top 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?
Annotations already declare destructiveHint=true and idempotentHint=true. The description adds meaningful nuance by explicitly stating the operation is permanent and that deleting a nonexistent cron job succeeds without error. This goes beyond the bare hints and helps set correct 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?
Two concise sentences with no unnecessary words. The primary action is front-loaded, and the idempotence clarification earns its place as a separate sentence.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter destructive operation with annotations covering idempotence and destructiveness, the description is nearly complete. It lacks explicit usage differentiation from similar delete tools, but otherwise gives an agent enough to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents both parameters. The description adds some relational context ('identified by its uuid' and 'from an Agency Plan website') but does not materially deepen parameter understanding 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 states a specific verb ('deletes'), a specific resource ('cron job'), and scope ('from an Agency Plan website'). This clearly distinguishes it from account-level cron job tools like hosting_deleteAccountCronJobV1 and from the create/list cron job siblings in the same namespace.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies it should be used when deleting a cron job from an Agency Plan website, but it does not explicitly state when to use it over alternatives or mention prerequisites such as listing cron jobs first. The idempotence note provides useful context but not routing 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?
Annotations already declare readOnlyHint=true and destructiveHint=false, covering the safety profile. The description goes beyond by disclosing pagination behavior and that returned entries include the database's non-system users, which is not inferable from annotations or schema. It does not add auth or rate-limit context, but that is not required for a read-only 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 sentences, each with distinct value: first states the operation and scope, second states the key content of the response. 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?
For a simple read-only, paginated list tool with fully described parameters and read-only annotations, the description is nearly sufficient. It mentions pagination and the notable inclusion of non-system users, though it leaves the full response shape unspecified since there is no output schema. Considering low complexity, 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?
All three parameters have schema descriptions (100% coverage), so the baseline is 3. The description's mention of 'paginated list' merely reinforces the schema's 'Page number' and 'Number of items per page' without adding new constraints or format details. website_uid scope is already described 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?
States a specific verb ('Returns a paginated list'), a concrete resource ('MySQL databases'), and a scoping qualifier ('created for an Agency Plan website'). This distinguishes it from account-level database listing tools such as hosting_listAccountDatabasesV1.
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 Agency Plan website databases, which differentiates from account-level database tools, but it never explicitly tells an agent when to choose this over a sibling like hosting_listAccountDatabasesV1 or when not to use it. No prerequisites or exclusions are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, covering the safety profile. The description adds useful scoping context by saying 'current DNS configuration' and 'domain management,' but it does not disclose return format, pagination, or record types. This is adequate but not exceptional given the annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is only two sentences and front-loads the core action ('Retrieve DNS zone records') before adding usage context. Every sentence earns its place, with 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?
For a simple one-parameter read-only tool with annotations covering safety, the description is nearly complete. It clearly identifies the resource, the scoping domain, and the use case. The only minor gap is that return shape or record-level details are not described, but this is not critical for selecting and 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 the single 'domain' parameter already described as 'Domain name.' The description merely reinforces that the operation is for 'a specific domain,' adding no new syntax, formatting, or behavioral nuance 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 states a specific verb and resource: 'Retrieve DNS zone records for a specific domain.' It also clarifies that this reads 'current DNS configuration,' which helps distinguish it from snapshot-related DNS tools like 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 gives clear usage context: 'Use this endpoint to view current DNS configuration for domain management.' However, it does not explicitly mention alternatives or when not to use this tool, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true and readOnlyHint=false, so the safety profile is covered. The description adds only a restatement of the revert behavior and does not disclose additional consequences such as overwriting current DNS records, but it does not contradict the 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?
Two short sentences convey the action and the reason to use it, with no filler or redundant detail. The 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?
For a two-parameter destructive restore with annotations covering the risk profile, the description is nearly complete. A note that the restore overwrites the current DNS configuration or that the snapshot should be obtained from the DNS snapshot list would make it 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% and both parameters are documented in the schema ('Domain name' and 'Snapshot ID'). The description adds no additional parameter guidance, matching the baseline for fully covered schemas.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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-resource pair ('Restore DNS zone to the selected snapshot') and clarifies with 'revert domain DNS to a previous configuration.' It clearly distinguishes this from DNS_getDNSSnapshotListV1/DNS_getDNSSnapshotV1 and from DNS_updateDNSRecordsV1/DNS_resetDNSRecordsV1.
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 gives a direct usage instruction: use this endpoint to revert a domain DNS to a previous configuration. It does not explicitly name alternatives or state when not to use it, so it falls short of 5, but the intended 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?
The annotations already convey the core behavioral profile: readOnlyHint=false, destructiveHint=true, and idempotentHint=true. The description adds useful context about the 5-day expiry and the stuck-WHOIS-change scenario, but it does not disclose side effects, reversibility, or the post-cancellation state, which would add further value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: the first sentence states the action directly, and the second provides a concrete use case with no filler or redundant wording.
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 action, the description covers the purpose, trigger scenario, and rationale well. It does not describe the response format or error cases—especially relevant since there is no output schema—but the low complexity and clear annotations make this nearly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already documents the only parameter (domain) with 100% coverage. The description does not add any parameter-level detail 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 opens with a direct verb-resource statement: 'Cancel a pending IRTP verification.' It further clarifies the scope by explaining it applies to a WHOIS change stuck waiting on registrant confirmation, which distinguishes it from related read-only 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 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 it: to back out of a WHOIS change stuck on registrant confirmation, such as when the confirmation email cannot be received, and to avoid waiting out the 5-day expiry. It does not explicitly name alternatives or list when not to use it, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark this as read-only and non-destructive. The description adds beyond that by disclosing the 90-requests-per-minute rate limit, the multi-TLD batch behavior, and the one-TLD requirement for alternatives. This is useful operational context that annotations do not provide.
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 and front-loaded with the core purpose. Each sentence adds either an operational constraint, a rate limit, or a usage recommendation. Some minor redundancy with the schema exists, such as the TLD format note, but overall it is well structured and not bloated.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only availability check, the description covers the essential operational details: multi-TLD support, alternatives behavior, TLD formatting, rate limit, and the intended purchase-verification use case. It does not describe the exact response shape, but no output schema exists and the tool's purpose makes the return intent clear enough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds meaningful extra semantics, especially for with_alternatives: it clarifies that alternatives are only returned when exactly one TLD is provided and the flag is true. It also reinforces the no-leading-dot TLD format with 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 verb and resource: 'Check availability of domain names across multiple TLDs.' It also frames the purpose as verifying availability before purchase, which distinguishes it from domain suggestion tools like domains_suggestDomainNamesFromADescriptionV1, though it does not explicitly name those alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context: use before purchase, support for checking multiple TLDs at once, and the specific condition for using with_alternatives (single TLD and set to true). It does not explicitly state when not to use this tool or name alternatives, but the provided usage context is strong.
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?
Annotations already mark this as destructive and idempotent, so the description only needs to add context beyond those flags. It adds 'unused' and 'from account' context but does not disclose side effects, restrictions, or behavior on failure. No contradiction with 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?
Two short sentences, front-loaded with the action, and no filler. Every sentence contributes either the operation or the intended 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 one-parameter delete operation with strong annotations, this is nearly complete: action, target, parameter, and intended use are all present. It could be slightly richer by noting that the profile should not be in use or default, but 'unused' already implies the key constraint.
Complex tools with many parameters or behaviors need more documentation. Simple tools need 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 single whoisId parameter is already described as 'WHOIS ID'. The description adds no parameter-level detail, but none is required given the schema's complete 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 'Delete WHOIS contact profile,' a specific verb plus resource, and the second sentence reinforces the exact operation ('remove unused contact profiles from account'). This unambiguously separates it from the get/create/change/set-default 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?
'Use this endpoint to remove unused contact profiles from account' gives a clear condition for when to call it. It does not explicitly name alternatives or exclusions (e.g., don't delete a profile in use/default), so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, covering the safety profile. The description adds minimal context by noting 'current redirect configuration,' but it does not elaborate on response format, pagination, or other behavioral traits. This aligns with the calibration example where annotation-covered safety yields a baseline score of 3.
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 short and front-loaded, with the core action in the first sentence and usage context in the second. The first sentence is somewhat redundant with the title 'Get domain forwarding,' but the overall size is efficient and free of clutter.
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, read-only GET-style tool with annotations covering safety, the description is sufficient. It states what the endpoint does and when to use it, and the schema defines the only parameter. Nothing essential for an agent to invoke the tool correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the single 'domain' parameter is documented in the schema. The tool description does not add additional parameter semantics, which matches the baseline of 3 when structured schema fields carry the explanatory burden.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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 and objects: 'Retrieve domain forwarding data' and 'view current redirect configuration for domains.' This clearly identifies the operation as read-only and distinguishes it from sibling tools like domains_createDomainForwardingV1, domains_updateDomainForwardingV1, and domains_deleteDomainForwardingV1.
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 tool's usage context: 'Use this endpoint to view current redirect configuration for domains.' It does not mention when not to use it or explicitly name alternatives, but the intent is clear for an agent needing to inspect forwarding configuration.
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?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds that the response includes status and expiration date, but does not disclose error behavior, domain existence requirements, or whether the renewal status has particular semantics beyond that.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Exactly two sentences: the first states the core operation and output, the second states the intended use case. There is no filler, 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?
For a one-parameter, read-only retrieval tool with no output schema, the description is nearly complete. It names the important output fields and the purpose. It could be improved by noting that the domain must belong to the account or enumerating possible status values, but these are not blocking.
Complex tools with many parameters or behaviors need more documentation. Simple tools need 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 only parameter 'domain' is described as 'Domain name'. The description does not add format, validation, or ownership nuances 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 a specific action verb ('Retrieve') plus a specific resource ('renewal information for a specified domain') and lists key output fields ('status and current expiration date'). This clearly distinguishes it from domain listing, forwarding, and billing 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 second sentence explicitly states the intended use case ('build renewal automation and expiry monitoring') and scopes it to a single domain. It does not name alternatives such as domains_getDomainDetailsV1 or billing_enableAutoRenewalV1, but the provided use-case 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, covering the safety profile. The description adds meaningful behavioral context by disclosing the 404 behavior when no move is in progress, which agents would not otherwise know. This is valuable beyond the 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 compact and efficient: one sentence states the core action, one discloses the 404 edge case, and one gives usage guidance. Every sentence earns its place, and the most important 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?
For a single-parameter read-only endpoint with clear annotations, the description is largely complete: it explains the purpose, the 404 case, and the intended use. There is no output schema, and the description does not describe the response body or possible move statuses, but this is a minor gap given the low complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already fully documents the single 'domain' parameter. The description reinforces that the domain is singular and specific but adds no format, example, or additional semantic detail. Baseline 3 is appropriate given the high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Retrieve the outgoing move') and the resource ('for a specified domain'), and the phrase 'single domain' distinguishes it from list-style endpoints. It accurately reflects the tool's function, though it does not explicitly name sibling endpoints like the incoming move or move-list variants.
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 endpoint to track the status of a move you have initiated for a single domain.' This tells the agent when the tool is appropriate. It does not explicitly state when not to use it or name alternatives, so it falls just short of 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?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds useful scope information about portfolio-wide incoming/outgoing transfers, but it does not disclose return format, pagination, status fields, or other behavioral details that an agent might need when processing the 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 with no redundancy. The core action is front-loaded in the first sentence, and the second sentence adds a clear use case without wasting 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 zero-parameter, read-only list endpoint, the description is sufficiently complete. It names the resource, the portfolio scope, and the incoming/outgoing coverage, while the annotations cover the read-only and non-destructive behavior. No additional context is necessary for an agent to invoke this 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?
The input schema has zero parameters and schema description coverage is 100%, so there is no parameter burden for the description. The baseline for a zero-parameter tool is 4; the description provides all the context needed without needing to explain individual parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Retrieve all domain transfers') and the resource scope ('your portfolio'). It also clarifies that the transfer list covers both incoming and outgoing registrar transfers, which helps distinguish it from single-transfer endpoints. However, it does not explicitly differentiate itself from closely related sibling tools like domains_getTransferV1 or the incoming/outgoing move list endpoints.
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 gives a direct usage context: 'Use this endpoint to monitor incoming and outgoing registrar transfers across your domains.' This tells an agent when the endpoint is appropriate, though it stops short of naming alternatives or stating 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?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the agent knows this is a safe read. The description adds minimal behavioral context—it does not describe pagination, return format, or any side effects. Given the annotations cover the safety profile, a baseline 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?
Two concise sentences with no fluff. The first sentence states the action and result; the second reinforces the purpose. The main operation is front-loaded, making it easy for the agent to parse quickly.
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 one well-documented parameter and annotations promoting safety, the description is largely complete. It does not specify the exact output structure, but given the simplicity and the lack of an output schema, it is sufficient for an agent to understand the tool's purpose without missing critical information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the single parameter 'whoisId', which is described as 'WHOIS ID'. The description does not add any additional meaning or usage details beyond what the schema already provides, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Retrieve') and resource ('domain list') with a clear filter ('where provided WHOIS contact profile is used'). It distinguishes from related sibling tools like domains_getWHOISProfileListV1 (which lists profiles) and domains_getDomainListV1 (which lists all domains) by narrowing to domains using 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear usage context: 'Use this endpoint to view which domains use specific contact profiles.' This tells the agent when to invoke it. However, it does not explicitly name alternative tools or state when not to use it, so it falls short of the highest bar for explicit routing.
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?
Annotations already declare readOnlyHint=false and destructiveHint=false, so the write nature is known. The description adds context about the two channel types (headless vs hosted) but doesn't disclose side effects, return values, or prerequisites beyond that. With annotations covering the basic safety profile, the description provides modest 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 concise sentences with no fluff. It front-loads the primary action and then efficiently explains the two type options, making it easy to parse and use.
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 fully described schema and the clarification of the two types, the description is sufficient for an agent to call the tool correctly. It doesn't explicitly mention the auto-generated handle for quick-link or the return format, but these are not critical for invocation and the overall context is complete enough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and the schema already details when `name` and `url` are required or unsupported for each type. The description restates the type semantics but adds no new parameter-specific information beyond what the schema provides, so it meets the baseline but doesn't exceed 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 creates a sales channel for a store, and explains the two channel types (custom and quick-link), distinguishing it from sibling tools like list or update. The verb 'create' is explicit, and the resource 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 explains when to use each channel type (custom for headless, quick-link for hosted one-page store), which guides the agent in choosing the right `type`. It doesn't explicitly contrast with alternatives like ecommerce_listSalesChannelsV1 or ecommerce_updateSalesChannelV1, but the context is sufficient for correct 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?
Beyond the annotations declaring a non-read-only, non-destructive operation, the description adds valuable behavioral context: the product is immediately published and has exactly one variant. It also clarifies that the download link is external and optional, which is not obvious from the schema alone.
Agents need to know what a tool does to the world before 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 tightly worded sentence front-loads the core action and the key state constraints. There is no filler, no restating of the schema, and no 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?
For a simple create tool with flat parameters, no enums, and no output schema, the description includes the key contextual facts: the product is published and single-variant. It does not describe the response or returned product ID, which would be useful without an output schema, but this is not required to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already documents 100% of the parameters with clear descriptions, so the baseline applies. The description adds little parameter detail beyond confirming the optional nature of download_url, which is already evident 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?
States exactly what the tool does: creates a digital product that is published, single-variant, and optionally has an external download link. This clearly distinguishes it from sibling tools like ecommerce_createPhysicalProductV1 and variant-management tools without needing to inspect the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the use case: digital, single-variant product creation. However, it does not explicitly mention alternatives or when to prefer the physical-product, product-update, or multi-variant creation siblings, so the agent must infer routing from the wording.
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?
Annotations already mark the operation as destructive, and the description adds valuable behavioral nuance: it deletes variants as well, and subscription products with active subscribers are archived instead of deleted. This goes beyond the basic destructive flag and helps the agent anticipate 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 convey the core action and an important exception without extra filler. The most important 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?
For a two-parameter delete operation with no output schema, the description covers the key behavior, the variant side effect, and the subscription archive exception. It is complete enough for an agent to call the tool correctly, though it could have explicitly mentioned idempotency behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and both parameters are already described clearly in the schema. The description does not add new meaning to the parameters, but the schema fully carries that burden.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Delete'), the resource ('a product'), and the scope ('and its variants from the store'). It also distinguishes itself from the sibling variant-level delete tool by explicitly including variants.
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 removing a product and its variants, but it does not explicitly state when to choose this over related tools such as ecommerce_deleteAProductVariantV1 or ecommerce_updateAProductV1. It does provide a conditional exception for subscription products with active subscribers, which offers some usage-relevant 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?
Beyond the annotations, the description adds important behavioral context: omitting items fulfils every remaining unfulfilled item, and tracking is attached in the same call. It also states the return value ('updated order summary'), which matters because no output schema is present. The write action aligns with readOnlyHint=false, so there is no contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences with no filler: the core action is front-loaded, followed by the key default behavior and return information. 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 6-parameter tool with no output schema, the description adequately covers the main default, the combined action, and the return value. Remaining details like tracking_url requiring tracking_number are already fully documented in the schema, so there is no critical gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all six parameters. The description mostly restates the items default behavior already present in the schema and adds little new parameter-level meaning beyond 'attach tracking.'
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names the specific verb and resource: 'Create a fulfilment for the order' and adds the compound capability 'and attach tracking in one call.' This clearly distinguishes it from sibling tools like ecommerce_cancelAnOrderV1 and ecommerce_retrieveAnOrderV1.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool: when an order needs fulfilling, optionally with tracking attached. However, it does not explicitly contrast with sibling order tools or state when not to use it, leaving some alternative-selection to inference.
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?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds useful behavioral context: variants are ordered by rank, and prices are integers in the smallest currency unit and live on variants rather than on the product. This goes beyond the annotations without contradicting them.
Agents need to know what a tool does to the world before 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 focused sentences with no filler. The primary action, ordering, and included fields are front-loaded, and the price-unit clarification follows naturally.
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?
Even without an output schema, the description states the essential returned content (variants, options, prices, inventory), the ordering, and the price unit. Combined with full parameter documentation and read-only annotations, this is largely sufficient; adding explicit pagination behavior would make it fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so store_id, product_id, and page are already documented. The description does not add much parameter-specific detail beyond reaffirming that the target is a product's variants and explaining how prices are represented, which is more relevant to the response than to the parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and resource ('a product's variants') and adds a distinctive ordering assertion ('ordered by rank') plus the included fields. It is immediately distinguishable from sibling ecommerce tools such as ecommerce_listProductsV1 and ecommerce_createAProductVariantV1.
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—when the agent needs a product's variants—but it does not explicitly mention alternatives, prerequisites, or when not to use it. There is no reference to related tools like ecommerce_listProductsV1 for finding product IDs or ecommerce_updateProductVariantsInBatchV1 for edits.
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?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds that it lists 'active' channels with 'full metadata,' but doesn't disclose pagination, ordering, or other behavioral details. Given annotation coverage, this is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence with no wasted words. It clearly states the action, target, and scope in minimal space.
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 annotations covering safety, the description is mostly complete. It clearly states the resource and scope, but could mention what constitutes 'active' or return format pagination. Still, it covers the essential information an agent needs to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter (store_id) is fully described in the schema with 100% coverage, so the schema carries the meaning. The description adds no additional parameter-level detail beyond what the schema provides, aligning with the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('List'), resource ('sales channels'), and scope ('a store's active sales channels'), clearly distinguishing it from sibling tools like create/update sales channels. The inclusion of 'full metadata' clarifies what the tool returns.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly indicates when to use the tool (to retrieve active sales channels for a store), but does not explicitly compare to alternatives or mention when not to use it. Since there are no sibling list tools for sales channels, the usage context is implicit but not 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?
The description goes beyond the annotations by disclosing a meaningful side effect: it will create the shipping zone if it does not yet exist. This helps the agent understand the operation is not purely a direct update, even though the annotations already correctly indicate it is mutating and not destructive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. It states the primary action first and then adds the important side effect, making efficient use of the space.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter mutation with complete schema descriptions and correct annotations, the description covers the core behavior and the key side effect. It does not explain expected response or return value, but that omission is minor given the tool's simplicity and absence of an 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?
Schema description coverage is 100%, so the schema already clearly documents both parameters, including price expressed in the smallest currency unit with 0 for free shipping. The description adds no extra parameter-level semantics beyond restating that the price is flat-rate and tied to a store.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb ('Set'), resource ('flat-rate shipping price'), and scope ('for a store'), and even adds the side-effect that the shipping zone will be created if absent. This makes the tool's purpose clear and unique among the otherwise broad sibling list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool—when setting or changing flat-rate store shipping—but provides no explicit when-to-use or when-not-to-use guidance, nor any named alternatives. The context is adequate but the usage conditions are left to inference.
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?
Annotations already indicate readOnlyHint=false and destructiveHint=false, so the mutation is expected. The description adds useful context that the created cron job is returned with its uid, and that this uid is needed for deletion and fetching output. It does not disclose potential side effects, permission requirements, or failure modes, but with the annotation coverage this is acceptable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no fluff. The primary purpose is front-loaded, and the return-value note is concise and directly relevant. 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 there is no output schema, the description appropriately explains the return value and highlights the uid's downstream necessity. Inputs are fully covered by the schema, and the account-level scope is clear. It is complete enough for a simple create operation, though it could have included an explicit pointer to list/delete siblings for fuller context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description does not add parameter-level meaning beyond what the schema already provides; it simply restates that a schedule expression and command are used. The username parameter is thinly described in the schema as 'username parameter' and the description does not 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 uses a specific verb and resource: 'Creates a cron job for the specified account from a schedule expression and a command.' This clearly distinguishes it from sibling tools like hosting_listAccountCronJobsV1, hosting_deleteAccountCronJobV1, and hosting_getCronJobOutputV1. It also specifies the key input types and the primary output.
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 a new account-level cron job needs to be created. It also states that the returned uid is required to delete the cron job or fetch its output, indirectly linking to sibling tools. However, it does not explicitly name alternatives or state when not to use it, so it stops 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true and idempotentHint=true, so the description need not repeat these. It adds the phrasing 'permanently removes' and 'revoking', reinforcing the destructive nature but not providing much additional behavioral context beyond annotations. There is no contradiction with the 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 two sentences, front-loading the action and following with critical parameter identification. Every sentence serves a purpose—first stating what it does, then how to identify the rule. No wasted words, and the structure is clean.
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 required parameters and no output schema, the description covers the essential invocation details: how to identify the rule and which values to use for ip and name. However, it does not explain the 'username' parameter beyond the schema's generic description, nor does it address potential error cases or response behavior. For a simple delete operation, this is sufficient, but a bit more on username would make it fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with each parameter fully described. The tool description essentially repeats the schema's guidance about using exact values from list endpoints without adding new meaning. Since the schema already documents parameters, baseline 3 is appropriate as no extra insight 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 action (permanently removes a remote-access rule) and the resource (database remote connection), explicitly distinguishing it from create/list siblings by saying 'removes'. It also describes the effect (revoking host's remote access), leaving no ambiguity about what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides concrete usage instructions: the ip must be exactly as returned by the list remote connections endpoint and the name must be the full name from list databases. This helps the agent call it correctly. However, it does not explicitly mention when to use this tool versus creating or listing connections, though the destructive purpose makes the choice evident.
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?
Annotations already declare destructiveHint=true and readOnlyHint=false, so the description does not need to restate mutation. It adds a useful 'existing' precondition and clarifies the parked/alias domain scope, but provides little behavioral context beyond that.
Agents need to know what a tool does to the world before calling it. Descriptions 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 with the key action front-loaded. The second sentence slightly restates the action but adds the use-case rationale, so 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 destructive operation with three fully required parameters and annotations covering destructive/idempotent/read-only behavior, the description is sufficient for selection and invocation. It does not describe response shape, but that is a minor gap for a delete 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%, but the schema parameter descriptions are tautological ('username parameter', 'parkedDomain parameter'). The description does not meaningfully clarify the parameters beyond implying domain selects the website and parkedDomain is the parked/alias domain, so it stays at the baseline 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 ('Delete') and a specific resource ('existing parked or alias domain from the selected website'). It clearly distinguishes this from create/list parked-domain tools and from deleting subdomains or redirects.
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 explicitly states when to use this endpoint: to remove parked domains that are no longer needed. It does not explicitly name alternatives or exclusions, but the intended use case 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?
Annotations provide readOnlyHint=false and destructiveHint=false, which offer minimal safety context. The description discloses the outputs (url, auth_key, rest_auth_key) and the intended upload flow, but does not state whether generating the URL has any side effects (e.g., creating a session or consuming quota). It implies a non-destructive operation but does not explicitly say so.
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 lengthy but well-organized: it starts with the return values and core purpose, then gives numbered steps and a concrete curl example. Every section contributes value, and the structure makes the long content easy to scan. The detail is justified by the need to explain the TUS protocol.
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?
With no output schema, the description fully covers return values and usage: it explains what to do with url, auth_key, and rest_auth_key, provides headers, expected status codes, and both TUS-client and curl workflows. The examples are complete and actionable, leaving no obvious gaps for an agent to call 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?
Input schema covers both parameters (domain and username) with 100% coverage, giving each a basic description. The tool description does not add further meaning about these parameters beyond integrating them into the upload context (e.g., 'relative_file_path' is not a parameter). Baseline of 3 applies given schema coverage; description adds minimal 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 states a specific verb ('Generate') and resource ('file browser upload URL') and explains its purpose: 'for uploading files directly to a website's file storage.' It clearly distinguishes itself from the many deployment and hosting tools in the sibling list by focusing on URL generation rather than file transfer or site management.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit step-by-step instructions on how to use the returned URL and credentials, including the TUS protocol workflow and a plain curl alternative. It does not explicitly discuss when to avoid this tool or name alternatives, but within the sibling set there is no direct equivalent (except agency-hosting_generateUploadURLV1, which is distinct by namespace), so context is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is established. The description adds useful scope: only the last execution's captured output is returned, not arbitrary executions, and uid is the lookup key. This is consistent with annotations, though it doesn't detail output format or edge cases, which is acceptable for a simple read.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences with no wasted words. The core behavior is front-loaded, and the helpful pointer to the list cron jobs endpoint is kept brief.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only retrieval tool with two documented required parameters and no output schema, the description is nearly sufficient: it states what is returned, the lookup key, and how to obtain the key. The only real gap is the unhelpful schema note 'username parameter' and the lack of description-level context for what username refers to, so an agent may need surrounding context to know which username to pass.
Complex tools with many parameters or behaviors need more documentation. Simple tools 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, uid and username, are fully described in the schema, giving 100% schema description coverage. The description correctly points out that uid is the cron job identifier and comes from the list cron jobs endpoint, but this largely duplicates the schema. It adds no meaningful explanation for username, so the baseline of 3 is appropriate since the schema carries most of the load.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource: returns the captured output from the last execution of a cron job identified by uid. The wording makes clear this is a retrieval operation and distinguishes it from sibling cron job create/list/delete tools. Minor omission: no explanation of the role of username, but the resource and behavior are unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The second sentence directs the caller to the list cron jobs endpoint for obtaining the required uid, which is actionable input guidance. It doesn't explicitly discuss when or when not to use this tool versus alternatives, but no direct sibling offers cron job output, so the implied usage context is sufficient. Could be more explicit about the need for username, 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?
The annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds valuable behavioral detail about the response scope, including supported and unsupported versions, extension conflict groups, and plan limits, which goes beyond the 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 front-loaded with the primary action and return content, and the usage guidance is in a separate concise sentence. Despite the long first sentence, every listed item adds value and the structure is 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?
For a read-only details tool with no output schema, the description covers the main return categories and gives context before update operations. It does not describe the response format or error behavior, but given the simple two-parameter input and read-only annotations, this 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 description coverage is 100%, so the baseline is 3. The description does not add parameter-level meaning beyond the schema; 'domain' and 'username' are only minimally described in the schema, and the description itself does not clarify how they identify the website.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb and resource: 'Returns the full PHP configuration for the website' and enumerates the exact data included (versions, extensions, options, plan limits, conflicting groups). It is not a tautology, but it does not explicitly differentiate from the similar sibling hosting_getPHPInfoV1, so the distinction is implied rather than stated.
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 usage context: 'Use it to check the current PHP setup before updating the version, extensions or options.' This tells the agent when the tool is appropriate, but it does not mention when not to use it or provide alternative 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?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds useful behavioral context about capacity-based filtering and the first item being the best match, but it does not disclose pagination behavior or response structure. This is adequate but not richly transparent beyond 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 compact: two sentences, no filler, and the main purpose is front-loaded. The second sentence adds an important ordering guarantee without extra verbosity. Every phrase contributes to call-time decision-making.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter, read-only list tool without an output schema, the description covers purpose, scoping, and result ordering well. It could slightly improve by mentioning expected result fields or pagination, but the current information is sufficient for correct invocation in most cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the single required parameter order_id is already described as 'Order ID'. The tool description does not add deeper semantics about the parameter, but there is little ambiguity to resolve given the simple schema and clear overall 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 uses a specific verb-resource pair ('Retrieve a list of datacenters') and immediately scopes it to hosting-plan setup for a specific order, distinguishing it from generic datacenter-listing tools. The clarity is further strengthened by mentioning capacity and order-based planning criteria.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies when to use the tool: when selecting or evaluating datacenters for a hosting plan tied to an order. It does not explicitly name alternative tools or exclusion cases, but the context is strong enough that an agent can infer the intended 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?
Annotations already declare readOnlyHint=true and destructiveHint=false, covering the safety profile. The description adds the 'not yet installed' scoping condition, but provides no detail about return shape, pagination, or ordering, which is acceptable but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded: the first sentence states the purpose, and the second provides the essential parameter guidance. There is no redundant or filler 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 read-only list tool, the description covers the critical parameter and the scope. The main minor gap is that username semantics are left vague, and no output format is described, but output schema absence is not a major issue for a straightforward listing 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 the baseline is 3. The description does add a useful retrieval source for the software identifier, but the username parameter remains only described as 'username parameter' in the schema and is not meaningfully enriched.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid 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 plugins recommended for installation that are not yet installed, pinning down the exact resource and scope. This distinguishes it from the many WordPress-related siblings such as listInstalled, search, and deploy 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 gives concrete guidance on how to obtain the required software identifier and says it goes in the path. It does not explicitly name when to prefer this over sibling tools like listSuggestedWordPressPluginsV1, so it falls just short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already communicate readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds useful behavioral detail about what constitutes a remote host, including IPv4/IPv6 and '%' wildcard. It does not mention pagination or default behavior when domain is omitted, but nothing contradicts the 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 two sentences long, front-loads the core purpose, and includes the filter usage without unnecessary filler. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only listing tool with only two well-documented parameters, the description gives enough context: what is returned, what the values mean, and how to narrow by domain. There is no output schema, but the description adequately conveys the return concept even if it does not specify the exact response shape.
Complex tools with many parameters or behaviors need more documentation. Simple tools need 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 reinforces the domain filter's meaning and gives the '%' wildcard context, adding slight value. The username parameter, however, is only described as 'username parameter' in both schema and description, so it adds no real 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 states a specific action and resource: 'Returns the remote-access rules for the specified account' and clarifies these are the remote hosts allowed to connect. It clearly distinguishes this from sibling tools like create/delete remote connection and database-listing 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 gives clear context for when to use the tool and specifically instructs how to use the domain filter to narrow results to a particular domain. It does not explicitly name alternative tools or exclusion cases, but the usage 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds meaningful behavioral context by disclosing that results include plugin status, available updates, and known vulnerabilities, which helps an agent set expectations about the returned data.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two well-structured sentences with no fluff. The core purpose is front-loaded, followed immediately by the most important operational detail: how to obtain the required identifier.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a straightforward read-only listing operation, the description covers the operation, key output aspects, and how to source the required path identifier. It does not specify response shape, but there is no output schema and the coverage is reasonable for an agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds useful context for the 'software' parameter by explaining it is the WordPress installation identifier and where to find it, but it does not clarify the purpose of 'username' beyond the schema's generic 'username parameter' text.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('List'), a specific resource ('plugins installed on a WordPress installation'), and the content returned (status, updates, vulnerabilities). The word 'installed' distinguishes it from sibling tools like hosting_listAvailableWordPressPluginsV1 and hosting_searchWordPressPluginsV1.
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 concrete how-to for obtaining the required software identifier, which is useful operational guidance. However, it does not explicitly say when to choose this tool over related plugin listing tools such as listAvailable, listSuggested, or search, nor does it state 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?
Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is clear. The description adds that results are grouped by website type and that slugs are meant for installation, which is useful context, but it does not disclose response format, pagination, or scoping behavior beyond what annotations cover.
Agents need to know what a tool does to the world before 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. The main purpose is front-loaded, and the installation hint is a relevant, actionable follow-up.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only listing tool with one optional parameter and safety annotations, the description is mostly complete: it states what the tool returns, how results are grouped, and how to use the output. It could be more complete by naming sibling alternatives or describing the response structure, but nothing essential for calling it is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter, order_id, is fully described in the schema as an optional scope. The description does not add additional meaning about parameters, but with 100% schema coverage, the schema carries the documentation burden adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'List curated plugin suggestions grouped by website type.' The word 'suggested' clearly differentiates this from sibling tools like hosting_listAvailableWordPressPluginsV1, hosting_searchWordPressPluginsV1, and hosting_listInstalledWordPressPluginsV1.
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 downstream context by instructing to use returned slug values with the install endpoint, which tells the agent how to act on results. However, it does not explicitly state when to choose this tool over sibling listing/search 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?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the description does not need to repeat that. The description adds value by specifying that the response includes parent domain and root directory per parked domain, which is not revealed in the annotations or schema. However, it doesn't discuss pagination, response format, or error conditions, which would enrich behavioral insight. With annotations covering safety, this is a solid 3.
Agents need to know what a tool does to the world before 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. The primary action is front-loaded in the first sentence, and the second adds a usage note and clarifies the returned data. 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?
For a simple read-only list operation with two fully described parameters and no output schema, the description covers what the tool does and what information it returns. Missing are potential limitations (e.g., pagination, maximum results) but these are not critical for a basic list call. Given the low complexity and good annotation coverage, this 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 description coverage is 100%: both required parameters ('username' and 'domain') have descriptions. The tool description adds context that the operation is for a 'selected website' and 'specific website,' which clarifies that 'domain' likely refers to the website's domain, but it does not provide additional parameter-specific guidance beyond the schema. Baseline of 3 is appropriate since 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?
The description clearly states the operation ('Retrieve all parked or alias domains') and the resource ('under the selected website'), and specifies that it returns 'the parent domain and root directory assigned to each parked domain.' This distinguishes it from sibling tools like hosting_createWebsiteParkedDomainV1 or hosting_listWebsiteSubdomainsV1 by focusing specifically on parked 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 second sentence, 'Use this endpoint to inspect parked domain configuration for a specific website,' provides clear usage context and implies this is the read-only inspection counterpart to the create/delete parked-domain tools. It does not explicitly mention when NOT to use it (e.g., for creating or deleting) but given the tool name and the description, the intent is unambiguous.
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?
Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds useful behavior beyond that: it retrieves all subdomains and states the returned information includes parent domain and root directory. There is no contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with the main action front-loaded in the first sentence. The second sentence adds relevant return-value context without excessive detail or 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?
For a simple read-only list tool with no output schema, the description covers the operation and mentions key return fields. However, it leaves ambiguity around the 'username' and 'domain' parameters and does not fully specify the response shape or edge cases like an empty subdomain list.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description does not clarify parameter semantics further; 'domain' is described only as 'Domain name' and 'username' as 'username parameter', which is weak, but the description at least frames the operation as targeting a specific website.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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: 'Retrieve all subdomains created under the selected website.' It clearly identifies what the tool returns and is distinct from siblings like hosting_createWebsiteSubdomainV1 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 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: 'Use this endpoint to inspect subdomain configuration for a specific website.' It does not explicitly name alternatives or exclusion cases, but the inspect/list framing implies that modification tools should be used for creating or deleting subdomains.
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?
Annotations already declare destructiveHint=true and idempotentHint=true. The description adds context about what the reset entails (default state) and when to use it, but does not disclose additional behavioral traits such as irreversibility, permissions, or scope beyond 'all extensions'. With annotations covering the safety profile, 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?
Two sentences with zero fluff. The primary action is stated first, followed by the use-case rationale. Everything earns its place and is 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?
The tool is simple (2 parameters, no output schema). Annotations provide the destructive/idempotent profile, and the description adds the purpose and use case. No critical information is missing for an agent to decide when to call it, though it could mention sibling tools or limitations (e.g., what happens to currently active extensions).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for both parameters (domain and username), each with a basic description. The tool description does not add any additional meaning or syntax details for parameters, 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 ('Resets'), the resource ('all PHP extensions'), and the outcome ('to their default state'). This uniquely identifies the tool's purpose and distinguishes it from tools that update or list extensions.
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 when to use: 'recover from extension conflicts or restore the original configuration'. It doesn't contrast with alternatives like hosting_updatePHPExtensionsV1, but the context implies it's for resetting to default rather than updating to custom values.
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?
Annotations already cover the safety profile with readOnlyHint=true and destructiveHint=false. The description adds useful behavioral scope: it searches an external WordPress.org directory and returns slug values for later installation. It does not mention pagination, result limits, or response format beyond the slug usage, so the added transparency is moderate.
Agents need to know what a tool does to the world before 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 focused sentences: the first states the purpose, the second explains how to use the result. 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?
For a simple read-only search with one documented parameter, the description is largely complete. It clarifies the external source, the purpose, and the next step using slug values. It could add the result shape or pagination details, but the absence is not critical for invoking 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 fully documents the single `search` parameter, including that it must be at least 3 characters. The description does not add parameter-level detail beyond this, so the schema carries the semantic weight.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action and resource: searching the WordPress.org plugin directory for plugins available to install. This distinguishes it from related listing tools like listInstalledWordPressPluginsV1 or listSuggestedWordPressPluginsV1.
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 by specifying the external directory and the install-centered purpose, and it tells the agent to use the returned slug values with the install endpoint. However, it does not explicitly contrast itself with sibling tools such as listAvailableWordPressPluginsV1 or listInstalledWordPressPluginsV1.
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?
Annotations already convey that the operation is non-read-only, idempotent, and destructive. The description aligns with those annotations and clarifies that the enabled flag drives activation versus deactivation, but it adds no additional behavioral context such as side effects, cache flushing, or prerequisites beyond identifying the installation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no filler. The first sentence states the action and condition, and the second provides the critical lookup path for the required identifier. 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 three-parameter toggle, the description covers the action, the controlling flag, and where to find the main identifier. It does not describe the expected response or error cases, but given the tool's simplicity and the idempotent/destructive annotations, this is a minor gap rather than a blocking one.
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 three parameters, so the baseline is 3. The description adds meaningful value for the software parameter by pointing to the exact GET endpoint and field from which its value can be obtained. However, the username parameter remains only described as 'username parameter', adding no real semantic depth.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action (activate or deactivate) on a specific resource (Memcached object cache for a WordPress installation), controlled by the enabled flag. This clearly distinguishes it from status-only tools like hosting_showMemcachedObjectCacheStatusV1 and other cache toggles.
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 useful guidance on how to obtain the software identifier via the installations endpoint and where to provide it. However, it does not explicitly explain when to use this tool versus alternatives such as checking the current cache status first, or choosing between Memcached, cacheless mode, or website cache toggling.
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 annotations already declare the operation destructive and non-read-only, so the description's main value is adding the asynchronous behavior: a successful response only means the uninstall job is queued. This is important runtime context beyond the annotations, though it does not explain how to track job completion 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?
The description is compact and front-loaded: the first sentence states the core action, the second provides essential path/identifier guidance, and the third discloses async behavior. Every sentence contributes meaningful information without repetition 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 destructive tool with three well-schematized parameters, the description covers the essential operational details: what it does, how to identify the installation, and the asynchronous response behavior. It does not describe the response payload or how to follow up on the queued job, but no output schema exists to fill that gap, making the description 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?
The input schema already describes all three parameters, so the description adds no new semantics for 'themes' or 'username'. It does add useful context for 'software' by explaining the identifier is in the path and how to obtain it, but 'username' remains only superficially described as '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 states a specific verb ('Uninstall') and resource ('one or more themes from a WordPress installation'), making the tool's function immediately clear. The tool name and title reinforce the same purpose, and the description distinguishes it from sibling tools like install/activate/update theme operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies when to use it—when installed themes need to be removed from a WordPress installation—but does not explicitly contrast it with alternatives such as install, activate, or update theme tools. It includes helpful guidance on obtaining the software identifier from a GET endpoint, but lacks explicit exclusions like 'do not use for active themes'.
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?
Annotations already indicate readOnlyHint=false and destructiveHint=false. The description adds valuable behavioral context by stating that the operation is asynchronous and that a successful response only means the update job has been queued, preventing the agent from treating success as completion.
Agents need to know what a tool does to the world before calling it. Descriptions 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: purpose first, then installation identifier lookup, then the asynchronous caveat. Every sentence contributes a distinct fact needed to invoke the tool correctly, with 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?
For a low-complexity operation with a fully covered schema and no output schema, the description covers the core invocation details: what to update, how to identify the installation, and how to interpret a successful response. It could optionally explain how to check job completion, but the essential context 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?
Schema coverage is 100%, so the baseline is 3. The description adds meaningful value for the 'software' parameter by pointing to GET /api/hosting/v1/wordpress/installations and the 'id' field to obtain the identifier. It does not add extra semantics for 'themes' or 'username', but those are already clearly described 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 immediately states the specific action: 'Update one or more installed themes to their latest version on a WordPress installation.' This clearly identifies the verb, resource, and scope, and distinguishes it from sibling tools for installing, activating, listing, or uninstalling themes, as well as from WordPress core/plugin 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?
The description gives no guidance about when to use this tool versus alternatives such as hosting_installWordPressThemeV1, hosting_activateWordPressThemeV1, or hosting_updateWordPressPluginsV1. It only explains how to obtain the software identifier, which is parameter acquisition rather than usage 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?
Annotations already indicate this is a mutating operation (readOnly=false). The description adds a non-obvious consequence: the destination must confirm before forwarding activates, so the agent knows not to expect immediate effect. It also explains the side-effect email to the destination address, going 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?
Two sentences, no redundant or promotional language. The core action and the critical side effect are both 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 three-parameter creation tool, the description covers the action, the two required inputs, and the confirmation delay that affects expected outcomes. It does not describe the response format or how to resend the confirmation email, but those are less critical for correct invocation given the rich schema and sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema already documents mailboxId, destination, and is_keep_copy_enabled with full coverage, so the description only needs to reinforce the key inputs. It maps 'given mailbox' to mailboxId and 'destination address' to destination, but does not add meaning for is_keep_copy_enabled; that is acceptable because the schema 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 names a specific verb ('Create'), a specific resource ('forwarder'), and the source-destination relationship, so it is immediately clear what the operation does. The added confirmation detail differentiates this creation flow from list/update/delete forwarder 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 establishes when the tool is applicable (setting up forwarding from a mailbox), but it does not explicitly state when to prefer it over mail_createAliasV1 or mail_updateForwarderKeepCopySettingV1, nor does it mention that resending confirmation is handled by a sibling. The guidance is therefore implied rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
It adds a valuable behavioral caveat beyond the annotations: the generated secret is returned only once and is sent as a bearer token with each delivery. This tells the agent an important consequence of the operation. With readOnlyHint=false and destructiveHint=false, the description clarifies the mutation's security-relevant side effect without contradiction.
Agents need to know what a tool does to the world before 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 filler. The main action is stated first, and the critical one-time-secret warning is placed immediately after, giving the agent the most important operational detail up front.
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 complete parameter documentation and an annotated mutation profile, the description covers the essential runtime behavior and the key response detail (one-time secret). It does not describe error conditions or idempotency, but those are not necessary for basic correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the parameters are already well documented. The description adds no parameter-level detail beyond tying the webhook to a mailbox, which matches the baseline for complete 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 names a direct action and target: 'Create a webhook for the given mailbox.' This clearly distinguishes it from sibling mail webhook tools such as get, update, delete, list, regenerate, and test, so an agent can select it without ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description makes the basic use case clear—creating a webhook for a mailbox—but does not state when to prefer this over the related webhook management tools, nor mention any exclusions or prerequisites. Usage is implied by the verb 'create' but no explicit routing to alternatives is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark this as destructive and idempotent. The description adds useful context beyond annotations by explicitly stating the behavioral effect: 'Messages sent to the alias address are no longer delivered to the mailbox.' This tells the agent what consequence to expect.
Agents need to know what a tool does to the world before 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 action, and no filler. The second sentence adds a meaningful consequence 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 destructive operation, the description is largely sufficient. It does not mention return values or error behavior, but given the idempotent and destructive annotations and the lack of an output schema, 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% with the only parameter, aliasId, described as 'Alias resource ID.' The description does not add further meaning or usage detail for the parameter, so it stays at the baseline for fully covered schemas.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Delete') and resource ('an alias'), and adds the concrete consequence that messages to the alias are no longer delivered. This clearly distinguishes it from sibling tools like mail_createAliasV1 and 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 purpose implies when to use it—when an alias should be removed—but it does not explicitly name alternatives or conditions, such as the difference from mail_deleteMailboxV1. Usage context is implied rather than directly stated.
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?
Annotations already declare destructiveHint=true and idempotentHint=true, so the description adds the behavioral effect (message routing ceases). It goes beyond the annotations by explaining the consequence of deletion, which is useful context for an agent considering this 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 short sentences with zero waste. The action is front-loaded in the first sentence, and the second sentence provides the key consequence. There is no redundant or filler 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 single-parameter delete operation with annotations covering safety and idempotency, the description is complete. It explains the operational effect, which is the main missing context. No output schema is expected. Could mention confirmation or reversibility, but given the low complexity, 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 coverage is 100% and the only parameter, catchallId, is described as 'Catch-all resource ID'. The tool description does not add further meaning, such as how to obtain the ID or format context, but with a single simple parameter the schema is sufficient. 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?
States a specific verb and resource: 'Delete a catch-all', and clarifies the consequence: 'Messages sent to unknown addresses of the domain are no longer routed to the mailbox.' This clearly distinguishes from mail_createCatchAllV1 and mail_listCatchAllsV1.
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 it (to stop routing unknown-address messages) but does not explicitly state prerequisites or contrast with alternatives. No mention of needing an existing catch-all or when not to use it, so the agent must infer from the name and the effect.
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?
Annotations already declare destructiveHint=true, readOnlyHint=false, and idempotentHint=true. The description adds valuable context beyond these: the mailbox is soft-deleted, restorable for a limited period, then permanently removed. This meaningfully informs an agent's risk assessment, though it omits specifics like the restore window length or effects on dependent resources (aliases, forwarders).
Agents need to know what a tool does to the world before 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 zero waste. The core action is front-loaded ('Delete a mailbox') and the critical behavioral nuance follows immediately. 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?
For a simple one-parameter tool with annotations covering safety and idempotency, and a fully documented schema, the description is nearly complete. It discloses the essential soft-delete behavior an agent needs before calling. The only gaps are minor: the vague 'limited period' and unspecified side effects on mailbox-associated resources.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% — the single required param mailboxId is already documented as 'Mailbox resource ID'. The description adds no parameter-specific detail, but none is needed since the schema fully carries the burden.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource ('Delete a mailbox') that precisely identifies the operation. The soft-delete detail further refines what 'delete' means here, distinguishing this from sibling mail tools like mail_createMailboxV1, mail_listMailboxesV1, and especially mail_deleteAliasV1 or 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied by the clear purpose — an agent needing to remove a mailbox can infer this is the right tool. The soft-delete note provides decision-relevant context (deletion is not immediately permanent), but no explicit alternatives, prerequisites, or when-not-to-use guidance 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?
Annotations already declare readOnlyHint=true and destructiveHint=false, covering the safety profile. The description adds the pagination scope, which is useful, but it does not disclose details such as default page size, maximum per_page, or result ordering. The added behavioral context is modest but not contradictory.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single focused sentence that front-loads the verb and resource, then adds the scoping detail ('across all mailboxes of a mail order'). There is no redundant wording or unnecessary 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 read-only list tool with fully documented parameters and safety annotations, the description covers the essential context. The absence of an output schema would ideally be compensated by return-format details, but 'paginated list' is a reasonable minimal indication for this low-complexity 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 page, orderId, and per_page are already fully documented. The description's reference to 'paginated list' loosely aligns with page and per_page but adds no additional parameter semantics beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Retrieve') and clearly identifies the resource: a paginated list of aliases across all mailboxes of a mail order. This distinguishes it from related mail tools like mail_createAliasV1 and mail_deleteAliasV1, and from other list tools that target different resources.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: this tool lists aliases for a mail order and does so across all mailboxes. It does not explicitly mention alternatives or exclusions, but among the mail siblings there is no competing alias-listing tool, so the usage 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?
Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds valuable behavior beyond this: the list is paginated, spans all mail orders, and plaintext tokens are never included — they appear only at creation time. This sets accurate expectations about response contents and security.
Agents need to know what a tool does to the world before calling it. Descriptions 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 main action, includes a useful documentation link, and adds the critical plaintext-token caveat 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 read-only list tool with three optional parameters and strong annotations, the description is largely complete. It covers pagination, scope, filtering, and the key security behavior. It does not detail the response structure or default pagination values, but that is not critical given the tool's simplicity and the absent 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?
Schema coverage is 100%, so the schema already documents all three parameters. The description adds minor context by mentioning pagination and optional order filtering, but it does not explain page/per_page semantics beyond what the schema provides. 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 verb and resource: 'Retrieve a paginated list of Hostinger Email API tokens.' It adds useful scope information ('across all your mail orders') and an optional filter by order, making it easy to distinguish from token creation/revocation siblings without opening their schemas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool — when you need to retrieve API tokens across mail orders, optionally filtered by order. However, it does not explicitly mention sibling alternatives such as mail_createAPITokenV1 or mail_revokeAPITokenV1, 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only and non-destructive behavior, so the description's job is lighter. It adds useful context beyond annotations: the list is paginated and spans all mailboxes, which clarifies the scope of the 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?
A single, front-loaded sentence conveys the verb, resource, pagination behavior, and scope with no wasted words. Every element 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 read-only list operation with fully covered parameters, the description is nearly complete. It could additionally mention default pagination behavior or available return fields, but those are not essential given the low complexity and annotation coverage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need 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 page, orderId, and per_page clearly. The description adds only the contextual note that results span all mailboxes, which modestly reinforces the meaning of orderId but does not add parameter-level 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 states a specific action ('Retrieve'), a specific resource ('autoreplies'), and a clear scope ('across all mailboxes of a mail order'). This clearly separates it from create/update/delete autoreply operations and from other mail 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The intended use is implied: use this when you need a paginated list of autoreplies for a mail order. However, it does not explicitly state when to prefer this over sibling tools or mention any exclusions, such as per-mailbox 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?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds meaningful behavioral context beyond that: results are paginated, sorted by timestamp descending, filtered by date range and event type, and the email must belong to the order's domain. No contradiction with 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?
Three sentences, all informative. The description front-loads the core action and resource, then adds constraints and behavior, with no filler or repetition of 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?
For a read-only, paginated log-listing tool, the description covers the essential invocation details: target resource, required identity constraints, filters, pagination, and sort order. There is no output schema, so the return record shape is not described, but the event enum and log-type description provide enough context for an agent to select and call the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already explains all eight parameters. The description reinforces the overall semantics by mentioning pagination, date range filtering, and event type filtering, but it does not add parameter-specific 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 states a specific verb and resource: 'Retrieve paginated mailbox action logs (message and mailbox events) for a mailbox in the given mail order.' It clearly identifies the operation's scope and content, and the event-type detail helps separate it from other mail log tools without needing to inspect schemas.
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 the agent what this tool returns and its scoping to a mailbox in a mail order, so usage context is implied. However, it does not explicitly contrast it with nearby siblings like mail_listAccessLogsV1, mail_listInboundLogsV1, or mail_listActionLogsV1, nor 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds useful behavioral context about not returning a contact list and about cost efficiency compared to paging, but does not disclose anything further such as response shape or rate limits. This is adequate given the annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no wasted words. The primary action is stated first, followed by the key usage rationale. 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 count operation with two required parameters and a clear title, the description is largely complete: it states what is counted, that contacts are not listed, and why this tool is preferable. It stops just short of explicitly stating the return value, though 'Count' and 'size' strongly imply a numeric 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 description coverage is 100%, so the parameters are already documented, even if only generically ('Profile uuid parameter', 'Segment uuid parameter'). The description does not add meaningful semantic detail beyond implying these identify the profile and segment whose contacts are being counted. 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?
States a specific verb ('Count') and resource ('contacts currently matching a segment'), and explicitly contrasts with listing ('without listing them'). This distinguishes it clearly from sibling tools like reach_listProfileSegmentContactsV1.
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?
Gives clear when-to-use guidance: when only the size is needed, because it is 'cheaper than paging through the segment contacts endpoint.' It names the alternative endpoint, though not the exact sibling tool name, and the 'when only the size is needed' clause effectively implies 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (readOnlyHint=false, destructiveHint=false), the description discloses key behaviors: background import (success means accepted, not finished), deduplication of existing emails, and double opt-in handling. This adds substantial value, though it omits potential failure modes 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?
The description is concise and front-loaded with the main action, followed by three critical behavioral notes. Every sentence adds value, with no redundant or filler 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?
The description covers essential aspects for a bulk async import: async acceptance, deduplication, and double opt-in handling. It does not mention error handling for individual contacts or output format, but given the lack of output schema and the tool's simplicity, 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?
Schema description coverage is 100%, so the baseline is 3. The description itself does not add parameter-specific guidance beyond what the schema already has (e.g., phone format). Some schema descriptions are weak ('name parameter'), but the description does not compensate for those.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid 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 many contacts in a profile in a single call,' specifying the verb, resource, and scope. It distinguishes this bulk operation from single-contact creation tools by emphasizing 'many' and 'single call.'
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 bulk creation ('many contacts') but does not explicitly name alternatives or state when not to use it. There is no mention of reach_createANewContactV1 or other single-contact tools, leaving the choice somewhat to inference.
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?
Annotations already provide readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds useful context about the returned contact counts and clarifies that the automation definition is not the workflow, but it does not describe response structure or error conditions; 3 is appropriate given the 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 two short sentences with no filler. The main result is front-loaded, and the alternative endpoint is presented clearly in the second sentence.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with two required UUIDs and annotations covering side effects, the description is nearly complete. It explains what the response contains and how this differs from the steps endpoint, which compensates for the lack of an 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?
Schema description coverage is 100%, so both parameters are already documented in the input schema. The description does not add extra meaning about parameter formats or relationships, so it stays at the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Get' with a precise resource ('single automation') and identifies what makes it distinct: it returns contact counts by lifecycle stage. It also explicitly contrasts the automation definition with the workflow, distinguishing it from the steps 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 clearly states that this tool returns the automation itself, and directs the agent to the steps endpoint when the workflow is needed. It could go further by mentioning list automation as the precursor, but the routing guidance is clear enough 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?
Beyond the readOnlyHint and destructiveHint annotations, the description discloses a key behavioral trait: the response has no ready-made embed snippet, and the caller must serve the HTML or build an embed around the form uuid. This is genuinely useful context for agent 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?
Two concise sentences front-load the purpose, then add a necessary caveat about the embed snippet. Every sentence earns its place with no 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 read-only tool with full schema coverage, the description is nearly complete: it states what the response contains, what it lacks, and the two required parameters are in the schema. The only gap is not describing the response shape in more detail, but with no output schema the existing information is reasonably 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%, so the baseline is 3. The description adds slight context for formUuid ('build your own embed around the form uuid'), but profileUuid remains unexplained and the schema's parameter descriptions are tautological ('Form uuid parameter'). No meaningful semantics are 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 states a specific verb and resource: 'Get a single form' and lists the key response components (URL of hosted template, tags applied to captured contacts). This clearly differentiates it from sibling tools like reach_listFormsV1, which lists forms rather than retrieving one.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The usage context is implied: this is the tool to use when a single form's details are needed. However, it does not explicitly state when to use this versus reach_listFormsV1 or other reach tools, and it offers no exclusions or alternative 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?
Annotations already establish readOnlyHint=true and destructiveHint=false, so the description does not need to repeat safety. It adds valuable behavioral context: the steps form a tree, must be reconstructed using parent_uuid and step_order, and an automation with no steps returns an empty list. This goes beyond the schema and annotations, providing essential interpretation guidance.
Agents need to know what a tool does to the world before calling it. Descriptions 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 efficient: two sentences with no filler. The first sentence front-loads the core purpose, and the second sentence provides essential structural detail. Every sentence earns its place, and the structure is clean.
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 largely complete for a read-only list operation. It explains the output structure (flat list, tree reconstruction via parent_uuid and step_order) and the empty-list behavior. It does not describe all potential output fields, but the critical ones are covered. Given the lack of an output schema, this is sufficient, though it could mention pagination or limits if applicable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% (both parameters have descriptions), so the baseline is 3. However, the parameter descriptions ('Profile uuid parameter' and 'Automation uuid parameter') are minimal and essentially restate the parameter names. The tool description does not add any additional parameter semantics, so it stays at the baseline without 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 the tool's function: 'Get the workflow of an automation as a flat list of steps.' The verb 'Get' and resource 'workflow of an automation as a flat list of steps' are specific and distinguish it from sibling tools like reach_getAutomationDetailsV1 (which likely returns automation details) and reach_listAutomationsV1 (which lists automations). The purpose is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool (when you need the steps of a specific automation), but it does not explicitly contrast with alternatives or state when not to use it. For a tool with many related siblings (e.g., automations, campaigns, forms), more explicit guidance would help, but the intent is reasonably inferable from the name and description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds useful behavioral detail such as pagination and the fact that forms reference templates, but it does not disclose defaults, ordering, or response characteristics beyond that.
Agents need to know what a tool does to the world before 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, focused paragraphs with no filler. The first sentence states the core purpose, and the second provides valuable follow-up guidance about template references and when to fetch form details. 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 paginated list tool with complete schema coverage and read-only annotations, the description is largely sufficient. It explains the resource, scope, pagination, and what the list items contain. A slightly more explicit pointer to the exact sibling tool would make it fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all three parameters. The description reinforces that profileUuid refers to the profile and that the result is paginated, which maps to page/per_page, but it adds no new parameter-level 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's action and resource: 'Get a paginated list of the signup forms in a profile.' It is specific enough to distinguish this from sibling tools like reach_getFormDetailsV1 and reach_deleteFormV1, which concern individual forms or destructive 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 gives clear context for when this list tool is appropriate and subtly routes the agent to a separate details operation: 'Get the form details for a directly usable template URL and for the tags...' It does not explicitly name the sibling tool or state when not to use it, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true, idempotentHint=true, and readOnlyHint=false, covering the safety profile. With annotations present, the bar is lower. The description adds the context that this removes 'unused' scripts, but doesn't add meaningful behavioral detail beyond that (no mention of what happens on failure, whether deletion is permanent, or what response to expect). The description doesn't contradict annotations — 'delete' aligns with destructiveHint. It just doesn't extend much beyond them.
Agents need to know what a tool does to the world before calling it. Descriptions 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 zero wasted words. The primary action is front-loaded in the first sentence, and the second sentence adds relevant usage context. Both sentences earn their place — no boilerplate 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 low-complexity tool — one required integer parameter with full schema coverage, annotations covering the destructive/idempotent safety profile, and no output schema — the description is nearly complete. The only minor gap is that it doesn't point the agent to the sibling getter (VPS_getPostInstallScriptsV1) for finding the ID, but this is a minor omission 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 description coverage is 100% — the single parameter postInstallScriptId is documented as 'Post-install script ID'. Since the schema already fully documents the parameter, the baseline of 3 applies. The description adds no additional parameter context (e.g., how to obtain the ID, or that it comes from VPS_getPostInstallScriptsV1), but it doesn't need to given full schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb (delete) + resource (post-install script) + scope (from your account). The action is unambiguous and easily distinguished from its VPS_ siblings (VPS_createPostInstallScriptV1, VPS_getPostInstallScriptV1, VPS_updatePostInstallScriptV1, VPS_getPostInstallScriptsV1) by the delete operation. No ambiguity about what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage 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 remove unused automation scripts' provides context for when this tool is appropriate — cleaning up unused scripts. It doesn't name alternatives explicitly, but the purpose distinction is fairly clear given the sibling names. A stronger definition might mention that modifications should use VPS_updatePostInstallScriptV1, but this is adequate.
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?
Annotations already provide readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds the context that this is for viewing backup points for VPS data recovery, but it does not disclose additional behavioral details like pagination behavior, response structure, or backup ordering. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is only two sentences long, front-loads the core operation in the first sentence, and the second sentence adds useful use-case context without redundancy or fluff. Every line 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, read-only, list-style endpoint with complete parameter descriptions and safe annotations, the description is largely sufficient. It clearly conveys the resource and purpose. However, with no output schema, a bit more detail about the response shape or pagination behavior could improve completeness, though it is 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?
Schema description coverage is 100%: both virtualMachineId and page have descriptions. The description only adds the phrase 'for a specified virtual machine,' which slightly reinforces the virtualMachineId parameter but adds no 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 the operation: 'Retrieve backups for a specified virtual machine.' It also adds 'view available backup points for VPS data recovery,' which reinforces that this is a read-only inspection tool rather than a restore action, distinguishing it from the sibling 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear usage context: use this endpoint to view available backup points. However, it does not explicitly mention alternatives or state when not to use it, such as directing restore operations to VPS_restoreBackupV1. This is clear context without explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds that the response includes both firewall configuration and associated rules, which is useful, but it does not disclose behavior around invalid IDs, authentication requirements, or error cases. This is acceptable for a simple read but not richly transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences with no filler. The first sentence states the core action, and the second reinforces the intended usage. 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 single-parameter read-only lookup, the description gives enough information: it identifies the required ID and indicates the returned data includes firewall configuration and rules. It lacks an explicit output schema or response structure, but the absence is not critical given the tool's simplicity and existing 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 description coverage is 100%, with firewallId already documented as 'Firewall ID.' The description only mirrors this by saying 'by its ID,' adding no new parameter-level meaning. Baseline 3 is appropriate since the schema carries the semantic weight.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Retrieve') and a specific resource ('firewall by its ID') with the additional scope of 'rules associated with it.' Saying 'specific firewall configuration' distinguishes this from the sibling list tool VPS_getFirewallListV1 without 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 explicitly says 'Use this endpoint to view specific firewall configuration and rules,' which gives clear context for when to invoke it. It does not name alternative tools like the list endpoint or mention exclusions, but the intended use case is clearly 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?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds only a vague indication that the endpoint returns 'specific automation script details,' with no deeper context such as response format, permissions, or pagination. It is adequate but not enriching.
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 short and front-loaded with the core action. The second sentence is somewhat redundant with the first but still reinforces the specific-details use case without bloating the description.
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 single-ID read operation with one fully documented parameter and read-only annotations, the description is complete enough for an agent to select and invoke the tool correctly. No critical context is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the single parameter is already described as 'Post-install script ID.' The description's 'by its ID' adds no meaningful semantic information beyond the schema, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Retrieve post-install script by its ID.' It clearly distinguishes this singular get tool from its siblings such as VPS_getPostInstallScriptsV1 (list), VPS_createPostInstallScriptV1, and VPS_deletePostInstallScriptV1.
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?
'Use this endpoint to view specific automation script details' gives a clear context for when to call it: when the agent needs details for a known script ID. It does not explicitly name alternatives or state exclusions, but the usage intent 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?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds meaningful context about what the tool returns: number of scans, detected threats, and other malware-scan statistics. It could mention behavior when Monarx is not installed, but that is a minor gap for a simple read endpoint.
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 first sentence is strong and front-loaded, but the third and fourth sentences are largely redundant ('useful for monitoring security status' and 'Use this endpoint to monitor VPS security scan results'). Condensing these would make the description tighter.
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 read-only tool with full schema coverage, the description provides enough information to select and invoke it correctly. It explains what the metrics contain and why they matter, though an explicit note distinguishing it from VPS_getMetricsV1 would make it fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single required parameter virtualMachineId is already 100% documented in the input schema. The description only refers to 'a specified virtual machine' without adding constraints, formatting, or relationship details, so it does not meaningfully extend schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Retrieve') and names a precise resource: scan metrics for the Monarx malware scanner installed on a specified virtual machine. This clearly differentiates it from the broader VPS_getMetricsV1 sibling and other 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 gives clear intended use ('monitor VPS security scan results and threat detection') and implies the prerequisite that Monarx is installed. It does not explicitly exclude or compare against VPS_getMetricsV1, so an explicit alternative statement would improve it slightly.
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?
Annotations already indicate this is a non-read-only, non-destructive mutation. The description adds useful context by saying the response includes the cron job's uuid, which is required for deletion. It does not discuss permissions or side effects, but the annotation coverage lowers the burden.
Agents need to know what a tool does to the world before calling it. Descriptions 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 filler. The first sentence states the action and inputs, while the second supplies the most important output detail, the uuid, in a focused way.
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 three-parameter creation tool, the description plus fully documented schema covers everything needed to invoke it correctly. Since there is no output schema, the explicit mention of the returned uuid is valuable and sufficient for the likely next step, deletion.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all three parameters are already documented with their meanings and constraints. The description only summarizes 'schedule expression' and 'command' without adding new semantic information, so the schema carries the load.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action: it creates a cron job for an Agency Plan website from a schedule expression and a command. The 'Agency Plan website' scope and the distinction from account-level cron jobs are clear, so an agent can tell it apart from similar sibling tools such as 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?
The description clearly scopes the tool to Agency Plan websites, which implies when it should be used instead of account-level cron tools. It does not explicitly name alternatives or exclusions, but the context is strong enough for correct routing.
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?
Annotations already provide destructiveHint=true and idempotentHint=true, but the description adds valuable context: it clarifies the operation is permanent, revokes all access, and explains the idempotency behavior in practical terms (deleting a non-existent user succeeds without error). This goes beyond what the annotations alone convey.
Agents need to know what a tool does to the world before calling it. Descriptions 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 that are front-loaded with the core action and consequence, followed by the idempotency note. Every sentence earns its place; there is no redundant or filler content.
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, three-parameter delete operation with no output schema, the description plus annotations are sufficient for an agent to invoke it correctly. It covers what is deleted, the scope, destructiveness, and idempotency. No critical behavioral or scoping information is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the parameters are already documented in the schema. The description itself adds no extra parameter-level guidance, leaving the baseline at 3. The schema's references to the list-databases endpoint are the primary source of semantic meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific verb 'Permanently deletes' and the resource 'database user from an Agency Plan website database', which distinguishes it from sibling tools like deleteWebsiteDatabaseV1 that delete the whole database. It also names the consequence ('revoking all access it had'), leaving no ambiguity about what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool (when you need to remove a database user from an Agency Plan website database) but does not explicitly discuss alternatives, exclusions, or when not to use it. For example, it does not contrast with deleting the entire database or with other user-management 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?
Annotations already provide readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds value by specifying that it returns 'every' extension and includes enabled status, but it does not disclose additional behavioral details such as failure modes or permission requirements. This is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, well-structured sentence that states the action, scope, and return details with no filler. The key scoping phrase 'Agency Plan website' is front-loaded, and every word contributes to understanding.
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 read-only list operation with one documented parameter and no output schema, the description is sufficient. It explains what is listed, for what scope, and what status information is included. The safety profile is already carried by the 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 description coverage is 100%: the only parameter, website_uid, is described as 'Agency Plan website UID'. The description does not add parameter-specific meaning, but with full schema coverage, the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Lists'), a clear resource ('every PHP extension available to an Agency Plan website'), and a meaningful detail ('whether it is currently enabled'). It immediately distinguishes itself from sibling tools like agency-hosting_replaceWebsitePHPExtensionsV1 and agency-hosting_listAvailablePHPVersionsForAWebsiteV1.
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 identifies the context: use it for an Agency Plan website when you need to inspect available PHP extensions and their enabled state. It does not explicitly name alternatives or exclusions, but the Agency Plan scope is a clear contextual marker relative to the many hosting and VPS 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?
Annotations already declare readOnlyHint=true and destructiveHint=false, covering safety. The description adds context about the returned data (default, current value, accepted values) and the scope (Agency Plan website), going beyond annotations without contradicting them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that conveys the action, scope, and output details without redundancy. It is directly front-loaded and free of filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only list operation with one parameter and no output schema, the description fully explains what is listed and the per-item data. It covers the essential aspects an agent needs to call and interpret the result.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the single parameter website_uid, which is already described as 'Agency Plan website UID'. The description does not add any additional parameter-level details, 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 tool lists php.ini directives for an Agency Plan website, specifying the exact resource and scope. It differentiates from siblings like agency-hosting_listAvailablePHPVersionsForAWebsiteV1 (versions) and agency-hosting_replaceWebsitePHPOptionsV1 (modification) by focusing on directive configuration details.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this tool is for reading PHP configuration, but it does not explicitly mention when to use it versus alternatives (e.g., when to use replaceWebsitePHPOptionsV1 for changes). No exclusions or alternative routing are given, so guidance is only implied by the tool's name and description.
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 adds useful behavioral context beyond the annotations: the domain stays in the account that initiated the move, and accepted moves can no longer be rejected. It does not cover auth or rate limits, but the annotations already flag this as destructive and non-read-only, lowering the burden on the description.
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 and front-loads the core operation, then adds the effect and limitation. The final sentence 'Use this endpoint to decline...' is slightly redundant with the first sentence, but it is short and reinforces intent.
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 action with no output schema, the description covers the purpose, outcome, and a critical state limitation. It could mention prerequisites such as a pending incoming move or describe the response, but the essential information for correct invocation is present.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the single 'domain' parameter is already described as 'Domain name'. The description adds no additional format, validation, or syntax details, so the schema carries the burden and the 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 ('Reject') and the resource ('an incoming move for a specified domain'). The phrase 'decline a domain you do not want to take over' reinforces the purpose and separates it from accepting or outgoing move 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 when declining a domain you do not want to take over. It also gives a key exclusion: moves already accepted cannot be rejected. It doesn't name sibling tools like domains_acceptIncomingDomainMoveV1, but the intended usage 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?
Annotations already declare readOnlyHint=true and destructiveHint=false, covering the safety profile. The description adds the substantive content of the result (payment/shipping flags and default currency) but does not discuss error conditions or other behavioral details; with annotations present, 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 sentences, no filler, with the key result fields stated first and the use case second. Every sentence adds value and the description is appropriately 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 simple read-only tool with one parameter, the description states the required input, the fields returned, and a representative use case. No output schema exists, so the description adequately substitutes by enumerating the result contents.
Complex tools with many parameters or behaviors need more documentation. Simple tools 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 store_id is already fully described in the schema as 'The ID of the store to read metadata for', giving 100% schema coverage. The 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 specifies the operation ('Get'), the resource ('a store's readiness metadata'), and the exact contents returned (payment methods configured, shipping configured, default currency). It is specific enough to be distinguished from sibling ecommerce tools like ecommerce_getStoresV1 and ecommerce_getCustomStorefrontSetupInstructionsV1.
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 gives a clear context for use: 'verify prerequisites before building a storefront.' It does not explicitly name alternative tools or state when not to use it, but the use case is concrete and distinguishes it from configuration or instruction 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?
Annotations already indicate readOnlyHint=false and destructiveHint=false, so the description is consistent. It adds valuable behavioral context: creation is asynchronous ('takes up to a few minutes to complete') and requires polling the websites list endpoint. It also discloses that a new hosting account is provisioned when datacenter_code is supplied. This exceeds mere annotation repetition without contradicting it.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is four sentences, each earning its place: it states the action, lists required inputs, explains the datacenter nuance, and gives completion/timing guidance. It is front-loaded and free of redundancy, making it an example of tight, efficient writing.
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 is quite complete. It covers required and optional parameters, the datacenter situation, and how to verify success. It doesn't mention error conditions or authentication, but those are commonly understood across the API; except for the lack of sibling differentiation, nothing critical 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?
Input schema covers all three parameters with descriptions (100% coverage), so the baseline is 3. The overall description adds meaning beyond the schema: it explains that 'subsequent websites will be hosted on the same datacenter automatically,' which clarifies why datacenter_code is only required on the first website. This extra context justifies a higher score than 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 a specific action: 'Create a new website for the authenticated client.' This gives a verb and resource, making the tool's purpose unambiguous. However, it does not differentiate from sibling tools like horizons_createWebsiteV1 or agency-hosting_createANewWebsiteV1, which also create websites, so it doesn't fully earn a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides concrete usage context: it explains that datacenter_code is required for the first website on a new hosting plan, and that subsequent websites reuse the datacenter automatically. It also tells how to verify completion (check the websites list endpoint). This is clear guidance for when to use the tool, though it does not mention any alternative 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already flag this as a write/destructive operation (readOnlyHint=false, destructiveHint=true), so the description does not need to re-establish that. It adds meaningful behavioral detail: uploads via TUS, extracts and deploys the archive directly without build steps, uses internal credentials, and auto-resolves the username from the domain. It could explicitly mention that a deployment may overwrite existing site content, but that is largely implied by destructiveHint.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is longer than average, but every sentence earns its place: core purpose, static-only constraint, alternative routing, upload behavior, internal-credential warning, and username auto-resolution. Information is front-loaded, with the essential purpose and constraint appearing before procedural details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers prerequisites, alternative routing, destructive/write behavior, internal upload flow, and archive content requirements—enough for a competent agent to invoke the tool correctly. The primary gap is the unaddressed relationship with hosting_deployStaticSiteArchiveV1, which could leave tool selection ambiguous. The lack of an output schema is not penalized.
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 all three parameters at 100%, so the baseline is met. The description adds value by emphasizing that the archive must contain pre-built static files ready to be served, reinforcing archivePath semantics beyond the schema's path and format details. No additional parameter clarification is necessary.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific operation—deploy a static website from an archive to a hosting server—and clearly narrows scope to static, no-build sites. It also explicitly contrasts itself with hosting_deployJsApplication. However, the near-identically named sibling hosting_deployStaticSiteArchiveV1 is never addressed, so an agent comparing the two has no disambiguation.
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?
Strong when-to-use guidance is present: only static sites without a build process; if package.json or a build command is present, use hosting_deployJsApplication instead. It also warns against calling a separate upload-url endpoint, which is useful. The main gap is that it does not explain the relationship with hosting_deployStaticSiteArchiveV1, leaving some selection 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?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds useful context (the token includes MCP endpoint authentication and how the software id is sourced), but it does not disclose token properties like expiration, scope, or format. Similar to the get_calls calibration, the description adds some context beyond annotations but omits behavioral detail.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, each earning its place: the first states the core purpose, the second tells where to supply the identifier, and the third explains how to source it. No fluff or redundancy; 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?
For a simple read-only token retrieval with annotations covering safety and schema covering parameters, the description is mostly sufficient. The main gap is that 'username' is not explained—its schema description is just 'username parameter'—so an agent may not know which username to supply. The token itself and the source of 'software' are described, but the username gap prevents a higher score.
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 3. The description adds extra meaning for 'software' by clarifying it goes in the path and showing exactly where to get its value. The 'username' parameter is not elaborated, but the additional software-guidance justifies a score above 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 states a specific action ('Return a JWT token') and a specific resource ('the specified WordPress installation, including its MCP endpoint'). It clearly communicates what the tool does and distinguishes it from other hosting/WordPress tools that manage installations rather than emitting auth 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?
The description gives clear context: the token is for authenticating requests against a WordPress installation, and it explains how to obtain the required software identifier. It does not explicitly name when not to use the tool or compare it to alternatives, but the intended use case is clear enough for an agent to route correctly.
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?
Annotations already mark the tool as read-only and non-destructive, and the description adds meaningful behavior beyond that: polling semantics tied to build state, incremental fetching via 'from_line', and the ANSI escape sequence caveat. This is useful operational context an agent would not otherwise know.
Agents need to know what a tool does to the world before calling it. Descriptions 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, well-structured, and front-loaded with the core purpose. Every sentence adds useful information: the retrieval action, the polling pattern, and the ANSI warning. No filler or redundant restatement of the title or schema.
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 read-only log retrieval tool with annotations already covering safety, the description covers the key operational needs: how to stream logs incrementally, when to poll, and what content to expect. The absence of an output schema is partially mitigated by the mention of a returned 'lines' count, though exact response fields are not described.
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 real value by explaining the intended use of 'from_line' as incremental polling using the previously returned line count, which is more meaningful than the schema's 'Line from which to start retrieving logs'. Other parameters are adequately covered by 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 a specific action ('Retrieve logs') and resource ('a specific Node.js build process'), which distinguishes it from list-type siblings like hosting_listNodeJSBuildsV1. It does not explicitly name alternatives, so it stops short of a 5, but the purpose is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives concrete guidance on when and how to use the tool: poll repeatedly while the build state is 'running', and pass the previously returned 'lines' count as 'from_line' to fetch only new output. It does not mention exclusions or alternatives, but the contextual usage is clear and practical.
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?
Annotations already declare destructiveHint=true and readOnlyHint=false, so the safety profile is known. The description adds meaningful behavioral context: automatic extraction, asynchronous availability, internal upload credential generation, and automatic username resolution. It does not specify what existing files or database content may be overwritten, which is a minor gap given the destructive annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded with the main purpose. The timing note and the warning against separate upload flows earn their place, though the phrasing 'files are being extracted' is slightly awkward and the timing information could be tightened.
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 inputs, process, timing, and the key operational warning about not calling a separate upload endpoint, which is sufficient for an agent to invoke the tool correctly. It does not describe return values or status handling, and no output schema exists, but for moderate complexity with well-documented parameters the coverage is strong 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 description coverage is 100%, and the schema already documents the domain, archive path, supported formats, database dump, and the directory-to-archive naming pattern. The description mostly restates or summarizes what the schema provides, so it does not add significant new parameter semantics 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 states a specific verb and resource: 'Import a WordPress website from an archive file to a hosting server' by uploading an archive and database dump. It clearly distinguishes the end-to-end behavior from separately calling an upload-url endpoint, and explains that the username is resolved automatically from the 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 gives clear usage context and an explicit exclusion: 'do not call a separate upload-url endpoint or upload the files yourself, this tool does it end-to-end.' It does not name sibling alternatives such as hosting_deployStaticSiteArchiveV1 or agency-hosting_importWebsiteFromArchiveV1, so it falls short of full alternative routing, but the guidance is concrete and actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safe read-only nature is established. The description adds the behavioral detail that this returns slugs suitable for installation, which is useful context beyond annotations. No contradiction or unexpected side effects 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with no filler. The first states the core purpose, and the second provides a direct actionable pointer to the install endpoint. 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?
For a read-only listing tool with full schema coverage and annotations covering safety, the description is complete. It tells the agent what the list is for and how to use the returned values, which is all necessary context for calling this tool correctly. No output schema exists, but the essential return semantics are covered.
Complex tools with many parameters or behaviors need more documentation. Simple tools need 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 optional `search` and `order_id` parameters are already documented in the schema. The description does not add parameter-level meaning, but the baseline of 3 is appropriate since the schema carries the full burden and does so adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'List WordPress themes available to install.' The qualifier 'available to install' clearly distinguishes this from the sibling hosting_listInstalledWordPressThemesV1 and other theme operations like activate or update. An agent can understand exactly what this tool returns.
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 explicit downstream guidance: 'Use the returned `slug` values with POST /api/hosting/v1/accounts/{username}/wordpress/{software}/themes/install.' This tells the agent how to use the result. It doesn't explicitly state when not to use it or point to alternatives like the installed-themes list, but the context is clear enough for a simple list operation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark this as non-read-only, idempotent, and destructive. The description adds meaningful behavioral context: enabling the mode turns off all caching, and disabling it restores performance benefits. It stops short of describing side effects on live traffic, but the core consequence is clearly disclosed.
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?
Three sentences with no wasted content: action, effect, and usage guidance. There is slight redundancy between 'development (cacheless) mode' and 'turning off all caching,' but the structure 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?
For a simple 3-parameter toggle with no output schema, the description covers the operation, its effects, and the appropriate usage period. It does not explain return values, but that is not required for correct invocation here, and the safety profile is already carried by 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 description coverage is 100%, so the parameters are already documented. The description restates the enabled flag behavior but adds nothing about username or domain beyond the schema's minimal descriptions. It provides no extra semantic value beyond what the schema already offers.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource: 'Turns development (cacheless) mode on or off, based on the enabled flag.' It clearly identifies the affected resource (caching for the website) and the controlling flag. The term 'development (cacheless) mode' distinguishes this tool from generic cache-related siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit guidance on when to enable the mode ('actively developing, testing changes, debugging issues, or when real-time updates must be visible') and when to disable it ('after finishing development work'). It does not explicitly mention alternative tools, but the usage context is clear and actionable.
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 annotation already signals a mutating (readOnlyHint=false) yet non-destructive (destructiveHint=false) operation. The description adds an important behavioral trait not present in the annotations: this operation is asynchronous and a successful response only means the job is queued. This is a valuable disclosure that prevents agents from misinterpreting the response as completion of the update.
Agents need to know what a tool does to the world before calling it. Descriptions 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: an opening action statement, a practical parameter note, and an essential asynchronous caveat. There is no filler or repetition, and the most important 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 definition covers the main operational aspects: what it does, how to identify the software, and the asynchronous nature. However, the 'username' parameter is left ambiguous ('username parameter' in schema, no explanation in description), and with no output schema the agent is not told what a successful response contains beyond the queued-job indicator. These gaps prevent a higher score.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the parameters are already documented. The description reinforces the meaning of 'software' by explaining it is the WordPress installation identifier and how to obtain it. It adds little beyond the schema, especially for 'username' and 'plugins', so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Update one or more installed plugins to their latest version on a WordPress installation.' This specifies a verb, resource, and scope, making it easy to distinguish from theme or core updates. However, it does not explicitly contrast it with related sibling tools like install, activate, or uninstall plugins, so it stops short of full sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives practical context by explaining how to obtain the required WordPress installation identifier via GET /api/hosting/v1/wordpress/installations. It also implies this tool is for updating existing plugins, not installing new ones. It lacks explicit when-not-to-use guidance or alternative tool references, but the provided prerequisite and object scope offer clear 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?
The description discloses meaningful behavior beyond annotations: it explains the response contains is_accessible, instructs what to do when verification fails (add a TXT record), and warns about DNS propagation delays. Annotations only provide readOnlyHint=false and destructiveHint=false, so the description carries important behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well structured and front-loaded: the main purpose appears first, followed by usage context, failure handling, propagation timing, and an exception. Every sentence contributes useful information without repetition or 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 one-parameter tool with no output schema, the description covers the important operational details: when to use it, what the response indicates, what to do on failure, timing expectations, and an exception case. An agent can confidently invoke and interpret the result.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the parameter is already documented as 'Domain to verify ownership for.' The description adds some context by indicating the domain is used for new websites and that free subdomains are excluded, but it does not add format or syntax details beyond what the schema already conveys. This matches the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb and resource: verify ownership of a single domain and return verification status. It also clarifies the practical purpose (checking accessibility before using the domain for a new website). However, it does not explicitly distinguish itself from sibling tools like v2_getDomainVerificationsDIRECT, so it falls short of full differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear guidance on when to use the tool: before using a domain for new websites. It also provides an important exclusion: skip verification for Hostinger free subdomains. It stops short of naming alternative verification endpoints, so it is strong but not 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?
Annotations already establish that this is not read-only and not destructive. The description adds useful behavioral context: the alias address is formed from the local part plus the mailbox domain, and messages sent to the alias are delivered to the mailbox. It does not discuss conflict or duplicate behavior, but the annotations lower the burden here.
Agents need to know what a tool does to the world before calling it. Descriptions 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 with no filler. The core action is front-loaded, and the second sentence provides the essential mechanics of alias construction and delivery. 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?
For a simple two-parameter create operation, the description is complete: it identifies the target mailbox, explains how the alias address is formed, and states the delivery outcome. With annotations covering the safety profile and the schema covering the parameters, nothing essential is missing 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 schema already documents both parameters with 100% coverage, including mailboxId's meaning and local_part's validation rules. The description echoes the relationship between local_part and the mailbox domain but adds no new parameter-level semantics beyond the schema, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
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: 'Create an alias for the given mailbox.' It then explains how the alias address is constructed and where messages are delivered, making the tool's purpose unambiguous and distinct from sibling list/delete alias 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 clearly implies when to use this tool, but it gives no explicit guidance about alternatives or exclusions. It does not mention, for example, that listing or deleting aliases should be done with sibling tools, so usage context is left mostly to inference.
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?
Beyond the annotations, the description adds a concrete behavioral consequence: the mailbox stops sending automatic replies immediately. This gives the agent a useful temporal and functional expectation. It does not contradict the destructiveHint or idempotentHint 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?
Two short sentences deliver the action and its immediate effect with no redundancy. The description is front-loaded with the core operation and stays within the necessary scope.
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?
With one required parameter, no nested objects, no output schema, and annotations already covering destructive and idempotent behavior, the description sufficiently explains what the tool does and what happens after the call. Nothing critical is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter, autoreplyId, is already fully described in the schema as 'Autoreply resource ID.' The description adds no additional meaning or usage guidance for the parameter, 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 begins with a clear verb and resource: 'Delete the autoreply of a mailbox.' It is specific and distinct from sibling operations like mail_createAutoreplyV1, mail_updateAutoreplyV1, and mail_listAutorepliesV1.
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 second sentence, 'The mailbox stops sending automatic replies immediately,' implies the intended use case but does not explicitly state when to use this tool versus alternatives or when not to use it. There are no exclusions or alternative routing.
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?
Annotations already indicate destructiveHint=true and readOnlyHint=false, so the description's added value is the permanence warning and the concrete consequence that the URL stops receiving event notifications. This is meaningful behavioral context beyond the structured 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?
The description is three short sentences with no filler. The action is front-loaded, and each sentence adds useful information: what happens, the irreversibility, and the operational consequence.
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 destructive operation, the description fully covers what the agent needs: what is deleted, permanence, and the effect on the webhook URL. No output schema exists, and none is needed for this simple action.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a clear parameter description ('Webhook ID (returned when the webhook was created)'). The tool description adds no parameter-specific meaning, but the schema already fully documents the only parameter, 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 states the exact verb and resource ('Permanently delete a webhook') with a clear consequence. It distinguishes itself from sibling webhook tools (create, list, get, update) by emphasizing permanent removal.
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: call this when a webhook should be permanently removed and stop receiving event notifications. However, it does not explicitly name alternatives 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the operation as destructive, but the description adds specific behavioral detail: the token immediately loses access to the Hostinger Email API and the action is irreversible. This goes beyond the generic destructiveHint and clarifies exactly what is 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 three short sentences with the core action first and the critical warning immediately after. Every sentence adds value and there is no filler 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?
For a single-parameter, fully documented tool with safety annotations, the description conveys the action, scope, immediacy, and irreversibility. Nothing necessary for correct invocation is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the tokenId schema description already explains that the ID is returned when the token was created. The tool description adds no additional parameter semantics, matching the high-coverage 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 opens with 'Revoke an API token,' a specific verb and resource. It further scopes the action to Hostinger Email API tokens, clearly distinguishing it from sibling token tools like mail_createAPITokenV1 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 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; usage is inferred from the verb and resource name. 'This action cannot be undone' provides a cautionary note but no direct routing guidance among the create/list/revoke API token 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?
Annotations already mark it read-only and non-destructive, and the description adds useful behavior: defaulting to regular campaigns, the ability to fetch automation/double opt-in emails, and the `publish` status for fully sent campaigns. It also tells agents each campaign carries headline engagement rates, which is helpful context for interpreting results.
Agents need to know what a tool does to the world before 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 paragraphs, front-loaded with the core purpose, and every sentence carries useful information about pagination, statuses, or type filtering. No filler 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?
For a read-only, paginated list tool with fully documented parameters and readOnly/destructive annotations, this description is sufficient. It covers the main behaviors an agent needs to call it correctly and gives a hint about the response content ('headline engagement rates').
Complex tools with many parameters or behaviors need more documentation. Simple tools need 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 input schema already explains all parameters. The description reinforces `type` defaults and status semantics, but adds no new parameter 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?
Description opens with 'Get a paginated list of the campaigns in a profile,' giving a specific verb, resource, and scope. It clearly distinguishes this list endpoint from detail/performance campaign tools and other reach list 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?
It gives clear context for filtering by status and switching the campaign type with the `type` parameter, but it never names alternatives like reach_getCampaignDetailsV1 or states when not to use this tool. The usage guidance is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes beyond the annotations (destructiveHint=true) by specifying exactly what gets deleted: options omitted from the list are removed along with the values contacts hold for them. It also explains the uuid-based behavior (kept/relabelled vs created) and the immutability of type/slug. This adds meaningful context about side effects and aligns with the idempotentHint and destructiveHint without contradiction.
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 paragraphs, front-loading the primary action in the first sentence. The second paragraph adds necessary detail about option handling and constraints. It is concise with no fluff, though the option behavior sentence is dense and could be slightly clearer with structure (e.g., bullet list).
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 behaviors: rename, option replacement with deletion semantics, and immutability of type/slug. It does not mention prerequisites like obtaining profileUuid or fieldUuid, but these are likely standard for reach tools. Given no output schema, return values are not needed. Overall, adequate for an agent to call it correctly, with minor gaps in prerequisite guidance.
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?
Although the schema descriptions are generic for label, fieldUuid, and profileUuid (e.g., 'label parameter'), the tool description clarifies the label as the new name and explains the options parameter's replacement and deletion semantics in detail. It also implies fieldUuid identifies the field to update. This adds value beyond the schema, especially for the options parameter which already has a descriptive schema comment.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: it renames a custom contact field and, for choice types, replaces its option set. This clearly distinguishes it from sibling tools like create, delete, and list contact fields. The note that field type and slug cannot be changed further defines 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for renaming or replacing options, but does not explicitly contrast with create or delete. The limitation 'field type and slug cannot be changed' implicitly suggests not using this tool for those changes, but it does not point to alternatives or mention prerequisites such as fetching UUIDs via list endpoints. Guidance is only partial.
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?
Annotations are minimal (readOnlyHint=false, destructiveHint=false), so the description carries the burden of behavioral disclosure. It goes beyond annotations by warning that any VM with the firewall activated will lose sync and require manual re-sync. This is a critical side-effect not conveyed by annotations, adding value.
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 four sentences, each serving a purpose: the first states the action, the second explains default behavior and necessity, the third warns about side-effects, and the fourth reaffirms the use case. It is concise without fluff, though it could be slightly more compact by merging some sentences.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the purpose, default-drop context, side-effects, and usage, providing a solid understanding for the agent. It lacks mention of prerequisites like needing an existing firewall, but that is implied by the 'specified firewall' phrasing. No output schema exists, so it doesn't need to explain 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 description coverage is 100%, so the parameters are already well-documented (e.g., port: 'Port or port range, ex: 1024:2048'). The description does not add parameter-specific details beyond what the schema provides. The general context about default drop behavior indirectly informs why these parameters matter, but that's not direct 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 verb 'Create' and the resource 'firewall rule for a specified firewall', which precisely defines the action. It is easily distinguished from sibling tools like VPS_updateFirewallRuleV1 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 provides important usage context: it explains the default drop-all-incoming-traffic behavior and the necessity to add accept rules for desired ports. It explicitly says 'Use this endpoint to add new security rules to firewalls.' However, it does not mention when NOT to use it or explicitly point to alternatives like update/delete.
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 goes beyond the annotations by warning: 'Creating new snapshot will overwrite the existing snapshot!' This is a critical behavioral side effect that an agent must know before calling the tool. The annotations do not contradict this: readOnlyHint=false correctly signals a mutating operation, and the overwrite warning is additional transparency rather than a denial of destructive 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 core action and the critical overwrite warning are front-loaded and easy to find. The explanatory sentence about snapshots adds useful context but is somewhat redundant. Overall, the description is well-structured and not excessively long.
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 creation endpoint, the description covers the purpose, the main behavioral warning, and appropriate use cases. There is no output schema, so a note about the response format or polling would have been helpful, but it is not essential given the tool's simplicity and the annotations provided.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already has 100% parameter coverage, including a description for virtualMachineId: 'Virtual Machine ID.' The description only repeats this by referring to 'a specified virtual machine,' adding no type, format, or lookup guidance. With full schema coverage, the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Create a snapshot of a specified virtual machine.' It identifies the resource and the core behavior, and it even highlights that creating a new snapshot overwrites the existing one. It does not explicitly differentiate itself from sibling snapshot tools like VPS_restoreSnapshotV1 or VPS_deleteSnapshotV1, so it misses the highest mark for sibling distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit intended use: 'Use this endpoint to capture VPS state for backup and recovery purposes.' This provides clear context for when the tool is appropriate. It does not mention alternatives or exclusion conditions, such as when to use VPS_restoreBackupV1 instead, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is clear. The description does not add behavioral context like pagination behavior, ordering, or what happens when no keys are attached, but it does not contradict the 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 two short sentences with no filler. The primary action is front-loaded, and the usage guidance is placed directly after, making it easy for an agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only lookup tool, the description is complete: it identifies the target resource, the parameter needed, and the read-only purpose. The schema and annotations cover parameter details and safety, so no critical context is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so both parameters are already documented. The description adds semantic context by tying 'virtualMachineId' to a specific VPS instance, but it does not elaborate on the 'page' 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?
The description states a clear verb ('Retrieve') and a specific resource ('public keys attached to a specified virtual machine'), which distinguishes it from siblings like VPS_getPublicKeysV1 or VPS_attachPublicKeyV1. The second sentence reinforces the scope by mentioning SSH keys configured for specific 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 explicitly says 'Use this endpoint to view SSH keys configured for specific VPS instances,' giving clear context for when to call it. It does not mention when not to use it or name alternatives, so it falls just short of full routing 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?
Annotations already declare this is not read-only and not destructive, so the description adds useful behavioral context beyond that: a setup-failure fallback via hPanel and the automatic use of the default payment method. It does not disclose cost implications, irreversibility, or asynchronous behavior, but the additional details meaningfully inform the agent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded with the core purpose, followed by actionable fallback and payment behavior. Every sentence earns its place; the final sentence reinforces the tool's scope without bloating the 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?
For a purchase operation with no output schema, the description covers important edge behavior (manual setup fallback, default payment) but omits what the response contains, whether the operation is asynchronous, and what the required 'setup' parameter should contain. The agent has enough to begin, but meaningful gaps remain for a reliable call.
Complex tools with many parameters or behaviors need more documentation. Simple tools need 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's payment-method default line duplicates what the schema already says, and it adds no clarifying detail about the ambiguous 'setup' parameter or how to obtain item_id. It neither hurts nor significantly improves 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 states a specific verb and resource: 'Purchase and setup a new virtual machine' and explicitly says 'Use this endpoint to create new VPS instances.' This distinguishes it from sibling tools like VPS_setupPurchasedVirtualMachineV1 and domains_purchaseNewDomainV1 by clarifying it creates VPS instances rather than merely performing setup or purchasing 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage context with 'Use this endpoint to create new VPS instances' and gives practical guidance about what to do if setup fails. It does not explicitly state when not to use it or contrast it with related billing/setup tools, but the purpose statement is strong enough for an agent to select it appropriately.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already flag this as destructive and idempotent. The description adds valuable context by specifying that both the hostname and PTR record are reset to defaults, which explains what the destructive action affects. No contradiction with the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and mostly front-loaded. The first sentence conveys the core action and scope. The second sentence adds context but is somewhat redundant with the first, so it is not perfectly 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 one-parameter tool with a clear destructive annotation and idempotency hint, the description provides enough guidance to invoke the tool correctly. It could mention broader consequences or prerequisites, but none are essential given the straightforward action.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The parameter virtualMachineId is fully described in the schema with coverage at 100%. The description adds no extra semantics about the parameter, but the schema already carries the necessary meaning, so a 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 states a specific action ('Reset hostname and PTR record'), the target ('specified virtual machine'), and the outcome ('to default value'). This clearly distinguishes it from related tools like VPS_setHostnameV1, which is for setting a custom hostname.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context: use this endpoint to restore default hostname configuration for VPS instances. It does not explicitly name alternative tools or conditions for when not to use it, but the purpose is specific enough for an agent to select 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?
Annotations already mark the operation as destructive and idempotent. The description adds meaningful behavioral context beyond annotations by warning that changing the hostname does not automatically update the PTR record and that A/AAAA records must point to the VM IP for hostname reachability. This helps an agent anticipate 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 compact and front-loaded with the core purpose. The DNS/PTR caveats and the explicit use statement are useful additions rather than filler. It could be slightly tighter, but every sentence contributes 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?
For a simple two-parameter mutation tool with annotations and no output schema, the description covers the key operational concerns: what the endpoint does, what it does not do automatically, and what else is needed for hostname reachability. Minor gaps remain around hostname validation and whether the previous hostname is replaced, but these are not critical for basic invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage for both parameters, so the schema carries most of the burden. The description adds a little semantic context by framing the hostname as a 'custom hostname' and implying it should be resolvable via DNS, but it does not specify format, length, allowed characters, or how virtualMachineId is used 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 a specific verb and resource: 'Set hostname for a specified virtual machine.' It further clarifies the purpose by saying it configures custom hostnames for VPS instances, which distinguishes it from sibling tools like VPS_resetHostnameV1 that imply resetting rather than setting custom values.
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 an explicit use statement: 'Use this endpoint to configure custom hostnames for VPS instances.' It also supplies relevant operational context about DNS/PTR requirements, but it does not explicitly contrast this with alternatives such as VPS_resetHostnameV1 or other VPS configuration endpoints.
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?
Annotations already mark the operation as not read-only and not destructive. The description adds useful behavioral context by noting idempotency: 'If the virtual machine is already running, the request will still be processed without any effect.' This goes beyond the structured 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 concise and well-structured: a clear action sentence, an important idempotency clarification, and a direct usage instruction. Every sentence earns its place without 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 simple one-parameter start operation with no output schema, the description covers the purpose, the target state ('stopped VPS instances'), and the already-running edge case. Nothing essential is missing 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 only parameter, virtualMachineId, is fully described in the schema as 'Virtual Machine ID' (100% schema coverage). The description does not add further parameter-level meaning, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action and resource: 'Start a specified virtual machine' and 'power on stopped VPS instances.' It does not explicitly name sibling tools like VPS_stopVirtualMachineV1 or VPS_restartVirtualMachineV1, so sibling differentiation is implied rather than explicit.
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 condition: 'Use this endpoint to power on stopped VPS instances.' It does not mention alternatives or exclusions, but the context is sufficient for deciding 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate this is a destructive, non-read-only mutation. The description adds the useful special behavior that setting domain to null reverts to the temporary domain, but it does not disclose broader consequences such as DNS/domain release effects. No contradiction with 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?
Three short sentences, each earning its place: purpose, request layout, and null-revert behavior. The purpose is front-loaded and there is 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 3-parameter mutation with no output schema, the description covers the core operation, required parameter placement, and an important edge case. It could mention side effects or success response behavior, but the annotations and schema cover most of the remaining 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%, so the baseline is 3. The description adds value by clarifying the request layout: the current domain goes in the path and the new domain goes in the request body. It also reinforces the null-to-revert special case.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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: 'Changes the primary domain for an Agency Plan website.' This clearly identifies what the tool does and its scope, and distinguishes it from sibling domain-linking/unlinking 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 operation context is clear: use this when changing the primary domain of an Agency Plan website. The description also explains how the current and new domains are supplied. It does not explicitly name alternatives like linkDomainToWebsiteV1, but the use case is specific enough to guide 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?
Annotations only indicate readOnlyHint=false and destructiveHint=false, so they do not disclose much. The description adds a meaningful behavioral constraint: each database supports only one non-system user, and creating another fails. This is exactly the kind of edge-case behavior an agent needs beyond the structured 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?
The description is two short sentences. The first states the core action and scope; the second delivers the single-most important constraint. There is no filler, repetition, or unnecessary background, and the critical 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?
With no output schema, the description does not state the success response format, but it does cover the essential preconditions, the uniqueness restriction, and the failure case. Combined with fully documented parameters and clear annotations, this is sufficient for an agent to decide when to call the tool and what inputs to supply. A brief note on the success response would make it fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with all four required parameters and the optional host already documented. The description does not add parameter-level detail, which is acceptable because the schema carries the full burden. It receives the baseline score for not repeating or detracting from schema 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 a specific verb and resource: 'Creates a user for an existing database on an Agency Plan website.' This clearly distinguishes the operation from creating the database itself (agency-hosting_createWebsiteDatabaseV1) and from deleting a user (agency-hosting_deleteWebsiteDatabaseUserV1). The scope is explicit and immediately actionable.
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 conditions usage on an existing database and on the database not already having a user, giving the agent a clear precondition and failure outcome. It does not explicitly name the sibling alternative for creating the database, but the 'existing database' wording effectively routes the agent away from database creation 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?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the description does not need to restate safety. It adds useful behavioral context about pagination and the content of entries (schedule expression and command), which goes beyond the annotations. Since the read-only nature is covered, the description contributes meaningful extra transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences with no redundancy. The core purpose is front-loaded in the first sentence, and the second sentence clarifies the response contents. Every word contributes to understanding the tool's function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only list tool with a simple required parameter and two optional pagination parameters, the description is sufficiently complete. It explains what is returned (schedule and command) and mentions pagination. It does not describe error conditions or the full response structure, but given no output schema exists and the operation is straightforward, these omissions are minor.
Complex tools with many parameters or behaviors need more documentation. Simple tools 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 descriptions (website_uid, page, per_page). The description does not add additional parameter semantics beyond mentioning pagination, which is already implied by the schema's page/per_page fields. Since schema coverage is high, baseline 3 is appropriate; no added value beyond that.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid 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 ('paginated list of cron jobs configured for an Agency Plan website'). It differentiates from siblings like hosting_listAccountCronJobsV1 by scoping to a website and specifying the plan type, and mentions that each entry includes schedule and command, leaving no ambiguity about what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context by specifying 'Agency Plan website', which implicitly distinguishes it from account-level cron jobs (hosting_listAccountCronJobsV1) and website create/delete operations. However, it does not explicitly mention when not to use this tool or name alternative listing tools, so it lacks explicit exclusion 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?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds useful behavioral context by listing statuses (running, completed, failed) and the intended polling pattern after async operations, which helps the agent understand expected behavior beyond the structured 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 concise and front-loaded: the first sentence states the core purpose, and the second adds essential details about process fields and polling usage. Every sentence contributes value 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?
For a simple one-parameter read-only tool, the description covers the main points: what is listed, what fields are included, and when to poll. It does not specify response formatting or pagination, but given the simplicity and the lack of an output schema, the description 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 description coverage is 100%, and the only parameter, website_uid, is documented as 'Agency Plan website UID'. The description does not add much beyond the schema, but it reinforces the Agency Plan scope. Since the schema already fully documents the parameter, 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 clearly states the tool 'Lists active and recently completed asynchronous processes for an Agency Plan website', naming a specific verb and resource. It also explains what information each process exposes (ID, type, status) and distinguishes this poll/status tool from other list tools by focusing on async process tracking.
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 explicit guidance on when to use the tool: 'Poll this endpoint after initiating async operations (SSL setup, backups, cloning) to track progress.' It does not mention exclusions or alternative tools, but the usage context is clear 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?
Annotations already declare readOnlyHint=true and destructiveHint=false, covering the safety profile. The description adds meaningful behavioral context beyond that by disclosing the price representation: prices are displayed as cents without a floating point, e.g., 17.99 becomes 1799. This is exactly the kind of format detail that prevents misinterpretation of returned data.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three short sentences, each earning its place: the first states the core function, the second gives a critical pricing-format detail, and the third provides usage context. Key information is front-loaded and there is no 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 read-only list endpoint with two optional, fully documented parameters and no output schema, the description is largely complete. It explains what the tool returns, the pricing unit, and when to use it. It does not explicitly state default behavior when no filters are applied, but the name and schema make that reasonably inferable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and both parameters (name, category) already have clear descriptions in the schema. The tool description mentions pricing but does not add any extra meaning about the name wildcard or category enum values. With full schema coverage, a baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
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: 'Retrieve catalog items available for order.' It clearly positions this as the catalog/index endpoint for orderable services and pricing, distinguishing it from billing operations like subscriptions or purchase orders. The final sentence reinforces the purpose as pre-order discovery of services and pricing.
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 this tool: 'Use this endpoint to view available services and pricing before placing orders.' This gives clear contextual guidance. It does not explicitly list alternatives or when-not-to-use conditions, but for a simple read-only list endpoint 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?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the tool is non-mutating. The description adds specific behavior: it explains success (200) and error (422) response codes and confirms the purpose is verification only. This aligns with annotations and provides useful operational detail.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, efficient and front-loaded with the purpose. It wastes no words and includes exactly the needed behavioral cues (success/failure codes) and 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.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a validation-only tool with no output schema, the description explains the return codes and clearly indicates it is for pre-update verification. It does not mention authentication or prerequisites, but these are likely implicit. The essential context is covered without missing critical information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so each parameter (domain, zone, overwrite) is already well documented. The description doesn't add param-specific meaning beyond stating the tool validates records, which is implied. Baseline 3 is appropriate given the schema already handles 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 states a specific verb ('Validate'), a resource (DNS records), and the context ('prior to update'). It explicitly says 'Use this endpoint to verify DNS record validity before applying changes,' which clearly distinguishes this from sibling tools like DNS_updateDNSRecordsV1 or DNS_getDNSRecordsV1.
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 says when to use the tool: 'prior to update' and 'before applying changes.' It implies this is a pre-application step, but doesn't explicitly mention alternatives or when not to use it. The context is sufficient for an agent to understand the intended workflow.
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?
Annotations already signal mutation and destructiveness; the description adds meaningful behavioral context by explaining the real-world consequence—private information becomes visible in the public WHOIS database. This goes beyond the schema and helps the agent understand the sensitivity of the action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences, all earning their place: the action, the consequence, and the usage directive. It is front-loaded with the primary purpose and contains 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?
For a single-parameter mutation endpoint with annotations covering idempotency and destructiveness, the description provides the essential behavioral and usage context. It doesn't describe return values, but with no output schema and a simple action, that is not a significant gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the only parameter, with 'domain' documented as 'Domain name.' The description adds no extra parameter-level meaning, so the schema already does the necessary work; 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 and resource ('Disable privacy protection for the domain') and clearly distinguishes the tool's effect from its sibling enablePrivacyProtectionV1. The consequence—making the owner's information publicly visible in WHOIS—reinforces what the tool does rather than merely restating the title.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context for when to use the endpoint: 'Use this endpoint to make domain owner's information publicly visible.' It does not explicitly name the alternative (enablePrivacyProtectionV1) or state when not to use it, but the intended use case is unambiguous.
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 adds meaningful behavioral context beyond annotations by explaining that enabling the lock prevents transfer until the lock is disabled. This clarifies the operational impact and implies reversibility. The annotations already cover idempotency and destructive intent, so the description does not need to repeat them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short, front-loaded with the core action, and contains no filler. Every sentence contributes useful information: what it does, what effect it has, and why to use it.
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 mutation tool, the description covers the action, effect, and reasoning. It does not mention prerequisites like domain ownership or errors when re-enabling the lock, but the annotations and schema richness make the tool straightforward to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There is only one parameter, 'domain', and its schema description ('Domain name') fully covers the meaning. The tool description does not add extra constraints or format 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 states a clear verb ('Enable') and resource ('domain lock'), making the operation unambiguous. It also differentiates from the sibling domains_disableDomainLockV1 by describing the exact action and consequence.
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 secure domains against unauthorized transfers. It does not mention alternatives or state when not to use it, but the use case is clear enough for an agent to select 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?
Annotations already provide readOnlyHint=true and destructiveHint=false, so the description does not need to repeat that. It adds valuable behavioral detail: requesting a new code invalidates any previously retrieved code. This is a side effect beyond the simple retrieval and is not covered by annotations. No contradiction with 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 three sentences, each earning its place: purpose, a critical side-effect warning, and explicit usage guidance. It is front-loaded with the action and purpose. There is minor repetition of 'transfer to another registrar' across sentences, but it remains tight and without 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 single-parameter read operation with annotations covering safety, the description provides enough to call it correctly: what it does, the side effect of invalidation, and when to use it. It doesn't mention the response format, but with no output schema, that is not required. Missing prerequisites (e.g., domain must exist, transferable) are minor given the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the single 'domain' parameter, and the schema already says 'Domain name'. The description adds minimal semantic value ('specified domain'), but essentially restates what the schema provides. It does not clarify format, encoding, or constraints, but given full coverage, a baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
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), the resource (authorization (EPP) code), and the purpose (so it can be transferred away from Hostinger). It distinguishes this from other domain operations like domain locks or incoming/outgoing moves by focusing on the code for transfer. Not a tautology; specific and actionable.
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 obtain the code required to transfer a domain to another registrar,' providing a clear when-to-use. It also warns that requesting a new code invalidates previous ones, which is a usage caution. However, it does not mention alternatives or when not to use, such as distinguishing from starting a transfer move (domains_startOutgoingDomainMoveV1).
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 annotations already declare readOnlyHint=true and destructiveHint=false, so the description need not repeat that. It adds meaningful behavioral details beyond the annotations: the 404 response when no move exists, and the implication that the endpoint can be used for status polling. It does not describe side effects (none expected) or rate limits, but the disclosed 404 behavior 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 succinct sentences with no filler. It front-loads the primary purpose, then provides the key edge case (404) and a practical usage hint. 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 read-only getter with no output schema, the description covers the essential invocation context: the domain required, the 404 condition, and the intended use case. It doesn't describe the success response structure, but that is reasonable to infer from the resource name. The tool is simple enough that this is adequate, though slightly more detail on the returned move object could push it to a 5.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both 'domain' and 'force_sync' documented in the input schema. The description adds no additional parameter context, so it meets the baseline of 3 but does not exceed 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 resource 'incoming move for a specified domain'. It also distinguishes this singular getter from the list variant (getIncomingDomainMoveListV1) and accept/reject siblings by focusing on a single domain and the use case of checking acceptance status. The 404 note further clarifies the precise scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a concrete use case: 'Use this endpoint to check whether a domain addressed to you is still waiting to be accepted.' This gives clear context for invocation. However, it does not explicitly mention when not to use it or name alternatives (e.g., the list endpoint for multiple moves), so it falls short of a full 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds meaningful context beyond that by explaining that both the old and new registrant must confirm before the WHOIS change takes effect, which clarifies the meaning of 'pending.' It does not describe the return format, but the annotations plus this contextual process detail make the behavior clear enough.
Agents need to know what a tool does to the world before calling it. Descriptions 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. The main action is front-loaded in the first sentence, and the supporting context and usage hint follow efficiently. Every sentence earns its place 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 read-only operation with a single parameter, this description covers the essential purpose, the confirmation process, and the intended usage. There is no output schema, so the description could optionally mention what kind of status is returned, but it's not critical for an agent to call the tool correctly. The information provided is sufficient for a competent agent to decide and execute the call.
Complex tools with many parameters or behaviors need more documentation. Simple tools need 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 sole parameter 'domain,' which is documented as 'Domain name' in the schema. The description does not add any additional meaning or format guidance for the parameter, so it does not exceed what the schema already 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 the action ('Retrieve a pending IRTP verification for a domain') with a specific verb and resource. It also explains the context (WHOIS change requiring confirmation) and explicitly says to use it for checking status. This unambiguously distinguishes it from the cancel counterpart (domains_cancelPendingIRTPVerificationV1) and 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 says 'Use this endpoint to check the status of a WHOIS change awaiting registrant confirmation,' which gives clear when-to-use guidance. It doesn't explicitly mention alternatives or when not to use it, but the purpose is so well-defined that an agent can infer the correct context. The double-confirmation detail further clarifies the scenario.
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 goes beyond the basic annotations (readOnlyHint=false, destructiveHint=false) by explaining the move initiation process, subscription auto-resolution, and specific error status codes (404, 428). It also clarifies that the move is not immediate—requires acceptance by the receiving account. No contradictions with 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 concise, front-loading the primary purpose, and then elegantly organizes prerequisites and error scenarios in separate sentences. No redundant information is included, 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 two-parameter tool without an output schema, the description covers the purpose, prerequisites, error handling, and the requirement for recipient acceptance. It could be improved by mentioning what the response looks like or that the move is pending until accepted, but the current detail is adequate for successful 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%—both 'domain' and 'new_customer_email' are fully described in the schema. The description does not add extra semantics beyond referencing them in context. Since the schema already covers them, a baseline score of 3 is appropriate; the description neither enhances nor detracts.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid 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 ('Initiate a move'), the resource ('a specified domain'), and the destination ('to another Hostinger account'). It distinguishes from siblings like acceptIncomingDomainMoveV1 by focusing on the outgoing move initiation. The purpose is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage 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: 'hand a domain over to another Hostinger user'. It also states prerequisites (receiving account must exist and accept, domain must be active) and error conditions (404, 428). However, it does not explicitly contrast with alternative sibling tools like cancelOutgoingDomainMoveV1, though the name and context make the distinction inferable.
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?
Annotations already mark the tool as read-only and non-destructive. The description adds valuable behavioral context by stating that suggestions are AI-generated and non-deterministic across calls, and it discloses a specific rate limit of 90 requests per minute.
Agents need to know what a tool does to the world before 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 short sentences, each earning its place: the purpose, the non-deterministic behavior, the rate limit, and the specific use case. Information is front-loaded and there is no redundant or filler 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, two-parameter, read-only tool, the description covers purpose, input type, behavioral caveats, and rate limiting. It could further describe the exact response shape, but the absence of an output schema is partially mitigated by the clear phrase 'suggest available domain names.'
Complex tools with many parameters or behaviors need more documentation. Simple tools need 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 both parameters. The description adds little beyond restating that the input is a free-text project description and that the limit controls the number of suggestions, which makes 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?
States a specific action and resource: suggest available domain names from a free-text description. The phrase 'when you only know what the website is about' clearly differentiates it from sibling tools like domains_suggestDomainNamesFromADomainV1.
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 this endpoint when only a project description is known, which gives clear usage context. It does not explicitly mention alternatives or when not to use it, so it stops short of a full exclusion-based guideline.
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?
Beyond the mutation implied by readOnlyHint=false, the description discloses important behaviors: options missing from the product are auto-created, prices are integers in the smallest currency unit and default to the store currency, and the created variant is returned. It does not address failure modes like duplicate variants, but the annotations already cover the mutation/safety profile.
Agents need to know what a tool does to the world before 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 tight, front-loaded sentences cover the action, key variant-option behavior, price rules, and return value. There is no filler or repetition of the title, and every sentence contributes operational 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?
For an 8-parameter mutation with no output schema, the description covers the highest-risk semantics: option completeness/auto-creation, integer price units, currency default, and return value. Defaults for title and inventory are left to the schema, which already documents them, so the definition 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 description coverage is 100%, so the baseline is 3. The description mostly restates what the schema already says about options and prices, such as 'provide a value for every option the product already has' and integer prices. It adds little new meaning beyond the structured 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 opens with a specific verb and resource: 'Add a variant to a product along one or more option dimensions,' which clearly states what the tool does. The mention of option dimensions and auto-creation of missing options distinguishes it from product-level create tools and from batch variant updates.
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 gives clear usage context: variants are added along option dimensions, missing product options are created automatically, and callers must provide values for every existing product option. It does not explicitly name alternatives such as updateProductVariantsInBatch or state when not to use this tool, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the operation as destructive and idempotent, but the description adds important context beyond that: it is a soft delete, the underlying data is preserved, and only the store record is marked as deleted. This clarifies what actually happens and reduces the risk of the agent assuming permanent data destruction.
Agents need to know what a tool does to the world before calling it. Descriptions 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 with no filler. The core action is front-loaded, and the behavioral clarification about data preservation is presented immediately after, 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?
For a simple tool with one documented parameter and no output schema, the description is sufficiently complete. It states the action, ownership constraint, and soft-delete behavior, covering everything an agent needs 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 schema already fully documents store_id as "The ID of the store to delete," so the description does not need to repeat it. The description adds no new parameter-level detail beyond the schema, which is acceptable given 100% schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: "Soft-delete a store owned by your account." It clearly distinguishes the operation from a hard delete and clarifies the ownership scope, so an agent can immediately understand what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when this tool is appropriate: deleting a store while preserving its underlying data. It does not explicitly name alternatives or exclusions, but the soft-delete semantics and account ownership constraint give enough guidance for a single-parameter delete 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?
Annotations already mark the tool as read-only and non-destructive, so no contradiction exists. The description adds the Markdown output format and scope of the instructions, but it does not elaborate on response contents, authentication, or side effects. That is acceptable given the annotation coverage, though it provides only modest additional behavioral detail.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One well-formed sentence carries the action, target, output format, and purpose without repetition. It is front-loaded with 'Retrieve step-by-step setup instructions' and wastes no tokens.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter read-only tool, the description gives enough context: what to retrieve, for which purpose, and in what format. There is no output schema, but the tool is simple enough that the missing response details are unlikely to prevent correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and an empty schema, so there is no parameter ambiguity for the description to resolve. With no parameters, a 4 baseline is appropriate; nothing is missing.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb ('Retrieve'), a specific resource ('custom storefront setup instructions'), and notes the output format (Markdown). It clearly distinguishes this from sibling sales-channel CRUD tools like ecommerce_createASalesChannelV1 or ecommerce_listSalesChannelsV1, which perform actual channel operations rather than returning guidance.
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 conveys the intended scenario: use when connecting a custom sales channel and keeping catalog/orders/shipping/payments in sync via the Ecommerce API. It does not explicitly name alternatives or exclusion conditions, but the use case is clear enough that an agent can select it over the related sales-channel 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?
Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds useful behavioral detail beyond that: results are newest first, returned as summaries, and amounts are in the smallest currency unit. It does not mention pagination defaults or result limits, but covers the key 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?
Three tight sentences with no filler. The main action and ordering are front-loaded, filters are summarized compactly, and the pointer to single-order retrieval earns its place by preventing misuse.
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 read-only list tool with 100% schema coverage, the description covers ordering, summary granularity, currency units, filter categories, and the path to richer order details. Without an output schema, a bit more about pagination or response structure would help, but nothing essential is missing for invoking it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents every parameter in detail. The description broadly mirrors the filter categories but adds no parameter-specific semantics beyond what the schema provides, 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 uses a specific verb and resource: "List a store's orders newest first as summaries." It clearly distinguishes itself from order-detail retrieval by noting that full line items, addresses, and fulfilments require retrieving a single order.
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 gives clear context: this tool lists filtered order summaries, while a single order should be retrieved for detailed line items, addresses, and fulfilments. It does not explicitly name the sibling tool ecommerce_retrieveAnOrderV1, but the guidance is direct 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?
Beyond the annotations (idempotentHint=true, destructiveHint=true, readOnlyHint=false), the description discloses that updates happen in place, omitted variants are unaffected, and prices replace the full existing set. This is important destructive behavior that helps an agent anticipate consequences.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Four sentences with no filler: the main action and scope are front-loaded, followed by the two most important behavioral caveats and the return value. Every sentence adds 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 batch update with no output schema, the description covers the key semantics an agent needs: cap of 100, in-place update by id, untouched omitted variants, full price replacement, and that updated variants are returned. It does not detail response shape or error cases, but the schema handles parameters and the annotations handle destructiveness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need 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 store_id, product_id, and variants, including the price replacement semantics. The description mostly restates those semantics (e.g., 'Prices replace... in full') rather than adding new parameter meaning, so a baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource — 'Update up to 100 existing variants in place by id' — and lists the fields affected (title, inventory, stock tracking, prices). It clearly distinguishes this batch-update tool from sibling variants tools like create/delete/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?
It conveys clear context: this is for batch updates of existing variants, up to 100, with omitted variants left untouched. It does not explicitly name alternatives or state when not to use it, but the batch/existing framing makes the intended use unambiguous.
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?
Annotations already indicate a destructive write operation, and the description adds the critical nuance that passing null clears a value. It also clarifies that the url parameter is exposed as the channel domain, giving useful behavioral detail beyond the structured hints.
Agents need to know what a tool does to the world before 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, followed by the exact fields affected and the null-clearing behavior. Every sentence contributes useful information with 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?
For a straightforward update tool, the description covers what can be changed and how to clear values, while the schema supplies the required IDs. No output schema exists, so return values are not described, but this is a minor gap for a simple mutation.
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 parameters are already well documented. The description adds one meaningful extra semantic: the public url is 'returned as the channel domain,' which helps an agent correlate request and response naming. The rest mostly reinforces the schema's existing null-clearing 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 opens with a specific verb and resource: 'Update a custom sales channel.' It clarifies which fields are mutable (name and url) and is clearly distinct from siblings like ecommerce_createASalesChannelV1 or ecommerce_listSalesChannelsV1.
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 changing an existing sales channel's name or URL, but it does not explicitly state when to use this tool over the create or list siblings, nor does it mention prerequisites such as store ownership. The usage context is present but only by implication.
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?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds behavioral value by clarifying that the tool returns an edit link, not website content or management actions, and that editing is only possible in the Hostinger Horizons interface.
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 core purpose. The only minor redundancy is repeating 'Hostinger Horizons interface' and the concept of editing, but overall every sentence contributes meaningful guidance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter, read-only tool with full schema coverage and no output schema, the description is complete. It explains what the tool returns, when to use it, and the critical limitation that editing must happen in the Hostinger Horizons interface.
Complex tools with many parameters or behaviors need more documentation. Simple tools 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 documents websiteId with 100% coverage. The description does not add parameter-level detail, but it provides useful context about what the returned link is for. With full 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 states a specific verb and resource: it 'gets a link' for editing a website in the Hostinger Horizons interface. This clearly differentiates the tool from other website-related tools like hosting_getWebsiteDetailsV1 or agency-hosting_getWebsiteDetailsV1, which return details rather than an edit link.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says when to use the tool: when the user wants to modify, edit, or add features to an existing website. It does not mention when not to use it or name alternative tools, but the usage context is clear enough for an agent to route correctly.
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?
Annotations already declare readOnlyHint=true, so the description does not need to restate safety. It adds behavioral context by explaining what the tool checks (missing files, plugins, themes) and that it can detect broken installations. This goes beyond the annotations. 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 no filler. It front-loads the purpose in the first sentence, then details what issues are detected, and finally explains how to provide the required parameters. Every sentence contributes useful information, and the structure is 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?
For a read-only validation tool with no output schema, the description covers the core functionality, input requirements, and source of identifiers. It does not describe the return format or any limits (e.g., batch size), but given the simplicity and clear annotations, what is missing is minor and unlikely to hinder correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so parameters are already documented. The description adds value for the software_ids parameter by telling the agent where to obtain the identifiers (GET endpoint, id field), which is not in the schema. It does not add extra meaning for force or username, but the additional context for the key parameter warrants a score above baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool checks whether WordPress installations are valid and working correctly, and even lists the types of issues detected (missing files, broken plugins, themes). This distinguishes it from sibling tools like listing, installing, or deleting installations. The verb and resource are explicit 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 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. It implies usage for validation checks but does not mention when not to use it or name alternatives. It does provide guidance on how to obtain the identifiers, which is helpful, but the when-to-use context is 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?
The description usefully discloses that the operation is asynchronous and that a successful response only means the job was queued. This adds meaningful behavioral context beyond the annotations, which only indicate readOnlyHint=false and destructiveHint=false.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded. The core purpose appears in the first sentence, followed by essential parameter-retrieval guidance and the async caveat. Every sentence earns its place with no wasted wording.
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 three required parameters, no output schema, and clear annotations, the description covers the essential points: what it does, the async job semantics, and where to get the software identifier. Minor gaps remain around the meaning of `username` and how to verify job completion, but these do not severely impair correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds real value by explaining exactly where to retrieve the `software` identifier from an existing API response. It also clarifies `plugin` as a slug. The `username` parameter remains under-explained, but the schema description covers it minimally.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb and resource: 'Deactivate an installed plugin on a WordPress installation.' This distinguishes it effectively from sibling tools like hosting_activateWordPressPluginV1, hosting_installWordPressPluginsV1, and hosting_uninstallWordPressPluginsV1.
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 operational guidance, such as how to obtain the WordPress installation identifier from the list endpoint. However, it does not explicitly explain when to choose deactivation over activation, installation, or uninstallation, leaving tool selection largely to inference from the tool name and siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark readOnlyHint=false and destructiveHint=true, and the description does not contradict them. It adds useful behavioral detail: the tool uploads all plugin files, triggers deployment, and handles upload credentials internally. It does not spell out whether existing plugin files are overwritten, but the destructive annotation covers the general risk and the description meaningfully extends beyond it.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no filler. The core purpose is front-loaded in the first sentence, and the second sentence delivers a high-value operational warning about not calling a separate upload endpoint. 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 tool with three fully documented required parameters and a destructive annotation, this description is largely complete. It tells the agent what the tool does, how it handles credentials, and what not to do. The lack of an output schema is not a major gap, though slightly more detail about the deployment outcome or overwrite behavior would strengthen it 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 description coverage is 100%, so each parameter already has meaningful documentation. The description's mention of 'directory' and 'hosting server' loosely aligns with pluginPath and domain, but it adds no new syntax, format, or relationship information beyond what the schema provides. Baseline 3 is appropriate because the schema carries the parameter-documentation burden.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a precise action: 'Deploy a WordPress plugin from a directory to a hosting server.' It clearly identifies the resource as a WordPress plugin rather than a theme, static site, or generic application, which distinguishes it from many sibling deploy tools. It also explains the mechanism ('uploads all plugin files and triggers plugin deployment') without 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 gives clear context for when to use the tool: deploying a WordPress plugin from a directory. It explicitly warns against using a separate upload-url endpoint or uploading files manually, which is actionable guidance for tool selection. It does not explicitly contrast with sibling deploy tools like theme/static-site/PHP deployments, but the plugin-specific wording makes the intended use fairly 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?
Annotations already signal readOnlyHint=false and destructiveHint=true. The description adds useful behavior beyond that: it uploads all theme files, triggers deployment, supports optional activation, and manages credentials internally. It does not describe exact destructive effects, but the annotation covers the destructive nature and the description adds meaningful 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 three focused sentences with no filler. The main action is front-loaded, and the critical instruction about not calling a separate upload-url endpoint is included without bloating the 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 deploy operation with fully documented parameters and destructive/read-only annotations, the description covers the workflow end-to-end: source directory, deployment trigger, optional activation, and internal credential handling. It does not specify return values or async behavior, but that is not a critical gap for this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all four parameters. The description adds only light mapping by mentioning 'from a directory' for themePath and 'optionally be activated' for activate, but it does not need to provide deeper 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 opens with a specific verb and resource: 'Deploy a WordPress theme from a directory to a hosting server.' It further distinguishes itself from upload-only or install workflows by stating it uploads all theme files, triggers deployment, optionally activates the theme, and works end-to-end without a separate upload-url call.
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 operational guidance: upload credentials are generated internally, and the agent should not call a separate upload-url endpoint or upload files manually. It does not explicitly name sibling alternatives such as install or activate theme tools, but the local-directory deploy use case 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?
Annotations already establish that this is a read-only, non-destructive operation. The description adds that the software identifier goes in the path and can be sourced from the installations endpoint, which is useful, but it does not disclose response shape, pagination, or any rate-limit behavior. This is acceptable but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences. The first states the tool's purpose, and the second provides immediately actionable instructions for the key parameter. No filler or redundant restatement of the title or annotations.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only list operation, the description is mostly complete: annotations cover safety, schema covers parameters, and the description supplies the critical ID provenance. The main gaps are the unexplained username parameter and the absence of any note about what the return payload looks like, but no output schema exists and the operation name makes the return type predictable.
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 value beyond the schema for the software parameter by specifying that it is a path parameter and showing exactly how to obtain it ('from GET /api/hosting/v1/wordpress/installations (the `id` field)'). The username parameter remains only vaguely described as 'username parameter,' but this is partially compensated by the otherwise strong software guidance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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 clear verb 'List' with a specific resource ('available WordPress core updates') and scopes it to 'the specified installation.' This distinguishes it from siblings like hosting_updateWordPressCoreV1 and hosting_showWordPressCoreVersionV1, which perform update and status operations respectively.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly indicates this tool is for listing updates for a particular installation and explains how to obtain the required software identifier from a list endpoint. It does not explicitly contrast with sibling tools or state when not to use it, but the read-only listing intent 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?
The annotations already declare readOnlyHint=true and destructiveHint=false, so the safe read-only nature is covered. The description adds valuable behavioral context by explaining what the response will include: theme status, available updates, and known vulnerabilities. No contradictions with 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 compact and front-loaded: the first sentence states the core purpose and outputs, and the second gives the single key usage detail. 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.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only listing tool with two parameters and no nested objects, the description is largely complete. It covers what the tool returns and how to source the main identifier. The only minor gap is the unexplained 'username' parameter, which prevents 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 covers both parameters at 100%, so the baseline is 3. The description adds useful meaning for the 'software' parameter by specifying it is the WordPress installation identifier and showing how to retrieve it. However, the 'username' parameter remains only described as 'username parameter' in the schema and is not clarified in the 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 states a specific verb and resource: 'List themes installed on a WordPress installation', and usefully enumerates what the listing includes (status, available updates, known vulnerabilities). This clearly distinguishes it from sibling tools like hosting_listWordPressThemesV1, which likely covers available or marketplace 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 clear context for when to use the tool: when listing installed themes on a specific WordPress installation. It also explains how to obtain the required software identifier from the installations endpoint. It does not explicitly name alternatives or state when not to use the tool, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark this as read-only and non-destructive. The description adds meaningful behavioral context: the list is paginated, scoped to a specific website, filterable by states, and the results contain uuids that can be used for log polling. It does not contradict the annotations and goes beyond them by describing the workflow and response linkage.
Agents need to know what a tool does to the world before 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 tight sentences with no filler. The core action and scope are front-loaded, followed by filtering guidance and a cross-reference to the log endpoint. 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 read-only, paginated list endpoint with full schema coverage, the description covers the essential context: what is returned, how to filter, and how to proceed to logs. The only minor gap is that pagination parameters are not explained in the description, but the word 'paginated' plus schema coverage makes this acceptable. Without an output schema, a bit more detail about the response shape could help, but the uuid-to-logs hint partially compensates.
Complex tools with many parameters or behaviors need more documentation. Simple tools need 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 real value for `states` by enumerating valid values and explaining that they filter by build state. It also implicitly ties `username`/`domain` to 'a specific website.' However, it does not add meaning beyond the schema for `page` or `per_page`, which are already adequately described as pagination 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 opens with a specific verb and resource: 'Retrieve a paginated list of Node.js build processes for a specific website.' It clarifies that a build is 'a single run of the Node.js build pipeline,' distinguishing this from deployment or log tools. The scope ('for a specific website') and the mention of the uuid-to-logs workflow further disambiguate it 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 gives clear operational guidance: use the `states` query parameter to filter, and use the returned `uuid` to poll output via the 'Get Node.js Build Logs' endpoint. It explicitly names the follow-up endpoint, which is a useful alternative. However, it does not explicitly contrast this with other listing tools like `hosting_listJsDeployments` or state when not to use it, so it falls just short of a full 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false, idempotentHint=true, and destructiveHint=true, covering the mutation and idempotency. The description adds that the operation is asynchronous and that the database name must be the exact name from the list databases endpoint, which are useful behavioral details beyond the 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 two sentences with no wasted words. The core action and async nature are front-loaded, followed by usage guidance and a parameter constraint. Perfectly sized.
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 maintenance tool with two required params and no output schema, the description covers the when-to-use, the async behavior, and the critical name format. It does not mention how to track completion or response format, but given the simple scope and annotations, 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 descriptions for both parameters. The description reinforces the 'name' requirement but adds no new meaning for 'username' (schema only says 'username parameter'). Given high schema coverage, a baseline of 3 is appropriate; the description provides marginal 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 (repairs corrupted database tables), the resource (database tables), and the asynchronous nature. This distinguishes it from other database tools like change password or delete, and the verb+resource is 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?
It explicitly says 'Use when database errors, crashes, or corruption are reported', giving a clear trigger condition. However, it does not name alternatives or exclusion criteria, so it falls short of a 5 but is above a 3 because the usage context is direct.
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?
Annotations already convey readOnlyHint=false, destructiveHint=true, and idempotentHint=true, covering the core safety profile. The description adds that the target is the Hostinger Tools plugin and explains where to get the software identifier, but it does not add details about side effects, reversibility, 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?
Two concise sentences with the primary action front-loaded. The second sentence provides only the needed lookup guidance without 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 four-required-parameter toggle with no output schema, the description is largely complete: it states what is changed, on what target, and how to resolve a key parameter. It could have referenced the status-checking sibling for verifying current state, but that is not essential for invoking this 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 beyond the schema by explaining that the software identifier can be obtained from a specific listing endpoint, and it clarifies the option applies to the Hostinger Tools plugin. Username remains weakly documented, but the schema at least names it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Enable or disable an AI option' for the Hostinger Tools plugin on a specific WordPress installation. The resource and scope are specific, and the action explicitly differentiates it from the sibling hosting_showAIOptionStatusV1.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides clear operational context by telling the caller how to obtain the WordPress installation identifier via a specific GET endpoint and that it belongs in the path. It does not explicitly name alternatives or give when-not-to-use conditions, but the context is clear enough for selecting 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?
Annotations already declare readOnlyHint=true and destructiveHint=false, covering the safety profile. The description adds behavioral context beyond that: it confirms this is a read of 'current' status, scopes it to the Hostinger Tools plugin, and explains the single-vs-all filtering behavior. It does not describe return format or pagination, but that is a minor gap for a read-only status 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 compact and front-loaded. The first sentence states the purpose clearly, the second explains the filter behavior, and the final sentence covers how to obtain the path identifier. No word is wasted, and it does not repeat the title or annotation 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 is a read-only status check with no output schema, the description provides the essential operational context: scope, optional filtering, and identifier provenance. The main omissions are the meaning of `username` and an explicit pointer to the sibling setter tool, but the agent has enough to invoke this tool correctly with the schema and 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 description coverage is 100%, so the baseline is 3. The description adds meaningful context for `software` by explaining it is the WordPress installation ID obtainable from a specific endpoint, and it clarifies the `option` parameter's filtering effect. However, `username` is left as the unhelpful 'username parameter' in the schema and not enriched by the 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 uses a specific verb and resource: 'Show the current AI option status for the Hostinger Tools plugin on the specified WordPress installation.' It clearly identifies the scope and behavior, and the phrase 'current status' distinguishes it from the sibling setter, hosting_setAIOptionStatusV1. The optional filtering by `option` adds further precision.
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 it: filter by `option` for a single result or omit it for all options. It also tells the user where to obtain the required `software` identifier via the installations endpoint. It does not explicitly name alternatives like hosting_setAIOptionStatusV1, but the read-only intent 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?
Annotations already declare readOnlyHint=true and destructiveHint=false, covering the safety profile. The description adds context about the target scope and how to find the identifier, but does not disclose behavioral details such as return format or error behavior, which the annotations do not cover either.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no wasted words. The first sentence states the purpose, and the second provides essential identifier-sourcing context, keeping the most relevant information 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 read-only status tool, the description covers the main action and how to obtain the primary parameter. It is slightly incomplete because it does not clarify the required 'username' parameter, and with no output schema it does not hint at the expected response shape, leaving minor ambiguity for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds meaningful value beyond the schema by specifying that the 'software' identifier can be obtained from GET /api/hosting/v1/wordpress/installations and corresponds to the 'id' field. However, the 'username' parameter remains only vaguely described as '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 states a specific verb ('Show'), a clear resource ('maintenance mode status'), and a precise scope ('specified WordPress installation'). This clearly distinguishes it from the sibling hosting_toggleMaintenanceModeV1, which changes the mode rather than reporting 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 gives clear context for when to use the tool and explains how to obtain the crucial 'software' identifier from the installations list endpoint. It does not explicitly compare with alternatives like toggleMaintenanceMode, but the read-only purpose is self-evident and the identifier sourcing guidance is practical.
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?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds little behavioral nuance beyond confirming this is a show/status operation and that the identifier is a path value; no side effects or return details are disclosed, but none are needed given the 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 compact, front-loaded with the operation, and every sentence serves a purpose: state what it does and how to obtain the required identifier. No filler or redundant restatement.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter read-only tool with annotations covering behavior, the description is largely sufficient: it identifies the resource and tells where to get the required software ID. The only notable gap is the under-explained `username` parameter and the absence of any output/status value details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the description adds value by explaining that `software` is a path identifier and pointing to the installations list endpoint for its value. However, it does not clarify the `username` parameter beyond the schema's minimal 'username parameter' text.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Show') and identifies the exact resource ('Memcached object cache status') and target ('specified WordPress installation'). This distinguishes it from related toggle and other status tools without 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?
It clearly tells the agent to supply the WordPress installation identifier and where to obtain it (GET /api/hosting/v1/wordpress/installations, `id` field). It does not explicitly name alternatives such as hosting_toggleMemcachedObjectCacheV1, but the read-only 'Show' framing makes the intended context 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?
Annotations already communicate the key safety traits: destructiveHint=true, idempotentHint=true, and readOnlyHint=false. The description is consistent with those and adds the path-location detail for `software`, but it does not elaborate on behavioral consequences such as visitors being locked out. With annotation coverage present, the lack of extra explanation is acceptable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and well organized: action and flag semantics come first, followed by a single useful piece of lookup guidance. Every sentence earns its place, with no repetition of the title or schema.
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 three-parameter toggle with no output schema, the description plus schema covers the action, the state flag, and how to source the required identifier. It is sufficient for an agent to call the tool correctly, though it could improve completeness by noting the visitor-facing impact or pointing to the status-check sibling.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds meaningful value for `software` by clarifying that it is the path identifier and pointing to the exact GET endpoint and `id` field to obtain it. It also reinforces how `enabled` controls the toggle, though it adds nothing about `username`.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action—enable or disable maintenance mode—for a specific resource, a WordPress installation, and ties the behavior to the `enabled` flag. This makes it easy to distinguish from read-only status tools like hosting_showMaintenanceStatusV1 and from other toggles such as cache or cacheless 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?
The intended usage is clear: use this tool when maintenance mode for a WordPress installation needs to be turned on or off. It also provides a practical precondition by explaining how to obtain the required `software` identifier. It does not explicitly mention alternatives or exclusions, but the action is self-contained enough that this is only a minor gap.
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?
Annotations already mark this as read-only and non-destructive. The description adds useful behavioral details beyond those annotations: results are paginated, sorted by timestamp descending, and support multiple filter dimensions. This gives an agent a clearer expectation of 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 with no filler. The primary action and scope are front-loaded, and the supporting filter and ordering information is compact and directly useful.
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 list operation with 10 fully documented parameters and a read-only annotation, the description covers the core invocation context: pagination, filtering, sorting, and the required order scoping. It does not describe return fields, but no output schema exists and an access-log list response is reasonably inferable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents each parameter. The description adds a high-level grouping of filter types (account, date range, protocol, status, deletion flag) but no additional semantic details beyond what the parameter descriptions already provide. 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 identifies the action ('Retrieve'), the resource ('paginated access logs'), and the scoping context ('domain attached to the given mail order'). This distinguishes it from sibling mail log tools like listInboundLogs and listOutboundLogs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use the tool: to fetch access logs for the domain tied to a specific mail order. It does not explicitly name alternatives or state when not to use it, but the access-log scope is evident enough to avoid confusion with other log-list 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?
Annotations already mark the operation as read-only and non-destructive. The description adds useful behavioral detail beyond that: results are paginated, sorted by timestamp descending, and cover both administrative and user actions, which sets accurate expectations without implying 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 short sentences with no filler; the core action and scope are front-loaded, followed by filtering and ordering details. 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 read-only paginated list operation with an 8-parameter schema, the description covers the essential purpose, filters, and ordering. Minor gaps remain: it does not describe the response shape and does not explicitly contrast with sibling log-list tools, though the schema covers parameter semantics.
Complex tools with many parameters or behaviors need more documentation. Simple tools need 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 every parameter and its role. The description restates the filter categories (account, date range, status) but does not add meaningful syntax or precedence 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 uses a specific verb ('Retrieve') plus a precise resource ('paginated account action logs for the given mail order') and clarifies the log scope as administrative and user actions. This distinguishes it from sibling mail log tools such as access, inbound, and mailbox 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 gives clear context: use this tool when you need account action logs for a mail order, optionally filtered by account, date range, or status. It does not explicitly name alternatives or exclusion conditions, but the scope is specific enough to route an agent correctly.
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?
Annotations already signal a safe read-only operation, and the description adds meaningful behavioral context: results are paginated and cover all mailboxes within a mail order. This goes beyond the schema and annotations, though it stops short of describing response structure or default 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?
A single, front-loaded sentence that conveys the action, resource, scope, and pagination without wasted words. It is appropriately concise and structured for an agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple, read-only list tool with one required parameter and a fully documented schema, the description is complete enough for an agent to use it correctly. It could optionally mention that the orderId comes from a mail order resource and describe the output shape, but these are not critical 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 the parameters are already well documented in the schema. The description adds the 'mail order' context and the pagination behavior, but does not provide additional detail beyond what the schema and description together already convey.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid 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'), the resource ('forwarders'), and the scope ('across all mailboxes of a mail order'), which distinguishes it from sibling tools like mail_listAliasesV1 or mail_listMailboxesV1. The pagination aspect is also named, leaving no ambiguity about what this tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context: use it to get a paginated list of forwarders for a mail order. It does not explicitly state when not to use it or name alternatives, but the scope is specific enough for an agent to select it appropriately among the many mail-related list 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?
Annotations already mark readOnlyHint=true and destructiveHint=false. The description adds useful behavioral detail by noting the result is paginated and sorted by timestamp descending, which is not visible in the annotations or 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 focused sentences front-load the main action, list supported filters, and note sort order. There is no filler or repetition of the tool name/title.
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 paginated read-only list with a fully documented 10-parameter schema, the description gives the essential context: scope to a mail order's domain, available filters, and sort order. It does not describe response fields, but no output schema exists and the tool type makes the returned list self-evident.
Complex tools with many parameters or behaviors need more documentation. Simple tools need 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 documents every parameter. The description's filter list (account, date range, status, sender, recipient) restates schema properties without adding format, precedence, or default-value nuance, so it earns the baseline 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 opens with 'Retrieve paginated inbound (received mail) delivery logs,' providing a specific verb, resource, and scoping to the 'domain attached to the given mail order.' The parenthetical '(received mail)' clearly separates it from outbound and action log 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 clearly establishes the context: use this to list inbound mail delivery logs for a mail order's domain. It lacks explicit 'use X for outbound' routing to sibling tools, so it stops short of a 5, but the inbound/received-mail framing is a clear contextual signal.
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?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds value by noting pagination and especially the lag in usage numbers, which is a behavioral nuance an agent must know before interpreting results. This goes beyond the schema and annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with no filler. The primary action is front-loaded, and the use-case and caveat follow naturally. Every sentence adds value and the length is appropriate for a listing operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only list tool with full parameter documentation and safety annotations, the description covers the purpose, the returned data aspects, and a key caveat (lagging usage). It does not detail pagination mechanics, but these are evident from the parameters. It is complete enough for an agent to call 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?
All five parameters have schema descriptions with 100% coverage, so the schema carries the parameter semantics. The description does not add extra detail about how to combine or use parameters beyond what the schema states; it only mentions pagination generically. Baseline of 3 is appropriate given full schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves a paginated list of mailboxes for a mail order, with a specific verb, resource, and scope. It also enumerates the data it returns (status, protocols, resource counts, usage), which distinguishes it from sibling list tools like mail_listForwardersV1 or mail_listAliasesV1 without 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 explains the intended use case: monitoring mailboxes and their attributes, including a caveat about lagging usage numbers. It does not explicitly name alternatives or state when NOT to use this tool, but the context clearly implies this is the mailbox-specific list, so an agent can infer the right choice from the sibling names.
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?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds that the endpoint is paginated and returns status, plan, domain, and expiration details—useful context beyond the annotations. It does not contradict the annotations and adds value by describing what the caller can expect in the 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?
Two sentences, zero filler. The primary action is front-loaded ('Retrieve a paginated list...'), and the second sentence gives a practical use case. Every word earns its place, making it easy for an agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only list operation with six optional, well-documented parameters, the description covers the essential usage context: what it returns and why you'd use it. No output schema exists, but the description lists the key fields returned. It doesn't mention pagination defaults or edge cases, but those are minor for a standard list endpoint. Overall, it's complete enough for an agent to call correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%: every parameter (page, sort, domain, status, is_trial, per_page) has a description. The tool description adds almost nothing beyond the schema – it mentions 'paginated' but that's already implied by page/per_page. Since the schema does the heavy lifting, a baseline of 3 is appropriate; the description doesn't provide extra semantic detail or compensate for gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Retrieve a paginated list of mail orders associated with your account.' It clearly distinguishes this from sibling list-order tools (hosting_listOrdersV1, agency-hosting_listOrdersV1) by explicitly scoping to 'mail orders'. It also lists the key fields returned (status, plan, domain, expiration), giving the agent a precise sense of what this tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states a concrete use case: 'Use this endpoint to monitor your mail services.' This gives clear context for when to invoke it. However, it does not explicitly warn against using other list-order tools or mention when not to use it, though the 'mail orders' qualifier implicitly separates it from hosting/agency-hosting order lists. It lacks explicit 'when not to use' guidance, so a 4 rather than 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint and destructiveHint annotations already establish this as a safe read operation. The description adds valuable behavior beyond that: the list is paginated and the webhook secret is never included, which is important because there is no output schema to convey this. It does not discuss response shape or pagination defaults, but the secret caveat is meaningful.
Agents need to know what a tool does to the world before 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 sentences deliver the action, the resource scope, the available filters, and the key response caveat. There is no filler, and the most important 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?
For a straightforward read-only list tool with fully documented parameters and no output schema, the description covers scope, pagination, filters, and the most important response detail (secret exclusion). It does not specify default page sizes or exact response item fields, but those are not essential for invoking the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters. The description reinforces that orderId scopes the list to a mail order and names the mailbox/status filters, but it does not add formats, defaults, or constraints beyond what the schema provides. This is an adequate baseline case.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and 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 operation as retrieving a paginated list of webhooks scoped to a mail order, which is distinct from sibling operations like mail_getWebhookV1 or mail_createWebhookV1. The verb 'Retrieve' plus the resource 'webhooks' makes the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context for when to use it: when you need a list of webhooks for a mail order, with optional mailbox/status filtering. It does not explicitly state when not to use it or name alternatives like mail_getWebhookV1, but the context is strong enough for an agent to select it correctly.
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 key behavioral trait beyond annotations: omitted optional fields are cleared, meaning the replacement is not additive but wholesale. It also clarifies activation behavior for starts_at and indefinite duration for ends_at. Annotations already signal read-only=false and destructive-hint=true, and the description coherently builds on those without contradiction.
Agents need to know what a tool does to the world before 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 filler. The core replacement behavior is front-loaded, and the omission-clear rule is stated immediately after. Every sentence contributes meaningful 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 description, combined with complete schema parameter documentation and annotations, gives an agent enough to call the tool correctly: what it does, which fields are replaceable, and what omission means. The lack of an output schema is not a major gap for a replacement operation, though explicit mention of the existing-autoreply requirement would make it slightly 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 each parameter already has a baseline explanation. The description adds extra value by explaining the replace-and-clear semantics that apply to all omitted optional fields, and by restating the practical effect of omitting starts_at and ends_at. This goes beyond the 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 opens with 'Replace the autoreply with the given content and schedule', which names a specific verb, resource, and scope. It clearly distinguishes this update operation from sibling tools like mail_createAutoreplyV1, mail_deleteAutoreplyV1, and mail_listAutorepliesV1.
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 semantics of omitting starts_at and ends_at, which helps an agent know how to configure activation and duration. However, it does not explicitly say when to prefer this over creating or deleting an autoreply, or mention any prerequisites such as an existing autoreply ID. The usage context is implied rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With annotations already marking this as mutable, non-read-only, idempotent, and destructive, the description adds valuable behavioral context: only included fields are changed, omitted fields are preserved, and null clears the description. This goes beyond the structured annotations without contradicting them.
Agents need to know what a tool does to the world before 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 tightly written sentences carry the essential semantics: partial update behavior and the null-clearing special case. There is no filler, duplicated title content, or unnecessary elaboration.
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 mutation tool with a heavily documented schema and safety-related annotations, the description is sufficient for correct invocation. It lacks a return-value description, but there is no output schema and the missing details are not critical for calling 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 each parameter is already documented. The description adds cross-parameter semantics by clarifying partial-update behavior, which is not inferable from individual property descriptions. This meaningfully helps an agent understand that omitted fields are not reset.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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 'Partially update a webhook', which names a specific verb, resource, and update semantics. It clearly distinguishes this from sibling tools like mail_createWebhookV1, mail_deleteWebhookV1, and mail_getWebhookV1.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool: when you need to modify an existing webhook. However, it does not explicitly state exclusions or point to alternatives such as create or delete. The usage context is clear but not fully articulated.
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?
Annotations already show this is not read-only and not destructive. The description adds useful behavioral details beyond that: the operation applies immediately and is idempotent—assigning an existing tag succeeds without duplicating it.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and well-structured: a one-line statement of purpose, followed by a relevant contrast to the bulk endpoint and a useful idempotency note. 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 single-contact tagging operation, the description covers the core behavior, immediate execution, and idempotency. No output schema exists, but the tool's effect is clear enough for an agent to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with each UUID parameter minimally described. The description adds no additional parameter-level semantics, but the schema already provides enough labels for the agent to understand the three required identifiers.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action—'Assign a tag to a single contact'—with a clear verb and resource. It also distinguishes itself from the bulk endpoint, so an agent can tell this 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly contrasts this tool with the bulk endpoint and notes that it is applied immediately rather than queued. This gives clear selection guidance for the single-contact case, though it does not name the sibling tool 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?
Annotations only indicate a read-write operation with no destructiveness. The description adds meaningful behavioral details: only template metadata is returned, and the stored HTML is sanitised so the saved template can differ from what was submitted. This goes beyond what the schema and annotations already convey.
Agents need to know what a tool does to the world before calling it. Descriptions 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 with the core purpose. Every sentence contributes: the primary action, the relationship to campaigns, the sanitisation behavior, and the return value guidance. 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?
The description is largely complete for a creation tool: it explains what a template is, how it is used by campaigns, that HTML is sanitised, and what the response contains. A minor gap is that it does not explicitly point an agent to reach_listProfilesV1 or reach_listEmailTemplatesV1 for resolving profileUuid or checking existing templates, but this is not critical for invoking 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 the schema already documents all three parameters. The description adds useful cross-tool context around the returned uuid and template_uuid, but does not materially clarify the parameters themselves beyond what the input schema provides. This matches the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Create an email template') and resource ('in a profile'), then clarifies its purpose: holding the HTML body a campaign reuses. It clearly distinguishes the tool from campaign creation tools like reach_createADraftCampaignV1, even without naming a sibling explicitly.
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 usage context: the template can be created before any campaign exists, and the returned uuid is later used as template_uuid for a campaign. It does not explicitly compare against alternatives or state when not to use it, but it provides enough context for an agent to decide when this tool is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=true and destructiveHint=false, and the description does not contradict them. It adds useful behavioral context by clarifying that the response covers campaign setup and delivery progress, while excluding engagement metrics. It does not describe the full response envelope, but the field list compensates.
Agents need to know what a tool does to the world before 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 carry all the essential information: the operation, the returned attributes, the semantic scope, and a redirect to another endpoint. The core verb and resource are front-loaded, and there is no 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 two-parameter read-only detail endpoint, the description names the target object, the main data fields, and the companion endpoint for metrics. It could be slightly more explicit about the response shape, but the listed fields largely cover what an agent needs.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline of 3 applies. The description adds no parameter-level meaning, and the schema descriptions are merely 'Profile uuid parameter' and 'Campaign uuid parameter,' which are minimally informative. Still, for a detail lookup, the two identifiers are self-evident.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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 precise verb and resource: 'Get a single campaign.' It specifies what is included (sender, subject, template reference, targeting, delivery progress), which clearly distinguishes it from listing campaigns and from the campaign statistics/performance 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 explicitly states that opens, clicks, and unsubscribes should be retrieved from the campaign statistics endpoint, providing a clear when-not-to-use signal. It does not explicitly name the list endpoint as an alternative, but 'single campaign' makes the contrast with listing 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?
Annotations declare readOnlyHint=true and destructiveHint=false, so the read-only nature is already known. The description adds a valuable behavioral detail: counts are unique contacts rather than raw events, with an illustrative example. This goes beyond the annotations and helps avoid misinterpretation of the returned numbers.
Agents need to know what a tool does to the world before calling it. Descriptions 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 filler. It front-loads the core purpose and then provides a crucial clarification about counting semantics. Every word earns its place, and the structure is 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 read-only metric retrieval tool with no output schema, the description adequately covers the returned metrics and the unique-contact counting rule. It could optionally have mentioned the response format or whether rates are percentages, but given the annotations already cover the read-only behavior, this is sufficiently complete for an agent to call 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 description coverage is 100% (both parameters have descriptions), but those descriptions are minimal ('Profile uuid parameter' and 'Campaign uuid parameter'). The tool description adds no further meaning about these parameters. Since the schema already documents them at a baseline level, a score of 3 is appropriate, as the description does not need to compensate for a coverage 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 resource (campaign performance) and the specific metrics (delivery, opens, clicks, unsubscribes and their rates). The verb 'get' is explicit, and the list of metrics distinguishes this from sibling tools like reach_getCampaignDetailsV1, which would focus on campaign metadata rather than performance numbers.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description conveys a clear context: it is for retrieving performance metrics of a specific campaign. It does not explicitly mention alternatives or exclusions, but the metric list leaves little ambiguity about when this tool is appropriate. With many reach_* siblings present, a more explicit comparison to reach_getCampaignDetailsV1 or reach_listCampaignsV1 would have elevated the score, but the current wording is sufficient for most agents.
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?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is clear. The description adds valuable behavioral context beyond annotations: it explains that each automation includes contact-journey counts (entered, moving through, finished, failed) and explicitly states these are not email engagement metrics. This prevents misuse and sets expectations for the returned data, which is more than the annotations provide.
Agents need to know what a tool does to the world before calling it. Descriptions 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. The first sentence immediately states the core purpose. The second paragraph adds a crucial clarification about the counts and directs users to the correct endpoint for engagement metrics. Every sentence earns its place, with 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?
For a paginated list endpoint with well-described parameters and read-only annotations, the description covers the key behavioral nuance (counts vs. engagement metrics) and the scope (per profile). It doesn't explicitly explain pagination defaults or response structure, but since there is no output schema and the description already clarifies the data content, only a minor gap remains. A bit more detail on page/per_page defaults could push it to 5.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so each parameter (profileUuid, page, status, per_page, sort_direction) is already well documented with descriptions and enums. The description does not add any parameter-specific meaning beyond what the schema provides; it focuses on the return data instead. With high 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 states a specific action ('Get a paginated list'), a specific resource ('automations in a profile'), and immediately distinguishes it from related siblings like listAutomationSteps and getAutomationDetails by focusing on list semantics and profile scope. It also clarifies that the counts included are contact-journey metrics, not engagement metrics, which further differentiates it from campaign-statistics 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 gives an explicit exclusion: for opens, clicks, and unsubscribes, use the campaign statistics endpoint instead. While it doesn't name the exact sibling tool (e.g., reach_getCampaignPerformanceV1), it provides clear guidance on when not to use this tool and frames the primary use case (listing automations and their journey counts). Slightly more explicit alternative naming would improve 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?
Annotations already mark readOnlyHint=true and destructiveHint=false; the description adds that the result is paginated, that meta.total counts filter-matching contacts, and that calling without filters yields the profile's total contact count. No contradiction.
Agents need to know what a tool does to the world before 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-load the core action, then add filter options and response semantics. Every sentence earns its place and there is no 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 read-only list endpoint, the description plus a fully described schema is largely sufficient: pagination, filtering, and the meaning of meta.total are covered. It doesn't spell out the response list field or pagination defaults, but with no output schema those are minor gaps for tool selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All 6 parameters already have schema descriptions (100% coverage), so the baseline is 3. The description paraphrases tag_uuid, subscription_status, and search as filter options but adds no syntax, defaults, or parameter behavior 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?
States a specific operation ('Get a paginated list'), resource ('contacts belonging to a profile'), and available filters. This clearly distinguishes it from broader contact-list siblings like reach_listContactsV1 and segment-scoped listers without relying on the title alone.
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 profile-scoping phrase gives clear when-to-use context, and the filter sentence explains how to adjust for status, tag, or email. It stops short of explicitly naming alternatives or saying when not to use them, so it doesn't reach 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark readOnlyHint=false and destructiveHint=false. The description adds the create/update nuance, which is more precise than the annotations alone. It does not disclose overwriting behavior or other side effects, but with annotation coverage this is a minor 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 only two sentences with no wasted words. The core function is front-loaded, followed by the use case, making it 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?
For a simple three-parameter tool with no output schema, the description covers purpose and use case sufficiently. Annotations provide the write/non-destructive safety profile. A missing note about the response format is minor and does not block 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 input schema has 100% parameter description coverage, so the baseline is 3. The description adds only that the domain/IP are for reverse DNS lookup, which slightly clarifies the domain parameter but does not add format or syntax 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 states the specific action 'Create or update a PTR (Pointer) record' with a clear resource and scope ('for a specified virtual machine'). It differentiates from the sibling VPS_deletePTRRecordV1 by covering create/update rather than 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?
Clear context is provided: 'Use this endpoint to configure reverse DNS lookup for VPS IP addresses.' This tells the agent when the tool is relevant, but it does not explicitly name alternatives or exclusions, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true and idempotentHint=true, so the destructive nature is known. The description adds valuable behavioral context: 'Any virtual machine that has this firewall activated will lose sync with the firewall and will have to be synced again manually.' This goes beyond the annotations by warning about the side effect on VMs, which is critical for an agent to consider before invoking.
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 short and front-loaded with the core action in the first sentence. The second sentence conveys an important side effect. The third sentence ('Use this endpoint to remove specific firewall rules.') is redundant with the first, adding minor noise. Nonetheless, the overall structure is efficient and easy to parse, so it earns a 4 rather than 5.
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 two required parameters, the description is complete. It states the action, the exact scope (specific rule), and the critical side effect (VM sync loss). Annotations cover destructive behavior, and no output schema is needed. An agent has all necessary context to correctly invoke the tool and understand consequences. No significant gaps exist.
Complex tools with many parameters or behaviors need more documentation. Simple tools need 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 (ruleId and firewallId) having descriptions ('Firewall Rule ID' and 'Firewall ID'). The description does not add any extra meaning or context about the parameters beyond what the schema already provides, so it meets the baseline for high schema coverage but adds no additional value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Delete a specific firewall rule from a specified firewall,' specifying the exact verb and resource. It implicitly differentiates from sibling tools like VPS_deleteFirewallV1 (delete entire firewall) and VPS_replaceAllFirewallRulesInGroupV1 by emphasizing 'specific' rule deletion. The additional side-effect mention reinforces the tool's scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage 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 ('Use this endpoint to remove specific firewall rules'), which directs the agent to this operation over similar ones. However, it does not explicitly name alternatives or state when NOT to use it (e.g., for deleting the whole firewall), so it lacks explicit exclusion guidance but is sufficiently clear for the intended 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?
Annotations already declare destructiveHint=true, idempotentHint=true, and readOnlyHint=false. The description adds a meaningful behavioral consequence beyond the annotations: after deletion, reverse DNS lookups will no longer return the previously configured hostname. This helps the agent anticipate the operation's effect on DNS resolution.
Agents need to know what a tool does to the world before 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 accomplish full clarity: action, consequence, and usage guidance. There is no redundancy, repetition, or filler, and key information is front-loaded in the first sentence.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter delete endpoint, the description covers the purpose, effect, and use case. There is no output schema, but the description does not explain what response to expect; however, this is a minor gap for a delete operation and the parameter meanings are fully covered by 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?
Schema description coverage is 100% and both parameters have descriptions ('IP Address ID' and 'Virtual Machine ID'), so the schema carries the parameter meaning. The description adds only general context that the record belongs to a virtual machine, but does not supplement or clarify parameter semantics beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource: 'Delete a PTR (Pointer) record for a specified virtual machine.' It clearly states the scope of the operation and semantically distinguishes itself from the sibling VPS_createPTRRecordV1 by naming the inverse action without 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 provides clear context: 'Use this endpoint to remove reverse DNS configuration from VPS instances.' This tells the agent when to invoke it, though it does not explicitly mention alternatives or when-not-to-use conditions.
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?
Annotations already declare readOnlyHint=true and destructiveHint=false, covering the safety profile. The description adds behavioral context by stating the response includes 'current status, port mappings, and runtime configuration,' which helps the agent anticipate the output. This goes beyond the structured 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 three sentences: purpose, response content, and usage. Every sentence adds meaningful information with no filler or redundancy, and the key scoping is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only list operation with two parameters, the description adequately covers the tool's action, return data type, and intended use. It does not mention error conditions or pagination, but for this straightforward tool, the information provided 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?
Both parameters (projectName, virtualMachineId) have descriptions in the input schema, so coverage is 100%. The description does not add any further parameter details, so it relies on the schema as expected for a 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 verb 'retrieves' and the resource 'list of all containers' for a specific Docker Compose project. It distinguishes the tool from siblings like VPS_getProjectListV1 (list projects) and VPS_getProjectContentsV1 by specifying the container focus.
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 an explicit use case: 'monitor the health and state of all services within your Docker Compose project.' It does not explicitly mention alternatives or when not to use the tool, but the purpose is clear enough for an agent to select it appropriately.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds meaningful behavioral detail: logs are aggregated, recent, organized by service name with timestamps, and capped at 300 entries. This goes beyond the annotations without contradicting them.
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 front-loaded with the core purpose and adds useful response details and use cases. It is slightly verbose in places, but every sentence contributes relevant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with two clearly documented parameters, the description is complete. It explains the response shape, the 300-entry limit, the grouping by service, and the intended use cases, so an agent has enough context to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and both parameters have clear descriptions in the schema. The tool description does not need to repeat parameter meanings, 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 states a specific verb and resource: 'Retrieves aggregated log entries from all services within a Docker Compose project.' It clearly distinguishes this tool from log-related siblings by emphasizing project-wide aggregation and Docker Compose scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage context: 'Use this for debugging, monitoring application behavior, and troubleshooting issues across your entire project stack.' However, it does not explicitly mention when not to use it or name alternatives, so it stops short of full routing 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?
Annotations already declare readOnlyHint=false, destructiveHint=true, and idempotentHint=true, covering the safety profile. The description adds a link to password requirements on the recreate endpoint, but it does not disclose additional behavioral consequences such as sessions being invalidated or services being restarted. This is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded: the first sentence states the core action, the second provides the password requirement reference, and the third gives usage context. No redundant or filler 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 two-parameter mutation with annotations covering its destructive and idempotent nature, the description is mostly complete. It provides purpose, usage context, and password constraints. Minor gaps include no explicit contrast with VPS_setPanelPasswordV1 and no indication of what response the caller should expect, but these are not critical for selecting and invoking 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 the baseline is 3. The description adds value by linking to the recreate endpoint for password requirements, giving the agent a concrete reference for password validation rules beyond the simple schema description 'Root password for the virtual machine'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Set root password') on a specific resource ('a specified virtual machine'), and further clarifies the purpose as updating administrator credentials. It distinguishes itself naturally from the sibling VPS_setPanelPasswordV1 by specifying root password rather than panel password.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly states when to use the endpoint ('Use this endpoint to update administrator credentials for VPS instances'). It does not explicitly mention alternatives or exclusion conditions, but the context is clear enough for an agent to select it over unrelated 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?
Annotations already convey readOnlyHint=false and destructiveHint=false; the description adds that containers are brought up in dependency order and only stopped services are started. It does not go into idempotency or asynchronicity, but the core behavior is 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 short, purposeful sentences: what it does, how Compose handles ordering, and when to use it. There is no fluff 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?
For a two-parameter start operation with a 100%-covered schema, the description is nearly complete. It could mention what happens if the project is already running or what the return value looks like, but these are relatively minor for a simple start action.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents virtualMachineId and projectName, including the project name character restriction. The description adds no parameter-specific semantics beyond referring to a Docker Compose project, so the 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?
The description opens with a specific verb-resource-scope statement: 'Starts all services in a Docker Compose project that are currently stopped.' This clearly differentiates it from sibling operations like VPS_restartProjectV1 and VPS_stopProjectV1.
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 gives explicit use cases: resume a previously stopped project or start services after a reboot. It does not name when-not-to-use or point to alternatives such as VPS_restartProjectV1, so it falls just short of full routing 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?
Annotations already mark this as destructive and non-read-only. The description adds useful context beyond those flags: it preserves data/configurations, shuts down gracefully, and stops containers in reverse dependency order. This meaningfully informs an agent about side effects and safety.
Agents need to know what a tool does to the world before 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. The core action is front-loaded, and each sentence adds distinct value: what it stops, how it behaves, and when to use it. No redundant or filler 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 two-parameter tool with fully documented schema and clear annotations, the description is largely complete. It explains the operation's effect, preservation guarantees, shutdown ordering, and intended use. It could go slightly deeper on what happens if the project is already stopped, but this is not a significant gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so both parameters are already well documented. The description does not add additional parameter-level detail, but with full schema coverage, the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('stops all running services') and a specific resource ('Docker Compose project'), and emphasizes preservation of container configurations and data volumes. This clearly distinguishes it from sibling tools like VPS_deleteProjectV1 or VPS_stopVirtualMachineV1.
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?
Gives explicit guidance: 'Use this to temporarily halt a project without removing data or configurations.' It does not explicitly name alternatives or say when not to use it, but the 'temporarily halt' framing makes the use case 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?
With annotations already marking this destructive (destructiveHint=true) and idempotent (idempotentHint=true), the description adds a useful edge case: 'If Monarx is not installed, the request will still be processed without any effect.' This goes beyond what the structured hints alone convey.
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 first two sentences are front-loaded and useful; the third sentence largely repeats the first. Still, the entire definition is compact and easy to scan.
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 one-parameter tool with annotations carrying the destructive/idempotent safety profile and no output schema, the description covers what the tool does, the target virtual machine, and the no-op case. Nothing essential is missing for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%: the single parameter virtualMachineId is already described as 'Virtual Machine ID.' The description only restates 'a specified virtual machine' and adds no parameter-level semantics 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?
States a specific verb+resource: 'Uninstall the Monarx malware scanner on a specified virtual machine.' It clearly differentiates itself from the nearby install operation by naming the product and the action, so an agent can tell it apart from VPS_installMonarxV1.
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 gives explicit context: 'Use this endpoint to remove malware scanner from VPS instances.' It does not explicitly name alternative tools or exclusion conditions, but for this tool the intended use is unambiguous.
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?
Annotations already establish a mutating but non-destructive operation; the description adds the key guarantee that data volumes are preserved during recreation. It also discloses that containers are recreated, giving the agent a realistic picture of the side effect.
Agents need to know what a tool does to the world before 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 sentences front-load the core action, then add a safety guarantee and concrete use cases. There is no filler and every sentence contributes to tool selection or invocation.
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 two-parameter action with a clear safety profile, the description is sufficient for correct invocation. It could mention asynchronous behavior or return value since there is no output schema, but 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 description coverage is 100%: projectName documents allowed characters and virtualMachineId is defined. The tool description does not add anything beyond the schema, so the 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 a specific verb ('Updates'), names the resource ('Docker Compose project'), and explains the mechanism (pulling latest image versions and recreating containers). This clearly distinguishes it from sibling lifecycle operations like VPS_restartProject, VPS_startProject, or VPS_stopProject.
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 lists three use cases: deploying application updates, applying configuration changes, and refreshing container images. It does not state exclusions or name alternatives, but the context is clear enough for an agent to select it over start/stop/restart/delete project tools.
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 adds valuable behavioral context beyond the annotations: the deletion is permanent, removes all data including users, and is idempotent so deleting a non-existent database succeeds without error. This fully discloses the destructive nature and the idempotency edge case.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no filler. The first sentence states the core action and scope, and the second sentence clarifies the important idempotent behavior. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter delete operation with no output schema, the description is complete. It covers the destructive outcome, the resource type, the scope, and the idempotent behavior, giving an agent everything needed to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and both parameters, website_uid and database_name, already have clear descriptions. The tool description itself adds no additional parameter semantics, 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 what the tool does: permanently deletes a MySQL database and all its data from an Agency Plan website, including its users. The verb 'deletes' plus the specific resource (MySQL database) and scope (Agency Plan website) make the purpose unambiguous and distinct from sibling tools like database user 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 the tool: when a database needs to be removed from an Agency Plan website. However, it does not explicitly compare against alternatives such as deleting a database user or deleting the website itself, and it offers 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.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes well beyond annotations by explaining the async deletion process, the immediate transition to a deleting state, and background removal of server resources. It also reinforces the destructiveHint with 'permanently deletes,' and is consistent with the idempotentHint.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with no filler. The core action and permanence are stated first, followed by the important asynchronous behavior.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter destructive operation, the description is complete: what it deletes, permanence, and the asynchronous lifecycle are all covered. No output schema exists, but none is needed 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% and the parameter is already described as 'Agency Plan website UID.' The description adds no additional parameter detail, but with full schema coverage, the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('permanently deletes') and a specific resource ('Agency Plan website'), making the tool's scope clear. It does not explicitly contrast with sibling hosting_deleteWebsiteV1, but the 'Agency Plan' qualifier provides enough differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly indicates this tool is for Agency Plan websites, which gives the agent context for selecting it. It does not explicitly state 'use this instead of hosting_deleteWebsiteV1' or list exclusions, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds useful behavioral context: pagination, inclusion of shared-access websites, and the warning that the response shape differs per platform via the platform field.
Agents need to know what a tool does to the world before calling it. Descriptions 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 organized: core purpose first, then scope, response-shape caveat, and filter guidance. Every sentence adds information without redundancy, and the most decision-relevant facts are 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?
With no output schema, the description carries more burden for explaining return values. It notes that the response shape differs per platform and points to the platform field, but it does not describe fields, pagination metadata, or item structure. For a list endpoint this is a noticeable 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 documents all parameters at 100% coverage, but the description adds value with concrete examples such as website_types=wordpress and website_types=nodejs, and advises combining order_ids, states, or domain for targeted results. This goes beyond simply restating parameter names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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: 'Retrieve a paginated list of Agency Plan websites' and names the three platforms (H5G, Builder, Horizons). It further clarifies the access scope, including shared access from other hosting accounts, which distinguishes it from similar list endpoints 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?
The description clearly explains the data scope: it returns websites from your own hosting accounts and from other accounts sharing access with you. It also gives practical filtering guidance using website_types and combining filters, though it does not explicitly state when to prefer this tool over a 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?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds behavioral context: it explains the pinger_url field facilitates latency measurement and that results include a 'code' to be used as datacenter_code, which is beyond the schema and aids correct usage. It doesn't describe pagination or return format, but for a list tool this is acceptable given read-only 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 efficiently structured: the first sentence states the primary purpose, and the second paragraph explains the practical usage with pinger_url and code selection. Every sentence adds value—no fluff or repetition. The key information is front-loaded, making it easy for an agent to quickly grasp the tool's function.
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 read-only list operation with a single parameter, the description is complete. It explains the purpose, provides the practical workflow (ping, compare, pick code), and mentions the key fields returned (pinger_url, code). The parameter is fully documented in the schema, and the absence of an output schema is mitigated by the description highlighting relevant fields. Nothing essential is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already describes order_id as 'Agency Plan order ID' with 100% coverage, so the schema carries the parameter meaning. The description mentions 'given Agency Plan hosting order' which reinforces this but doesn't add new syntax or format details beyond the schema. Thus a baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action ('Lists') and resource ('datacenters available for provisioning a new website') scoped to a given Agency Plan hosting order. It distinguishes itself from VPS_getDataCenterListV1 by explicitly tying to Agency Plan hosting, and explains the 'pinger_url' and 'code' fields, making its 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?
It clearly indicates when to use it (before creating a website setup on an Agency Plan order) and how to use the results (ping pinger_url, compare latency, pick nearest, use code as datacenter_code). It doesn't explicitly state when not to use it or name alternatives, but the scoping to Agency Plan hosting and the reference to website setup provide clear contextual 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?
Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds useful context beyond those annotations by clarifying the scope: it lists versions available for installation and is tied to Agency Plan websites, differentiating it from update-related and PHP-version siblings.
Agents need to know what a tool does to the world before 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 with no filler. It front-loads the core action, then adds the two key qualifiers: "WordPress core versions" and "Agency Plan website," which are necessary for correct tool selection.
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 read-only list operation with one fully documented parameter and a safety profile already covered by annotations, nothing needed to call this tool correctly is missing. The lack of an output schema is not a gap because the return value is self-evident from the name and description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the single required parameter, website_uid. The description adds no parameter-specific detail, but the schema already fully documents the parameter, 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 states a specific verb and resource: "Lists the WordPress core versions available for installation on an Agency Plan website." It clearly distinguishes itself from related siblings like hosting_listAvailableWordPressCoreUpdatesV1 by specifying installation availability rather than updates.
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 use case clear: an agent should call this when it needs WordPress core versions available for installation on an Agency Plan website. It does not explicitly name alternatives or when-not-to-use conditions, but the qualifiers are strong enough that an agent can route to this tool correctly.
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 goes well beyond the annotations by disclosing concrete behavioral effects: traffic stops immediately, files and database are preserved, other linked domains remain accessible, and the only-domain edge case is called out. This is exactly the kind of context an agent needs before invoking a destructive 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 compact, well-structured, and front-loaded with the primary action. Every sentence earns its place by adding a distinct behavioral or edge-case detail, with no redundant wording.
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 mutation with annotations already marking it destructive and non-read-only, the description provides all essential operational context: immediate traffic impact, preservation of files/database, and the only-domain edge case. No return schema exists, so explaining return values is not 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 covers both parameters with 100% description coverage, so the baseline applies. The description adds no additional parameter-level detail beyond what the schema provides, but none is needed here.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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: 'Unlinks a domain from the specified Agency Plan website.' It clearly distinguishes this from the obvious sibling, agency-hosting_linkDomainToWebsiteV1, by describing the inverse operation and clarifies the scope (Agency Plan websites only).
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 primary use case (removing a domain from a website) and provides important context, such as files/database being preserved and other domains staying accessible. However, it does not explicitly state when to use this tool versus alternatives like linkDomainToWebsiteV1 or changeWebsiteDomainV1, so guidance remains 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?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds scope ('all subscriptions') and a use case but does not disclose extra behavioral details like pagination, response format, or authentication needs. This is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences with no filler. The core action is front-loaded, and the second sentence gives a practical purpose. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, read-only list endpoint, the description is complete: it states what is retrieved, the account scope, and the intended use. No output schema exists, but the absence of parameters and mutations makes this 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?
There are zero parameters and the schema is empty, so there is nothing for the description to clarify. With no parameters, the baseline is 4 and the description needs no parameter-specific 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 'Retrieve a list of all subscriptions associated with your account,' using a specific verb and resource. This distinguishes it from sibling billing tools like payment-method or catalog listing. 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?
'Use this endpoint to monitor active services and billing status' provides explicit context for when this tool is appropriate. It does not mention alternatives or when not to use it, but the use case is clear enough for a read-only list operation.
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?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the read-only nature is covered. The description adds useful context by noting the snapshot contains DNS zone records and serves historical viewing, which clarifies what kind of data is returned without contradicting the 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 two short sentences with no filler. The first sentence front-loads the core action and resource, and the second sentence adds the practical use case. Every phrase earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with two clearly described required parameters and no output schema, the description is complete. It explains what the tool returns (DNS zone records from a snapshot) and when to use it, so an agent has enough context to call it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so both 'domain' and 'snapshotId' are already documented. The description adds minimal new meaning beyond the schema—only that a 'particular' snapshot is retrieved—so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Retrieve') and resource ('particular DNS snapshot'), and clarifies that the result includes the contents of DNS zone records. The word 'particular' distinguishes it from listing all snapshots, and 'view historical DNS configurations' separates it from restore and update 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 instructs when to use this endpoint: 'Use this endpoint to view historical DNS configurations for domains.' It gives a clear use case, but it does not explicitly name alternatives like DNS_getDNSSnapshotListV1 for listing snapshots or DNS_restoreDNSSnapshotV1 for restoring them.
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?
Annotations already signal readOnlyHint=false, idempotentHint=true, and destructiveHint=true. The description adds value by explaining the cancel condition and clarifying that the domain stays in the account, which mitigates the destructiveHint by showing the domain itself is not lost.
Agents need to know what a tool does to the world before calling it. Descriptions 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: direct action first, then the key precondition, a clarifying consequence, and a final statement of intent. No sentence is wasted.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter mutation with annotations and no output schema, the description covers what the tool does, when it can be used, and the expected effect on the domain. Nothing essential for correct invocation is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the only parameter is already documented as 'Domain name.' The description adds no new parameter-level detail, so the schema carries the burden as expected.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource: 'Cancel an outgoing move for a specified domain,' and reinforces intent with 'withdraw a move you no longer want to complete.' This clearly distinguishes the tool from related domain move operations like start, accept, or reject.
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 an explicit precondition: the move can only be cancelled while the receiving account has not accepted it yet. It also states when to use it, but does not explicitly name alternative tools or situations where cancellation is no longer possible.
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?
Annotations already declare readOnlyHint=false, idempotentHint=true, and destructiveHint=true, so the description doesn't need to restate these. It adds useful behavioral context by explaining that the default profile is pre-selected for the TLD during new domain registrations, which goes beyond a mere action statement. No contradiction with annotations is present.
Agents need to know what a tool does to the world before calling it. Descriptions 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 precise sentences, front-loaded with the main action and followed by a brief behavioral explanation and usage motivation. Every sentence contributes value, with no filler or 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 simple one-parameter mutation tool with no output schema and well-covered annotations, the description is complete. It explains what the tool does, the effect after execution, and why an agent would call it. No critical details are missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%: the only parameter whoisId is fully described as 'WHOIS ID' in the schema. The description adds no extra meaning to the parameter. Since the schema already documents it well, the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Set WHOIS contact profile as default.' It also explains the implication that the default profile is 'pre-selected for the TLD it belongs to when registering new domains.' This distinguishes it from related tools like domains_unsetDefaultWHOISProfileV1 and domains_changeWHOISProfileForDomainV1.
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 rationale: 'Use this endpoint to avoid picking contact information for every registration.' This tells an agent when to use the tool. However, it doesn't explicitly mention when not to use it or point to alternatives (e.g., unset). Still, the guidance is clear enough for typical 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?
Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds meaningful behavioral context beyond annotations: suggestions are AI-generated and vary between calls, and the endpoint rate limit is 90 requests per minute. This helps the agent set expectations without contradicting the 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 four short sentences, each earning its place: purpose, nondeterministic behavior, rate limit, and when to use. The most important 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 simple read-only suggestion tool with two fully documented parameters and safe annotations, the description covers purpose, usage context, behavioral variability, and rate limiting. Nothing essential is missing for an agent to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so both parameters are already documented in the input schema. The description adds little beyond restating the domain-based input and suggestion purpose, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool suggests available domain names based on an existing domain, which is a specific verb and resource. It also differentiates from the sibling domains_suggestDomainNamesFromADescriptionV1 by emphasizing 'a domain name you already have in mind' and 'close 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?
The description gives explicit when-to-use guidance: 'Use this endpoint when the domain you wanted is taken and you need close alternatives.' However, it does not explicitly name alternative tools or state when not to use this endpoint, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations, the description usefully clarifies that unsetting the default is not destructive to the profile itself: 'The profile itself is kept, it is only no longer pre-selected for its TLD.' This adds meaningful behavioral nuance and aligns with the destructiveHint annotation without contradicting it.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: the core action is front-loaded, followed by a clarifying non-destructive note and a practical use-case sentence. Every sentence earns its place with no redundant filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter, mutation-style tool with annotations covering idempotency and destructiveness, the description provides sufficient operational context. It explains what happens to the profile, what changes for the TLD, and why an agent would invoke this endpoint, so nothing critical is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter, whoisId, is fully described in the schema as 'WHOIS ID', giving 100% schema coverage. The description does not add parameter-specific guidance beyond the tool's context, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Unset WHOIS contact profile as default') and clearly distinguishes it from deleting the profile by noting 'The profile itself is kept'. It also contrasts with setting a default, making the endpoint's purpose unambiguous among sibling tools like domains_setWHOISProfileAsDefaultV1 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 gives clear usage context: 'Use this endpoint to stop reusing contact information for new registrations.' It does not explicitly mention when not to use it or list alternatives, but the intended scenario is clear enough for an agent to select this tool appropriately.
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 annotations only provide basic read/write/destructive hints, so the description carries the behavioral burden. It reveals that generation is asynchronous, that the tool returns a website URL and ID, that the chat reply must be exactly one sentence, that no code should be written, and how failures should be handled. This is comprehensive behavioral disclosure with 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is longer than average, but it is well-sectioned and front-loaded with the core purpose and usage trigger. The following behavioral instructions and technology constraints are verbose but each section serves a distinct purpose, from post-call reply formatting to strict stack enforcement. It could be tightened slightly without losing 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 lack of an output schema, the description provides the essential post-invocation knowledge: the tool returns a URL and ID, generation is asynchronous, and the agent must immediately share the URL with a specific one-sentence response. It also covers failure handling. A small gap is that it doesn't mention any follow-up status-checking tool or polling flow, though the sibling list includes horizons_getWebsiteV1.
Complex tools with many parameters or behaviors need more documentation. Simple tools 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 'message' parameter is already fully documented in the schema at 100% coverage, including the nested text/type structure and the requirement for a detailed project specification. The description adds nothing specific about the parameter format or how to construct the message, so the schema does the heavy lifting. The technology-stack constraints are relevant context but not 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 states a specific verb and resource: 'Create new Hostinger Horizons website from the given message.' It also names the concrete user intents that should trigger it ('landing page, blog or any other type of application'), and the Hostinger Horizons qualifier distinguishes it from sibling website-creation 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit trigger conditions: 'Use this tool when user asks you to create a website, landing page, blog or any other type of application.' It doesn't explicitly name alternative tools or say when not to use it, but the trigger is clear and the asynchronous behavior and expected reply structure further guide 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?
Annotations already declare destructiveHint=true, and the description adds meaningful detail about the destructive scope: it removes plugins, themes, staging websites, and other related data. The phrase 'optional file and database removal' is somewhat unclear because no corresponding parameter appears in the schema, but it does not contradict the 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 compact: one sentence states the action and destructive scope, and a short paragraph explains how to find the required identifier. There is no filler 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?
For a destructive two-parameter tool, the description covers the deletion scope and how to obtain the software identifier. However, it leaves gaps: the 'username' parameter is not explained beyond the tautological schema text, and 'optional file and database removal' is mentioned without indicating how that option is controlled given the schema exposes no such flag.
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 schema already documents both required parameters. The description adds extra value for the 'software' parameter by explaining how to obtain the identifier (from GET /api/hosting/v1/wordpress/installations, using the 'id' field). It adds nothing about 'username', but the high schema coverage keeps the baseline reasonable.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid 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 specific resource ('WordPress installation'), and it expands the scope by naming what is removed: plugins, themes, staging websites, and related data. This distinguishes it from generic website deletion tools like hosting_deleteWebsiteV1.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context: use this tool to delete a WordPress installation and its associated components. It also provides actionable guidance for obtaining the software identifier from the installations list endpoint. However, it does not explicitly contrast this with sibling delete tools 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.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, and the description reinforces and extends this by disclosing that symlinks, oversized files, non-text file types, and secret-containing files are refused and not returned. This gives the agent important behavioral expectations beyond the 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 two focused sentences: the first delivers the core action and scope, and the second details behavioral limitations. No filler or redundant restatement of the title.
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 read-only, single-file retrieval tool with 100% schema coverage and safety annotations, the description provides enough context: what it returns, where paths are relative to, and which file categories are excluded. The lack of an output schema is mitigated by the explicit 'content' focus.
Complex tools with many parameters or behaviors need more documentation. Simple tools need 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 useful context for 'path' by noting it is relative to the document root, but does not add significant new meaning for from_line or max_lines 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 states a clear, specific action: 'Get a single file's content, relative to a website's document root.' This distinguishes it from file-listing tools like hosting_listWebsiteFilesAndDirectoriesV1 and from other hosting/DNS/mail tools in the sibling list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage context is implied: this tool is for retrieving one file's content, and the constraint of being relative to the document root clarifies scope. However, it does not explicitly name alternatives or state when not to use it, such as when listing files or reading cron job output 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?
Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds valuable behavioral context beyond that: each installation includes a `valid` flag and, when invalid, a `validationError`, and a newly appearing installation indicates WordPress is ready. This goes beyond the minimal safety profile.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with a clear purpose, then adds practical usage guidance, and finally a useful note about the response's validity fields. Every sentence earns its place and there is no redundant wording.
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 read-only listing tool with fully documented optional parameters, the description is complete. It explains the main use case, how to poll for readiness, how to filter, and what key fields appear in the response. No output schema exists, but the description covers the essential return semantics.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already fully documents domain, username, and ownership. The description only lightly rephrases filtering by username and domain to narrow results to a specific website and does not mention the ownership parameter, so it 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 a specific verb and resource: 'List WordPress installations accessible to the authenticated client.' It clearly differentiates this from sibling tools like hosting_listWebsitesV1 by focusing specifically on WordPress installations and adds a distinct polling 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?
The description explicitly states when to use the tool: to discover existing WordPress installations and to poll for installation status after calling the install endpoint. It does not explicitly name alternatives or exclusions, but the usage context is clear enough for an agent to select it correctly.
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?
Beyond the annotations, the description discloses important behavior: a confirmation email is sent, the catch-all is not active until confirmed, and a domain can have only one catch-all. These are non-obvious side effects and constraints an agent must know before calling the tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, each earning its place: what the catch-all does, the confirmation requirement, and the one-per-domain limit. No redundant or speculative content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool with no output schema, the description is complete: it explains the mechanism, activation delay, confirmation step, and uniqueness constraint. An agent has enough information to decide when and how to invoke it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already fully describes the single parameter as 'Mailbox resource ID', so the schema carries the semantic load. The description adds minimal parameter-specific value beyond naming 'given mailbox', which is acceptable given 100% schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Create') and resource ('catch-all'), and clearly explains what the catch-all does: routes all messages to unknown domain addresses to a given mailbox. This distinguishes it from related sibling tools like mail_createAliasV1 and mail_createForwarderV1.
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 it: when you want all unknown-address mail to route to one mailbox. However, it does not explicitly mention alternatives or conditions for preferring another tool, such as mail_createForwarderV1 or mail_createAliasV1.
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?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds that results are paginated and span all mailboxes of an order, which is useful behavioral context beyond the schema and annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that states the action, resource, scope, and pagination without unnecessary words. It is front-loaded and every part contributes useful information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only list operation with complete schema coverage and clear annotations, the description provides what an agent needs to call the tool correctly. The return value is implied by 'Retrieve a paginated list of catch-alls,' and no output schema is required for invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all three parameters. The description adds no additional parameter-level meaning, but the existing schema descriptions are sufficient, giving the baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Retrieve'), names the resource ('catch-alls'), and defines the scope ('across all mailboxes of a mail order'). This clearly distinguishes it from sibling tools like mail_createCatchAllV1 and mail_deleteCatchAllV1.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context for when to use the tool: to list catch-alls within a mail order. It does not explicitly name alternatives or exclusion criteria, but the resource and action are specific enough that an agent can infer the correct 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?
Annotations already mark the tool as read-only and non-destructive, so the baseline burden is lower. The description adds meaningful behavioral details: results are paginated, sorted by timestamp descending, scoped to the domain attached to the mail order, and filterable by multiple criteria. No contradiction exists.
Agents need to know what a tool does to the world before 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 focused sentences: the first states the purpose and scope, the second lists filters and sorting. Every sentence adds value, and the most important 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 read-only list tool with a fully documented schema, the description covers the essential operational facts: resource, scope, pagination, filtering, and ordering. No output schema is present, but the description still gives enough for an agent to call the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description mentions filtering by account, date range, status, sender, and recipient, but these concepts already appear in the schema; it adds no new detail such as parameter format or precedence 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 a specific verb ('Retrieve'), a precise resource ('outbound (sent mail) delivery logs'), and the scope ('for the domain attached to the given mail order'). It also differentiates from the sibling inbound/access/action log tools by explicitly saying 'outbound' and 'sent mail'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context: use this when you need paginated outbound delivery logs for a domain linked to a mail order, with several filtering dimensions. It does not explicitly state when not to use it or name alternatives like mail_listInboundLogsV1, but the context is unambiguous enough for an agent to select it.
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 important behavioral characteristics beyond the annotations: the previous secret is invalidated immediately, the new secret appears only in this response, and it is used as a bearer token on deliveries. This is exactly the kind of side-effect and security-relevant context an agent needs before calling the tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences deliver the core action, the critical invalidation side effect, and the important one-time return behavior. There is no fluff or repetition of structured metadata, and the most important operational constraint is stated upfront.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple: one documented parameter, no nested objects, and no output schema. The description fully covers what the agent needs to know to call it safely and correctly, including the irreversible nature and the one-time visibility of the new secret.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the single parameter webhookId is already documented in the input schema as 'Webhook ID (returned when the webhook was created).' The description does not add further parameter-level meaning, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource: 'Regenerate the secret of a webhook.' This clearly distinguishes it from sibling operations like getWebhook, updateWebhook, deleteWebhook, and testWebhook. An agent can immediately understand what this tool does and how it differs.
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 usage scenario through the verb 'regenerate' and the consequence that the previous secret is immediately invalidated, but it does not explicitly state when to choose this tool over updateWebhook or other webhook operations. No alternatives are named. The context makes the purpose evident, but the guidance is not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are neutral (readOnlyHint=false, destructiveHint=false), so the description carries the behavioral burden. It discloses that a test delivery will be sent, that the result is returned, and that requests are rate limited upstream. This adds useful operational context beyond the annotations, though it does not describe the exact success or failure response shape.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences. The first states the core action and return behavior; the second adds a meaningful rate-limit warning. No filler or redundant restatement of the tool name or title.
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 covers the essential context: what the tool does, what it returns, and a rate-limit caveat. The webhookId parameter is fully documented in the schema. Nothing critical is missing for an agent 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?
Schema coverage is 100% and the webhookId property already has a clear description ('returned when the webhook was created'). The tool description only references 'the webhook URL' without adding further parameter detail. Given the high schema coverage, the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Send a test delivery to the webhook URL and return the result.' This clearly distinguishes it from webhook CRUD siblings like mail_createWebhookV1 or mail_getWebhookV1 by focusing on the testing 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 clearly implies when to use it: when the user wants to test whether a webhook URL receives deliveries. It also adds a relevant caveat about upstream rate limiting. It does not explicitly name alternatives, but no sibling tool performs the same test action, so the usage context is clear 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?
Annotations only provide generic readOnlyHint=false and destructiveHint=false. The description adds meaningful behavioral context: the campaign is created as a draft, nothing is sent, no contact is touched, and it has no audience yet. This goes beyond the annotations and helps the agent understand the side effects of the call.
Agents need to know what a tool does to the world before 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 paragraphs are front-loaded with the core action and followed by relevant exclusions. Every sentence earns its place, and there is no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a create-draft tool, the description, schema, and annotations together cover what the agent needs: profile context, draft behavior, what fields are not involved, and the non-destructive nature. No output schema exists, but this is a straightforward creation call and the absence of return-value details is not a serious gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3 and the description does not need to restate parameter meanings. It adds no per-parameter detail beyond the schema, which is acceptable because the schema already fully documents each field.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource: 'Create a campaign in a profile' and immediately clarifies that it creates a draft, distinguishing it from campaign-read, campaign-update, and other reach creation tools. The title and tool name are reinforced with meaningful scope rather than merely repeated.
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 targeting and scheduling are not part of this request and that the draft is finished and sent from the Reach interface. This tells the agent this tool only stages a draft, not a send-ready campaign. It does not name a sibling alternative, but the exclusions are clear enough for the given tool family.
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 adds important behavioral detail beyond the annotations: it discloses that stored field values are deleted, choice-type options are deleted, and contacts themselves are unaffected. This is valuable because destructiveHint only signals danger without specifying side effects. It does not over-explain and stays consistent with the 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 compact and front-loaded: the primary action appears in the first sentence, followed by two crucial behavioral clarifications. Every sentence earns its place, and there is no redundant restatement of the title.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter destructive action with no output schema, the description covers everything needed: the target resource, the cascading deletion behavior, and the explicit non-effect on contacts. No critical operational detail is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so both parameters are already documented by the input schema. The description does not add parameter-specific detail about fieldUuid or profileUuid, but their names and the tool context make their roles reasonably clear. This matches the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource: 'Delete a custom contact field.' It clearly distinguishes this from reach_updateAContactFieldV1, reach_createAContactFieldV1, and reach_deleteAContactV1 by identifying the exact object being deleted. No ambiguity remains about what this tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies when to use this tool: when the goal is to remove an entire custom contact field. The cascade explanation that field values and choice-type options are also deleted helps prevent misuse, such as expecting to delete only a single value. It does not explicitly name alternatives, but the context is strong enough.
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?
Annotations already convey destructive and idempotent behavior; the description adds valuable context that only the segment definition is affected and contacts are preserved. No contradiction with 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?
Three short sentences with no filler; the main action is front-loaded and the important side-effect detail follows immediately.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-UUID destructive operation with no output schema, the description plus annotations fully cover what the tool does, what it affects, and what it does not affect. No missing information is needed to call 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 already describes both parameters with 100% coverage. The description adds no further parameter-level meaning, so it stays at the schema-dependent 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?
States a specific action ('Delete a segment') on a clear resource, amplified by the title 'Delete a profile segment'. The clarification that only the segment definition is removed distinguishes this from sibling contact-deletion tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains the scope of the deletion and explicitly notes that matched contacts are untouched, which tells an agent this is not the tool for removing contacts. It does not name a concrete alternative, but the behavioral distinction is clear enough for selection.
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?
Beyond the annotations, the description reveals important behavior: removing the tag from every contact, preserving contacts, and being idempotent even for nonexistent tags. This gives an agent a clear mental model of what happens when the tool is invoked.
Agents need to know what a tool does to the world before calling it. Descriptions 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 primary action and cascade effect come first, followed by two essential clarifications. Every sentence earns its place without 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?
This is a simple two-parameter destructive operation, and the description covers the core scope, side effects, and idempotence behavior. With no output schema required and annotations already marking destructiveness, nothing essential is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The schema provides parameter names and types, and the description adds little beyond implying that the tag exists within a profile context. The parameter descriptions themselves are minimally informative but the schema still covers them.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Delete a tag') and the exact resource affected, including the cascade behavior ('remove it from every contact carrying it'). This clearly distinguishes it from related tag tools like reach_renameATagV1 or reach_removeAContactFromATagV1.
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 the tool should be used, but does not explicitly mention alternatives or state when not to use it. The note that contacts are not deleted is useful context, but there is no direct routing between this and the other tag-related 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?
Annotations already declare readOnlyHint=true and destructiveHint=false, covering the safety profile. The description adds actionable behavioral context by specifying the return contents (tags and custom field values), which is not available from the annotations. It doesn't contradict anything and provides useful detail about what the tool returns, so it goes beyond the baseline.
Agents need to know what a tool does to the world before calling it. Descriptions 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 primary action, the second elaborates what is returned. Every word earns its place, there is no fluff, and the core purpose is front-loaded. It is appropriately sized for the tool's simplicity.
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 read-only operation with two required parameters and no output schema, the description fully explains what the agent can expect: full contact attributes, tags, and custom field values. There is no missing information about side effects (annotations cover safety), errors, or pagination (not applicable for a single contact fetch). The description is comprehensive for this tool's 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 both parameters have descriptions, but those descriptions are minimal ('Contact uuid parameter', 'Profile uuid parameter'), essentially restating the parameter names. The tool description adds no further semantic detail about the parameters beyond the context that this is for a single contact in a profile. Baseline 3 is appropriate because the schema nominally covers parameters, but neither schema nor description adds meaningful semantics beyond naming.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid 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 the full details of a single contact' with a specific verb and resource. It explicitly lists what is returned (contact attributes, tags, and custom field values), which distinguishes it from sibling tools like reach_listContactsV1, reach_createANewContactV1, or reach_updateAContactV1. The purpose is unambiguous and well-differentiated.
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 for retrieving a single contact's details, and the sibling namespace makes the alternative (list for multiple contacts) obvious. However, it does not explicitly mention when not to use this tool or suggest an alternative, so it's clear context without explicit exclusions. A score of 4 fits: clear context, no 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?
Annotations already mark this as read-only and non-destructive. The description goes beyond annotations by warning about the deprecation, the forced fallback to the client's default profile, and the inability to read other profiles' segments. These are important behavioral caveats that an agent needs to know before invoking.
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 reasonably concise and front-loads the core purpose before the deprecation warning. The segment-purpose sentence is helpful context but somewhat redundant with the title and first sentence, so it is not perfectly lean.
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 read tool with strong annotations and a clear deprecation warning, the description is nearly complete. It lacks any mention of the response shape or fields, but the tool's purpose makes return values fairly predictable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need 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 segmentUuid described as 'Segment uuid parameter'. The description confirms the segment is identified by UUID but adds little beyond the schema. Baseline 3 is appropriate because the schema already carries the parameter 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 that the tool retrieves details of a specific segment by UUID, naming both the resource and the operation. It provides a useful scope limitation ('cannot target a profile... cannot read segments of any other profile') that helps distinguish it from profile-scoped segment tools, though it does not name a specific sibling tool directly.
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 deprecation notice explicitly tells the agent when not to use this tool (when targeting a specific profile) and provides the exact replacement endpoint. This is strong, actionable guidance that routes the agent to the alternative, leaving little to inference.
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?
Annotations already declare this a read-only, non-destructive operation. The description adds useful behavioral detail about the response: returned UUIDs are used to set values on contacts, and choice fields expose their selectable options. No contradiction with 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 compact, front-loaded with the core purpose, and every sentence adds value: context about custom fields, the update flow, and choice options. No redundant or filler wording.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter read-only list tool without an output schema, the description explains what is returned, how the returned UUIDs are used, and what choice fields offer. Nothing essential is missing for an agent to decide to call 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 coverage is 100% and the single required parameter profileUuid is documented as 'Profile uuid parameter'. The description reinforces that fields are scoped to a profile but adds no additional parameter-level semantics, matching the baseline for full schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific action and resource: get the custom contact fields defined in a profile. This clearly differentiates from siblings like reach_listContacts or reach_listContactGroups, and from field mutation tools such as reach_createAContactField.
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: custom fields store attributes on contacts, and the returned UUIDs are consumed by the contact update endpoint. It does not explicitly name alternatives or state when not to use the tool, but the intended use 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds valuable behavioral context: the endpoint is paginated, returns basic contact info, always falls back to the default profile, and cannot list contacts of other profiles. This goes beyond the structured annotations without contradicting them.
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 front-loads the core purpose and keeps the deprecation warning in a separate, clearly marked paragraph. It is mostly efficient, though phrases like 'list of contacts' are repeated and the middle sentence adds only modest 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?
Despite having no output schema, the description provides enough context for correct invocation: pagination, filters, deprecation, and the recommended replacement. It does not detail page size or response shape, but for a read-only list endpoint with fully documented optional parameters, the missing details are minor.
Complex tools with many parameters or behaviors need more documentation. Simple tools need 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 confirms that group_uuid and subscription_status act as filters, but it adds little beyond that; page is not mentioned at all. Since the schema carries the semantic weight, a baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the operation as 'Get a list of contacts' and specifies the optional filters (group and subscription status), making the resource and action explicit. It also differentiates itself from profile-scoped contact listing by noting the endpoint cannot target a profile and falls back to the default 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?
The deprecation notice is explicit: this tool cannot target a profile and should be replaced with `GET /api/reach/v1/profiles/{profileUuid}/contacts` instead. This gives clear when-not-to-use guidance and names the alternative, which is exactly what an agent needs to route correctly.
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?
Annotations already signal read-only and non-destructive behavior. The description adds meaningful behavioral detail beyond that: results are sorted most recently updated first, the list is not paginated, and only metadata is returned without exposing template content. This gives the agent accurate expectations before invoking.
Agents need to know what a tool does to the world before 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 add value: the first states the purpose and ordering, the second defines the domain concept, and the third covers pagination, return scope, and downstream usage. There is no filler or repetition of the title.
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 read-only list operation with one parameter and no output schema, the description covers what the agent needs: ordering, non-pagination, metadata-only return, and how the result should be used downstream. Combined with the read-only annotation, nothing critical is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter `profileUuid` is described in the schema as 'Profile uuid parameter,' which is generic. The description contributes the context that templates belong to a profile but does not explain how to discover or format the profileUuid. With 100% schema coverage, the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
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: 'Get a list of the email templates in a profile, most recently updated first.' It clearly defines what a template is and is easily distinguished from sibling tools like reach_createAnEmailTemplateV1, which creates templates rather than listing them.
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 usage context: templates are the reusable email bodies campaigns are built from, and the returned `uuid` is meant to be used as `template_uuid` when creating a campaign. It does not explicitly call out alternatives or exclusions, but the downstream use case makes it clear when this listing tool is needed.
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?
Annotations already declare destructiveHint=true, readOnlyHint=false, and idempotentHint=true. The description adds valuable context beyond that: the operation is irreversible, deletes all project data, and cleans up containers, networks, volumes, and images. There is no contradiction with the 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?
Three short sentences: the core action first, the irreversible destruction warning second, and the usage guidance last. Every sentence earns its place and there is no redundant wording.
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 destructive operation with a fully described schema and annotations covering safety, the description provides all necessary context: what gets deleted, the irreversibility, and when to use the tool. No output schema is needed for such a straightforward 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?
The schema covers both parameters completely: projectName has a format constraint and virtualMachineId has a clear description. The description does not add parameter-level detail, but with 100% schema coverage the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('removes'), a clear resource ('Docker Compose project'), and the exact scope: stopping all containers and cleaning up networks, volumes, and images. This distinguishes it from nearby siblings like VPS_stopProjectV1 or VPS_deleteFirewallV1, even without naming them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says when to use the tool: 'Use this when you want to permanently remove a project and free up system resources.' It does not name non-destructive alternatives or give exclusion criteria, but the wording makes the distinction from stopping or restarting obvious.
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 annotations already mark the operation as destructive and idempotent. The description adds valuable context beyond those hints by clearly stating what is destroyed — the account-level key — and what is not affected: the key on the virtual machine. This is exactly the kind of side-effect boundary that helps an agent reason about consequences.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loads the most important caveat before the usage statement. It loses a point because 'Delete a public key from your account' and 'Use this endpoint to remove unused SSH keys from account' are semantically redundant.
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 destructive operation with annotations covering idempotence and destructiveness, the description provides the essential side-effect context. There is no output schema, but the response shape is not critical for this kind of delete operation. It is complete enough 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 schema already describes the single parameter 'publicKeyId' as 'Public Key ID' with 100% coverage. The description adds little parameter-specific meaning, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Delete a public key from your account.' The bold caveat explicitly scopes the operation by stating it does not remove the key from a virtual machine, which helps distinguish this from VM-level key 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?
It gives a clear usage directive: 'Use this endpoint to remove unused SSH keys from account.' It does not name alternative tools or state explicit exclusions, but the intended context is clear enough for an agent to decide when this endpoint applies.
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?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the read-only nature is covered. The description adds useful context about returning all data centers and supporting pre-deployment location selection, but it does not disclose details like response shape, pagination, or authentication requirements beyond what annotations provide.
Agents need to know what a tool does to the world before calling it. Descriptions 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 with no filler. The primary action is front-loaded ('Retrieve all available data centers') and the second sentence adds a meaningful use case. Every sentence contributes 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 zero-parameter, read-only list endpoint, the description fully supports correct invocation. It states what the tool returns, why an agent would use it, and the sibling context makes its VPS-specific role clear. No output schema is present, but the simplicity of the tool means nothing critical 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?
The tool has zero parameters and the schema coverage is 100%, so there are no parameter semantics to clarify. The description correctly focuses on the operation rather than inputs, matching the baseline for a parameterless tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource: 'Retrieve all available data centers.' It also clarifies the VPS-specific scope by stating this is for viewing location options 'before deploying VPS instances,' which distinguishes it from sibling tools like hosting_listAvailableDatacentersV1.
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 view location options before deploying VPS instances.' It does not explicitly name alternative tools or exclusion conditions, but the use case is unambiguous enough for an agent to know when to select 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?
Annotations already indicate this is a mutating but non-destructive operation. The description adds meaningful behavioral context by explicitly stating that data volumes and network configurations are preserved while containers are refreshed, and that containers are stopped and started in dependency order. This goes beyond the structured annotations without contradicting them.
Agents need to know what a tool does to the world before calling it. Descriptions 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 earning its place: what the tool does, what is preserved, and when to use it. The main action is front-loaded, and there is no filler or redundant restatement of the tool name.
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 operation with no output schema and low complexity, the description provides everything an agent needs: the operation, the resource scope, the non-destructive behavior, and usage scenarios. The schema covers the parameter requirements, so no critical invocation details are missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with both parameters already described: projectName as the Docker Compose project name and virtualMachineId as the VM ID. The description does not add extra parameter-level semantics, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('restarts') and a clear resource ('all services in a Docker Compose project'), distinguishing it from VM-level operations like VPS_restartVirtualMachineV1 and from project lifecycle tools like VPS_startProjectV1 and VPS_stopProjectV1. The resource and scope are unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear use context: 'apply configuration changes or recover from service failures.' It does not explicitly mention when not to use it or name alternative tools, but the guidance is sufficient for an agent to understand the intended scenario.
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?
Annotations already cover read-only, idempotent, and destructive traits. The description adds valuable behavioral context beyond annotations, especially the no-op behavior on non-panel OS VMs and the delegated password-requirements link. It does not contradict the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded with the core action. The final sentence is somewhat redundant with the first, but overall every clause earns its place and the edge-case warning 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?
For a two-parameter write operation with no output schema, the description covers the essential context: what it does, the no-op edge case, and the password constraints. It could mention return behavior or session impact, but annotations and simplicity keep the gap small.
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 schema already documents both parameters. The description adds meaningful parameter-level guidance by linking to password requirements from the recreate endpoint, which is not present in the schema. This goes beyond the baseline for full schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb-resource pair: 'Set panel password for a specified virtual machine.' It further clarifies the scope by distinguishing panel credentials ('configure control panel access credentials') from other password-related operations like root passwords, which matches the sibling tool set.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context for when the call has effect: if the VM does not use a panel OS, the request is processed without effect. It also states the intended use case. It does not explicitly name alternatives such as VPS_setRootPasswordV1, but the panel-specific framing makes the appropriate context 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?
Annotations already indicate a mutating, destructive, and idempotent operation. The description adds meaningful behavioral context by warning that the operation fails if the VM is not currently in recovery mode, and by explaining the resulting state change back to normal operation. This is valuable beyond the annotations, though it does not detail any other 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 and well-structured: a direct first sentence states the action, a second sentence flags the failure condition, and a third sentence provides the purpose and expected outcome. No filler or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool without an output schema, the description is complete: it states the action, the precondition, and the intended result. Nothing essential is missing for an agent to decide when and how to call this 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 description coverage is 100% and the single parameter `virtualMachineId` is documented as "Virtual Machine ID." The description only references "a specified virtual machine" without adding further semantic detail, so the schema carries the full weight for parameters. A baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource: "Stop recovery mode for a specified virtual machine." It further clarifies the outcome by noting the operation "exit[s] system rescue mode and return[s] VPS to normal operation," which distinguishes it clearly from related VPS lifecycle 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 states when to use the tool: "Use this endpoint to exit system rescue mode and return VPS to normal operation." It also gives a key precondition: calling it on a VM not in recovery mode will fail. It does not explicitly name an alternative such as VPS_startRecoveryModeV1, but the usage 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark it read-only and non-destructive; the description adds behavioral context on top: the tool is meant to be polled, completion is represented by a `completed` status, and the resulting `website_uid` identifies the new website. It doesn't mention polling intervals or failure states, but the read-only profile lowers the burden.
Agents need to know what a tool does to the world before 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 filler. The first delivers the core purpose, and the second gives the exact polling behavior, with the key output (`website_uid`) front-loaded near the completion condition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only status poll, the description covers enough: what it returns, when to call it, and what to look for at completion. There is no output schema, so mentioning `status` and `website_uid` is valuable; only a small amount of detail like non-completion states or polling cadence is absent.
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 by specifying that setup_uuid is the one 'returned from the provisioning request,' giving the agent provenance for that parameter beyond the schema's one-line label.
Input schemas describe structure but not intent. Descriptions should explain non-obvious 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 opens with a specific verb and resource: 'Returns the current status of an Agency Plan website setup.' It further clarifies the domain by referencing the setups endpoint and the terminal signal (status becomes completed, website_uid identifies the new website), which differentiates it from getWebsiteDetails and other listing 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?
It gives explicit polling guidance: 'Poll this endpoint using the setup_uuid returned from the provisioning request until status becomes completed.' It does not name alternative tools or exclusion conditions, so it stops short of a 5, but the intended usage 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?
Annotations already signal destructiveHint=true, but the description adds crucial detail: 'Website contents are overwritten by the archive contents' and the required pre-upload step. This goes beyond the annotation by specifying the exact destructive scope and operational prerequisite. No contradiction with 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 compact and front-loaded: the first sentence states the purpose, followed by a clear prerequisite, effect, and supported formats. No fluff or redundant content; 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 destructive import with two parameters and no output schema, the description covers the essential requirements: the upload prerequisite, the overwrite behavior, and supported archive types. It lacks explicit error handling or return value info, but these are not mandated given the absence of an output schema. The description is nearly complete, though the directory inconsistency slightly reduces 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 description coverage is 100%, so baseline is 3. The description adds value by emphasizing that archive_name must already be uploaded (and referencing the .h5g/ directory) and that website_uid is the Agency Plan identifier, reinforcing the schema text. The slight inconsistency between 'root directory' and '.h5g/' is minor but doesn't detract significantly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid 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 ('Imports'), the target resource ('Agency Plan website'), and the source ('already-uploaded archive'). It differentiates from sibling tools by specifying Agency Plan scope and the archive-based import method, leaving no ambiguity about what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/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 the website's root directory via file browser first') and explains the effect ('Website contents are overwritten'). While it doesn't explicitly compare to alternative import tools, the Agency Plan qualifier and archive requirement effectively guide usage, and supported archive types are listed. Missing explicit 'when not to use' guidance, 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?
Annotations (readOnlyHint: true, destructiveHint: false) already declare the safe read nature. The description adds the behavioral nuance that results are determined by the server the order is hosted on, which is useful context. No contradictions exist, and for a simple list operation, the description adds sufficient transparency beyond 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 two sentences with no redundant wording. The purpose is front-loaded, and the usage guidance follows concisely. 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?
For a simple one-parameter read tool with no output schema, the description covers the core purpose, scoping, and usage context. It does not describe the response format, but that is not critical for a listing endpoint, and the tool's simplicity lowers the burden. It is adequately complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter, order_id, has 100% schema description coverage ('Agency Plan order ID'). The description does not add extra meaning beyond mentioning the order context, which is already in the schema. Since coverage is complete, the baseline of 3 applies, and the description does not elevate 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 lists PHP versions for websites under an Agency Plan order, determined by the hosting server. It uses a specific verb ('Lists') and resource ('PHP versions'), and explicitly differentiates itself from the website-scoped equivalent, making it distinguishable from siblings without ambiguity.
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: use before creating a website, and for an existing website call the website-scoped versions endpoint instead. This directly addresses when to use this tool versus an alternative, leaving no room for misuse.
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 adds substantial behavioral detail beyond the annotations: it discloses automatic resolution of the current profile, failure if roles are not on the same profile, IRTP verification for owner contact changes, and asynchronous processing. These are exactly the kind of behavioral traits an agent 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?
The description is concise and well-structured. It front-loads the core purpose, then explains behavior and caveats in short, scannable sentences. No filler or redundant wording beyond a mild restatement in the final 'Use this endpoint' sentence.
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 mutation with no output schema, the description covers essential operational context: registry submission, failure mode, IRTP trigger, and asynchronous behavior. The only gap is that it does not indicate what the asynchronous response contains or how to track the operation, but this is minor given the simplicity of the parameters and 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 description coverage is 100%, so the baseline is 3. The description mostly restates the schema's parameter meaning (domain, contact roles, WHOIS profile ID) and adds only one useful cross-parameter constraint: the roles must currently be on the same profile. This is helpful but does not elevate parameter semantics 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 a specific verb and resource: 'Change WHOIS contact profile for a domain.' It further clarifies the exact operation—repointing contact roles to a new WHOIS profile—and distinguishes it from WHOIS profile management tools by emphasizing the domain-level 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?
It clearly states when to use the endpoint: 'Use this endpoint to move a registered domain onto different contact information.' It does not explicitly name alternatives or exclusions, but the context is sufficiently clear to avoid confusion with profile CRUD or default-profile 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?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is known. The description adds behavioral context beyond this, specifically that all statuses are returned including completed ones. It does not contradict annotations. While it doesn't detail pagination or response format, for a zero-parameter read-only endpoint this is sufficient additional transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences with no wasted words. The primary purpose is front-loaded in the first sentence, followed by a clarifying detail (all statuses) and a concrete use case. It is concise and well-structured, making it easy for an agent to quickly grasp the tool's function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple zero-parameter read-only list operation, the description capably explains what the tool does and why it would be used. It mentions that all statuses are returned, which helps set expectations. However, it does not mention potential pagination or response structure, but given the lack of an output schema and the simplicity of the operation, this is a minor gap. The annotations cover the safety profile, so overall completeness is high.
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 no properties, so schema coverage is 100% (vacuously). With zero parameters, the description does not need to explain any parameters. Baseline for 0 parameters is 4; the description adds no parameter-specific info, but none is required. The tool has no inputs, so the description is complete in this regard.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid 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 and resource: 'Retrieve all domains other Hostinger accounts are moving to your account.' It also specifies the list nature ('all domains') and distinguishes from sibling tools like domains_getIncomingDomainMoveV1 (which likely handles a single move) and domains_getOutgoingDomainMoveListV1 by focusing on incoming moves. The addition of 'Moves of every status are returned' further clarifies scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear use case: 'Use this endpoint to find domains waiting for you to accept them.' This indicates when the tool is appropriate. However, it does not explicitly mention alternatives or exclusionary conditions (e.g., 'Use domains_getIncomingDomainMoveV1 for a single specific move'), so the guidance is helpful but not comprehensive.
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?
Annotations already declare readOnlyHint=true and destructiveHint=false, covering safety. The description adds the behavioral constraint that only incomplete moves are returned, which is meaningful for an agent expecting past or completed moves. It also hints at response content ('the accounts they are addressed to'). While it doesn't describe pagination or response format, for a simple read-only list with no parameters, 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?
Three concise sentences with no filler. The first sentence states the primary action, the second adds the crucial filter, the third provides usage guidance. Each sentence earns its place; information is front-loaded with the main verb and object.
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 0-parameter read-only list endpoint with no output schema, the description covers the essential aspects: what it returns (outgoing domain moves), the filter (incomplete only), and when to use it (track initiated moves). It doesn't specify the exact structure of each move object or pagination, but these are not critical for a list endpoint without parameters. The description is sufficient for an agent to decide whether to call it and 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 there is nothing for the description to explain. Per rubric, baseline is 4 for 0 parameters. The description adds no parameter detail because none exist, and the schema is already 100% covered. No improvement needed here.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid 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 all domains you are moving to other Hostinger accounts' – a specific verb (retrieve), resource (outgoing domain moves), and scope (all moves you initiated to other accounts). It distinguishes from incoming moves via phrase 'to other Hostinger accounts' and from single-move tools by being a list operation. The filter 'Only moves which have not completed yet are returned' further clarifies the exact set returned.
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 track moves you have initiated and the accounts they are addressed to' explicitly states a use case and implies this is for initiated outgoing moves, not incoming ones. It doesn't explicitly name alternatives like domains_getIncomingDomainMoveListV1 or domains_getOutgoingDomainMoveV1, but the context from name and description is clear enough for an agent to select it appropriately. It lacks an explicit 'when not to use' but provides 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?
Annotations only indicate non-readonly and non-destructive behavior. The description adds a critical behavioral detail: the operation is asynchronous and a successful response only means the activation job has been queued. This helps set correct agent expectations beyond the 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?
Three short sentences, each earning its place: the action, the path/identifier guidance, and the async caveat. Information is front-loaded and there is 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 three-parameter action with no output schema, the description covers the key points: what it does, how to find the software id, and the async nature of the response. It could mention how to verify eventual completion, but this is not necessary for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds meaningful value by explaining that the 'software' identifier goes in the path and can be obtained from a specific endpoint's 'id' field. It also frames 'plugin' as an installed plugin slug, reinforcing 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 begins with a specific action and resource: 'Activate an installed plugin on a WordPress installation.' This clearly distinguishes the tool from related siblings like hosting_installWordPressPluginsV1, hosting_deployWordPressPluginV1, and hosting_deactivateWordPressPluginV1.
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: the tool is for activation of an already-installed plugin and tells the agent where to find the required software identifier via GET /api/hosting/v1/wordpress/installations. It does not explicitly name alternative tools, but no exclusions are needed for this straightforward action.
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?
Annotations already declare destructiveHint=true and idempotentHint=true. The description adds behavioral context: 'Permanently deletes' confirms irreversibility, and the instruction to pass the from value exactly as returned from the list endpoint clarifies the required input provenance. This is useful beyond the annotations, which only convey generic safety flags.
Agents need to know what a tool does to the world before 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 extraneous information. The first sentence states the purpose and permanence, and the second gives a precise actionable instruction. The critical usage constraint is front-loaded, making it easy for an agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a delete tool with 3 required params and no output schema, the description covers the essential action, the identifier source, and implies the necessary context (username, domain). It does not mention error scenarios or idempotency, but the annotations already signal destructive and idempotent behavior. The only minor gap is lack of explicit note that the redirect must exist, but the instructions are sufficient for correct manual 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%, so baseline is 3. The description and schema add real value for the `from` parameter: the schema says 'Source URL returned by the list redirects endpoint,' and the description reinforces passing it exactly. The `domain` and `username` descriptions are minimal ('Domain name', 'username parameter') but adequate. Overall, the from parameter semantics are significantly enriched, warranting 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 action: 'Permanently deletes the redirect identified by its source URL.' It identifies the resource (redirect), the verb (delete), and the key identifier (source URL). It distinguishes itself from siblings like hosting_listWebsiteRedirectsV1 and hosting_createWebsiteRedirectV1 by specifying deletion, so an agent can easily tell them apart.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides a clear usage context: 'Pass the from value exactly as returned by the list redirects endpoint.' This prescribes a prerequisite and exact input source, guiding the agent to first list redirects. It does not explicitly state when not to use it, but the instruction gives enough context for correct invocation.
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?
Annotations already declare readOnlyHint=true and destructiveHint=false, and the description reinforces that by framing the operation as previewing and reviewing settings. It adds useful context: detection comes from package.json, archive must be on the server, and which settings are exposed.
Agents need to know what a tool does to the world before 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, focused paragraphs: what it does, when to use it, and what prerequisite must be met. Every sentence adds operational value and the most important 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?
For a simple read-only tool with three plain parameters, the description provides purpose, usage, prerequisite, and the settings that will be returned. A detailed return format is missing, but the listed settings largely compensate for 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.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All three parameters have schema descriptions (100% coverage), so the schema carries the parameter documentation burden. The description adds general context about the uploaded archive and settings but gives no additional detail about username or domain beyond what the schema says.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource: auto-detect Node.js build settings from a package.json inside an archive. It connects to the related Start Node.js Build workflow and lists the settings that get previewed, making it clearly distinct from sibling node/hosting tools.
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 positions the tool in a workflow: call this before Start Node.js Build to preview or let the user override settings. It also states the prerequisite that the archive must already be uploaded and points to Generate Upload URL for that step.
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?
Even with readOnlyHint=true and destructiveHint=false, the description adds meaningful behavioral context: pagination, shared-access inclusion, platform-specific null fields (vhost_type, username, root_directory), and the meaning of website_type values. This goes well beyond the annotations and helps the agent interpret results correctly.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose, then explains scope, field semantics, and filtering in separate logical paragraphs. Every sentence adds useful information without repetition 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 read-only paginated list tool with no required parameters and no output schema, the description sufficiently covers pagination, response field semantics, and available filters. It does not spell out every response field, but it highlights the ones most likely to confuse an agent, making it nearly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters. The description adds some value by giving usage examples and grouping filter parameters, but it does not need to compensate for missing schema documentation. 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 states a specific verb and resource: 'Retrieve a paginated list of websites'. It also clarifies scope ('accessible to the authenticated client', including shared-access websites), which distinguishes this from other hosting list tools. The mention of CloudLinux, Builder, and Horizons makes the resource type concrete.
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 filtering guidance, including explicit examples ('website_types=wordpress', 'website_types=nodejs') and mentions combinable query parameters. It does not explicitly name sibling alternatives or state when not to use this tool, but the context is strong enough for an agent to know when this list endpoint is 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?
Annotations already mark the operation as destructive and non-read-only, and the description reinforces that by saying plugins are uninstalled. It adds helpful behavior beyond the annotations: the operation is asynchronous and a successful response only means the uninstall job has been queued. This is important for setting agent expectations about the 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 compact and well organized: the first sentence states the action, the second explains the key prerequisite, and the third discloses the asynchronous behavior. Every sentence contributes distinct information with 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 simple but destructive async operation, the description covers the essential prerequisites and success semantics. Since there is no output schema, the async note partially compensates by clarifying what a successful response means. It does not describe the response shape or how to track the queued job, but that is a minor gap for this tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already documents all three parameters with 100% coverage, giving a baseline of 3. The description adds real value by explaining how to obtain the `software` identifier from the installations endpoint's `id` field and by confirming that plugins are provided as slugs. The `username` parameter is left entirely to the schema, but overall the description supplements the schema usefully.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Uninstall') and a specific resource ('one or more plugins from a WordPress installation'). This clearly distinguishes it from sibling plugin operations such as activate, deactivate, install, and update. The plural support is an explicit scope detail that helps the agent understand its capability beyond the title.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear operational context: the software identifier must come from the WordPress installation list endpoint and should be placed in the path. It also clarifies that plugins are selected by slug. It does not explicitly mention alternatives or when not to use this tool, but the intended use is clear enough 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 adds important behavior beyond the annotations by disclosing that the operation is asynchronous and that a successful response only means the update job has been queued. This manages agent expectations about completion. It does not cover auth or other side effects, but the annotations already indicate this is not a read-only 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 action is stated immediately, followed by a practical parameter source note and a critical async caveat. Every sentence contributes meaningful 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?
For a 3-parameter tool with no output schema, the description covers the main invocation requirements and the async nature of the operation. It leaves some minor gaps such as how to track the update job or what the username parameter means, but it is sufficient for an agent to call 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 value by explaining that the software identifier is placed in the path and can be obtained from a specific GET endpoint, citing the `id` field. The username parameter remains vague, but the schema at least labels 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 uses a specific verb and resource: 'Update a Hostinger plugin to its latest version on a WordPress installation.' It clearly distinguishes this from generic plugin operations by restricting to Hostinger plugins, reinforced by the slug enum. The difference from sibling tools like hosting_updateWordPressPluginsV1 is apparent from the wording.
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: this is for updating a Hostinger plugin on a WordPress installation, and it explains how to obtain the required software identifier. It does not explicitly state when not to use this tool or name alternatives, but the Hostinger-specific scope makes the intended usage 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?
Beyond the minimal annotations (readOnlyHint=false, destructiveHint=false), the description discloses crucial behaviors: the plaintext token is returned only once and never again, and a maximum of 10 tokens can exist per order. This meaningfully informs the agent about security-sensitive and quota-related behavior, though it does not cover error conditions or exact 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 compact and front-loaded with the core purpose. Each sentence earns its place: creation intent, token access, one-time plaintext warning, quota limit, and scope guidance. There is no filler or redundant restating of 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 three parameters, a nested scope object, and no output schema, the description covers the essential call context well: what the token does, its one-time return, the quota, and the scope parameter choices. It stops short of explaining what happens on errors or how to recover if the limit is reached, but the overall definition is adequate for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already documents all three parameters, so the baseline is 3. The description adds value by explaining the relationship between scope.has_all_mailboxes and scope.mailbox_ids in plain terms, clarifying the either/or choice for scoping current and future mailboxes versus specific ones.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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: 'Create an API token for the given mail order.' It clearly distinguishes this action from sibling operations like mail_listAPITokensV1 and mail_revokeAPITokenV1 by defining the creation intent and the token's scoped access to 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 provides clear context for when this tool is relevant: when a token is needed for a mail order, with a hard limit of 10 tokens per order. It also gives concrete guidance on choosing scope via has_all_mailboxes versus mailbox_ids, but it does not explicitly name alternatives such as list or revoke token tools.
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?
Annotations only state readOnlyHint=false and destructiveHint=false, so the description carries the behavioral burden. It discloses deprecation, the default-profile fallback, and the inability to target other profiles—critical behavioral details an agent needs before invoking.
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 opening sentence duplicates the tool title, and the second sentence largely restates the first. The deprecation note is valuable and concise, but the early redundancy prevents a higher score.
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 key operational caveats (deprecation, default profile fallback, recommended alternative) and the schema handles parameter details. It does not describe the response shape, but given full schema coverage and no output schema, the description is sufficiently complete for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents all three parameters. The description adds only generic examples of criteria (email, name, subscription status) rather than new parameter-level meaning, 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 operation: create a new contact segment used to organize contacts, with configurable criteria. It also distinguishes this endpoint from profile-scoped alternatives by explicitly stating it cannot target a 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?
The description gives explicit guidance: the endpoint is deprecated, always falls back to the client's default profile, cannot create segments in other profiles, and the agent should use the alternative endpoint instead. This leaves no ambiguity about when to use or avoid the 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?
Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds a non-obvious behavioral detail: 'A profile with no domain connected returns the same shape with every field set to null.' This helps the agent interpret surprising responses and fits the read-only safety profile.
Agents need to know what a tool does to the world before 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, each earning its place: purpose, use-case justification, and null-return caveat plus alternative endpoint. The most important information is front-loaded. 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?
There is no output schema, so the description compensates by summarizing the returned data (verification status, suspended sender addresses) and the null-shape behavior for missing domains. It could list exact field names or error cases, but for a single-parameter read operation with readOnly annotations, it covers what an agent needs to call it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description mentions 'connected to the profile' which links profileUuid to the profile entity, but it does not explain how to obtain a valid profileUuid or add beyond the schema's tautological 'Profile uuid parameter' description. No significant extra meaning 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 opens with a specific verb and resource: 'Get the sending domain connected to the profile, its verification status and any suspended sender addresses.' This clearly defines the tool's output and distinguishes it from the DNS status endpoint, which handles individual MX/SPF/DKIM/DMARC records.
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 to use: 'Campaigns only go out once a domain is connected and active, so this is the cheapest way to check that precondition before building one.' It also names the alternative for detailed DNS records: 'use the DNS status endpoint.' These are clear when-to-use and when-not-to-use signals.
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?
Beyond the readOnlyHint and destructiveHint annotations, the description discloses important non-obvious behaviors: counters reset on the 1st, usage is shared across profiles on the same order, and only the current period is retained. This is exactly the kind of context an agent needs to interpret results correctly.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the main purpose and then provides two tightly scoped caveats that directly affect how the tool should be used. 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 simple read-only tool with one parameter and no output schema, the description covers the essential operational context: what is returned, how the period is defined, how usage is pooled, and what data is unavailable. An agent has enough to invoke it correctly and interpret the result.
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 documents profileUuid with 100% coverage. The description adds value by explaining that usage is tracked per order and that profiles on the same order share the same pool, which clarifies what profileUuid selects and why different profiles may return identical values.
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 and resource: 'Get how much of the plan is left for the current period.' It explains what the tool returns and adds useful scope, though it does not explicitly contrast it with a sibling tool such as reach_listPlanFeatureAccessV1.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context for using the tool, especially around calendar-month resets and per-order pooling, and warns that past usage is not available. It does not, however, explicitly say when to prefer this tool over an alternative.
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?
Annotations already declare readOnlyHint=true and destructiveHint=false; the description reinforces this by saying 'Nothing is stored and no contact is modified.' It also adds useful context about the condition body being shared with segment creation/update, which clarifies what the tool does with the request. This goes beyond the annotations without contradicting them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is tight and front-loaded: the first sentence states the core purpose, the second adds the preview-vs-persist distinction and non-destructive behavior, and the third gives a necessary prerequisite. Every sentence earns its place and there is no redundant or filler 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?
The description covers the main behavioral contract: previewing, not persisting, no modifications, and checking both who and how many. It also references the prerequisite filter attributes endpoint. With no output schema, it could more explicitly describe the response shape, but 'check who a filter reaches, and how many' conveys the essential return semantics.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3, but the description adds context about the conditions parameter: the body is the same accepted when creating or updating a segment, and it directs callers to the segment filter attributes endpoint for valid attribute/operator/value combinations. This helps an agent understand the semantics of the nested conditions parameter beyond the raw 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 a specific verb and resource, 'Preview the contacts matching a set of conditions,' and immediately distinguishes the tool from segment persistence with 'without saving a segment.' It also states that the body is the same conditions accepted when creating or updating a segment, which clearly separates it from sibling segment creation and listing 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?
It clearly states when to use the tool: 'this is how to check who a filter reaches, and how many, before persisting it.' It also gives an explicit prerequisite, 'Call the segment filter attributes endpoint first,' which is useful operational guidance. It does not explicitly name alternative segment-creation tools or list when not to use them, but the pre-persistence framing is clear enough.
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 goes beyond the destructiveHint annotation by explicitly warning that 'All data on the virtual machine will be overwritten with the data from the backup.' It also discloses that the restore may take time, which is valuable behavioral context for an agent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and every sentence contributes a distinct fact: the action, the potential delay, the destructive overwrite warning, and the intended use case. There is no filler or redundant restatement.
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 destructive restore operation, the description covers the target, the action, the overwrite consequence, and the time expectation. It does not mention how to track the asynchronous restore process, but enough is provided for safe invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so both parameters (backupId and virtualMachineId) are already described in the input schema. The description adds no additional parameter-level 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 uses a specific verb and resource: 'Restore a backup for a specified virtual machine.' It is not a tautology and distinguishes itself from siblings like VPS_getBackupsV1 and VPS_restoreSnapshotV1 by clearly naming backup as the restore source.
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 gives an explicit usage directive: 'Use this endpoint to recover VPS data from backup points.' This provides clear context for when to use the tool, though it does not explicitly exclude alternatives such as VPS_restoreSnapshotV1.
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?
Beyond the annotations (destructiveHint=true), the description discloses the overwrite and irreversibility ('overwrites the website's existing contents and cannot be undone'), requires user confirmation, explains that the operation is synchronous with no async build to poll, and notes that credentials are generated internally. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is fairly long but dense and front-loaded with purpose and warning. There is minor repetition around overwriting contents, but each additional sentence (synchronous behavior, credential handling, alternative routing) earns its place given the destructive nature.
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 what the tool does, how it works, when to use it, what to avoid, and its synchronous completion. With no output schema, the description does not document return values, so an agent must infer success semantics from context, but still has everything needed to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and the schema already documents all three parameters with formats and defaults. The description adds workflow context (auto-resolves UID from domain) but no parameter-specific semantic meaning beyond the schema, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Deploy'), identifies the resource (Agency Plan h5g website) and the source type (archive file), and explicitly distinguishes itself from node-static deployments that require a build step. It clearly states the tool's scope: extract-and-serve as-is without a build step.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-use guidance ('Use this for Agency Plan websites where...') and an explicit alternative ('For node-static websites that require a build step, use agencyHosting_deployNodeStaticWebsite instead'). It also instructs the agent not to call a separate upload-url endpoint, preventing misuse.
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?
Beyond the minimal annotations, the description discloses exactly what the tool returns, how those credentials must be used, the expected HTTP status codes, required headers, and the full TUS upload sequence. It even clarifies that the tool only generates the URL and credentials rather than performing the upload itself. This is richly transparent for a tool with no output schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Although the description is long, every section earns its place: purpose, return values, protocol steps, and a concrete curl example. The information is front-loaded with the core purpose and return contract, then progressively detailed. The numbered steps and code block make the protocol easy to follow rather than bloated.
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 complexity of the TUS upload flow, the absence of an output schema, and minimal annotations, the description is remarkably complete. It covers what the tool returns, how to construct the upload request, expected status codes, headers, and even a fallback curl method. An agent has everything needed to invoke the tool and then actually perform the upload.
Complex tools with many parameters or behaviors need more documentation. Simple tools 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, `website_uid`, already has a 100% schema-description coverage ('Agency Plan website UID'). The description refers to the website's file storage but does not add meaningful new semantics beyond the schema. The baseline of 3 is appropriate because the schema already provides sufficient meaning for the single 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 states a specific action ('Generate a file browser upload URL with authentication credentials') and specifies the target resource ('Agency Plan website's file storage'). It also names the exact return values (`url`, `auth_key`, `rest_auth_key`), making the tool's purpose unmistakable and distinct from the many hosting and deployment 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 clearly establishes the context for use: uploading files to an Agency Plan website's file storage. It provides a complete walkthrough of how to use the returned credentials, including TUS protocol steps and a curl example. It does not explicitly mention a sibling alternative such as the non-agency `hosting_generateUploadURLV1`, but the 'Agency Plan' scope makes the intended use clear enough.
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?
Annotations already mark this as read-only and non-destructive. The description adds useful behavioral context beyond that: values may be up to one hour stale and figures cover the entire order account. It does not contradict the 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?
Four short, purposeful sentences with no filler. The core result is front-loaded, followed by scope, freshness caveat, and routing guidance to the alternative endpoint.
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?
With only two well-documented parameters, read-only annotations, and no output schema, the description covers everything needed to select and invoke the tool: what is returned, the account scope, freshness limitation, and the correct sibling for other metric types.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and both parameters already have clear descriptions, including the enum for time_frame_days. The tool description only loosely refers to the 'selected time frame' and whole order scope, adding no parameter-specific detail beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Returns') plus a clear resource: aggregated disk and inode usage for an Agency Plan order over a time frame, with plan quotas. It also states the scope ('whole order account') and distinguishes this from CPU, memory, and process usage on another endpoint.
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 names the resource-usage-metrics endpoint for CPU, memory, and process usage, telling the agent when not to use this tool. This makes the choice between this and the closely related agency-hosting_listOrderResourceUsageMetricsV1 sibling clear.
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?
Beyond the readOnlyHint and destructiveHint annotations, the description discloses meaningful behavioral details: suspended and deleted websites are excluded, values may be up to one hour stale, and disk/inode usage is intentionally out of scope. This gives the agent accurate expectations about data freshness and coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is four focused sentences with no filler. It front-loads the main purpose, then adds exclusions, freshness, and routing information, with every sentence contributing useful operational context.
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 read-only metrics tool with two well-documented parameters, the description provides sufficient context: what is returned, what is excluded, how fresh the data is, and where to go for related metrics. No critical information needed to invoke it correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already fully describes both parameters with 100% coverage, so the baseline applies. The description adds only general context like 'selected time frame' and 'each website is identified by uid', which does not materially deepen parameter understanding beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb and resource: it returns aggregated CPU, memory, and process usage for an Agency Plan order, plus quotas and a per-website breakdown. It also explicitly distinguishes itself from the disk-usage-metrics endpoint, making it easy to separate 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 makes the primary use case clear and explicitly redirects disk and inode usage queries to the disk-usage-metrics endpoint. It does not name other alternative metrics tools like the per-website process list, but the main exclusion is well covered.
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?
Annotations already flag destructiveHint and idempotentHint, and the description adds materially by stating the website restarts, requests during the switch may fail, and incompatible code will break. This gives the agent the real-world consequences beyond the boolean flags, with no contradiction.
Agents need to know what a tool does to the world before 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 deliver the operation, the prerequisite, and the risky side effects with no filler. The most decision-relevant fact, 'Agency Plan website,' 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?
With two simple parameters, no output schema, and annotations carrying the idempotent/destructive flags, the description covers what to do first and what to expect during and after the switch. Nothing essential to deciding whether to invoke this tool is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline applies: the schema already documents both website_uid and version, including the 'major.minor' format and the constraint that version must come from the available versions endpoint. The description reinforces the version constraint but does not add 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 opens with a specific verb and resource: 'Switches an Agency Plan website to a different PHP version.' This states exactly what the tool does, and 'Agency Plan' distinguishes it from the sibling hosting_updatePHPVersionV1 while the list-available-versions tools are clearly read-only precursors rather than the same 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?
It explicitly tells the agent to 'Call the available versions endpoint first to see which versions can be selected,' giving a clear prerequisite and an ordering constraint. It does not name when-not-to-use or call out alternatives such as hosting_updatePHPVersionV1, but the Agency Plan scope supplies enough context to select 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?
Beyond the annotations, the description adds meaningful behavioral context: it will place an order, automatically use the default payment method if none is provided, and it will not perform product-specific provisioning. This clarifies side effects and boundaries, though it does not mention potential billing charges, order cancellation, or response behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and front-loaded with the core purpose. The paragraphs are purposeful, but the final sentence 'Use this endpoint to purchase any product available in the catalog' is somewhat redundant with the opening sentence, slightly reducing 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 three-parameter endpoint with no output schema and minimal annotations, the description covers the main operational context: what to purchase, where to find item IDs, default payment behavior, and the boundary between ordering and provisioning. It is complete for selecting and invoking the tool, though a brief note on response/order confirmation 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?
Schema coverage is 100%, so the schema already documents all parameters. The description adds practical value by pointing to the catalog endpoint for obtaining item_id values and clarifying that the order can contain 'one or more catalog items,' which enhances understanding of the `items` array 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 a specific verb and resource: 'Create a purchase order for any Hostinger product.' It clearly states that this is a unified endpoint placing orders for one or more catalog items across all Hostinger products, and distinguishes itself from product-specific purchase or provisioning flows by noting that provisioning is not performed here.
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 tells the agent when to use the endpoint ('Use this endpoint to purchase any product available in the catalog') and when not to rely on it for provisioning ('Product-specific provisioning... is not performed here'), directing to 'relevant product endpoints or hPanel' instead. It also references the catalog endpoint for looking up item_id values, which is actionable routing guidance.
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 goes well beyond the annotations, explaining that the operation consumes a free domain, requires no payment, indicates success only when registration is complete, and produces errors like 2037 when no free domain is available. It also discloses default WHOIS fallback and TLD-specific additional_details validation.
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 front-loaded with the core purpose and spends most sentences on useful behavioral details. The final sentence repeats the opening idea, which slightly reduces conciseness, but overall there is minimal 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 mutating tool with no output schema, the description adequately explains success semantics, failure handling, error codes, preconditions, and TLD-specific requirements. It could be slightly more explicit about what the response body contains or how it relates to transfer tools, but it is not incomplete enough to mislead an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already documents all three parameters, and the description adds meaningful context: domain_contacts relates to WHOIS records, additional_details is TLD-dependent and validated, and omitted WHOIS info falls back to defaults. This supplements the schema rather than merely repeating 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 uses a specific verb and resource: 'Claim a free domain available on your account and register it.' It also explicitly contrasts with purchasing a domain, which distinguishes it from siblings like 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly states when to use this tool: when a free domain is available and no payment method is required. It also covers prerequisites like ensuring WHOIS information exists. However, it does not explicitly name the transfer sibling domains_claimFreeDomainTransferV1 as an alternative.
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?
Annotations only say readOnlyHint=false and destructiveHint=false, so the description carries the behavioral burden. It discloses default payment method usage, default WHOIS fallback, TLD-dependent additional_details validation, and a concrete failure-handling step via hPanel. This goes well beyond the structured annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a bit longer than the minimum but every sentence carries a practical caveat or prerequisite. It is front-loaded with the action. The final sentence 'Use this endpoint to register new domains for users' is slightly redundant with the first sentence, costing it a perfect score.
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 accounts for payment defaults, WHOIS prerequisites, TLD-specific validation, and registration failure behavior. There is no output schema, and the description does not state what a successful response contains, which is a minor gap for a purchasing operation. Overall, it gives enough 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.
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 useful semantic context beyond the schema: payment_method_id defaults if omitted, domain_contacts defaults to TLD contact info, and additional_details may be required and validated. It does not add deep detail for item_id or coupons, but those are self-descriptive 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 opens with a specific verb and resource: 'Purchase and register a new domain name.' It closes with a direct usage statement, 'Use this endpoint to register new domains for users,' which sharpens intent. This is clearly distinct from siblings like domain availability checks, transfers, or free-domain claims.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context for using the tool: it is for registering new domains, requires WHOIS to exist for the TLD, and falls back to default payment/WHOIS when omitted. It does not explicitly name alternatives or state when NOT to use it, but the use-case guidance is strong enough for an agent to decide.
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?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds valuable behavioral detail beyond that: default sort order (newest first), response shape (lean summaries), currency-unit semantics for prices, and the effect of include=variants/media. This is strong but not exhaustive — for example, pagination behavior 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three dense sentences, each earning its place: the first defines the resource and response shape, the second clarifies price semantics, and the third explains filters and include options. Information is front-loaded and there is no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only list operation with full schema coverage and no output schema, the description covers what an agent needs: what is returned, ordering, filtering capabilities, and how to opt into heavier embedded data. The main gap would be pagination defaults, but this is minor for a list endpoint given the rest of 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%, so the baseline is 3. The description adds extra meaning beyond the schema: product_ids doubles as a single-product lookup up to 200 IDs, include=variants embeds prices and inventory, and prices are integers in the smallest currency unit. It does not clarify page defaults, but the added semantics justify above 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 names a specific verb and resource — "List a store's products" — and adds concrete distinguishing detail: newest first, lean summaries, and the specific summary fields (name, status, thumbnail, variant count, price range). This clearly differentiates it from sibling tools like ecommerce_listProductVariantsV1 and ecommerce_listDiscountsV1.
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 on how to use the tool: list products with filters by status, free text, or product IDs, and optionally embed variants or media via include. It does not explicitly name alternative tools or state when not to use it, but the usage context is unambiguous.
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?
Beyond the readOnlyHint annotation, the description adds a meaningful behavioral guarantee: 'Never exposes gateway credentials, secrets, or configuration.' It also states the response is split into two categories, which helps set expectations about what the tool returns even without an output schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, compact sentence that states the operation, the output structure, and a security-relevant behavior. It is front-loaded with the core action and avoids any filler or repetition of the title.
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 tool with two parameters and no output schema, the description provides enough information: what it lists, how the result is organized, and what it will never expose. An agent can correctly decide to invoke it and understand the basic shape of 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 description coverage is 100%, so the description does not need to explain the parameters. The optional include_currency_unsupported parameter is already well documented in the schema, and the description adds no additional parameter-level nuance. 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 ('List') and a clear resource ('a store's payment providers'), and further clarifies the output is split into connected providers and installable gateways. This distinguishes it cleanly from sibling tools like ecommerce_createAPaymentProviderConnectLinkV1, which handles installation/connection rather than listing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies this is the tool to use when you need to see a store's payment providers and available gateways. It doesn't explicitly name alternatives or state when not to use it, so it stops short of a 5, but the context is unambiguous enough for an agent choosing among siblings.
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?
Annotations already mark this as read-only and non-destructive. The description adds meaningful behavioral detail beyond that, including the exact components of the returned order, the fact that line items carry the ID needed by the fulfil endpoint, and that monetary amounts use the smallest currency unit. This helps the agent set expectations and interpret values correctly.
Agents need to know what a tool does to the world before 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 compact sentences, front-loaded with the core action and packed with useful information. There is no filler, and every clause adds value: response scope, fulfil linkage, and currency unit.
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?
With only two self-explanatory parameters and no output schema, the description appropriately carries the responsibility of explaining the return payload. It enumerates the major order components and includes the critical currency-unit caveat, making it complete enough for an agent to invoke the tool and interpret the result correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so both order_id and store_id are already documented. The description does not add much parameter-level detail, but it also does not need to; the baseline of 3 applies because the schema carries the burden 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 it retrieves one order and enumerates the response contents: line items with fulfil-relevant IDs, addresses, totals breakdown, and fulfilments with tracking. This distinguishes it from sibling tools like ecommerce_listStoreOrdersV1 (list vs single) and ecommerce_cancelAnOrderV1/ecommerce_fulfilAnOrderV1 (mutations vs read).
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 'Retrieve one order in full' gives clear context that this is the tool for a single, complete order lookup, and the mention of the fulfil endpoint's needed ID links it to the order fulfilment workflow. It does not explicitly name alternatives or exclusion criteria, but the context is sufficient for an agent to choose it over list or mutation tools.
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?
Beyond the annotations, the description adds crucial behavioral details: the operation cannot be undone, it returns success even when no log file exists, and it advises restarting the follow-up log call with `period` rather than reusing a `from_line`. This meaningfully enriches the agent's understanding of side effects and workflow.
Agents need to know what a tool does to the world before calling it. Descriptions 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 every sentence carries value: what it does, the irreversible warning, the no-op success behavior, and the recommended usage pattern. The actionable guidance is front-loaded and the follow-up instruction is directly relevant.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter tool with no output schema, the description covers the action, side effects, edge case behavior, and the correct post-call workflow. Nothing essential for an agent to use it correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for both parameters (`domain` and `username`), so the schema already provides adequate meaning. The description does not add parameter-level detail, which is acceptable given the 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 states a specific verb ('Empties') and resource ('Node.js application's runtime log file'), making the tool's purpose immediately clear. It is also naturally distinguished from the sibling `hosting_getNode_jsRuntimeLogsV1` by describing the clearing action versus reading 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 gives clear context for when to use the tool: before reproducing a problem, so the next log retrieval returns only fresh entries. It also instructs the user to confirm before calling due to destructiveness. It does not explicitly list when-not-to-use scenarios or alternatives, but the primary use case is well communicated.
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?
Annotations already set destructiveHint=true, but the description adds concrete behavioral context: 'overwrites the website's existing contents and cannot be undone'. It also discloses the no-build-step limitation, going beyond the annotation to tell the agent exactly what will be affected.
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?
Content is mostly efficient and front-loaded with the warning. However, the first sentence and the third paragraph repeat the same core statement ('Deploy a static application from an archive file'), introducing minor 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 what the tool does, destructive risk, target site type, and routing to alternatives for other app types. It is slightly incomplete in that it does not describe expected success/failure responses or archive format constraints, but for a three-parameter tool without an output schema this is a strong definition.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema documents each parameter. The description adds some context for archive_path by saying the archive has been 'uploaded to the website's directory', but it adds little for domain and username, and 'username parameter' in the schema remains uninformative. 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?
States a specific verb and resource: 'Deploy a static application from an archive file.' Scoping to static sites and naming Node.js/WordPress alternatives differentiates it from sibling deploy/import tools. The warning reinforces that this is the overwriting archive-deploy endpoint.
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 'This only works for static sites' and directs Node.js and WordPress users to sibling tools like 'Create NodeJS build from archive', 'Start Node.js build', and 'Import WordPress website'. The warning to verify before calling also serves as an explicit precondition.
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?
Annotations already mark the tool as read-only, and the description adds substantial behavioral context: results are sorted by severity and publish date, data comes from periodic scans and may lag, an empty list only means the latest scan found no vulnerabilities, and patchable/patching-in-progress flags have operational consequences. This goes far beyond what annotations provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but every sentence earns its place: the opening states the primary function, followed by sorting/filter behavior, patch-related interpretation, data freshness caveats, and plan availability. It is front-loaded with the core purpose and avoids 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?
Despite having no output schema, the description clearly communicates the kind of returned data (advisory metadata, severity, CVSS, CVE, advisory URL, patchable flags), result ordering, empty-list semantics, and plan restrictions. An agent has enough context to correctly interpret and use the response without further guessing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the parameter definitions already carry most of the weight. The description additionally references the severities filter, matching the schema's 'Severities to filter by.' It does not add extra meaning to username or domain beyond their schema entries, which is acceptable given 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 'Lists known npm package vulnerabilities detected on a Node.js website' and distinguishes it from the related patch endpoint by explaining what list results enable. It identifies the resource, the action, and the enriched advisory metadata, making it easy for an agent to differentiate 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 gives clear context for when to call this tool and explains the severities filter. It also references the Patch Node.js Vulnerabilities endpoint for auto-fixing patchable vulnerabilities, implicitly steering agents to the correct sibling. It stops short of explicitly stating exclusions or 'use this instead of X' scenarios, but the usage context is strong.
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?
Beyond the annotations, the description discloses the performance impact of disabling caching, the no-op behavior when already in the requested state, and the recommendation context. It aligns with idempotentHint=true and readOnlyHint=false, though it could more directly explain why destructiveHint=true is set, such as whether disabling clears cached data.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core action, then gives rationale, an explicit alternative, and the idempotency guarantee. Each sentence contributes useful information without unnecessary padding.
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 three-parameter tool with full schema coverage, the description provides the key behavioral details an agent needs: what the flag does, when to enable/disable, which alternative to prefer, and the idempotent no-op behavior. No output schema is present, so return-value explanation is not 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?
Schema coverage is 100%, and the enabled parameter is already documented as 'Turn server-side caching on (true) or off (false)'. The description reinforces this by saying the action is 'based on the enabled flag', but adds little new parameter-level meaning beyond usage context already covered by 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 a specific verb and resource: 'Turns server-side caching for the website on or off, based on the enabled flag.' It clearly differentiates this from related cache tools by naming cacheless mode as a distinct alternative, so an agent can distinguish it from hosting_toggleCachelessModeV1 and hosting_clearWebsiteCacheV1.
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 the tool is appropriate ('recommended for production websites') and when it is not ('to temporarily bypass caching while developing or debugging, prefer toggling cacheless mode instead'). This gives an agent a concrete decision rule and names the sibling alternative.
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?
Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds meaningful behavioral context beyond that: it explains the available/locked semantic, clarifies this is not a usage quota, and implies features can be gated by plan. This is valuable for interpreting results, though exact response shape 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose, followed by a concise distinction from quotas, value semantics, and an alternative endpoint. Every sentence carries useful information and there is no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter, read-only tool with no output schema, the description covers what the tool returns conceptually, what the values mean, what it does not cover, and when to use it. Nothing an agent needs for correct invocation is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the single parameter profileUuid is documented in the schema as 'Profile uuid parameter.' The description adds no additional parameter-level detail, but with full schema coverage the baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description opens with a specific verb and resource: 'List which plan features the profile can use.' It clearly distinguishes itself as the feature lock matrix rather than a usage quota, and separates from the limits endpoint, so an agent can tell this apart from related billing/limits tools.
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 tells the agent when not to use it: 'For remaining emails, recipients and AI credits use the limits endpoint instead.' It also gives a concrete use case—checking before building something that cannot be activated, such as an automation on a plan without automation activation—which helps select this tool in planning workflows.
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?
Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds valuable behavioral context by explaining pagination, that the contact count is recalculated on read rather than stored, and that count_type controls whether counts include all matching contacts or only subscribed ones. This goes well beyond the annotation-only safety profile.
Agents need to know what a tool does to the world before calling it. Descriptions 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 purpose, and the second adds the most important behavioral nuance. Every sentence earns its place without redundant 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 paginated read-only listing tool, the description covers the resource, pagination, entry content, and the key semantic choice (count_type). With full schema parameter documentation and annotations covering safety, nothing essential is missing for an agent to call and interpret this 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 description coverage is 100%, so the baseline is 3. The description adds meaning beyond the schema by clarifying that count_type chooses between 'every matching contact' and 'only the subscribed ones', which sharpens the enum semantics. Pagination is also mentioned in the first sentence, reinforcing page and per_page.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Get'), resource ('paginated list of the segments defined in a profile'), and scope ('in a profile'), which clearly distinguishes it from the general reach_listSegmentsV1 sibling. The title aligns with the description without being a tautology.
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 profile-scoped wording gives clear context for when to use this tool: when you need segments belonging to a specific profile rather than global segments. It does not explicitly name alternatives or provide when-not-to-use guidance, but the context is sufficient for correct selection.
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?
Annotations already signal read-only and non-destructive behavior, but the description adds crucial behavioral context beyond them: the endpoint is deprecated, always uses the default profile, and cannot access other profiles. This is valuable operational information not present in annotations or schema.
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 front-loaded with the core purpose and well-structured into summary, detail, and deprecation warning. There is minor redundancy between the opening sentence and the following sentence ('Retrieve contacts...' / 'This endpoint allows you to fetch...'), but overall it remains concise and readable.
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 deprecated list endpoint with one required parameter and two pagination parameters, the description covers purpose, parameter behavior, limitation, and replacement. It does not mention pagination defaults or response shape, and there is no output schema, but the core calling decision is fully supported.
Complex tools with many parameters or behaviors need more documentation. Simple tools need 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 page, per_page, and segmentUuid each described in the schema. The description adds only that a segment is 'identified by its UUID,' which is minimal extra meaning beyond the schema, so the baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Retrieve' and the resource 'contacts associated with a specific segment,' and it names the exact replacement endpoint. This makes the tool's purpose obvious and distinguishes it from sibling tools like reach_listProfileSegmentContactsV1.
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 marks the endpoint as deprecated, explains the limitation ('cannot target a profile... always falls back to the client's default profile'), and provides the exact replacement endpoint. This gives an agent clear when-not-to-use guidance and a direct alternative.
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?
Beyond the destructiveHint annotation, the description clarifies the actual scope of harm—'Neither the tag nor the contact is deleted'—and reveals the timing behavior 'applied immediately rather than queued'. This is meaningful context that directly prevents an agent from assuming this endpoint deletes either entity.
Agents need to know what a tool does to the world before calling it. Descriptions 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: main action first, timing contrast second, non-deletion safety note last. It does not duplicate schema field names or annotation values.
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 mutation with three required UUIDs, annotations for idempotency/destructiveness, and no output schema, the description covers the key operational facts: scope, immediacy, and non-destructive nature to the tag/contact. Nothing essential is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline applies; the param entries are terse ('Tag uuid parameter') but unambiguous. The description's 'single contact' reinforces contactUuid semantics but adds no material parameter 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 states a specific action—'Remove a tag from a single contact'—and names the target resources. It explicitly contrasts itself with the bulk endpoint, making differentiation from reach_removeContactsFromATagV1 and related tag/contact siblings immediate.
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 identifies the bulk endpoint as the main alternative and highlights the deciding factor: immediate application vs queued. It does not spell out an explicit 'use this when... / use bulk when...' rule, but the single-contact framing plus timing contrast provides clear 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 annotations already marking this as non-read-only, non-idempotent, and destructive, the description adds meaningful context beyond them: 'Contacts are never modified, but which of them match the segment can change immediately.' This clarifies the real-world side effect of a destructive-sounding operation and is genuinely useful information.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and well-structured: a one-sentence purpose, a required-parameter note, a replace-vs-omit clarification, and a side-effect warning. Every sentence earns its place and the most critical semantic trap (replace, not merge) is front and center.
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 5-parameter update tool with a nested conditions array and no output schema, the description covers the essential ambiguities an agent would face: when name is needed, how conditions behave, and what side effects occur to contacts. The schema handles the detailed condition structure and logic requirement, so nothing critical is missing for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds important behavioral meaning to parameters: name is always required even for a pure conditions update, omitting conditions preserves them, and supplying conditions replaces them wholesale. This goes beyond the schema's minimal 'name parameter' and 'Replaces the existing conditions entirely' notes, though it does not add anything about the logic parameter that the schema does not already say.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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 'Rename a segment and/or replace the conditions that define it,' which is a specific verb+resource statement covering the tool's two distinct actions. This clearly differentiates it from segment creation, deletion, listing, and retrieval siblings without needing to name them.
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 parameter-level guidance: 'name is always required', 'Omit conditions to rename without touching the conditions', and conditions replace the existing set entirely rather than being merged. It does not explicitly name alternatives like create or delete, but the context of modifying an existing segment is clear and unambiguous.
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?
Beyond the annotations (readOnlyHint=false, destructiveHint=false), the description discloses important side effects: the script is saved to /post_install, gets the executable attribute, executes once the VM is installed, output goes to /post_install.log, and there is a 48KB size limit. This gives the agent a clear picture of what will happen.
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 short and front-loaded with the main purpose, followed by useful execution details. The final sentence is somewhat redundant with the opening but still reinforces the intended use case, so no sentence is wasted.
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 endpoint with only two required parameters, the description covers the essentials: purpose, storage location, execution behavior, logging, and size limit. It does not describe the API response or how the script will be referenced later, but that is not critical for invoking this 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% for the two parameters, so the baseline is 3. The description adds meaningful context beyond the bare schema: the content parameter maps to a script saved to /post_install, executed later, and capped at 48KB. It does not add constraints for the name parameter, but the name is self-descriptive.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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: 'Add a new post-install script to your account.' It also clarifies the intended lifecycle ('can then be used after virtual machine installation') and ends by restating the purpose as creating automation scripts. This clearly distinguishes it from sibling update/delete/get script 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 context on when to use the tool: to create automation scripts for VPS setup, which run after installation. It does not explicitly mention alternatives like update/delete/get scripts, but the word 'new' and the creation purpose make the intended use unambiguous.
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?
Beyond the annotations, the description discloses a major side effect: any VM with the firewall activated will automatically have it deactivated. It also labels the intended use as removing unused configurations, adding real behavioral context to the destructiveHint.
Agents need to know what a tool does to the world before 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 sentences each add distinct value: the action, the side effect on VMs, and the intended use. There is no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter destructive operation with no output schema, the description covers what it does, the important consequence, and when it should be used. Nothing material is missing for an agent to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema fully describes the single firewallId parameter as 'Firewall ID,' so the description adds little parameter-level meaning. This is the appropriate baseline when schema coverage is complete.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The first sentence, 'Delete a specified firewall,' states a specific action and resource. The name and title agree, and it is clearly differentiated from sibling tools that delete firewall rules or deactivate firewalls.
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 to use this endpoint to remove unused firewall configurations, which provides clear intended context. However, it does not explicitly compare against VPS_deactivateFirewallV1 or VPS_deleteFirewallRuleV1, so an agent must infer the boundary between deactivating and deleting.
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?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is known. The description adds useful behavioral detail: it lists exactly what is returned (name, status, file path, container details) and explicitly states that container stats are omitted. This goes beyond the annotations and helps set 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?
The description is well-structured and efficiently worded: opening statement, return-content summary, explicit omission, sibling routing, and a usage recommendation. Every sentence contributes value and the most important details are 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 a single well-documented parameter, read-only annotations, and no output schema, the description provides sufficient return-value context, names an alternative for deeper data, and clarifies the intended use case. Nothing essential is missing for an agent to call 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?
Schema coverage is 100% and the single parameter `virtualMachineId` is documented as 'Virtual Machine ID' in the schema itself. The description indirectly ties the parameter to 'the virtual machine' but adds no parameter-specific constraints, format, or additional semantic detail 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 list of all Docker Compose projects on a virtual machine, with a specific verb and resource. It also distinguishes itself from the related `Get project containers` endpoint, so an agent can tell them apart.
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 tells the agent when to use this tool ('Use this to get an overview of all Docker projects') and when to use an alternative ('If you need to get detailed information about container with stats included, use the Get project containers endpoint'). This is clear routing 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?
Annotations already declare readOnlyHint=true and destructiveHint=false, establishing the safe read-only nature. The description adds context about the use case (viewing OS options before VM creation), which is beyond the annotations and helps an agent understand the intent. It does not describe response format or potential pagination, but given the annotations and simple list nature, this is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences with no filler. It front-loads the action ('Retrieve available OS templates') and then immediately provides usage context. Every word earns its place, making it highly efficient.
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 zero-parameter read-only listing tool, the description is fully complete. It states what is returned (available OS templates), when to use it (before creating/recreating VPS instances), and there is no output schema so the agent needs no further detail on return shape. Nothing essential 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?
The tool has zero parameters and the schema is empty, so there is nothing to explain. The description correctly makes no parameter references. With 0 params, the baseline is 4, and the description does not detract from it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Retrieve available OS templates') and the resource ('for virtual machines'). It also distinguishes itself from siblings like VPS_getTemplateDetailsV1 by indicating it lists templates, and the phrase 'before creating or recreating VPS instances' clarifies its role in the provisioning workflow. This is specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage 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 view operating system options before creating or recreating VPS instances,' providing a clear when-to-use context. However, it does not mention when not to use it or name alternative tools (e.g., VPS_getTemplateDetailsV1 for a specific template), so it lacks the full exclusion/alternative guidance that would merit a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructive and non-read-only behavior, so the description adds valuable context beyond them: atomicity of the replacement, the need for VM synchronization after replacing rules, and the role of the 'sync' parameter. This is meaningful behavioral disclosure that helps an agent understand side effects and follow-up actions.
Agents need to know what a tool does to the world before calling it. Descriptions 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: the first sentence states the core purpose and atomicity, the second sentence covers the important synchronization caveat. Every sentence earns its place, and no redundant information is included.
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 destructive replacement operation with three parameters and no output schema, the description covers the main things an agent needs: what the tool does, how it differs from individual rule operations, the requirement to sync VMs afterward, and how to trigger sync via the parameter. The annotations cover the destructive and idempotent traits, so nothing critical 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?
Schema coverage is 100%, so the baseline is 3. The description adds useful semantic meaning by clarifying the 'rules' array is the complete replacement set and by explaining the operational effect of the 'sync' parameter ('trigger synchronization immediately'). This goes beyond the schema's terse 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 states a specific verb and resource: 'Replaces all firewall rules within a specified firewall group' with the provided set. It further distinguishes itself from incremental rule management by noting it performs the replacement 'in a single atomic operation, instead of creating or deleting rules one by one.' This clearly separates it 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 gives clear context for use: replace an entire rule set atomically rather than mutating rules individually. It also explains the synchronization requirement and how the 'sync' parameter relates to it. However, it does not explicitly name alternative tools or state when NOT to use this tool, so it falls short of full exclusion guidance.
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?
Beyond the annotations, it discloses idempotent behavior for already-stopped VMs, clarifies that this is a compute-only power state change with no billing impact, and points to auto-renewal disabling as the way to stop future charges. This adds meaningful operational context beyond the bare destructive/read-only flags.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core action, then adds only valuable caveats: idempotence, billing independence, and the alternative for stopping charges. Every sentence earns its place without unnecessary padding.
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 power-state operation with annotations covering mutation and destructiveness, the description fully covers the relevant operational context: what it does, what happens if already stopped, billing implications, and how to avoid future charges. Nothing needed to call it correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already fully documents virtualMachineId as 'Virtual Machine ID' with integer type at 100% coverage. The description adds no additional parameter semantics, so the baseline score for high schema coverage 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 explicitly states 'Stop a specified virtual machine' and 'Use this endpoint to power off running VPS instances,' clearly identifying the action, resource, and intended effect. This distinguishes it from sibling operations like start or restart without 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 provides clear usage context: use it to power off running VPS instances. It also notes that stopping an already-stopped machine has no effect, and clarifies that this is not a billing action. It does not explicitly name the start/restart alternatives, but the intended condition is clear enough.
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 action applies updated firewall rules to all assigned VMs, which is a mutating operation consistent with readOnlyHint=false. It does not mention any side effects (e.g., temporary network impact), but it clearly states the action and its target. The behavior is transparent enough for the simple sync 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, consisting of three sentences that explain the purpose, the reason for sync, and the use case. No unnecessary information is included, and it is well-structured for quick comprehension.
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 a single parameter and no output schema, the description is complete. It tells what the tool does, why it might be needed, and when to use it. The context is fully covered, with no missing critical information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter, firewallId, has a basic description 'Firewall ID' that matches its schema. The description does not add additional context beyond what the schema already provides, but it is clear and sufficient. Since schema coverage is 100%, the baseline is 3, and the description does not enhance understanding 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: syncing firewall rules to all assigned VMs. It uses a specific verb 'sync' and identifies the resource (firewall) and target (all assigned VMs). It also explains why sync is needed, 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 provides usage guidance: 'Use this endpoint to apply updated firewall rules to all VPS instances assigned to the firewall.' It clarifies the scenario (when rules have changed) and distinguishes this from syncing to a single VM (as implied by sibling tools like VPS_syncFirewallV1).
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?
Annotations already declare readOnlyHint=true and destructiveHint=false, and the description adds useful behavioral context: the returned methods are limited to those usable for new orders, and the API cannot add new payment methods. It does not describe the response structure, but for a zero-parameter read-only list this is a minor omission.
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 short and front-loaded with the primary action. The hPanel alternative is useful, but the final sentence partly restates the first sentence's 'placing new orders' context, so it is slightly redundant rather than fully 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?
For a read-only, zero-parameter endpoint with no output schema, the description covers the purpose, the business context, and the relevant external alternative. Nothing needed for correct selection or invocation 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?
The tool has no parameters, so the input schema is complete and the baseline is 4. The description does not need to add parameter-level detail since there is nothing to document.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Retrieve') and a clear resource ('available payment methods') with an explicit scope ('that can be used for placing new orders'). This makes the tool's purpose unmistakable and distinguishes it from related billing list endpoints like billing_getSubscriptionListV1 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 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 endpoint ('view available payment options before creating orders') and provides a clear exclusion for a related need: adding a new payment method should go through hPanel, not this API. This gives the agent actionable routing guidance without ambiguity.
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?
Beyond the annotations, the description discloses important behavior: the free transfer is only consumed after validation, unsuccessful requests are rejected with an error code, a successful response only means the transfer has started, and default WHOIS data will be used if none is supplied. This gives the agent a realistic model of the operation's side effects and asynchronous nature.
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 longer than average but most sentences carry meaningful operational information, such as validation-before-consumption and WHOIS defaults. Some redundancy exists with the closing 'Use this endpoint...' sentence repeating the opening, but the structure is logical and front-loaded with the key distinction from paid transfers.
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 output schema, the description covers the essential operational context: prerequisites, validation semantics, async completion, WHOIS fallback behavior, and error handling. An agent has enough information to decide whether to call the tool and what to expect after doing so.
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 documents all parameters, so the baseline is 3. The description adds value by explaining that omitting domain_contacts causes default WHOIS information to be used, and it emphasizes the need to unlock the domain and have an authorization code before calling. This goes 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 uses a specific verb ('Claim') and resource ('free domain transfer'), and explicitly contrasts it with purchasing a transfer, which distinguishes it from related domain transfer tools. The first sentence states exactly what happens: a free transfer is claimed and the transfer process is started.
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 this endpoint should be used when a free domain transfer is available on the account and explicitly notes that it does not require payment, unlike purchasing a transfer. It also points to the transfer list endpoint for following completion, giving the agent a clear next step.
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 reveals the destructive behavior: 'Any toggleable extension not in the request is disabled', and clarifies built-in extensions are 'always active and are unaffected'. This goes well beyond the annotations (idempotentHint, destructiveHint), adding concrete operational consequences.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, no filler; the core action is first, with essential warnings and exceptions following. Each sentence carries necessary 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?
With only two parameters and annotations covering safety, the description supplies all needed operational context: full-set semantics, built-in exception, and endpoint ordering. No output schema exists so return values need not be documented.
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 already covers both parameters at 100%. The description adds meaning to the extensions parameter by requiring the full desired set and explaining the toggleable/built-in distinction, which is beyond schema text.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names the verb ('Replaces'), resource ('set of PHP extensions enabled on an Agency Plan website'), and effect ('with the ones provided'). It clearly differentiates from sibling listing/reset tools by emphasizing replacement semantics.
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 instructs the caller to 'call the extensions endpoint first and send the full desired set', which is direct procedural guidance. However, it does not explicitly name alternative tools or exclusion conditions, so 4 rather than 5.
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?
Goes well beyond the destructiveHint annotation by explaining exactly what gets reset: any option not in the request, and all options when an empty array is sent. This is the critical behavioral trait an agent must know before calling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences with no filler. The purpose is front-loaded, followed immediately by the most important behavioral warning and the empty-array edge case.
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?
With only two required parameters, full schema coverage, and no output schema, the description covers everything needed to call the tool correctly. The reset semantics and the prerequisite call to the options endpoint make the contract 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 parameter names and constraints are already documented. The description adds important semantics for the options parameter: it must contain the full desired set, and omissions mean reset-to-default.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('Replaces'), resource ('custom php.ini values on an Agency Plan website'), and the replacement behavior. This cleanly separates it from sibling tools like listing PHP options or replacing PHP extensions.
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?
Gives explicit usage guidance: call the options endpoint first and send the full desired set, since omitted options are reset. It lacks explicit contrasts with sibling tools, but the workflow instruction is concrete 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?
Annotations already indicate readOnlyHint=false, idempotentHint=true, and destructiveHint=true. The description goes beyond annotations by explaining the behavioral effect of each status value ('buyable', 'hide', 'retire') and by stating that the updated product summary is returned. It does not fully explain destructive consequences, but the annotation and 'retire' wording cover the essential risk.
Agents need to know what a tool does to the world before calling it. Descriptions 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 with the action. Each sentence earns its place: it states the operation, explains status semantics, redirects variant work, and notes the return value. No filler or redundant restatement.
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 5-parameter update tool with no output schema, this description is complete. It covers the updatable fields, the meaningful status transitions, the boundary with variant endpoints, and the return value. Annotations cover safety characteristics, and the schema covers required IDs and parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds value beyond the schema by enumerating exactly what can be updated ('name, description or status') and by explicitly excluding variant, price, and inventory parameters, helping the agent avoid looking for unrelated 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 states a specific verb and resource: 'Update a product's name, description or status.' It also differentiates from related sibling tools by explicitly noting that variants, prices, and inventory are handled through the variant endpoints, not here.
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 tool explicitly says what it is for and what it is not for: product-level fields are updated here, while variants, prices, and inventory belong to the variant endpoints. This gives an agent clear when-to-use and when-not-to-use guidance despite not naming a specific sibling 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?
Beyond the readOnlyHint=true annotation, the description discloses that each call reruns the analysis, that analysis/solution can be null, and that a 429 is returned above the rate limit. It also explains the 422 state constraint. No contradiction with the annotations exists.
Agents need to know what a tool does to the world before calling it. Descriptions 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 every sentence earns its place: purpose, state constraint, fallback behavior, and rate-limit guidance. It is front-loaded with the core purpose and avoids fluff or repetition of the title.
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 output schema, the description adequately explains return values (analysis, solution), null behavior, error cases, and rate limits. It also names the fallback sibling tool. An agent can correctly decide when to call it, what to expect, and how to handle 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%, so the baseline is 3. The description adds context about what the analysis is based on, but it does not clarify the meaning or format of the parameters beyond the schema. The schema's username description ('username parameter') is tautological, and the description does not resolve that ambiguity, so it stays at 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 states a specific verb ('Returns an AI analysis') and a specific resource ('why a build failed and how to fix it'), grounded in concrete inputs (build logs, project file list, package.json). It clearly distinguishes itself from sibling log-fetching tools by emphasizing the AI analysis output and the fallback to 'Get NodeJS 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 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 it (failed builds only), what happens otherwise (422), and what to do if the analysis is unavailable (read Get NodeJS build logs instead). It also gives operational guidance: call once per failed build, keep the result, and stay under the 5 calls/minute rate limit.
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?
Beyond the annotations, the description reveals three important behaviors: the cache clear is permanent, it clears all server-side cache at once, and it conditionally purges Hostinger CDN cache when CDN is enabled. It also adds the WordPress-subdirectory edge case. This is valuable behavioral context that annotations alone do not provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core action, followed by use cases and edge-case behavior. Every sentence adds distinct information: permanent scope, when to use, CDN behavior, and directory usage. There is no wasted text.
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 what the tool does, when to use it, what additional cache it affects, and how to target a subdirectory installation. Combined with complete schema descriptions and annotations, an agent has everything needed 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%, and the description adds meaningful behavior for the directory parameter by explaining the WordPress-subdirectory use case. It does not add much to username or domain, but the schema already names those parameters clearly enough. Overall the description enriches parameter understanding beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The first sentence names the exact operation and scope: 'Permanently clears all server-side cache for the website at once.' It adds CDN-cache behavior, which clearly distinguishes this broad cache-clearing tool from narrower siblings like hosting_purgeLiteSpeedCacheV1. The verb, resource, and scope are specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage 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: 'when content was updated and needs to be visible immediately, or after making major changes.' It does not name alternatives or when-not-to-use cases, so it falls short of full 5-level guidance, but the context is clearly framed.
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?
Annotations already mark destructiveHint=true and readOnlyHint=false, but the description significantly adds behavioral context: removal is irreversible, all files/databases/configuration are deleted, the hosting plan remains, processing is asynchronous, and the response returns before completion. It also documents the 404 case. This goes well beyond the 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?
Despite being multi-paragraph, every sentence adds necessary information for a destructive operation. The irreversible warning leads, followed by scope, error behavior, and async semantics. The structure is logical and front-loaded with the most critical guidance.
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 is fully self-contained for a one-parameter destructive tool. It covers what gets destroyed, what is preserved, which website types are valid, error cases, and asynchronous behavior. Even without an output schema, an agent has everything needed to call it safely and 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 only says 'Domain name', but the description adds critical meaning: it must be the exact website domain, not a preview domain or alias. It also ties the domain to the supported website types, giving the agent real guidance for supplying the single parameter correctly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: it permanently removes a website and all its data. It clearly distinguishes this from other hosting operations by detailing what is deleted and what is preserved. The scope is unambiguous even among many 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 gives explicit usage constraints: requires user confirmation, supports only main/addon domain websites and Website Builder websites, and excludes parked domains, subdomains, preview domains, and aliases. It does not explicitly name an alternative sibling for unsupported cases, but the supported/not-supported guidance is clear enough for correct tool selection.
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?
Even with readOnlyHint and destructiveHint annotations, the description adds substantial behavioral context: the four possible states, polling semantics, the 404 case for a UUID that does not belong to this website, and the fact that failed-build cause analysis is intentionally deferred to other tools.
Agents need to know what a tool does to the world before calling it. Descriptions 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: result summary, polling/failure routing, and 404 behavior. Essential information is front-loaded with no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only single-build detail call with no output schema, the description covers return contents (state, options, timestamps), state values, polling semantics, failure next-steps, and the 404 condition. No critical invocation decision is left unstated.
Complex tools with many parameters or behaviors need more documentation. Simple tools need 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 only the contextual hints that domain/username identify 'this website' and that uuid selects the build; it does not clarify the unhelpful 'username parameter' schema text or provide parameter formats. 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 concrete verb ('Returns one build by UUID') and specifies the resource and result fields: state, options, and timestamps. It clearly differentiates this single-build detail endpoint from sibling log/analysis tools by naming them later in the description.
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 to poll while a build is pending or running, and on failure to switch to 'Get NodeJS build logs' and 'Analyse failed Node.js build' for the cause. This is direct when-to-use and alternatives guidance, not just implied context.
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?
Annotations already mark it read-only and non-destructive, and the description adds valuable behavior beyond that: the 404-until-first-storage rule, the fact that API build requests only persist settings when none exist, and the role of stored settings in Git auto-deployment. These explain edge cases an agent would otherwise only discover at runtime.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is moderately detailed but every sentence earns its place: it enumerates the returned fields, explains storage semantics, warns about the 404 behavior, and gives a concrete usage flow. It is front-loaded with the core purpose before diving into nuances.
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 read-only tool with no output schema, the description is complete: it lists what is returned, when it returns 404, how stored settings interact with API builds, and what action to take next. An agent has enough context to call it correctly and interpret the result.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with domain and username both documented in the input schema. The description does not add parameter-level meaning beyond what the schema provides, which is acceptable because the schema already carries the full burden. 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 states a specific verb and resource: returns the build settings stored for the website, with an explicit list of fields. It clearly distinguishes this from nearby siblings like hosting_getNode_jsBuildSettingsFromArchiveV1 by emphasizing 'stored' settings and the website context. The mention of 404 until first build/settings update further pins down its exact 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 gives an explicit use case: use after a failed build to check framework/entry-file detection, then fix with the Update Node.js build settings endpoint. It also clarifies the relationship between API-initiated builds and stored settings, which helps an agent decide when this read reflects reality. This is strong contextual guidance.
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?
Beyond the annotations, the description clearly discloses that the operation is asynchronous, that a successful response only means the job is queued, that installation takes 1-2 minutes, and how to poll for completion. It also explains the failure mode when WordPress already exists and overwrite is false. This significantly enriches behavioral understanding beyond the structured hints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Although relatively long, every paragraph serves a distinct purpose: precondition, preflight check, and async completion behavior. The first sentence front-loads the core purpose, and the structure makes the operational workflow easy to follow. No filler or tautological content is present.
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 tool with 10 parameters, nested objects, async behavior, and no output schema, the description is remarkably complete. It tells the agent when the operation is safe to call, how to avoid a failing job, what the response actually means, and how to determine when the installation is ready. Nothing essential is left unspecified for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3; the schema already documents the parameters well. The description adds useful context around overwrite and preflight checks, but it does not meaningfully expand on most parameter 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?
Description opens with a specific verb and resource: 'Install WordPress on an existing website.' This clearly identifies the operation and separates it from related WordPress tools like import, plugin deployment, or core updates. The 'existing website' qualifier sets the scope precisely.
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 gives explicit preconditions: the website must already exist, and it tells the agent how to create and verify one before calling. It also instructs the agent to preflight for existing installations and explains the overwrite default behavior, plus how to poll for async completion. This is exemplary usage guidance with named endpoints and 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?
Annotations already declare readOnlyHint=true and destructiveHint=false, and the description adds critical behavioral details beyond that: values are always masked as `********` and cannot be read back through this API. This prevents an agent from expecting to retrieve actual secret values and explains why verification is key-based only.
Agents need to know what a tool does to the world before calling it. Descriptions 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: purpose first, then masking behavior, then usage guidance, then a critical warning about the replace endpoint. Every sentence earns its place, and there is no filler 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?
For a read-only listing tool with strong annotations and a rich description, this is complete. It covers what the tool returns conceptually (keys, masked values), its limitation, when to use it, and how it relates to the sibling replace operation. The absence of an output schema is not a problem because the response behavior is clearly 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 description coverage is 100%, so the baseline is 3 even without extra parameter explanation in the description. The description itself does not add meaning to `username` or `domain`, and the schema's `username` description ('username parameter') is weak, but this dimension measures whether the description compensates beyond the schema. It does not, though it also 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 opens with a specific verb and resource: 'Lists the Node.js environment variables currently set for the website.' It also clarifies what the tool does not do (values cannot be read back), which distinguishes it from writing or value-retrieval endpoints. This clearly differentiates it from sibling tools like hosting_replaceNode_jsEnvironmentVariablesV1.
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 endpoint: 'to see which keys are configured or to verify a change, not to read values.' It also points to the exact alternative endpoint for modifications and warns against copying masked values into the replace request. This gives the agent concrete decision criteria.
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?
Annotations are minimal (readOnlyHint=false, destructiveHint=false), so the description carries the behavior burden and does so thoroughly. It explains the PR flow, that merging triggers deployment, that non-patchable IDs are skipped, that an all-non-patchable selection is rejected, that only one patch PR can be open at a time, and the 404/403/422 failure modes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is information-dense but every sentence earns its place: core mechanics first, then prerequisites and failure modes, then edge cases and plan availability. Nothing is redundant, and the most important action 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 mutating tool with no output schema, the description is unusually complete. It covers prerequisites, permission requirements, error conditions for common failure cases, partial-success behavior, concurrency constraints, and plan eligibility. An agent has enough context to invoke it correctly and interpret the likely outcomes.
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 context on vulnerability_ids: only is_patchable vulnerabilities are patched, non-patchable ones are skipped, and the resulting PR's patch set is reported in patched_vulnerability_ids. It does not deeply explain username/domain, but the schema labels them acceptably and the overall semantics are clear.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Patches the selected Node.js vulnerabilities by updating the affected package versions in package.json and opening a GitHub pull request.' This clearly distinguishes it from list-only or deployment tools in the sibling set, such as hosting_listNode_jsVulnerabilitiesV1.
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 explicit when-to-use and when-not-to-use guidance: it only works for GitHub-connected repositories, archive-deployed sites return 404, the GitHub App needs write access, and only patchable vulnerabilities can be included. It does not explicitly name an alternative tool, but the conditions are concrete and actionable.
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?
Annotations only provide readOnlyHint=false and destructiveHint=false. The description adds valuable behavioral context beyond that: it does not rebuild or redeploy, it is a no-op for static sites, and it returns success even when there is no server process to restart. That last detail is especially useful and not predictable from the schema or 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 compact and well-structured: it leads with the core action, then covers scope limitations and edge-case behavior. Every sentence adds useful information, with no repetition or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter operation with no output schema, the description is complete enough. It covers what the tool does, when to use it, when it is ineffective, and what happens in the edge case where no process exists. An agent has the information needed to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description itself adds no parameter-level meaning beyond what the schema provides. The schema descriptions are minimal ('username parameter'), but the description is not responsible for compensating when formal coverage is already complete.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid 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 ('Restarts the Node.js server process for the website') and explicitly distinguishes itself from build/deploy operations ('Does not rebuild or redeploy the application'). This makes it easy for an agent to tell it apart from deployment and build siblings like hosting_deployJsApplication and hosting_startNode_jsBuildV1.
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 gives concrete when-to-use guidance: applying environment/config changes or recovering a hung application. It also explicitly states when not to use it — static front-end apps have no server process, so restarting has no effect. This is strong usage direction with clear 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?
The description discloses key behavioral traits beyond the annotations: the work is queued, a success response means accepted rather than finished, and already-tagged contacts are left alone. This gives an agent an accurate model of side effects and asynchronous behavior. No contradiction with 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?
Three compact sentences, no filler, and the core purpose is in the opening line. The target-selection options and queueing behavior are presented in a natural order.
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 bulk mutation tool with no output schema, the description covers the essential facts: target selection, asynchronous acceptance, and idempotent behavior for already-tagged contacts. The annotations supply the read/write and destructive hints, so nothing critical 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?
Schema coverage is 100%, and the description adds meaningful semantics beyond it by explaining the relationship between contact_uuids and all_contacts and their targeting behavior. The required profileUuid and tagUuid remain lightly described in the schema, but their meaning is self-evident from 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?
States a specific verb and resource: 'Assign a tag to many contacts at once.' The 'many contacts at once' phrasing distinguishes this from single-contact and removal siblings like reach_assignAContactToATagV1 and reach_removeContactsFromATagV1. No ambiguity about what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear within-tool usage guidance: pass contact_uuids for specific contacts or all_contacts for every contact in the profile. It does not explicitly mention sibling alternatives or when not to use this tool, but the 'many contacts at once' wording implicitly scopes it for bulk assignment.
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?
Annotations already mark the operation as destructive and non-read-only; the description adds the important behaviors of permanent removal, deprecation, default-profile fallback, and inability to delete contacts from other profiles. No contradiction with the annotations exists.
Agents need to know what a tool does to the world before calling it. Descriptions 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 the core action first, followed by the permanent-deletion consequence and then the deprecation/alternative. Every sentence contributes necessary information without filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter destructive endpoint with annotations covering destructiveness and idempotency, the description is complete: it explains the effect, irreversibility, scoping limitation, and replacement route. No return-format detail is necessary for correct selection or 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 schema already fully documents the single parameter 'uuid' as the UUID of the contact to delete, so the description adds little parameter-level meaning beyond what is structured. With 100% schema coverage, the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
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 and resource: deleting a contact by UUID, and adds the key consequence that it permanently removes the contact from the email marketing system. It also distinguishes itself from the profile-scoped alternative by explaining the default-profile fallback and deprecation.
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 warns that the endpoint is deprecated, cannot target a profile, and always falls back to the default profile. It then tells the agent to use the replacement endpoint instead, which is 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.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the tool as destructive and non-read-only, but the description adds genuinely useful behavioral context: deletion is permanent, the template is removed too, submission-bearing forms are protected, and views do not prevent deletion. This goes well beyond what the annotations communicate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is tight and well-structured: the primary action comes first, followed by the critical deletion constraint, the recommended alternative, and an important edge-case clarification. 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 destructive delete with no output schema, the description is complete. It explains the permanent scope, the precondition for deletion, the alternative action, and the fact that views do not block deletion, giving an agent everything needed to decide whether and how to call the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3 even though the description itself adds no parameter-level meaning. The descriptions 'Form uuid parameter' and 'Profile uuid parameter' are minimal but present, and the tool description does not 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 the operation: 'Permanently delete a form together with its template.' It specifies both the resource and the destructive action, and is easily distinguishable from sibling read-only form tools like reach_getFormDetailsV1 and reach_listFormsV1.
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 warns when deletion is not allowed ('a form that has already captured submissions cannot be deleted') and provides the recommended alternative ('pause the form instead'). It also clarifies that views alone do not block deletion, giving the agent concrete decision 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?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is known. The description adds valuable behavioral context: the list is profile-specific, includes custom fields, tags, and the 20 most recently published campaigns, and cannot be hardcoded. This goes beyond annotations and explains why the output is dynamic and limited to 20 campaigns.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficient: two short paragraphs. The first sentence states the core function, the second provides critical context and usage. No filler or repetition, and the most important information (what it returns) 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 simple read-only tool with one parameter and no output schema, this description is complete. It explains what the response covers, why the tool is needed before segment operations, and notes the dynamic nature. Nothing essential is missing for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the parameter is documented. The description adds meaning by explaining why profileUuid matters: the list is profile-specific and includes profile-dependent data. This helps the agent understand the parameter's role more deeply than the schema's simple 'Profile uuid parameter' line.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states what the tool does: lists every attribute a segment condition can filter on, including operators, value formats, and allowed values. It is specific about the resource (segment filter attributes) and distinguishes itself from sibling segment tools by focusing on filter capabilities rather than segment management itself.
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 tells the agent when to use this tool: 'Read it before creating or updating a segment to discover the valid `attribute`, `operator` and `value` combinations.' This provides clear context and a direct prerequisite for other segment operations, leaving no ambiguity about 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.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark this destructive, but the description goes further by disclosing that snapshots will be deleted, data is irreversibly lost, and the OS is reinstalled. It also reveals password validation against leaked databases, which is material behavioral context not available from annotations or 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 appropriately sized for a destructive, high-stakes operation. Key information is front-loaded, the password requirements are scannable in bullets, and the irreversible data-loss warning is prominent. No sentence is filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive recreation operation with no output schema, the description covers the essential facts: what happens, what gets destroyed, irreversibility, and additional password constraints. An agent has enough information to invoke the tool correctly and to warn the user about consequences.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already documents all five parameters, so the baseline is 3. The description adds meaningful extra semantics for the password parameter by specifying length, character class, and leaked-database requirements, going beyond the schema's basic 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 opens with a specific verb and resource: 'Recreate a virtual machine from scratch.' It clarifies the operation by explaining it reinstalls the operating system and resets the VM to its initial state, which distinguishes it from ops like restarting, stopping, or purchasing a 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 final line explicitly states when to use the endpoint: 'to completely rebuild VPS instances with fresh OS installation.' It gives clear context for use, though it does not explicitly name alternative tools or exclude non-recreation operations.
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 clearly discloses that provisioning is asynchronous: returns immediately with a setup UUID, website becomes reachable only after provisioning finishes. It also explains the domain fallback behavior. This adds substantial context beyond the sparse annotations (readOnlyHint=false, destructiveHint=false).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with a one-sentence purpose, followed by compact bullet recipes and a clear closing note about background provisioning. There is no filler, and the structure makes the multi-setup complexity 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?
For a 7-parameter nested create tool with no output schema, the description covers all major invocation paths, the free subdomain behavior, and the asynchronous job identification. The only minor omission (datacenter codes depend on live capacity) is already present in the schema, so the total tool definition is complete.
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?
Though schema coverage is 100%, the description adds crucial combinatorial meaning: how 'flavor' values map to PHP vs WordPress setups, how 'type'='node-static' creates a static frontend, and exactly what happens when 'domain' is omitted. These recipes go well beyond the schema's 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 opens with a specific verb+resource: 'Provisions a new website on one of your Agency Plan hosting orders.' It details the key choices (datacenter, flavor, PHP version, domain, WordPress) and explicitly scopes to Agency Plan hosting, distinguishing it from sibling deploy/import 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 concrete setup recipes (plain PHP, WordPress, static/Node.js) that tell an agent which parameter combinations work and when this tool is appropriate. However, it does not explicitly contrast with alternatives like agency-hosting_deployNodeStaticWebsite or hosting_installWordPressV1, so no clear exclusions or 'use X instead' guidance.
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?
Beyond destructiveHint=true, the description warns that the operation 'overwrites the website's existing contents and cannot be undone' and instructs always confirming with the user. It also discloses the synchronous nature of the operation, the internal generation of upload credentials, and the end-to-end behavior, giving the agent an unusually complete picture of what happens when the tool is invoked.
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 long but dense, and each sentence earns its place: purpose, destructive warning, applicability, process, synchronous guarantee, and exclusions. It is front-loaded with the core purpose and warning. The only slight knock is that it could be tightened without losing information, though no sentence is filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive, synchronous deployment tool with no output schema, the description covers everything an agent needs: what it deploys, the destructive side effect, the build-and-deploy flow, the synchronous wait semantics, the parameter nuances, and the explicit alternative. There is no material gap between what structured data provides and what an agent needs to call 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, but the description adds real value: it specifies accepted archive formats for archivePath, gives the exact naming pattern for creating an archive from a directory, and explains that removeArchive defaults to true. It also clarifies that the website UID is automatically derived from the domain, which removes potential confusion about an extra 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 opens with a precise verb and resource: 'Deploy a node-static Agency Plan (h5g) website from an archive file.' It further distinguishes the target by defining node-static as 'a Node.js-built static site that requires a build step or a plain simple static site,' and it explicitly contrasts with the PHP alternative. An agent can tell exactly which operation this is without opening a schema.
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 says when to use it ('Use this for Agency Plan websites of type node-static'), names the alternative ('For plain PHP applications... use agencyHosting_deployPhpApplication instead'), and gives explicit negative guidance ('do not call a separate upload-url endpoint or upload the archive yourself'). It also provides conditional instructions for handling a directory path, so an agent knows exactly what to do in a common edge case.
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?
Beyond the readOnlyHint and destructiveHint annotations, the description discloses oldest-first ordering, skipping of non-JSON lines, the difference between logs and total_lines, previous-deployment exclusion via last_deployed_at, and empty logs when no log file exists. No contradiction with the 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 front-loads the result and then organizes usage into first-call versus polling, with each sentence carrying a distinct rule or edge case. Despite its length, there is no filler 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?
With no output schema, the description compensates by naming the response fields it references (logs, total_lines, last_deployed_at) and covering edge cases such as non-JSON lines, no log file yet, and previous deployments. An agent has enough information to make a correct first call, interpret the response, and poll for new entries.
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%, but the description adds operation-level meaning: period applies to the first call, from_line is used for polling, period and from_line are mutually exclusive, and limit has a default of 1000 with newest entries kept on overflow. This materially improves correct parameter usage beyond the bare 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?
States a specific verb and resource: 'Returns the Node.js application's runtime console log entries, oldest first, each with timestamp, level and message.' The 'runtime console' wording distinguishes it from sibling build/deployment log tools such as hosting_getNodeJSBuildLogsV1 and 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 first-call protocol ('send period ... optionally levels and limit') and polling protocol ('send total_lines + 1 ... as from_line and omit period'), including the exclusion rule that period and from_line cannot be combined. It does not name sibling alternatives, but the usage context is clear and actionable.
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?
Despite annotations already indicating non-read-only, destructive, and idempotent behavior, the description adds valuable context: full-set replacement semantics, nulling of omitted nullable fields, creating settings when none exist, and the distinction between stored settings and API-triggered builds. This goes well beyond the annotation flags.
Agents need to know what a tool does to the world before calling it. Descriptions 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, the next covers the critical replace behavior, and the second paragraph explains non-build behavior and typical use cases. Every sentence earns its place without 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 9-parameter tool with no output schema, the description covers the essential semantics: replacement, upsert behavior, required fields, the relationship to Git auto-deployment, and the explicit alternative for rebuilding. Required identifiers are in the schema, and safety traits are in annotations, so nothing critical is missing for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds genuinely useful parameter-level guidance beyond the schema: 'Send the full set: node_version is required and every nullable field you omit is stored as null.' It also calls out entry_file requirements for specific frameworks, reinforcing the schema's hint.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Replaces the build settings stored for the website,' and clarifies it creates settings when none exist. It explicitly contrasts with starting a build, which distinguishes it from sibling tools like hosting_startNode_jsBuildV1.
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 specifies when to use this tool (fixing wrong app_type or missing entry_file) and explicitly names the alternative for rebuilding: 'call Start Node.js build with the same values.' It also explains that this does not start a build, so the agent knows not to use it for immediate builds.
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?
Annotations already indicate read-only and non-destructive behavior. The description adds meaningful context beyond annotations: the deprecation status, the always-default-profile fallback, and the inability to list segments of any other profile. This directly shapes whether an agent should select or avoid the tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short paragraphs are front-loaded with the core action, then usage context, then deprecation warning and replacement. Every sentence carries useful information with no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless list endpoint with read-only annotations, the description covers what it returns, the key limitation, and the replacement endpoint. It gives an agent enough to decide correctly even without an output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and schema coverage is 100%, so there is no parameter documentation burden. The description reinforces that the endpoint has no targeting/filtering capability by explicitly stating it cannot target a profile.
Input schemas describe structure but not intent. Descriptions should explain non-obvious 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 opens with 'Get a list of all contact segments', a specific verb and resource. It further scopes behavior by stating the endpoint cannot target a profile and always falls back to the client's default profile, distinguishing it from profile-scoped segment listing tools.
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 marked 'Deprecated' and gives the exact replacement endpoint. It clearly states when not to use this tool: when another profile's segments are needed, use GET /api/reach/v1/profiles/{profileUuid}/segmentation/segments 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?
Annotations already mark this as destructive and non-read-only, and the description meaningfully expands on that by detailing the full-replace behavior, deletion of omitted variables, process restart, build-time limitations, and masked values from the list endpoint. This goes well beyond the annotations and gives the agent a strong mental model of the operation's consequences.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but every sentence earns its place. The most critical fact (full replace) is front-loaded, and subsequent paragraphs cover restart semantics, build-time requirements, and the masked-value pitfall 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?
For a destructive, side-effect-heavy mutation with no output schema, the description is remarkably complete. It covers what happens to existing variables, what happens on save, when a build is needed, what to do next, and a common data-source trap. The agent has enough context to invoke this tool safely and correctly.
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?
The schema already documents the env_vars parameter well, but the description adds crucial operational semantics: the full desired set must always be sent, missing variables are deleted, an empty array deletes everything, and values from the list endpoint are masked and therefore unusable. It also directs the agent to source real values from the project .env file or user prompt, adding practical guidance 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 a specific verb and resource: 'Replaces the website's Node.js environment variables with the ones provided.' It immediately clarifies this is a full replace, which distinguishes it from list/read and build-related sibling tools. The naming and content align precisely, so an agent knows exactly what operation this performs.
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 gives explicit behavioral and routing guidance: it explains that a restart is enough for Express/NestJS apps, that build-time frameworks like Next.js standalone require a fresh build, and that the 'Start Node.js build' endpoint should be used afterward. It also warns against copying values from the 'List Node.js environment variables' endpoint, giving clear when-to-use and when-not-to-use context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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