BorealHost

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions the authentication requirement (API key with write scope), which is valuable context. However, it doesn't address other important behavioral aspects like rate limits, error conditions, whether the operation is idempotent, or what happens if a cron job with the same schedule already exists.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is efficiently structured with clear sections (purpose, requirements, arguments, returns). Each sentence serves a distinct purpose with zero wasted words. The information is front-loaded with the core purpose, followed by essential details in a logical flow.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a mutation tool with no annotations and no output schema, the description provides adequate but incomplete coverage. It explains the purpose, requirements, parameters, and return structure, but lacks details about error handling, side effects, or the specific content of the result object. Given the complexity of adding a cron job (which involves scheduling and execution), more behavioral context would be beneficial.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema description coverage, the description must compensate for the lack of parameter documentation in the schema. It provides clear explanations for all three parameters: 'slug' as 'Site identifier', 'schedule' with cron format examples, and 'command' as 'Command to execute'. This adds substantial meaning beyond what the bare schema provides, though it could benefit from more detail about slug format constraints.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the specific action ('Add a cron job') and the target resource ('to a site'), distinguishing it from sibling tools like 'list_cron' or 'delete_cron'. It uses precise terminology that leaves no ambiguity about the tool's function.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly states a prerequisite ('Requires: API key with write scope'), providing clear context for when this tool can be used. However, it doesn't specify when to use this tool versus alternatives like 'list_cron' or 'delete_cron', nor does it mention any exclusions or specific scenarios where it shouldn't be used.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes the write operation ('Add'), authentication requirements ('API key with write scope'), and includes error cases (VALIDATION_ERROR, NOT_FOUND) and return format. However, it doesn't mention rate limits, idempotency, or side effects beyond the immediate addition.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured with clear sections (description, requirements, args, returns, errors) and uses bullet points effectively. While comprehensive, it could be slightly more concise by combining some explanations, but every sentence earns its place by adding necessary information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complexity of a DNS record creation tool with 6 parameters, 0% schema coverage, no annotations, and no output schema, the description provides complete context. It covers purpose, prerequisites, all parameters with semantics, return format, and error cases—everything needed for correct tool invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema description coverage, the description fully compensates by providing detailed parameter explanations. It documents all 6 parameters with examples, clarifies defaults (ttl: 3600), specifies required conditions (priority required for MX), and explains domain/subdomain relationships. This adds substantial value beyond the bare schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the specific action ('Add a DNS record') and resource ('to a domain'), distinguishing it from sibling tools like 'delete_domain_dns' or 'list_domain_dns'. It provides a complete verb+resource+scope statement in the first sentence.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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 ('Add a DNS record to a domain') and provides prerequisites ('Requires: API key with write scope'), but doesn't explicitly mention when NOT to use it or name specific alternatives from the sibling list (e.g., 'delete_domain_dns' for removal).

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden and does well by disclosing key behaviors: it reloads Nginx after adding the rule, supports IPv4/IPv6/CIDR, has a max of 100 rules per site, updates existing rules instead of failing, and requires an API key with write scope. It doesn't mention rate limits or error conditions, but covers most critical operational aspects.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is efficiently structured with a clear purpose statement first, followed by behavioral details, prerequisites, and parameter explanations. Every sentence earns its place—no fluff. The use of sections (Args, Returns) enhances readability without unnecessary verbosity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a mutation tool with no annotations and no output schema, the description is remarkably complete. It covers purpose, behavior, prerequisites, parameters with examples, and even includes a return value example. Given the complexity (firewall rule management with Nginx reload), it provides all necessary context for safe and effective use.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema description coverage, the description fully compensates by providing detailed parameter semantics. It explains each parameter: 'slug' as site identifier, 'ip' with examples of formats, and 'action' with allowed values and default. This adds significant meaning beyond the bare schema, making parameters completely understandable.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the specific action ('Add an IP firewall rule'), the resource ('Nginx'), and the scope ('allow or deny'). It distinguishes itself from sibling tools like 'remove_firewall_rule' by specifying it's for adding/updating rules, not removing them. The purpose is explicit and well-defined.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides clear context for when to use this tool: for adding or updating firewall rules with IP/CIDR inputs. It mentions the sibling 'list_firewall_rules' implicitly by noting the max 100 rules per site, suggesting checking existing rules first. However, it doesn't explicitly state when NOT to use it or name alternatives like 'remove_firewall_rule' for deletion scenarios.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries full burden and does well by disclosing: the mutation nature ('inject'), specific file location ('/home/admin/.ssh/authorized_keys'), plan restrictions, authentication requirements, and error conditions. It doesn't mention rate limits or idempotency, but covers most critical behavioral aspects.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Well-structured with purpose first, then implementation details, requirements, parameters, returns, and errors. Every sentence earns its place, though the parameter documentation could be slightly more integrated with the main flow rather than in a separate 'Args' section.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 2-parameter mutation tool with no annotations or output schema, the description provides complete context: purpose, usage constraints, authentication needs, parameter details, return format, and error conditions. It leaves no significant gaps for agent understanding.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate fully. It provides detailed semantics for both parameters: 'slug' as 'Site identifier' and 'public_key' with specific format requirements and supported key types. This adds substantial value beyond the bare schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the specific action ('inject your SSH public key'), target resource ('site's container'), and purpose ('for direct SSH access'). It distinguishes from sibling tools like 'get_ssh_info' by focusing on adding rather than retrieving SSH information.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly states when to use ('Only available for VPS/dedicated plans') and prerequisites ('Requires: API key with write scope'). It also implicitly distinguishes from alternatives by specifying the exact behavior (appending to authorized_keys), though it doesn't name specific sibling alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries full burden and does well by disclosing critical behavioral traits: it's a destructive operation ('Flush all caches'), requires specific permissions ('API key with write scope'), and shows the expected return format. It doesn't mention rate limits or error conditions, but covers the essential 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.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is perfectly structured with clear sections (action, requirements, args, returns) in just four lines. Every sentence earns its place with zero wasted words, making it easy to scan and understand quickly.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a destructive operation with no annotations and no output schema, the description does well by covering purpose, prerequisites, parameter meaning, and return format. It could be more complete by mentioning potential side effects or error cases, but provides sufficient context for safe invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema description coverage for the single parameter, the description compensates by explaining that 'slug' is a 'Site identifier', adding meaningful context beyond the bare schema. This clarifies what the parameter represents, though it could provide more detail about format or examples.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the specific action ('Flush all caches') and resources involved ('Redis + WP object cache'), distinguishing it from sibling tools like cache_status (monitoring) and cache_toggle (enabling/disabling). It uses precise technical terminology that unambiguously defines the tool's function.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides explicit prerequisites ('Requires: API key with write scope') which gives clear context for when this tool can be used. However, it doesn't specify when to use this versus alternatives like cache_toggle or differentiate from other cache-related operations, missing explicit sibling differentiation.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden. It discloses the required API key scope ('read scope'), which is useful for authentication needs. However, it doesn't mention other behavioral traits like rate limits, error handling, or whether the operation is read-only (implied by 'Get' but not explicit). The description adds some value but lacks comprehensive 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.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured and front-loaded: it starts with the core purpose, lists requirements, and details arguments and returns in a clear format. Every sentence adds value without redundancy, making it efficient and easy to parse for an AI agent.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's low complexity (1 parameter, no output schema, no annotations), the description is reasonably complete. It covers purpose, prerequisites, parameters, and return values with examples. However, it lacks explicit confirmation of read-only behavior and doesn't address potential errors or edge cases, which could be beneficial for full completeness.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 0% description coverage, with one parameter 'slug' documented only as a string. The description adds meaning by specifying 'slug: Site identifier,' clarifying its purpose. However, it doesn't provide details like format or examples. Since schema coverage is low, the description compensates partially but not fully, meeting the baseline for minimal parameter info.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: 'Get cache status (Redis, WP object cache, hit rates).' It specifies the verb ('Get') and resources ('cache status'), including specific components like Redis and WP object cache. However, it doesn't explicitly differentiate from sibling tools like 'cache_flush' or 'cache_toggle' beyond the general 'get' vs. 'flush/toggle' distinction implied by the names.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides clear context for usage with 'Requires: API key with read scope,' indicating prerequisites. It doesn't explicitly state when to use this tool versus alternatives like 'get_site_status' or 'get_metrics,' but the specificity of 'cache status' implies it's for monitoring caching systems, which is adequate guidance without being exhaustive.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries full burden and does well by disclosing the mutation nature ('Enable or disable'), API key requirements with write scope, and the expected return format. It doesn't mention rate limits, side effects on site performance, or error conditions, but covers core behavioral aspects adequately.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is perfectly structured with a purpose statement, prerequisites, parameter explanations, and return format—all in four concise lines. Every sentence earns its place with no wasted words, and information is front-loaded appropriately.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a mutation tool with no annotations and no output schema, the description provides good coverage: purpose, prerequisites, parameter meanings, and return format. It could mention potential side effects or error cases, but given the tool's relative simplicity, it's largely complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must fully compensate. It explicitly documents both parameters with clear semantics: 'slug: Site identifier' and 'enable: true to enable, false to disable', adding essential meaning beyond the bare schema titles 'Slug' and 'Enable'.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the specific action ('Enable or disable') and the target resource ('WordPress object cache'), distinguishing it from sibling tools like cache_flush and cache_status. It provides a complete, unambiguous purpose statement.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description includes a 'Requires' section specifying API key prerequisites, which provides clear context for when to use the tool. However, it does not explicitly differentiate when to use this tool versus alternatives like cache_flush or provide when-not-to-use guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden. It effectively discloses key behavioral traits: it's a mutation (implied by 'Cancel'), requires specific permissions ('API key with write scope'), and includes error handling ('NOT_FOUND: Schedule not found or already executed'). It lacks details on rate limits or side effects, but covers core operational aspects.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is appropriately sized and front-loaded, starting with the core purpose, followed by requirements, arguments, returns, and errors in a structured format. Every section adds value without redundancy, making it easy to parse.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (mutation with permissions and error cases), no annotations, and no output schema, the description is complete enough. It covers purpose, prerequisites, parameters, return values, and errors, providing all necessary 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.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate. It adds meaning by explaining 'slug' as 'Site identifier' and 'schedule_id' as 'UUID of the scheduled snapshot to cancel', which clarifies the purpose of each parameter beyond the schema's generic titles. It does not cover format details (e.g., UUID structure), but provides essential context.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the specific action ('Cancel') and resource ('a scheduled snapshot'), distinguishing it from sibling tools like 'schedule_snapshot', 'create_snapshot', 'delete_snapshot', and 'rollback_snapshot' by focusing on cancellation of scheduled snapshots specifically.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides clear context with 'Requires: API key with write scope', indicating when to use based on permissions. However, it does not explicitly state when not to use this tool or name alternatives (e.g., vs. 'delete_snapshot' for unscheduled ones).

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes key traits: the token is single-use (implying idempotency or state change), the API key is automatically activated for the session (clarifying the outcome), and it includes error handling details (VALIDATION_ERROR cases). However, it lacks information on rate limits, authentication needs, or side effects beyond token consumption.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured and front-loaded with the core purpose, followed by usage steps, behavioral notes, and structured sections for Args, Returns, and Errors. Each sentence adds value—no wasted words—and the formatting enhances readability without verbosity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (involves token handling and activation), no annotations, and no output schema, the description is highly complete. It covers the purpose, usage workflow, parameter semantics, return values (including example structure), and error cases, providing all necessary context 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.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 0% description coverage (only titles), but the description compensates fully by explaining the 'claim_token' parameter: it's a string read from a specific container file, derived from 'request_api_key()', and single-use. This adds crucial context beyond the schema, making the parameter's purpose and source clear.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the specific action ('Claim an API key') and resource ('using a claim token from the container'), distinguishing it from siblings like 'request_api_key' (which presumably generates the token) and 'set_api_key' (which might set an existing key). It explicitly mentions the token source and the outcome of activation.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides explicit guidance on when to use this tool: after calling 'request_api_key()' and reading the token from a specific file path (~/.borealhost/.claim_token). It also specifies an alternative ('request_api_key') and includes exclusions (the token is single-use, so not reusable). This clearly differentiates it from sibling tools.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes the tool's purpose, output format, and authentication requirements ('Requires: API key with read scope'), though it lacks details on rate limits, error handling, or side effects.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured and front-loaded with the core purpose, followed by usage explanation, requirements, and input/output details. Every sentence adds value without redundancy, 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.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's moderate complexity (single parameter, no output schema, no annotations), the description is largely complete: it covers purpose, usage, authentication, parameter meaning, and return format. However, it lacks explicit error cases or operational constraints like rate limits.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 0% description coverage for its single parameter 'slug'. The description compensates by explaining that 'slug' is a 'Site identifier', adding meaningful context beyond the schema's bare 'Slug' title, though it could provide more detail on format or examples.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the specific action ('Get Cloudflare proxy (CDN) status'), identifies the resource ('for a site'), and distinguishes it from siblings by focusing on Cloudflare proxy status rather than other Cloudflare or site-related operations like 'cloudflare_analytics' or 'get_site_status'.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides clear context for when to use this tool ('Shows whether traffic is routed through Cloudflare's CDN... or goes direct to origin') and mentions prerequisites ('Requires: API key with read scope'), but does not explicitly state when not to use it or name alternatives among siblings.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden of behavioral disclosure and does so effectively. It explains the two operational modes (full purge vs. selective purge), mentions the 30-URL limit per call, and specifies the required API key with write scope. This covers key behavioral aspects like scope, limits, and authentication requirements.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is efficiently structured with clear sections (overview, behavior modes, requirements, args, returns) and every sentence earns its place. It's front-loaded with the core purpose, followed by essential details without redundancy or unnecessary elaboration.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a mutation tool with no annotations and no output schema, the description provides excellent completeness. It covers purpose, behavior modes, authentication requirements, parameter semantics, and even includes a return value example. This gives the agent sufficient context to understand and use the tool correctly despite the lack of structured metadata.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema description coverage, the description fully compensates by providing clear semantic meaning for both parameters. It explains that 'slug' is a site identifier and 'urls' is an optional list of specific URLs to purge, including a concrete example. This adds substantial value beyond the bare schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the specific action ('Purge Cloudflare CDN cache') and resource ('for a site'), distinguishing it from sibling tools like 'cache_flush' or 'cache_status' by specifying Cloudflare CDN context. It provides a precise verb+resource combination that leaves no ambiguity about the tool's function.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides clear context about when to use the tool with or without URLs, explaining the scope difference between purging all cached content vs. specific URLs. However, it doesn't explicitly mention when NOT to use it or name specific alternatives among the sibling tools, though the distinction from other cache-related tools is implied.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries full burden and does well by disclosing key behavioral traits: it explains the operational consequences of both proxy states (traffic routing, caching, DDoS protection, SSL termination), mentions authentication requirements ('API key with write scope'), and describes the return format. It doesn't mention rate limits or error behaviors, but covers the essential mutation effects.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is efficiently structured with a clear purpose statement, usage explanation, requirements, parameter details, and return example—all in well-organized sections. Every sentence adds value with zero wasted text, and key information is front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a mutation tool with no annotations and no output schema, the description does an excellent job covering purpose, behavior, parameters, and even provides a return example. The main gap is lack of explicit error handling or edge case information, but given the tool's straightforward nature, it's nearly complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema description coverage (schema only has titles 'Slug' and 'Proxied'), the description fully compensates by explaining both parameters: 'slug' as 'Site identifier' and 'proxied' as 'true to enable CDN proxy, false to disable'. This adds crucial meaning beyond the bare schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the specific action ('Enable or disable Cloudflare CDN proxy for a site') and distinguishes it from sibling tools like cloudflare_proxy_status (which likely checks status) and cloudflare_purge_cache (which manages cache). It specifies the exact resource affected (Cloudflare CDN proxy configuration for a site).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides clear context for when to use this tool (to enable or disable the CDN proxy) and explains the effects of both states (orange vs grey cloud). However, it doesn't explicitly state when NOT to use it or name specific alternatives among the sibling tools, though the distinction is implied by the tool's unique purpose.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes key behaviors: the tool triggers payment and provisioning, has status prerequisites ('ready' status), handles two distinct payment flows with different outcomes (URL vs. immediate API key), includes post-payment steps (polling), and mentions error conditions (VALIDATION_ERROR, FORBIDDEN). It lacks explicit rate limit or authentication details, but covers most critical operational aspects.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured with clear sections (overview, prerequisites, payment methods, args, returns, errors) and front-loaded key information. Most sentences earn their place by providing essential operational details. It could be slightly more concise in the returns sections, but overall it's efficient and avoids redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (payment processing, provisioning, multiple flows) and lack of annotations or output schema, the description is highly complete. It covers purpose, prerequisites, parameter semantics, detailed return values for both payment methods, error conditions, and integration steps (e.g., polling another tool). This provides all necessary context 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.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must fully compensate. It adds substantial meaning beyond the schema: it explains that 'checkout_id' is a session ID, defines the two possible values for 'payment_method' and their implications, specifies that 'payment_method_id' is a Stripe PaymentMethod ID (pm_...) and is required only for 'stripe_payment_method', and clarifies the default behavior. This provides complete parameter context missing from the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose with specific verbs ('complete checkout with payment and start site provisioning'), identifies the resource ('checkout'), and distinguishes it from siblings like 'create_checkout' (which likely creates a checkout) and 'update_checkout' (which likely updates it). It goes beyond the tool name to explain the outcome.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides explicit guidance on when to use this tool: 'The checkout must be in "ready" status.' It also details two payment method alternatives ('stripe_checkout' vs. 'stripe_payment_method') with clear usage instructions for each, including prerequisites like 'payment_method_id' for the latter and post-invocation steps like polling 'get_checkout_status()' for the former.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Since no annotations are provided, the description carries the full burden of behavioral disclosure. It effectively describes key traits: it's a write operation (implied by 'Create'), has a rate limit ('Max 10 rules per site'), requires specific permissions ('API key with write scope'), and details notification mechanisms (email/webhook). This covers critical behavioral aspects without contradictions.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured and front-loaded, starting with the core purpose, followed by behavioral details, prerequisites, and a clear breakdown of parameters and returns. Each sentence adds essential information without redundancy, making it efficient and easy to parse for an AI agent.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complexity of an 8-parameter write tool with no annotations or output schema, the description is highly complete. It covers purpose, usage context, behavioral traits, parameter semantics, and even includes a return example. This provides all necessary context for the agent to invoke the tool correctly, compensating for gaps in structured data.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema description coverage, the description compensates fully by explaining all 8 parameters in the 'Args' section. It clarifies meanings (e.g., 'metric' options, 'threshold' range, default values like 'gt' for 'operator'), adding significant value beyond the bare schema titles. This ensures parameters are well-understood despite the schema's lack of descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('Create an alert rule') and the resource ('to monitor CPU, memory, or disk usage'), making the purpose specific and actionable. It distinguishes this tool from siblings like 'list_alert_rules' or 'delete_alert_rule' by focusing on creation rather than listing or deletion.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides clear context for when to use this tool (e.g., for monitoring specific metrics and sending notifications) and mentions prerequisites ('Requires: API key with write scope'). However, it does not explicitly state when not to use it or name alternatives, such as using 'list_alert_rules' to check existing rules first.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden and does so well. It discloses key behavioral traits: permission requirements ('Requires: API key with write scope'), scope limitations ('Cannot create keys with higher scopes than the current key'), site restrictions, and error conditions (VALIDATION_ERROR, FORBIDDEN). It also notes the one-time nature of the API key display. No contradictions exist.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured with clear sections (purpose, constraints, requirements, args, returns, errors) and front-loaded key information. It's appropriately sized, though slightly verbose; every sentence adds value, such as the error details and return message.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complexity (a mutation tool with permissions and constraints), no annotations, and no output schema, the description is highly complete. It covers purpose, usage, parameters, return values, and errors comprehensively, leaving no gaps for the agent to infer behavior.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate fully, which it does. It adds detailed meaning for all three parameters: 'name' (human-readable, 1-100 chars), 'scopes' (comma-separated options with default), and 'site_slug' (optional for site restriction). This goes well beyond the minimal schema titles.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose with a specific verb ('Create') and resource ('new API key'), and distinguishes it from siblings like 'list_api_keys', 'claim_api_key', 'revoke_api_key', and 'set_api_key' by focusing on creation with scopes and site restrictions.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It provides explicit guidance on when to use (e.g., for creating keys with specified scopes) and when not to use (e.g., cannot create keys with higher scopes than current key, site-scoped keys restrict access). It also mentions prerequisites ('Requires: API key with write scope'), though it doesn't name specific alternatives among siblings.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries full burden and excels by disclosing key behavioral traits: it's async ('Runs in background — returns immediately'), has billing implications ('billed separately at cost+5%'), requires polling ('Poll list_snapshots()'), and includes error conditions ('VALIDATION_ERROR: Not a VPS plan or max snapshots reached'). It also specifies the return format and storage type.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is efficiently structured with clear sections (overview, requirements, args, returns, errors) and every sentence adds value. It's front-loaded with the core functionality and avoids redundancy while maintaining comprehensive coverage.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complexity of an async cloud snapshot tool with no annotations and no output schema, the description provides complete context: purpose, usage constraints, behavioral details, parameter semantics, return format, and error conditions. It leaves no gaps for the agent to understand and invoke the tool correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema description coverage, the description fully compensates by explaining both parameters: 'slug' as 'Site identifier' and 'description' as 'Optional description (max 200 chars)'. It adds crucial semantic information beyond the bare schema, including constraints and optionality.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the specific action ('Create a B2 cloud-backed snapshot') and distinguishes it from sibling tools like 'create_snapshot' by specifying it's zero local disk, async, and uses Backblaze B2 via restic. It explicitly differentiates from other snapshot-related tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides explicit guidance on when to use this tool ('Only available for VPS plans') and when not to use it (non-VPS plans). It also mentions prerequisites ('Requires: API key with write scope') and alternatives by directing users to 'list_snapshots()' for checking completion status.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes key behavioral traits: the asynchronous execution ('runs asynchronously', 'starts in the background'), the need for polling to check status, and authentication requirements ('API key with write scope'). It doesn't mention rate limits or error conditions, but covers the essential operational behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is perfectly structured and front-loaded: the first sentence states the core purpose, followed by operational details, prerequisites, parameter explanation, and return format. Every sentence earns its place with zero waste, making it highly efficient for an agent to parse.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a mutation tool with no annotations and no output schema, the description provides excellent coverage: purpose, asynchronous behavior, polling instructions, authentication requirements, parameter meaning, and return format. The only minor gap is lack of error condition documentation, but it's otherwise highly complete given the context.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema description coverage for the single parameter, the description adds significant value by explaining that 'slug' is a 'Site identifier'. This provides essential semantic context that the schema's bare 'Slug' title doesn't convey. The description doesn't provide format examples or constraints, but gives meaningful interpretation.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the specific action ('Create a manual backup') and resource ('backup'), distinguishing it from siblings like 'create_snapshot' or 'restore_backup' by specifying it's a manual backup process. It provides explicit differentiation through its asynchronous nature and polling requirement.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides explicit guidance on when to use this tool: for creating manual backups that run asynchronously. It also specifies an alternative action ('Poll list_backups() to check status') for monitoring completion, and mentions prerequisites ('Requires: API key with write scope'), giving comprehensive usage context.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries full burden and delivers well: it discloses that no authentication is needed, outlines the multi-step workflow, specifies rate limits (10 checkouts per IP per hour), and describes error conditions. It doesn't mention whether the operation is idempotent or has side effects beyond creating a session.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is efficiently structured with clear sections (purpose, authentication, workflow, args, returns, errors). Every sentence earns its place—no wasted words. The front-loaded purpose statement immediately communicates the tool's function.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with no annotations, no output schema, and minimal schema coverage, the description provides complete context: purpose, usage sequence, parameter details with examples, return value structure, and error conditions. It fully compensates for the lack of structured metadata.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema has 0% description coverage for its single parameter, but the description fully compensates: it explains the SKU parameter's purpose, format (bh_{plan_slug}_{monthly|annual}), provides concrete examples, and references list_plans() for discovery. This adds substantial meaning beyond the bare schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the specific action ('Start a new checkout session') and resource ('to purchase a hosting plan'), distinguishing it from siblings like update_checkout and complete_checkout. It explicitly defines the tool's scope as initiating a purchase flow.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides explicit guidance on when to use this tool (to start a checkout), when not to use it (no authentication needed), and what alternatives to use next (update_checkout then complete_checkout). It also references list_plans() for discovering available options.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries full burden and does well by disclosing key behavioral traits: it creates parent directories automatically, requires specific authentication (API key with write scope), and lists potential errors (NOT_FOUND, FORBIDDEN). However, it doesn't mention rate limits, idempotency, 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.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is efficiently structured with clear sections: purpose statement, behavioral note, requirement, parameters, return value, and errors. Each sentence earns its place with no redundant information, making it easy to scan and understand.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a mutation tool with no annotations and no output schema, the description provides good coverage: purpose, behavior, auth requirements, parameters, return format, and error cases. It's nearly complete but could benefit from mentioning whether the operation is idempotent or what happens if the directory already exists.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema description coverage for the 2 parameters, the description compensates by explaining both parameters: 'slug' as 'Site identifier' and 'path' as 'Relative path of the directory to create'. This adds crucial meaning beyond the bare schema, though it could provide examples or format details.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the specific action ('Create a directory') and target resource ('in a site's container'), with the additional detail about creating parent directories. It distinguishes itself from sibling tools like 'delete_file' or 'list_files' by focusing on directory creation rather than file operations or listing.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage when needing to create directories, but provides no explicit guidance on when to use this tool versus alternatives like 'upload_file' or 'write_file' for file operations. It mentions a prerequisite ('Requires: API key with write scope') which gives some context, but lacks comparison with sibling tools.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes key traits: the user is chrooted to a directory, password and username constraints, and authentication requirements ('API key with write scope'). However, it lacks details on error handling, rate limits, or idempotency.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured and front-loaded with the main purpose, followed by detailed constraints and parameters in a clear format. Every sentence adds value without redundancy, 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.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no annotations and no output schema, the description does a good job covering inputs, constraints, and authentication needs. It includes a return value example, which helps compensate for the lack of output schema. However, it could be more complete by addressing potential errors or side effects.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate fully. It adds significant meaning beyond the schema by explaining each parameter's purpose, constraints (e.g., 'username must be lowercase alphanumeric', 'password must be at least 8 characters'), and default values ('home_dir' defaults to '/var/www/html'), which are not in the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('Create an FTP account') and the resource ('on a site'), making the purpose specific and unambiguous. It distinguishes itself from sibling tools like 'remove_ftp_account' by focusing on creation 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.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides clear context for when to use this tool: when needing to create an FTP account on a site with specific requirements. It mentions prerequisites ('Requires: API key with write scope') but does not explicitly state when not to use it or name alternatives among siblings, such as 'list_ftp_accounts' for viewing existing accounts.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries full burden and excels: it discloses async behavior with polling requirement, storage type ('local'), impact on disk quota, required permissions ('API key with write scope'), and error conditions like quota limits. This goes beyond basic functionality to cover operational traits.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Well-structured and front-loaded with key info (action, async nature). Each sentence adds value: polling instructions, eligibility, storage details, auth requirements, args, returns, and errors. No wasted words, making it efficient for an agent to parse.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a mutation tool with no annotations and no output schema, the description is highly complete: it covers purpose, usage, behavior, parameters, return values (including example output), and error cases. This provides all necessary context for safe and effective tool invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate fully. It adds crucial semantics: 'slug' is explained as 'Site identifier', and 'description' gets constraints ('Optional', 'max 200 chars') and a default (implied via 'Optional'). This provides clear meaning beyond the bare schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the specific action ('Create a local container snapshot'), resource ('snapshot'), and operational mode ('async'), distinguishing it from sibling tools like create_b2_snapshot (which implies a different storage type) and schedule_snapshot (which implies scheduling rather than immediate creation).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicit guidance is provided: use when 'max_snapshots > 0' for VPS/dedicated/cloud plans, and not to use if quota limits are reached (implied via errors). It also specifies when to use list_snapshots() for polling instead of expecting immediate completion, and mentions API key requirements, though it doesn't name specific alternatives among siblings.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden of behavioral disclosure. It does well by mentioning safety ('Handles serialized data safely'), authentication requirements ('API key with write scope'), and the dry-run capability. However, it doesn't mention rate limits, error conditions, or what happens when the tool fails mid-execution.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is perfectly structured and concise. It starts with the core purpose, adds important behavioral notes, provides usage guidance, then details parameters and returns. Every sentence earns its place with zero wasted words, and the information is front-loaded appropriately.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a mutation tool with no annotations and no output schema, the description does an excellent job covering purpose, usage, parameters, and authentication. The only gap is the lack of explicit output schema documentation, though the 'Returns:' section provides a helpful example. Given the complexity of database search-and-replace operations, a bit more detail on error handling would make it perfect.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema description coverage, the description fully compensates by explaining all 4 parameters in detail. Each parameter gets clear semantic meaning: 'slug: Site identifier', 'old: String to search for (e.g. "http://old-domain.com")', 'new: Replacement string', and 'dry_run: Preview only without making changes (default: true)' with practical examples.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose with specific verbs ('Search and replace in WordPress database') and resource ('WordPress database'), distinguishing it from siblings like 'optimize_database' or 'execute_query'. It provides concrete examples ('e.g. URL migration') that clarify the use case.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly provides usage guidance: 'Use dry_run=true first to preview changes' gives a clear when-to-use recommendation, and 'Requires: API key with write scope' specifies prerequisites. It distinguishes this tool from read-only siblings by emphasizing the write scope requirement.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries full burden and does so comprehensively. It discloses critical behavioral traits: destructive nature, immediate inaccessibility, 7-day grace period before permanent deletion, required admin scope, and error conditions. This provides the agent with complete understanding of the tool's behavior and consequences.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured and front-loaded with the core purpose, followed by warnings, best practices, requirements, and technical details. Every sentence earns its place by providing critical information without redundancy. The formatting with clear sections (Args, Returns, Errors) enhances readability.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a destructive operation with no annotations and no output schema, the description provides complete context: purpose, behavioral consequences, prerequisites, parameter meaning, return value format, and error conditions. This gives the agent everything needed to understand when and how to use this tool safely and effectively.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema description coverage and only one parameter, the description adds essential meaning by explaining 'slug' as 'Site identifier'. While it doesn't provide format examples or validation rules, this basic semantic clarification compensates adequately for the schema's lack of documentation.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose with specific verbs ('Delete a site and schedule resource cleanup') and distinguishes it from siblings by focusing on site deletion rather than other operations like snapshot management or file deletion. It goes beyond just restating the name by explaining the two-phase deletion process.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicit guidance is provided on when to use this tool: for deleting sites with a 7-day grace period. It also offers best practice advice ('create a snapshot before decommissioning') and explicitly states prerequisites ('Requires: API key with admin scope'), helping the agent understand usage context and requirements.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Since no annotations are provided, the description carries the full burden of behavioral disclosure. It effectively describes key behavioral traits: the irreversible nature ('WARNING: This is irreversible'), the soft-delete and anonymization process, decommissioning of sites, and the required admin scope. This covers safety, permissions, and side effects comprehensively.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured and front-loaded with the core action, followed by warnings, requirements, and return value. Each sentence earns its place by providing critical information without fluff, 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.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the high-stakes nature of this tool (destructive, irreversible), no annotations, and no output schema, the description is complete. It covers purpose, usage guidelines, behavioral transparency (including warnings and requirements), and even specifies the return format, which compensates for the lack of output schema.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description appropriately does not discuss parameters, focusing instead on behavioral aspects. A baseline of 4 is applied since no parameters exist, and the description adds value elsewhere without redundancy.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the specific action ('permanently anonymize the account') and resource ('the account'), distinguishing it from siblings like 'update_account' or 'decommission'. It goes beyond just restating the name by detailing the effects (cancels subscriptions, deactivates keys).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly states when to use this tool: for permanent anonymization of accounts. It also provides prerequisites ('Requires: API key with admin scope') and warnings about irreversibility, which helps differentiate it from less destructive alternatives like 'update_account' or 'decommission' in the sibling list.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden. It discloses the required API key scope, which is useful for authentication needs, but lacks details on potential side effects (e.g., irreversible deletion), error handling, or rate limits. It adds some behavioral context but could be more comprehensive.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured and front-loaded with the purpose, followed by prerequisites and parameter details. Every sentence adds value without redundancy, 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.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (destructive operation with 2 parameters, no annotations, no output schema), the description is mostly complete: it covers purpose, prerequisites, parameters, and return value. However, it lacks explicit confirmation that deletion is irreversible and does not detail error responses or confirm the tool's idempotency.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema description coverage is 0%, so the description must compensate. It explains both parameters: 'slug' as 'Site identifier' and 'rule_id' as 'UUID of the alert rule to delete', adding clear meaning beyond the bare schema. However, it does not specify format details (e.g., UUID version) or examples.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the specific action ('Delete') and resource ('an alert rule'), distinguishing it from sibling tools like 'create_alert_rule' and 'list_alert_rules'. It directly answers what the tool does without being tautological.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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 it by specifying prerequisites ('Requires: API key with write scope'), but does not explicitly mention when not to use it or name alternatives like 'list_alert_rules' for checking existing rules before deletion.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries full burden and does well by disclosing the destructive nature ('Delete'), authentication requirements ('API key with write scope'), and expected return format ('{"deleted": true}'). It doesn't mention rate limits or error behaviors, but covers key operational aspects.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Well-structured with clear sections: purpose, prerequisites, parameters, and return value. Every sentence adds value with no redundancy. The information is front-loaded and efficiently presented.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a destructive tool with 2 parameters, 0% schema coverage, and no output schema, the description provides complete context: purpose, usage guidance, authentication needs, parameter meanings, and return format. It adequately compensates for the lack of structured annotations and schema descriptions.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate. It explains both parameters: 'slug' as 'Site identifier' and 'line_number' as 'Line number of the cron entry to delete' with context about obtaining line numbers from 'list_cron()'. This adds meaningful semantics beyond the bare schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the specific action ('Delete a cron job by line number'), identifies the resource ('cron job'), and distinguishes from the sibling 'list_cron' by explaining the relationship. It goes beyond a tautology by specifying the deletion mechanism.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly states when to use this tool ('Get line numbers from list_cron()') and provides prerequisites ('Requires: API key with write scope'). It clearly differentiates from 'list_cron' and implicitly from other cron-related tools by focusing on deletion.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries full burden and adds valuable behavioral context: it discloses the required API key with write scope, specifies the return format and success message, and lists error conditions (NOT_FOUND). However, it lacks details on rate limits, idempotency, or confirmation prompts.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Well-structured with clear sections (description, requirements, args, returns, errors), front-loaded purpose, and no wasted sentences. Each part earns its place by providing necessary information efficiently.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a destructive tool with no annotations and no output schema, the description is quite complete: covers purpose, prerequisites, parameters, return values, and errors. Minor gaps include lack of confirmation behavior or side effects, but it provides sufficient context for safe use.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate fully. It clearly explains both parameters: 'domain_name' as the full domain name with an example, and 'record_id' with its source ('from list_domain_dns'), adding essential meaning beyond the bare schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the specific action ('Delete a DNS record from a domain'), identifies the resource ('DNS record'), and distinguishes it from siblings like 'add_domain_dns' and 'list_domain_dns' by specifying the destructive operation.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It provides clear context for when to use this tool ('Delete a DNS record from a domain') and references a sibling tool ('list_domain_dns') for obtaining the record_id, but does not explicitly state when NOT to use it or name alternatives for similar operations.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden and does well by disclosing key behavioral traits: it's a destructive operation (implied by 'Delete'), directories are deleted recursively, protected system paths cannot be deleted, authentication requirements (API key with write scope), and error conditions (NOT_FOUND, FORBIDDEN). It doesn't cover rate limits or exact response format details, but provides substantial context.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is efficiently structured with clear sections (purpose, behavior, requirements, args, returns, errors), each sentence adds value, and it's front-loaded with the core purpose. No wasted words or redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a destructive tool with 2 parameters, 0% schema coverage, no annotations, and no output schema, the description does a strong job: it explains the action, constraints, auth needs, parameters, return values, and errors. The main gap is lack of output schema, but the description compensates by documenting the return structure. Slightly more detail on path format or examples would make it complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate. It explicitly documents both parameters ('slug: Site identifier', 'path: Relative path to delete'), adding clear meaning beyond the bare schema. However, it doesn't provide examples or format details (e.g., path syntax), leaving some ambiguity.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the specific action ('Delete a file or directory'), the resource ('from a site's container'), and distinguishes from siblings like 'list_files' or 'read_file' by specifying the destructive nature. It goes beyond just restating the name by explaining scope and behavior.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides clear context for when to use this tool (to delete files/directories from a site container) and mentions prerequisites ('Requires: API key with write scope'). However, it doesn't explicitly state when NOT to use it or name specific alternatives among siblings, though the context implies alternatives like 'list_files' for viewing or 'upload_file' for adding.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries full burden. It discloses key behavioral traits: the destructive nature ('Delete'), authentication requirements ('API key with write scope'), and error conditions ('NOT_FOUND: Snapshot not found'). It also hints at the return format, though not fully detailed.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured with sections (Requires, Args, Returns, Errors), making it easy to scan. It's front-loaded with the core action. Some redundancy exists (e.g., 'Delete' in description and tool name), but overall it's efficient.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a destructive tool with no annotations and no output schema, the description is quite complete. It covers purpose, prerequisites, parameters, return values, and errors. Minor gaps include lack of details on side effects (e.g., irreversible deletion) or rate limits.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate. It adds meaning beyond the schema by explaining 'slug' as 'Site identifier' and 'snapshot_id' as 'UUID of the snapshot to delete', which clarifies their roles and formats effectively.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('Delete') and resource ('a snapshot'), specifying it can be 'local or B2'. It distinguishes from siblings like 'create_snapshot' and 'rollback_snapshot' by focusing on deletion.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It provides explicit prerequisites ('Requires: API key with write scope') and context for when to use (deleting snapshots). However, it doesn't specify when NOT to use or mention alternatives like 'rollback_snapshot' for reverting instead of deleting.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden and does well by disclosing authentication requirements ('API key with write scope'), timing behavior ('may take up to 60 seconds'), and error conditions ('NOT_FOUND: Unknown slug'). It doesn't mention rate limits or idempotency, but covers key operational aspects.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is perfectly structured and front-loaded: purpose first, then requirements, timing, parameters, returns, and errors. Every sentence earns its place with zero wasted words, making it easy to scan and understand quickly.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a mutation tool with no annotations or output schema, the description is quite complete—covering purpose, auth, timing, parameters, returns, and errors. It could be slightly more comprehensive by mentioning side effects or idempotency, but it provides sufficient context for effective use.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema description coverage for the single parameter 'slug', the description compensates by explaining it as 'Site identifier' in the Args section. This adds essential meaning beyond the bare schema, though it could provide more context about slug format or examples.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the specific action ('Trigger a deployment') and resource ('for a site'), distinguishing it from siblings like 'get_site_status' (read-only) or 'create_snapshot' (different operation). It precisely communicates the tool's function without ambiguity.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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 it ('Requires: API key with write scope') and timing expectations ('may take up to 60 seconds'), but doesn't explicitly mention when NOT to use it or name specific alternatives among the many sibling tools (e.g., 'rollback_snapshot' for undoing deployments).

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden. It effectively discloses key behavioral traits: it's a read operation (implied by 'Get'), requires specific authentication ('API key with read scope'), and includes error handling ('NOT_FOUND: Domain not owned by this account'). It adds context on what data is returned (DNS, infrastructure status) and ownership constraints, though it could mention rate limits or performance characteristics.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is appropriately sized and front-loaded: the first sentence states the core purpose, followed by prerequisites, args, returns, and errors in a structured format. Every section adds value without redundancy, making it easy to scan and understand.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (detailed retrieval with authentication and error handling), no annotations, no output schema, and low schema coverage, the description is mostly complete. It covers purpose, prerequisites, parameters, return values, and errors. However, it lacks details on output structure (e.g., nested objects in 'dns_records') or additional behavioral aspects like pagination or caching.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 1 parameter with 0% description coverage, so the description must compensate. It adds meaning by explaining the parameter ('domain_name: Full domain name') and providing an example ('e.g. "example.com"'), clarifying the expected format. However, it does not detail constraints like domain format validation or length limits.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose with a specific verb ('Get') and resource ('full domain details'), including scope ('including DNS and infrastructure status'). It distinguishes itself from siblings like 'list_domains' (which likely lists domains) and 'search_domain' (which might search for domains) by focusing on detailed retrieval for a specific domain.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides clear context for when to use this tool: to retrieve comprehensive details for a specific domain. It mentions prerequisites ('Requires: API key with read scope'), which helps guide usage. However, it does not explicitly state when not to use it or name alternatives (e.g., 'list_domains' for a list or 'search_domain' for searching), missing full differentiation.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden of behavioral disclosure. It does well by specifying the mutation nature ('Update'), the partial update behavior ('Only provided (non-None) fields are updated'), authentication requirements ('API key with write scope'), and error conditions ('NOT_FOUND: Domain not found or not owned by account'). It doesn't mention rate limits or other constraints, but covers the essential behavioral aspects for a mutation tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is efficiently structured with clear sections: purpose statement, behavioral note, requirements, parameters, return values, and errors. Every sentence earns its place by providing essential information. The front-loaded purpose statement immediately communicates the tool's function.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a mutation tool with 4 parameters, 0% schema coverage, no annotations, and no output schema, the description provides comprehensive coverage. It explains what the tool does, when to use it, behavioral characteristics, all parameter meanings, return format, and error conditions. This is complete enough for an agent to understand and invoke the tool correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema description coverage, the description fully compensates by providing clear documentation for all 4 parameters. Each parameter is listed in the Args section with meaningful explanations: 'domain_name' specifies format requirements, and the three boolean parameters clearly explain what they control. This adds substantial value beyond the bare schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the specific action ('Update') and resource ('domain settings'), listing the three specific settings that can be modified (auto-renew, WHOIS privacy, registrar lock). This distinguishes it from sibling tools like 'domain_detail' (which likely reads settings) and 'register_domain' (which creates new domains).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides clear context for when to use this tool: when needing to modify domain settings. It explicitly states the prerequisite 'Requires: API key with write scope.' However, it doesn't explicitly mention when NOT to use it or name specific alternatives among the sibling tools, though the context implies it's for updates rather than reads or creation.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes key traits: the tool supports various SQL operations, imposes a row limit on SELECT queries, requires an API key with write scope, and returns structured results including columns, rows, affected rows, and query time. This covers critical aspects like permissions, limitations, and output format, though it could add more on error handling or transaction behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured and front-loaded, with the core purpose stated first, followed by key details (supported statements, limits, requirements), and ending with parameter and return value explanations. Every sentence adds value without redundancy, 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.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (executing arbitrary SQL queries) and the lack of annotations and output schema, the description is largely complete. It covers purpose, usage constraints, parameters, and return format. However, it could be more comprehensive by addressing potential errors, security implications, or transactional behavior, which are relevant for a tool with such broad capabilities.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The description adds significant meaning beyond the input schema, which has 0% description coverage. It clearly explains each parameter: 'slug' as the site identifier, 'database' as the database name, and 'query' as the SQL query string. This compensates fully for the schema's lack of descriptions, providing essential context for proper usage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: 'Execute a SQL query on a site's database.' It specifies the verb ('Execute'), resource ('SQL query'), and target ('site's database'), making it distinct from sibling tools like 'database_search_replace' or 'optimize_database' which have different functions.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides clear context for usage: it lists supported SQL statement types (SELECT, INSERT, UPDATE, DELETE, DDL) and notes the 1000-row limit for SELECT queries. However, it does not explicitly state when to use this tool versus alternatives like 'database_search_replace' or 'optimize_database', nor does it mention prerequisites beyond the API key requirement.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries full burden and does well: it discloses authentication requirements ('API key with read scope'), polling behavior, and the tool's read-only nature (implied by 'Get' and polling context). It could mention rate limits or error handling but covers key behavioral aspects.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with purpose, followed by usage, requirements, parameters, and returns in a logical structure. Every sentence adds value with zero waste, efficiently covering multiple dimensions in minimal space.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 2-parameter tool with no annotations or output schema, the description is complete: it explains purpose, usage, auth, parameters, return structure, and status values. No gaps remain for the agent to understand and invoke this tool correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate fully. It clearly explains both parameters: 'slug' as 'Site identifier' and 'app_id' as 'App ID from install_app() response', adding crucial context not in the schema's generic titles ('Slug', 'App Id').

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose with specific verbs ('Get app installation status and log') and identifies the resource ('app'). It distinguishes from siblings like 'install_app' (which it references) and 'get_site_status' (different resource).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly states when to use ('Poll this after install_app() to track progress') and provides prerequisites ('Requires: API key with read scope'). It clearly differentiates from the installation tool and implies this is for monitoring rather than action.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden and does well by disclosing key behavioral traits: it returns a URL (not a redirect), requires an API key with read scope, and specifies the human-facing nature. It could improve by mentioning rate limits or error conditions.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is appropriately sized and front-loaded, with each sentence earning its place: purpose statement, behavioral detail, requirement, parameter explanation, and return value. No wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's low complexity (1 optional parameter) and no output schema, the description is nearly complete, covering purpose, behavior, requirements, parameters, and returns. It could slightly improve by mentioning authentication details beyond 'API key with read scope'.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate. It adds meaningful semantics for the single parameter 'flow', explaining its optional nature and providing an example value ('payment_method_update') with its effect, which goes beyond the bare schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose with a specific verb ('Get') and resource ('Stripe billing portal URL'), and distinguishes it from siblings by specifying it returns a URL for managing payment methods and invoices, which no other sibling tool addresses.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides clear context for when to use this tool (to get a billing portal URL for payment/invoice management) and mentions an API key requirement, but does not explicitly state when not to use it or name alternatives among siblings.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes key behaviors: polling strategy (timing and stop conditions), status lifecycle (including terminal statuses), and critical handling of the api_key (appears once then cleared). However, it doesn't mention error handling or rate limits, leaving some gaps.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured and front-loaded, starting with the core purpose and usage, then detailing polling strategy, statuses, and returns. Every sentence adds value—no fluff—and information is organized logically for quick comprehension, making it highly efficient.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (polling with status transitions) and lack of annotations or output schema, the description is complete. It covers purpose, usage, behavior, parameters, and return values in detail, providing all necessary context for an agent to invoke it correctly without relying on external documentation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 0% description coverage, but the description compensates fully by explaining the single parameter: 'checkout_id: Checkout session ID.' It adds essential context beyond the schema's basic type, clarifying what the parameter represents and its role in the polling process.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description explicitly states the tool's purpose: 'Poll a checkout session for status updates.' It specifies the verb ('poll') and resource ('checkout session'), and distinguishes it from siblings by referencing 'complete_checkout' as a prerequisite, making its role clear and specific.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides explicit usage guidelines: 'Call this after complete_checkout to track payment and provisioning.' It clearly indicates when to use this tool (after a specific sibling tool) and implies when not to use it (e.g., not for initial checkout creation), offering direct context for selection.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively communicates that this is a read-only operation (implied by 'Get'), specifies authentication requirements ('API key with read scope'), and restricts usage to 'WordPress sites only'. It also provides a concrete example of the return format, though it lacks details on error handling or rate limits.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured and front-loaded with the core purpose, followed by prerequisites, parameter details, and a return example. Each section is concise and directly relevant, with no wasted sentences or redundant information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's moderate complexity (single parameter, no output schema, no annotations), the description is largely complete. It covers purpose, prerequisites, parameter semantics, and return format. However, it could improve by mentioning potential errors or limitations, such as handling invalid slugs or site accessibility issues.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema description coverage is 0%, so the description must fully compensate. It clearly explains the single parameter 'slug' as 'Site identifier' in the Args section, adding essential meaning beyond the schema's generic 'Slug' title. This is sufficient given only one parameter exists.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the specific action ('Get WordPress database information') and enumerates the exact resources returned ('size, tables, row counts'). It distinguishes itself from sibling tools like 'list_databases' or 'list_tables' by focusing on detailed metrics for a specific site rather than listing multiple databases or tables.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly states prerequisites ('Requires: API key with read scope. WordPress sites only.'), providing clear context for when to use this tool. However, it does not mention alternatives or when not to use it compared to siblings like 'get_site_status' or 'database_search_replace', which could offer overlapping functionality.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden and does so effectively by disclosing key behavioral traits: it requires specific authentication ('API key with read scope'), describes error conditions ('NOT_FOUND', 'VALIDATION_ERROR'), and outlines the return format. It does not mention rate limits or destructive effects, but covers essential operational context.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured and appropriately sized, with each section ('Requires:', 'Args:', 'Returns:', 'Errors:') adding value without redundancy. Sentences are front-loaded with key information, and there is no wasted text, 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.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (4 parameters, no annotations, no output schema), the description is complete enough. It covers authentication needs, parameter details, return values with an example, and error cases, providing all necessary context for an agent to invoke the tool correctly without relying on structured fields.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The description adds significant meaning beyond the input schema, which has 0% description coverage. It explains each parameter's purpose (e.g., 'slug: Site identifier', 'log_type' options with details, 'lines' range and default, 'search' as a keyword filter), compensating fully for the schema's lack of documentation and providing clear semantics for all four parameters.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose with specific verbs ('Retrieve container logs') and resources ('error, access, or PHP'), distinguishing it from sibling tools like 'read_file' or 'get_metrics' by focusing on container logs. It precisely identifies the types of logs available, making its scope unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides clear context for usage by specifying prerequisites ('Requires: API key with read scope') and detailing the log_type options, which helps in selecting this tool. However, it does not explicitly mention when not to use it or name alternatives among siblings, such as 'get_app_status' for other site data.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries full burden and excels by disclosing key behavioral traits: authentication requirements ('API key with read scope'), error conditions ('NOT_FOUND', 'VALIDATION_ERROR'), and the structure of return data with examples, which helps the agent understand operational constraints.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured with clear sections (purpose, requirements, args, returns, errors), front-loaded key information, and every sentence adds value without redundancy, making it highly efficient.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no annotations and no output schema, the description provides complete context: it covers purpose, prerequisites, parameters, return format with examples, and error handling, which is sufficient for a read-only tool with two parameters.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate, and it does so effectively by explaining both parameters: 'slug' as 'Site identifier' and 'days' with its range and default value, adding crucial meaning beyond the bare schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose with a specific verb ('Get') and resource ('traffic and performance metrics for a site'), distinguishing it from sibling tools like 'get_logs' or 'get_site_status' that focus on different data types.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It provides clear context for when to use this tool (to retrieve metrics for a site) and includes prerequisites ('Requires: API key with read scope'), but does not explicitly mention when not to use it or name alternatives among siblings.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries full burden and does well by disclosing authentication requirements ('API key with read scope'). It also implies read-only behavior through 'Get' and shows the return format, though it doesn't mention rate limits, permissions beyond scope, or error conditions.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is efficiently structured with purpose statement, requirements, parameter documentation, and return example in four clear sections. Every sentence earns its place with no wasted words, and key information is front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

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 no output schema, the description is complete: it explains purpose, requirements, parameter meaning, and provides detailed return format with example values. No annotations exist, so the description fully covers behavioral aspects needed for correct invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate. It explicitly documents the single parameter 'slug' as 'Site identifier' and provides the complete return structure with all fields and example values, adding significant meaning beyond the bare schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the specific action ('Get current resource usage') and resources involved (CPU, memory, disk, load average). It distinguishes from siblings by focusing on real-time system metrics rather than other operations like backups, deployments, or database management.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly states 'Requires: API key with read scope' which provides clear context about prerequisites. However, it doesn't specify when to use this tool versus alternatives like 'get_metrics' or 'get_site_status' that might overlap in functionality.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes the tool as a read operation (implied by 'Get'), specifies authentication requirements ('API key with read scope'), and outlines error conditions ('NOT_FOUND: Unknown slug or not owned by this account'), adding valuable context beyond basic functionality.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured and front-loaded with the core purpose, followed by sections for requirements, arguments, returns, and errors. Each sentence earns its place by providing critical information without redundancy, 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.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's moderate complexity (1 parameter, no output schema, no annotations), the description is complete. It covers purpose, prerequisites, parameter details, return value example, and error handling, providing all necessary 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.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema description coverage is 0%, so the description must compensate. It clearly explains the single parameter 'slug' as 'Site identifier (the slug chosen during checkout)', adding essential meaning not present in the schema. This fully addresses the parameter semantics gap.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose with a specific verb ('Get') and resource ('detailed status of a hosted site'), listing key components like resources, domains, and modules. It distinguishes from siblings like 'get_app_status' by focusing on site-level status rather than app-level.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides clear context for usage with the 'Requires: API key with read scope' statement, indicating prerequisites. However, it does not explicitly state when to use this tool versus alternatives like 'get_app_status' or 'domain_detail', nor does it mention exclusions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes the tool as a read operation ('Get'), specifies authentication requirements ('API key with read scope'), and outlines the return format with example data. It does not mention rate limits or error handling, but covers key behavioral aspects adequately for a read-only tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured and front-loaded, starting with the core purpose, followed by requirements, arguments, and returns in clear sections. Every sentence adds value without redundancy, making it efficient and easy to parse for an AI agent.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's low complexity (1 parameter, no output schema, no annotations), the description is largely complete. It covers purpose, authentication, parameters, and return values with an example. However, it lacks details on error cases or edge behaviors, which could enhance completeness for a production tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 0% description coverage, but the description compensates by explaining the single parameter 'slug' as 'Site identifier'. This adds meaningful context beyond the schema's basic type information. Since there is only one parameter, the description provides sufficient semantic clarity, though it could elaborate on format or constraints.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose with specific verbs ('Get snapshot disk usage and quota info') and identifies the target resource ('for a site'). It distinguishes itself from siblings like 'list_snapshots' (which likely lists snapshots) or 'get_site_status' (which provides general status) by focusing specifically on usage metrics.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides clear context for when to use this tool ('Get snapshot disk usage and quota info for a site') and includes a prerequisite ('Requires: API key with read scope'). However, it does not explicitly state when not to use it or name specific alternatives among the siblings, such as 'get_site_status' for broader site information.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden. It effectively discloses key behavioral traits: the tool is read-only (implied by 'Get'), requires specific permissions ('API key with read scope'), and has plan-based access restrictions. It also outlines error conditions ('NOT_FOUND', 'FORBIDDEN'), adding valuable context beyond basic functionality.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Well-structured and front-loaded with the core purpose, followed by prerequisites, arguments, returns, and errors in clear sections. Every sentence adds value without redundancy, 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.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's low complexity (1 parameter, no output schema, no annotations), the description is complete. It covers purpose, usage constraints, parameters, return values with an example, and error cases, providing all necessary context 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.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate. It adds meaningful semantics by explaining that 'slug' is a 'Site identifier', which clarifies the parameter's purpose beyond the schema's generic 'Slug' title. However, it doesn't detail format or examples for the slug.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose with a specific verb ('Get') and resource ('SSH connection info for a VPS/dedicated site'). It distinguishes itself from siblings by focusing on SSH information retrieval, unlike tools for backups, snapshots, or domain management.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly states when to use ('Only available for VPS/dedicated plans') and when not to use ('not shared hosting'). It also specifies prerequisites ('Requires: API key with read scope'), providing clear context for tool selection.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes the tool's behavior by specifying the authentication requirement ('API key with read scope') and providing a concrete example of the return value, which helps the agent understand what data to expect. However, it lacks details on potential errors, rate limits, or side effects.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured and front-loaded with the core purpose, followed by requirements, arguments, and returns in a clear format. Every sentence adds value without redundancy, 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.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's moderate complexity (1 parameter, no output schema, no annotations), the description is mostly complete. It covers the purpose, authentication, parameter semantics, and provides an example return value. However, it could improve by mentioning potential error cases or limitations, such as what happens if the slug is invalid.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema description coverage is 0%, so the description must compensate. It adds meaning by explaining that the 'slug' parameter is a 'Site identifier', which clarifies its purpose beyond the schema's generic 'Slug' title. Since there is only one parameter, this additional context is sufficient to guide usage effectively.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'Get' and the resource 'detailed system stack information', specifying the exact components (OS, PHP, DB, web server versions). It distinguishes itself from sibling tools like get_database_info or get_site_status by focusing specifically on system stack details.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides some usage context by stating 'Requires: API key with read scope', which implies when authentication is needed. However, it does not explicitly guide when to use this tool versus alternatives like get_site_status or get_metrics, nor does it mention any exclusions or prerequisites beyond the API key.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries full burden and does well by disclosing: background/asynchronous nature, authentication requirements (write scope), plan restrictions (VPS/Cloud only), error conditions, and return format. It doesn't mention rate limits or idempotency, but covers most critical behavioral aspects.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Well-structured with clear sections (purpose, usage, args, returns, errors). Some redundancy exists (app_name constraints appear twice), but overall efficient with each sentence adding value. Could be slightly more front-loaded with the core purpose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a complex mutation tool with 6 parameters, 0% schema coverage, and no output schema, the description provides everything needed: clear purpose, usage guidelines, parameter details, return format, error conditions, and integration instructions (polling). No significant gaps remain.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, but the description provides comprehensive parameter documentation: explains each parameter's purpose, provides template enumeration, character limits for app_name, default values, domain substitution pattern, and database type dependencies. This fully compensates for the schema's lack of descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the specific action ('Install an app template'), target resource ('on a VPS/Cloud site'), and distinguishes from siblings like 'deploy' or 'toggle_module' by focusing on template-based app installation. It provides a complete verb+resource+scope statement.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly states when to use ('Starts a background installation. Poll get_app_status() for progress'), prerequisites ('Requires: API key with write scope. VPS or Cloud plan only'), and exclusions ('FORBIDDEN: Plan does not support apps (shared plans)'). It clearly distinguishes this from monitoring tools like get_app_status.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden and does well by disclosing key behavioral traits: it's a write operation ('Link'), triggers automatic processes (DNS configuration and SSL provisioning), requires specific permissions (API key with write scope), and includes error cases (NOT_FOUND, VALIDATION_ERROR). It doesn't cover rate limits or side effects like downtime.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is appropriately sized and front-loaded: the first sentence states the purpose, followed by key details in bullet-like sections (Attaches, Requires, Args, Returns, Errors). Every sentence adds value with no waste, making it easy to scan.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (a write operation with 2 parameters, no annotations, and no output schema), the description is complete enough. It covers purpose, usage, parameters, return values, and errors, providing sufficient context for an agent to invoke it correctly without relying on structured fields.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema description coverage is 0%, so the description must compensate. It adds meaning beyond the schema by explaining both parameters: 'domain_name' as a full domain name with an example, and 'site_slug' as a site identifier. This clarifies their roles, though it could detail format constraints like valid characters.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose with a specific verb ('Link') and resource ('domain to a hosted site'), and distinguishes it from siblings like 'add_domain_dns' or 'domain_settings' by focusing on attachment and configuration. It's not a tautology of the name.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides clear context for when to use this tool ('Link a domain to a hosted site') and mentions prerequisites ('Requires: API key with write scope'), but does not explicitly state when not to use it or name alternatives among siblings, such as 'register_domain' or 'manage_dns'.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It adds value by specifying the authentication requirement ('API key with read scope') and the return format with example data. However, it lacks details on potential behaviors like pagination, error handling, rate limits, or whether the operation is read-only (implied by 'list' but not explicitly stated). The description does not contradict any annotations, as none exist.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is appropriately sized and front-loaded: the first sentence states the purpose clearly, followed by prerequisite and parameter/return details in a structured format. Every sentence earns its place by adding necessary information. It could be slightly more concise by integrating the 'Args' and 'Returns' sections more fluidly, but overall it is efficient and well-organized.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (a simple read operation with one parameter), no annotations, no output schema, and low schema coverage, the description is fairly complete. It covers purpose, authentication, parameter semantics, and return format with an example. However, it could improve by addressing potential behavioral aspects like pagination or error cases, but for a basic list tool, it provides enough context for effective use.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema description coverage is 0%, so the description must compensate. It adds meaning by explaining the 'slug' parameter as 'Site identifier', which clarifies its purpose beyond the schema's generic 'Slug' title. Since there is only one parameter, this is sufficient to understand its role. However, it does not provide additional details like format examples or constraints, which could be helpful.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: 'List user-configurable alert rules for a site.' It specifies the verb ('list'), resource ('alert rules'), and scope ('for a site'), which is specific and actionable. However, it does not explicitly differentiate from sibling tools like 'create_alert_rule' or 'delete_alert_rule', though the distinction is implied by the verb 'list' versus 'create'/'delete'.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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: it lists alert rules for a site, and it includes a prerequisite ('Requires: API key with read scope.'). This gives guidance on authentication needs. However, it does not explicitly state when not to use it or mention alternatives, such as using 'create_alert_rule' for adding rules instead of listing them, though the sibling tool names make this somewhat obvious.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively adds context beyond basic functionality: it specifies what metadata is shown (e.g., 'name, prefix, scopes, last used') and explicitly states what is not shown ('never the full key value'), clarifies authentication requirements ('Requires: API key with read scope'), and details the return format with a clear example, covering output behavior comprehensively.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is appropriately sized and front-loaded: the first sentence states the core purpose, followed by key details in bullet-like sections ('Shows...', 'Requires:', 'Returns:'). Every sentence earns its place by providing essential information without waste, making it easy to scan and understand.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (a read operation with no inputs but specific output and requirements), the description is complete. It covers purpose, behavioral traits (e.g., what data is included/excluded), prerequisites, and a detailed return example. Since there is no output schema, the description effectively fills that gap, making it sufficient 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.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 0 parameters with 100% description coverage, so the schema fully documents the lack of inputs. The description does not add parameter information, which is unnecessary here. Since there are no parameters, a baseline score of 4 is appropriate, as the description compensates by focusing on output and requirements without redundancy.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: 'List all API keys for the account.' It specifies the verb ('List'), resource ('API keys'), and scope ('for the account'), distinguishing it from sibling tools like 'create_api_key' or 'revoke_api_key' that perform different operations on the same resource.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides clear context for usage with 'Requires: API key with read scope,' indicating prerequisites. However, it does not explicitly state when to use this tool versus alternatives (e.g., 'claim_api_key' or 'set_api_key'), nor does it mention exclusions or comparisons to other list tools like 'list_apps' or 'list_domains'.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions the API key requirement, which is useful context for authentication. However, it does not disclose other behavioral traits such as rate limits, pagination, error handling, or whether the operation is read-only or has side effects. The description adds some value but leaves gaps in behavioral transparency.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured with clear sections: purpose, requirements, arguments, and returns. It uses bullet points and JSON formatting efficiently. However, the 'Returns' section could be more concise by summarizing instead of showing a full JSON example, and some sentences could be tightened for brevity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's low complexity (1 parameter, no output schema, no annotations), the description is fairly complete. It covers the purpose, authentication requirement, parameter meaning, and return format. However, it lacks details on error cases, pagination, or how to handle multiple sites, which could be relevant for a list operation. The absence of an output schema means the description must explain returns, which it does adequately.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema description coverage is 0%, so the description must compensate. It provides a clear explanation of the 'slug' parameter as 'Site identifier,' which adds meaningful semantics beyond the schema's basic 'Slug' title. Since there is only one parameter, this is sufficient to earn a high score, though it could include more details like format or examples.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: 'List installed apps on a site.' It specifies the verb ('List') and resource ('installed apps on a site'), making it easy to understand what the tool does. However, it does not explicitly differentiate from sibling tools like 'get_app_status' or 'install_app', which prevents a perfect score.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description includes a 'Requires' section stating 'API key with read scope,' which provides some context for when to use the tool. However, it lacks explicit guidance on when to use this tool versus alternatives like 'get_app_status' or 'install_app', and does not mention any exclusions or prerequisites beyond the API key. This implies usage but does not fully clarify alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden. It discloses authentication requirements ('API key with read scope') and the scope of data returned ('all backups for a site'), but doesn't mention rate limits, pagination behavior, or error conditions.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is efficiently structured with purpose statement, requirements, and clear sections for Args and Returns. Every sentence adds value with no wasted words, and key information is front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

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 no output schema, the description provides purpose, authentication requirements, parameter explanation, and detailed return format. It could improve by mentioning any limitations (e.g., maximum backups returned) but is largely complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, but the description compensates by explaining the single parameter 'slug' as 'Site identifier', adding meaningful context beyond the schema's generic 'Slug' title. This is sufficient for the single parameter.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb ('List') and resource ('all backups for a site'), specifying both automatic and manual backups. It distinguishes from siblings like 'list_snapshots' and 'restore_backup' by focusing specifically on backups.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides clear context ('for a site') and mentions prerequisites ('Requires: API key with read scope'), but doesn't explicitly state when to use this tool versus alternatives like 'list_snapshots' or 'create_backup'.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes the tool as a read operation ('List'), specifies authentication requirements ('API key with read scope'), and provides a clear example of the return format, covering key behavioral aspects without contradictions.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured and front-loaded, starting with the core purpose, followed by requirements, arguments, and returns in a clear, bullet-like format. Every sentence adds value without redundancy, 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.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's low complexity (one parameter, no output schema, no annotations), the description is largely complete. It covers purpose, prerequisites, parameters, and return format. However, it lacks details on error handling or pagination, which could be relevant for a list operation, preventing a perfect score.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 0% description coverage, so the description must compensate. It adds meaning by explaining that 'slug' is a 'Site identifier,' which clarifies the parameter's purpose beyond the schema's generic 'Slug' title. Since there's only one parameter, this is sufficient for a high score, though it doesn't detail format or constraints.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose with a specific verb ('List') and resource ('cron jobs on a site'), making it immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'get_site_status' or other list_* tools, which prevents a perfect score.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides some usage guidance by stating 'Requires: API key with read scope,' which indicates prerequisites. However, it doesn't specify when to use this tool versus alternatives (e.g., other list_* tools or site status tools) or any exclusions, leaving the 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.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively adds context by specifying authentication requirements ('API key with read scope') and the return format (a JSON object with a 'databases' array). It does not cover potential limitations like rate limits or pagination, but provides essential 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.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is appropriately sized and front-loaded, starting with the core purpose, followed by requirements, arguments, and returns in a structured format. Every sentence earns its place with no redundant information, 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.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's low complexity (one parameter, no output schema, no annotations), the description is largely complete. It covers purpose, authentication, parameters, and return values. A minor gap is the lack of explicit mention of error cases or behavioral constraints like pagination, but it provides enough context for effective use.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate. It adds meaning by explaining that 'slug' is a 'Site identifier,' which clarifies the parameter's purpose beyond the schema's generic 'Slug' title. With only one parameter, this is sufficient to achieve a high score, though it could include format examples.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the specific action ('List all databases') and resource ('on a site's container'), distinguishing it from sibling tools like 'get_database_info' or 'list_tables' which have different scopes. It precisely defines what the tool does without being vague or tautological.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly states 'Requires: API key with read scope,' providing clear context for when to use this tool. However, it does not mention when not to use it or name specific alternatives among sibling tools, such as 'get_database_info' for detailed information on a single database.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes authentication requirements ('API key with read scope'), error conditions ('NOT_FOUND: Domain not found or not owned by account'), and the return format. However, it doesn't mention rate limits, pagination, or other operational constraints.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is efficiently structured with clear sections (purpose, usage, requirements, args, returns, errors). Every sentence adds value—no redundant information—and key details are front-loaded, making it easy to parse quickly.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's low complexity (1 parameter, no output schema, no annotations), the description is complete. It covers purpose, usage, authentication, parameters, return values, and errors, providing all necessary context for an agent to invoke the tool correctly without relying on structured fields.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The description adds significant meaning beyond the input schema, which has 0% description coverage. It explains the 'domain_name' parameter with an example ('e.g. "example.com"') and clarifies it must be a 'Full domain name'. This compensates well for the schema's lack of documentation.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose with a specific verb ('List') and resource ('DNS records for a domain'). It distinguishes from sibling tools by explicitly contrasting with 'manage_dns' for site-level DNS management, making the scope unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides explicit guidance on when to use this tool ('for domains that may not be linked to a site') and when to use an alternative ('independent of site-level manage_dns'). It also includes prerequisites ('Requires: API key with read scope'), offering comprehensive usage context.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden. It discloses key behavioral traits: it requires authentication ('API key with read scope') and describes the return format with an example. It does not mention rate limits, pagination, or error handling, but for a read-only list tool with zero annotations, this is reasonably comprehensive, though not exhaustive.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with the core purpose in the first sentence, followed by prerequisites and return details. Every sentence adds value: the purpose, authentication requirement, and example output structure. There is no wasted text, making it highly efficient and well-structured.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity (0 parameters, no output schema, no annotations), the description is largely complete: it covers purpose, authentication, and return format. However, it lacks details on potential behavioral aspects like pagination or error cases, which could be relevant for a list operation. With no output schema, the example return format is helpful but not a full specification.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has 0 parameters, with 100% schema description coverage (empty schema). The description does not need to add parameter semantics, so a baseline of 4 is appropriate. It correctly omits parameter details, focusing on other aspects like authentication and output.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb ('List') and resource ('all domains owned by the authenticated user'), making the purpose specific and unambiguous. It distinguishes this tool from siblings like 'domain_detail' (which likely provides details for a single domain) and 'search_domain' (which likely filters domains), establishing clear differentiation.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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 ('List all domains') and includes a prerequisite ('Requires: API key with read scope'), providing clear context for usage. However, it does not explicitly mention when not to use it or name specific alternatives (e.g., 'search_domain' for filtered queries), which prevents a score of 5.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries full burden. It discloses behavioral traits: path scoping differences by plan type, authentication requirements (API key with read scope), and error conditions (NOT_FOUND for unknown slug or path). However, it doesn't mention rate limits, pagination, or sorting behavior, leaving some gaps.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Well-structured with clear sections: purpose, plan-specific scoping, requirements, args, returns, and errors. Each sentence earns its place—no fluff. Front-loaded with the core purpose, followed by essential details in logical order.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no annotations and no output schema, the description provides comprehensive context: purpose, usage guidelines, parameter semantics, authentication needs, plan-specific behavior, return format example, and error conditions. This is complete enough for a read operation tool with 2 parameters.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate. It fully explains both parameters: 'slug' as 'Site identifier' and 'path' as 'Relative path to list (empty for root of accessible area)'. This adds crucial meaning beyond the bare schema, clarifying usage and defaults.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'List' and the resources 'files and directories in a site's container'. It distinguishes from siblings like read_file (reads content) and delete_file (deletes) by focusing on directory listing. The specific scope ('in a site's container') adds precision.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly states when to use: 'List files and directories in a site's container'. Provides context on path scoping differences between shared vs. VPS/dedicated plans, and mentions prerequisites: 'Requires: API key with read scope.' This gives clear guidance on applicability and requirements.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively adds context beyond basic functionality by specifying authentication requirements ('API key with read scope') and implementation details ('Nginx allow/deny directives per container'). However, it lacks information on rate limits, error handling, or pagination, which could be relevant for a list operation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is appropriately sized and front-loaded, starting with the core purpose, followed by implementation details, prerequisites, and input/output examples. Each sentence adds value without redundancy, and the structure is logical and easy to parse, making it highly efficient.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (a read operation with authentication), no annotations, and no output schema, the description is largely complete. It covers purpose, implementation, prerequisites, parameters, and return format with an example. However, it could improve by mentioning potential limitations like pagination or error cases, slightly reducing completeness.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The description adds significant meaning beyond the input schema, which has 0% description coverage. It explains that 'slug' is a 'Site identifier', clarifying the parameter's purpose and usage. This compensates fully for the schema's lack of documentation, making the parameter semantics clear and actionable.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the specific action ('List IP allow/deny firewall rules') and resource ('for a site'), distinguishing it from sibling tools like 'add_firewall_rule' and 'remove_firewall_rule'. It provides precise scope by mentioning the implementation details ('Nginx allow/deny directives per container'), 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.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage context by specifying 'Requires: API key with read scope', which indicates prerequisites. However, it does not explicitly state when to use this tool versus alternatives like 'add_firewall_rule' or 'remove_firewall_rule', nor does it provide exclusions or comparative guidance, leaving some ambiguity.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden. It discloses authentication requirements ('API key with read scope') and the return format, which adds value. However, it does not mention potential behavioral traits like rate limits, pagination, or error conditions, leaving gaps for a read operation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured with clear sections (purpose, requirements, args, returns) and uses bullet-like formatting. It is front-loaded with the core purpose and avoids unnecessary verbosity, though the 'Args' and 'Returns' labels could be more integrated into the flow.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's low complexity (one parameter, no output schema, no annotations), the description is reasonably complete. It covers purpose, prerequisites, parameter semantics, and return format. However, it lacks details on error handling or example usage, which could enhance completeness for an agent.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema description coverage and only one parameter, the description compensates by explaining 'slug' as 'Site identifier' in the Args section. This adds meaning beyond the schema's minimal title 'Slug', making the parameter's purpose clear and adequate for the single input.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: 'List FTP accounts on a site.' It specifies the verb ('List') and resource ('FTP accounts'), but does not differentiate from sibling tools like 'remove_ftp_account' or 'create_ftp_account' beyond the action itself, which is implied but not explicitly stated.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description includes a 'Requires' clause indicating API key prerequisites, which provides some context for when to use it. However, it lacks explicit guidance on when to choose this tool over alternatives like 'list_domains' or 'list_files', or any exclusions for 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.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes key behaviors: it's a read operation (implied by 'List'), requires specific authentication ('API key with read scope'), and handles errors ('NOT_FOUND: Unknown slug'). It also specifies the return structure with examples. However, it doesn't mention rate limits, pagination, or other operational constraints, leaving some gaps.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is appropriately sized and front-loaded: the first sentence states the core purpose, followed by additional details in a structured format (Args, Returns, Errors). Every sentence adds value, with no wasted words, making it easy to scan and understand quickly.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's low complexity (1 parameter, no output schema, no annotations), the description is complete. It covers purpose, authentication, parameters, return values with examples, and error handling. This provides all necessary context for an AI agent to use the tool effectively without needing additional structured data.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 0% description coverage, so the description must compensate. It adds meaning by explaining that 'slug' is a 'Site identifier', which clarifies the parameter's purpose beyond the schema's generic 'Slug' title. Since there's only one parameter, this is sufficient to achieve a high score, though it doesn't provide format examples or constraints.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: 'List AI modules and their enabled/disabled state for a site. Also returns the list of modules available for the site's plan.' It specifies both the verb ('List') and resources ('AI modules', 'enabled/disabled state', 'modules available for the site's plan'), distinguishing it from sibling tools like 'toggle_module' which modifies modules 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.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides clear context for when to use this tool: to retrieve module information for a specific site. It mentions a prerequisite ('Requires: API key with read scope') but does not explicitly state when not to use it or name alternatives among siblings (e.g., 'toggle_module' for modifying modules). This gives good guidance but lacks explicit exclusions or comparisons.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden. It discloses authentication requirements ('API key with read scope') and hints at read-only behavior by using 'List,' but lacks details on rate limits, error handling, or whether it's a safe operation. It adds some context but misses key behavioral traits for a tool with no annotation support.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with the core purpose, followed by prerequisites, parameters, and a clear return example. Every sentence adds value without redundancy, making it efficient and well-structured for quick understanding.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's low complexity (one parameter, no output schema, no annotations), the description is mostly complete. It covers purpose, prerequisites, parameters, and return format with an example. However, it lacks details on error cases or behavioral limits, which would enhance completeness for a tool with no annotation support.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate. It explains the 'slug' parameter as 'Site identifier,' adding meaning beyond the schema's generic 'Slug' title. However, it does not provide examples or constraints for the slug format, leaving some ambiguity. With only one parameter, this is sufficient for a high score.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the specific action ('List available PHP versions and the currently active one') and identifies the resource (PHP versions for a site). It distinguishes from sibling tools like 'switch_php' which changes the active version, making the purpose 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.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides clear context by specifying 'Requires: API key with read scope,' which indicates prerequisites. However, it does not explicitly mention when to use this tool versus alternatives like 'get_site_status' or 'get_stack_info,' which might also provide PHP version information, leaving some ambiguity about tool selection.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden of behavioral disclosure. It explicitly states 'No authentication needed' which is valuable behavioral information. It also shows the return format with detailed examples, though it doesn't mention rate limits, pagination, or error conditions. The description adds significant value beyond what's in 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.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured with clear sections (purpose, authentication note, args, returns) and every sentence earns its place. It's appropriately sized for a tool with 2 parameters and detailed return values, with no wasted words or redundant information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's moderate complexity (2 parameters, no output schema, no annotations), the description is quite complete. It covers authentication requirements, parameter usage, and provides a detailed return example. The main gap is lack of guidance on when to use this versus other listing tools, but otherwise it provides good context for agent usage.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema description coverage, the description fully compensates by providing detailed parameter semantics. It explains both parameters clearly: 'track' with valid values and behavior when empty, and 'include_deprecated' with its default value. The description adds substantial meaning beyond the bare schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose with specific verb ('List') and resource ('available hosting plans'), and distinguishes it from siblings by specifying it returns pricing and resource information. It's not a tautology of the name and provides concrete details about what information is returned.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives. While it mentions filtering parameters, it doesn't explain when this tool is appropriate compared to other listing tools like list_apps, list_domains, or list_subscriptions. There's no context about prerequisites or typical use cases.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Since no annotations are provided, the description carries the full burden of behavioral disclosure. It adds valuable context beyond the basic purpose: it specifies prerequisites ('API key with read scope'), platform constraints ('WordPress sites only'), and includes a detailed example of the return format. This covers key behavioral aspects like authentication needs and output structure, though it could mention rate limits 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.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured and front-loaded, with the core purpose in the first sentence, followed by prerequisites and a clear example of the return value. Every sentence adds value without redundancy, 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.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's moderate complexity (one parameter, no output schema, no annotations), the description is largely complete. It covers purpose, prerequisites, parameter semantics, and return format. The only minor gap is the lack of explicit mention of potential errors or edge cases, but overall it provides sufficient context for effective use.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 0% description coverage, with one parameter 'slug' undocumented. The description compensates by adding meaning: it clarifies that 'slug' is a 'Site identifier,' which provides essential context not in the schema. However, it does not specify the format or constraints of the slug, leaving some ambiguity.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: 'List installed WordPress plugins with status.' It specifies the verb ('List'), resource ('installed WordPress plugins'), and scope ('with status'), distinguishing it from siblings like list_themes or list_modules. 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.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides clear context for when to use this tool: 'WordPress sites only' and 'Requires: API key with read scope.' However, it does not explicitly differentiate from potential alternatives (e.g., manage_plugin for plugin management) or state when not to use it, so it falls short of a perfect score.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.