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

The description goes well beyond the annotations by disclosing a meaningful side effect: ordering a product and potentially incurring costs. It also explains that provisioning is asynchronous and that the result contains a provisioning job id. These behavioral details are crucial and not available elsewhere.

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 three short sentences with no filler. It front-loads the core purpose, then delivers the most important caveats: side-effect cost and background provisioning. Every sentence earns its place.

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 create operation with a complete input schematons, the description covers the essential operational context: the side effect, async provisioning, and how to track progress. The return format is adequately implied by mentioning the provisioning job id, and there is no output schema to explain.

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 100%, so the baseline is 3. The description does not add parameter-level meaning beyond what the schema provides, but it does not need to because each parameter already has a clear description.

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 states a specific verb and resource: 'Create a new account for a servicepack.' It clearly distinguishes this from sibling tools like combell_accounts_list and combell_accounts_get by describing the creation action, so an agent can tell it apart without opening the schema.

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 gives clear context about when to use the tool, notably warning that it orders a product and may incur costs animation. It also directs the agent to poll combell_provisioning_jobs_get afterward. It does not explicitly name exclusion or alternative conditions, but no sibling tool provides the same create-account behavior.

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?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, which covers safety. The description adds useful behavioral context by detailing what the response includes (servicepack and addons), which is especially valuable given there is no output schema.

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

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

The description is a single, focused sentence with no filler. It front-loads the primary action and resource, then adds the key detail about included servicepack and addons.

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 simple read-only retrieval by ID, the description is largely complete: it names the input, the resource, and notable response contents. It does not describe not-found behavior or exact response formatting, but with no output schema and low complexity, this is a minor gap.

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 provides 100% coverage, including a description of account_id as 'The account id'. The tool description only repeats the same concept ('by id') and does not add extra meaning such as format, source, or validation requirements.

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 uses a specific verb ('Get') and resource ('Combell account'), and clearly scopes the operation to retrieval by ID. It also states the returned content includes servicepack and addons, which distinguishes it from combell_accounts_list.

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 clearly indicates this tool is for fetching a single account when its ID is known. It does not explicitly name alternatives or exclusions, but the 'by id' phrasing provides clear context relative to the sibling list and create 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?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds that the tool lists accounts and supports filtering, which is behavioral, but it does not explain pagination behavior, return shape, or any edge considerations. This is a useful but minimal addition over annotations.

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 a single sentence that front-loads the action and resource, then defines the key term and names the filter options. Every phrase earns its place with no redundancy or filler.

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

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

Given the annotations cover safety and the schema fully documents parameters, the description provides enough domain context to invoke the tool: it defines what an account is and how to filter. It does not contrast itself with sibling list tools or describe the response format, but for a read-only list operation these are minor gaps.

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 100%, so all four parameters are already documented. The description mentions filtering by asset type and identifier, mirroring the schema; the 'usually the domain name' hint adds little beyond the schema's own 'e.g. a domain name' example. This is baseline value with no substantial extra parameter semantics.

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?

Description clearly states a specific verb and resource: 'List Combell accounts'. The parenthetical defining accounts as 'instances of a servicepack' and the mention of filters by asset type or identifier distinguish it from related tools like accounts_get or domain_list, making its purpose unambiguous.

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

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

The description implies when to use the tool: for listing accounts with optional filters. However, it does not explicitly mention alternatives or when-not-to-use cases, such as using combell_accounts_get for a single account or servicepacks_list for servicepacks themselves. Usage is clear but not explicitly contrasted with 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?

The description explicitly warns 'SIDE EFFECT: changes live DNS', which is valuable behavioral disclosure beyond the annotations (which only say destructiveHint=false). It does not contradict annotations. It could add more context (e.g., propagation time, whether existing records are replaced), but the side-effect warning is a strong 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?

Two sentences, front-loaded with the action and resource, then a compact parameter-routing rule, then the side-effect warning. Every sentence earns its place; no fluff.

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 create tool with 11 parameters and no output schema, the description covers the essential routing logic and side-effect warning. It doesn't describe the response/return value, but with no output schema and a create operation, that is a minor gap. The parameter grouping is sufficient for an agent to construct a valid call.

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 coverage is 91%, so the schema already documents most parameters. The description adds value by grouping parameters by record type and clarifying the SRV-specific set, which the schema does not do. It also clarifies record_name semantics ('Empty or '@' means the domain itself') beyond the schema's description.

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 states a specific verb ('Create') and resource ('DNS record on a domain'), and immediately distinguishes the two record-type families (standard vs SRV) with their required parameters. It clearly differentiates from siblings like combell_dns_records_update and combell_dns_records_delete by naming the create action.

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 gives explicit usage guidance for which parameters to pass for which record types ('For A/AAAA/CNAME/MX/TXT/CAA/ALIAS/TLSA pass record_name + content (+ priority for MX); for SRV pass service, protocol, priority, weight, port and target'). It does not explicitly name alternatives or when-not-to-use, but the sibling set makes the create-vs-update-vs-delete distinction 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?

Annotations already mark this as destructive and non-idempotent, and the description adds valuable context beyond that: the operation is irreversible and changes live DNS. This explicitly warns the agent about real-world impact, which is genuinely useful behavioral information.

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 a single, direct sentence followed by a compact side-effect warning. It is front-loaded with the action and resource, contains no filler, and every word adds meaning.

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 simple two-parameter delete operation with no output schema, the description covers the essential context: what is deleted, from where, and the irreversible live-DNS consequence. The only minor omission is an explicit note about response behavior, but that is not critical for this type of destructive 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 schema already documents record_id as 'The record id to delete,' but domain_name has no description in the schema. The tool description only says 'from a domain,' which indirectly clarifies that domain_name is the domain whose record should be deleted, but it does not fully compensate for the 50% schema coverage 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 uses a specific verb ('Delete') and a clear resource ('a DNS record from a domain'), which precisely distinguishes this from sibling tools like combell_dns_records_create, update, list, and get. The side-effect warning also reinforces that this is the destructive removal 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?

The description clearly implies the tool is used when you need to remove a DNS record from a domain, but it does not explicitly state when to use it over alternatives such as combell_dns_records_create or combell_dns_records_update. The context is unambiguous, but no exclusions or alternative routing are provided.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered and consistent with the word 'Get'. The description adds only the scoping detail that this returns a single record by ID; it does not describe the return format, error behavior for a missing record, or authentication requirements. Given the annotations carry the safety burden, this is adequate but adds no rich behavioral context beyond scoping.

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?

A single short sentence front-loads the verb and resource. No filler, no repetition of the tool name, and no extraneous detail — every word earns its place.

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 simple 2-parameter read-only getter whose annotations cover the safety profile, the description is nearly sufficient: it states the scope and the selection criterion. The only real gap is the undocumented domain_name parameter, which would matter if the tool accepted multiple domain formats.

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 documents record_id with a genuinely useful pointer to combell_dns_records_list for ID discovery, but domain_name is a bare string with no description in schema or description text. With schema coverage at exactly 50%, the description could have compensated for the undocumented domain_name but does not.

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?

States a specific verb ('Get'), a specific resource ('DNS record of a domain'), and a precise selection criterion ('by record id'). The word 'single' clearly differentiates it from the sibling combell_dns_records_list, and the read semantics separate it from combell_dns_records_create/update/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?

No explicit when-to-use or when-not-to-use guidance appears in the description. The only usage signal is indirect: the record_id schema description says 'see combell_dns_records_list', which implies a list-then-get workflow, but the main description never names alternatives or exclusion conditions.

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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the description need not restate safety. It adds behavioral context about filter dependencies and implies a read-only list operation. It does not contradict annotations and provides useful additional constraint information.

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?

Two concise sentences with no redundancy. The core purpose is stated first, followed by the essential filter constraint. Every word adds value and the description 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 list operation with pagination parameters (skip/take) already documented in the schema, the description covers the main functionality and filter constraints. It does not describe the return format, but no output schema exists and it's an implied list of DNS records. The tool is adequately specified 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 100%, so all parameters are already documented. The description adds extra meaning by clarifying that record_name and service are only effective when a type filter is present, which is not explicitly stated in the schema. This enhances parameter understanding beyond 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 verb and resource ('List the DNS records of a domain') and enumerates the filter types. It implicitly distinguishes from the sibling get tool via the word 'list', but does not explicitly mention that get retrieves a single record. This is clear but not fully 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 a specific usage constraint: 'record_name and service filters only apply together with a type filter.' However, it does not mention when to use this tool versus the sibling combell_dns_records_get, nor does it state any prerequisites or exclusions. The guidance is limited to a single filter dependency.

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?

Discloses the read-modify-write mechanism ('current record is read first and only the fields you pass are changed') and the 'SIDE EFFECT: changes live DNS' warning. Annotations already mark readOnlyHint=false, but the description adds the partial-update pattern and the live-DNS impact, which are not in annotations.

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?

Two concise sentences plus a side-effect note. The purpose and behavior are front-loaded, followed by a critical limitation, then the side-effect warning. Every sentence earns its place with zero waste.

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 an 11-parameter tool with rich schema descriptions and annotations, the description covers the update mechanism, the SRV exception, and the live-DNS side effect. It doesn't mention return values, but no output schema exists and that's not essential for calling 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 coverage is 91%, so the baseline is 3. The description adds meaning beyond the schema by clarifying that only passed fields are changed (partial update) and that SRV fields are non-editable, which affects how parameters should be used.

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?

States a specific verb+resource: 'Update an existing DNS record.' Clearly distinguishes from siblings (create/delete/list/get) by describing the partial-update behavior and the SRV limitation, leaving no ambiguity about what this tool does.

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

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

Provides an explicit exclusion: SRV service/protocol/port/target cannot be edited; delete and recreate instead. This directly routes the agent to the correct alternative (delete+create) for that case, and the purpose statement implies using this tool for updating existing non-SRV records.

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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds value by specifying the exact fields returned, which is beyond the annotation. It doesn't contradict any annotations.

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

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

A single sentence that is front-loaded with the primary purpose and then lists the returned details. 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?

For a simple read-only get with one parameter, the description is complete: it states what the tool does and what details it returns. It doesn't describe error behavior, but given the simplicity and annotations, it's sufficient.

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 fully describes domain_name with an example ('example.be'). The description does not add any parameter-specific information beyond what the schema provides, which is acceptable given the schema coverage is 100%.

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 ('Get the details') and the resource ('a domain name'), and enumerates the specific fields returned (expiration, renewal state, name servers, registrant, renewal toggle). This distinguishes it from combell_domains_list (which lists domains) and from mutation tools like combell_domains_set_renew.

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 makes it clear that this is for retrieving details of a single, specific domain (requires domain_name). It doesn't explicitly name alternatives, but the verb 'get' and the field list imply it's for detailed inspection, not for listing or modifying. It could benefit from explicitly contrasting with combell_domains_list, but the context is clear.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds the return fields (expiration date, renewal state) but does not mention pagination limits or behavior beyond what the schema already documents for skip/take. Since annotations carry the main burden, a 3 is appropriate.

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

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

A single, clear sentence that states the action, scope, and key return fields. No unnecessary words or redundancy. The information is front-loaded and immediately actionable.

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 list tool with annotations covering safety and schema covering parameters, the description is nearly complete. It tells the agent what the list contains (domains with expiration and renewal state). No output schema exists, but the description provides enough return context. Pagination is covered by 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?

Schema description coverage is 100%, so both parameters (skip and take) are fully documented in the schema. The description does not add additional meaning to the parameters, but it does clarify the purpose of the returned list. Baseline 3 is correct when the schema handles parameter 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 action (List), the resource (domain names on your Combell account), and the specific fields returned (expiration date and renewal state). This distinguishes it from siblings like combell_domains_get (single domain) and combell_domains_register (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?

The description provides clear context: it lists all domains on the account. While it doesn't explicitly name alternatives or exclusion criteria, the sibling tools (e.g., combell_domains_get) make it obvious that this is for bulk listing. The scope is unambiguous.

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?

The description prominently discloses that this purchases a domain and incurs costs, that execution is asynchronous with a 202 response, and that a provisioning job must be checked. These are critical behavioral traits beyond the minimal annotations (readOnlyHint=false, idempotentHint=false) and materially help an agent handle 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?

Three tight sentences front-load the action and side-effect warning before the async and TLD notes. No sentence is wasted, and critical warnings appear before less urgent details.

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 purchase operation with no output schema, the description covers the essential behavioral context: cost, asynchronous 202 handling, and a TLD eligibility rule. It doesn't spell out the polling contract or explicitly point to combell_provisioning_jobs_get, but 'check the returned provisioning job' gives a sufficient starting point.

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 a registrant country_code constraint ('.ca' only for country code 'CA') not present in the input schema, and the term 'available' conditions the domain_name parameter. With 67% schema coverage, the schema already documents most field semantics, so the description's extra constraint is meaningful but not exhaustive.

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 says 'Register an available domain name', which is a specific verb and resource that clearly identifies the action. It distinguishes from sibling operations like combell_domains_transfer and combell_domains_list 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?

It clearly indicates this is for newly available domain registrations and states the '.ca' country-code restriction. It doesn't explicitly name alternative tools for transfers or renewals, but the domain registration vs transfer/list distinction is clear from the wording and sibling names.

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?

The description explicitly discloses a side effect: DNS resolution will switch to the new name servers after propagation. The annotations already indicate idempotentHint=true and destructiveHint=false, and the description adds behavioral context about the propagation delay and the fact that this replaces existing nameservers. It does not over-explain and directly warns about the operational impact.

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

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

The description is a single sentence that communicates the core action and the important side effect. It is concise, front-loaded, and contains no filler or redundant restating of the tool name.

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

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

Given that the tool has only two parameters and no output schema, the description is reasonably complete: it names the action, the affected resource, and the propagation effect. It could mention the required format for domain_name or the exact semantics of replacing nameservers (e.g., that existing nameservers are overwritten), but overall this definition provides enough context for an AI agent to call the tool correctly with minimal assumptions.

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 50%, meaning the name_servers parameter has a description, but domain_name has none. The description clarifies that the name_servers array is a full replacement list ('Replace'), which adds meaning to the operation mode. Still, it could state the required format for domain_name (e.g., bare domain vs with www) to improve parameter semantics further.

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 uses a specific verb (Replace) with a clear resource (name servers of a domain name). It accurately distinguishes this tool from siblings like combell_dns_records_update and combell_domains_get, because it targets domain-level nameserver configuration rather than individual DNS records. The scope is unambiguous.

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

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

The description implies usage: use this when you need to change which name servers serve a domain. It does not explicitly state when not to use it, nor does it mention alternatives such as combell_dns_records_create/update for managing individual records instead of delegated nameservers. Some guidance is present, but exclusions and alternatives are absent.

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?

The description discloses the side effect of disabling renewal (letting the domain expire) and the precondition about can_toggle_renew. Annotations already indicate readOnlyHint=false, idempotentHint=true, destructiveHint=false, and the description adds context about the side effect and role requirement. No contradiction with annotations.

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

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

The description is concise, front-loaded with the main action, and every sentence adds value: the action, the precondition, and the side effect. 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?

The description covers the action, preconditions, side effects, and role requirement. It doesn't describe the return value, but there is no output schema and the tool is a simple boolean toggle. The only minor gap is not explaining what the response looks like, but for a setter tool this is acceptable.

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 50%: the will_renew parameter has a description ('true to renew automatically, false to let it expire'), but domain_name has no description. The description text adds context about the domain detail and can_toggle_renew, but doesn't explain domain_name format. Baseline 3 is appropriate since the schema covers half the parameters and the description adds some 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 action ('Enable or disable automatic renewal of a domain name') with a specific verb and resource. It distinguishes itself from sibling tools by focusing on the renewal toggle, which is unique among the domain-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 explicitly states when the tool is allowed: only when can_toggle_renew is true on the domain detail, with specific conditions (no unpaid invoices, renewal not starting within a month) and the API user has the finance role. This provides clear guidance on when to use this tool versus alternatives.

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

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

The description goes well beyond the annotations by disclosing that the operation incurs costs, runs asynchronously, returns a 202 Accepted, and requires checking the returned provisioning job. This is exactly the kind of behavioral context an agent needs before invoking the tool.

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

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

Two sentences, front-loaded with the primary action and the critical side effect. No filler, and the asynchronous behavior is stated clearly and compactly.

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 transfer operation with no output schema, the description covers the essential contextual points: cost, asynchronous execution, and where to check the result. It does not explain failure modes or prerequisites beyond the EPP code, but the core invocation context is sufficiently covered.

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 the 'EPP' framing for the auth_code, but the input schema already documents the parameters thoroughly, including registrant object details and name server meaning. The description does not add significant parameter-level meaning beyond 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 names an exact operation (transfer), the resource (a domain name), and the required credential (EPP/auth code), making the tool's intent unambiguous. It is clearly distinct from sibling tools like register, set_nameservers, or list because 'transfer' is a specific lifecycle action.

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 clearly implies when to use the tool: when transferring an existing domain into Combell using an EPP code. However, it does not explicitly state when not to use it or point to alternatives such as combell_domains_register for new registrations.

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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds meaningful behavioral context by listing exactly what data the call returns, which goes beyond the annotations. It does not mention error/not-found behavior or authentication, but the annotation coverage lowers that burden.

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 one well-structured sentence that front-loads the action and resource, then uses a semicolon-separated list to pack in the returned data categories. Every clause adds value and there is no filler or repetition of the tool name.

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

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

Given there is no output schema, the description compensates well by enumerating the main response categories: webspace size/usage, IP, FTP/SSH status and usernames, PHP version, websites with host headers and SSL settings, and linked MySQL databases. It could mention error behavior or the singleness of the result, but for a simple get-by-domain operation the description is sufficiently 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 100%, with the single parameter domain_name described as 'The Linux hosting domain name'. The description reinforces that the resource is a Linux hosting but adds no new parameter-level details beyond the schema. Baseline 3 is appropriate since the schema already carries the parameter semantics.

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 begins with a specific verb and resource ('Get the details of a Linux hosting') and then enumerates the exact categories of information returned: webspace, IP, FTP/SSH status, PHP version, websites with host headers and SSL, and MySQL databases. This clearly distinguishes it from sibling tools like combell_linux_hostings_list (listing) and the set_* mutation 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 makes the retrieval intent clear and implies use for inspecting a single Linux hosting by domain name. It does not explicitly state when not to use it or point to alternatives such as combell_linux_hostings_list, but the contrast with the sibling names is strong enough that an agent can infer the right 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?

Annotations indicate this is a mutating, non-idempotent operation, but the description adds no behavioral detail beyond the action itself. It does not disclose potential side effects, duplicate handling, propagation timing, or whether the change can be reverted, which is relevant for a write operation.

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

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

The description is a single, efficient sentence that front-loads the action and resource, with a helpful parenthetical explanation. Every word earns its place, and there is no redundant or filler content.

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

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

For a simple three-parameter creation tool with fully documented schema, the description is mostly adequate. However, it omits usage guidance and behavioral consequences, and with no output schema it does not mention what response or confirmation an agent should expect after invoking the 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?

Schema description coverage is 100%, so the parameters are already documented in the schema. The description adds little semantic value beyond the schema, only framing the operation as adding a host header; it does not deepen understanding of the domain_name, site_name, or host_header relationship.

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 uses a specific verb ('Add'), a clear resource ('host header'), and a scope ('to a website on a Linux hosting'). It also clarifies the domain term with a parenthetical definition, making the tool's function unambiguous and distinguishable from sibling operations like set_gzip or subsites_create.

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?

No guidance is given about when to use this tool versus alternatives such as DNS record creation, domain registration, or subsite creation. The description implies its use for adding aliases but does not state prerequisites, exclusions, or when a different Combell tool would be more appropriate.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds that results are keyed by domain name, which is useful, but it does not disclose pagination behavior or that the API may return fewer items than requested (though the schema hints at this).

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?

A single, front-loaded sentence that states the action, resource, and result format with zero waste. It earns its place and is appropriately sized for a simple list operation.

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

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

For a simple read-only list tool with full schema coverage and annotations covering safety, the description is nearly complete. It could mention that results are paginated via skip/take or that the API may return fewer items, but the schema already covers those details, so nothing critical is missing.

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 100%, so both parameters (skip, take) are already documented in the schema. The description adds no additional parameter meaning beyond what the schema provides, so the baseline of 3 applies.

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

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

The description states a specific verb ('List') and resource ('Linux hosting accounts') scoped to the Combell account, and clarifies the result is by domain name. It is clear enough to distinguish from siblings like combell_windows_hostings_list, though it doesn't explicitly name that sibling.

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

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

The description implies this is the read-only listing tool for Linux hosting accounts, and the sibling list shows combell_linux_hostings_get for retrieving a single account. However, it does not explicitly state when to use this vs alternatives or mention pagination usage context beyond the schema.

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?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is clear. The description adds a little context by specifying that the listing is scoped to a Linux hosting, but it does not disclose additional behaviors such as return format, ordering, or error cases.

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

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

The description is a single, front-loaded sentence with no filler. Every word contributes to identifying the operation, making it easy for an agent to parse quickly.

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

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, and safe read-only annotations, the description is largely sufficient. There is no output schema, so a slight note about what the returned list contains would improve completeness, but the core invocation context is clear.

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 for the undocumented domain_name parameter. It partially does by saying 'for a Linux hosting,' which links domain_name to the hosting's domain, but it does not explicitly explain the parameter's format or required semantics beyond the schema's required flag.

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 uses a specific verb ('List') and a clear resource ('PHP versions available for a Linux hosting'), which makes the tool's read-only purpose immediately obvious. It also distinguishes itself from sibling tools like combell_linux_hostings_set_php_version by emphasizing enumeration rather than modification.

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 when to use the tool: when the agent needs to know which PHP versions are available for a Linux hosting. However, it does not explicitly state when not to use it or mention alternatives such as combell_linux_hostings_set_php_version for changing the version.

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?

Annotations already declare idempotentHint=true and destructiveHint=false, so the safety profile is covered. However, the description adds no behavioral detail beyond restating the operation: no mention of whether disabling FTP affects existing FTP accounts, whether the change applies immediately, or whether re-enabling restores prior state. It adds essentially nothing beyond what the name and annotations already convey.

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

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

A single 10-word sentence that front-loads the action ('Enable or disable FTP access') and then scopes it ('on a Linux hosting'). Every word earns its place; there is zero redundancy or filler.

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?

The tool is low-complexity (2 required params, no output schema, no nesting) and annotations cover idempotency and non-destructiveness, so a short description is defensible. However, with 0% schema description coverage, the agent is left to infer the meaning of domain_name and any effects of toggling FTP, so the definition is adequate but not fully self-sufficient. No output schema exists, and the description does not address return 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 for undocumented parameters. It does implicitly map 'enable or disable' to the `enabled` boolean, which is helpful, but it adds nothing about `domain_name` (format, ownership, or how to obtain valid values) beyond its schema name. Coverage is only partial for the boolean and absent for the domain 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?

States a specific verb (enable/disable), a specific resource (FTP access), and a scope (Linux hosting). This clearly differentiates it from the many sibling set_* tools on Linux hostings (set_gzip, set_http2, set_php_version, etc.) by naming the exact feature being toggled, and from combell_ssh_set_enabled by naming the protocol.

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?

No guidance on when to use this tool versus alternatives. It does not name the other linux_hostings set_* tools it complements, state prerequisites (e.g., that the domain must correspond to an existing Linux hosting), or explain when FTP toggling is appropriate versus other access controls like SSH. Usage must be inferred entirely.

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?

Annotations already declare readOnlyHint=false, idempotentHint=true, and destructiveHint=false, so the mutation and idempotence are known. The description adds only the enable/disable meaning, without extra behavioral context like effect timing, prerequisites, or response behavior. No contradiction with annotations exists.

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

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

The description is a single, front-loaded sentence with no filler, repetition, or unnecessary detail. Every word contributes to the core meaning and the tool's action is immediately clear.

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 simple two-parameter setter, the description is minimally usable, but it leaves the agent to infer that `domain_name` must refer to an existing Linux hosting and that `enabled` directly controls the compression state. With no output schema and no parameter descriptions, a little more context would improve 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?

Schema description coverage is 0%, so the description must compensate for explaining the required parameters. It only implicitly maps 'enable or disable' to the `enabled` boolean and never mentions `domain_name` or clarifies that `enabled=true` turns GZIP on while `false` turns it off.

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 uses a specific verb–resource pair: 'Enable or disable GZIP compression on a Linux hosting.' This clearly distinguishes it from sibling set_* tools such as set_http2, set_ftp, and set_letsencrypt, while accurately naming the affected 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 implies the use case (toggling GZIP compression) but gives no explicit when-to-use or when-not-to-use guidance. It also does not contrast this tool with alternative compression or hosting settings tools, leaving the routing decision to inference.

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?

Annotations already signal readOnlyHint=false, idempotentHint=true, and destructiveHint=false, and the description is consistent with those. It adds the SSL prerequisite as useful behavioral context, but it does not explain what happens if SSL is not enabled, whether the change is immediate, or what response to expect.

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

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

Two brief sentences with no filler. The action is stated firstamental, and the key prerequisite follows. Every word earns its place.

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?

The description is adequate for a simple, idempotent setter with no output schema, and it includes an important functional constraint. Still, it lacks any mention of async/provisioning behavior or the meaning of domain_name vs site_name, so an agent may need extra inference to call it correctly on the first try.

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 correctly implies that `enabled` controls the feature, but it does not explain `domain_name` or `site_name`, their relationship, or expected formats. This leaves two of three required parameters semantically under-specified.

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 states a specific verb ('enable or disable') and resource ('HTTP/2 for a website on a Linux hosting'), so the tool's core action is clear. It does not explicitly differentiate from sibling configuration tools like set_gzip or set_php_version, but the HTTP/2 target is unambiguous.

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

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

The description provides a directly relevant prerequisite: SSL must be enabled for HTTP/2 to work. However, it does not say when to prefer this tool over alternatives or when not to use it, leaving usage guidance mostly 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?

Annotations already declare idempotentHint=true and destructiveHint=false, and the description adds that it controls an automatic redirect. However, it does not disclose behavioral consequences like whether an SSL certificate is required or what happens when disabled. No contradiction with annotations.

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

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

A single, front-loaded sentence with no filler or redundancy. Every word contributes to understanding what the tool does.

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 simple idempotent setter with three clearly named parameters, the description is largely sufficient. It lacks return/response behavior and edge-case guidance, but the low complexity and annotation coverage make this acceptable.

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's 'enable or disable' maps usefully to the boolean enabled parameter, but it adds little beyond the schema's existing descriptions for hostname and domain_name. With 67% schema coverage, the description does not need to compensate heavily, but it also does not enrich parameter meaning much.

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 states a specific action ('enable or disable') and a precise resource ('automatic HTTP to HTTPS redirect for a hostname on a Linux hosting'). This clearly distinguishes it from sibling tools like set_gzip or set_http2.

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?

There is no guidance on when to use this tool versus alternatives, no mention of prerequisites such as an existing SSL certificate, and no relationship to other hosting settings. The intended use case is only implied by the name and description.

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

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

The annotations already signal mutability (readOnlyHint: false), safety (destructiveHint: false), and idempotency (idempotentHint: true). The description adds no behavioral context beyond restating that the tool can enable or disable the certificate, such as whether disabling removes an existing certificate, triggers a provisioning job, or requires validation.

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 a single, tight sentence that front-loads the action and identifies the exact scope. There is no filler, redundant phrasing, or repetition of the tool name.

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 simple three-parameter setter, the description plus schema is minimally sufficient to attempt a call. It is incomplete, though, because it omits operational context such as the intended workflow with Let's Encrypt, whether disabling has side effects, and when to prefer this over other SSL-related sibling tools.

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 already describes domain_name and hostname, and the description's 'Enable or disable' provides the essential meaning for the otherwise undocumented boolean enabled parameter. However, the description does not clarify whether enabled=false merely deactivates or fully removes the Let's Encrypt certificate, so it only partially compensates for the missing parameter description.

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 states a specific verb ('Enable or disable'), a specific resource ('free Let's Encrypt SSL certificate'), and a scope ('for a hostname on a Linux hosting'). This distinguishes it from related SSL listing/get and other hosting-set siblings without requiring the schema to be opened.

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 gives no guidance on when to use this tool versus alternatives such as ssl_certificate_requests_create or set_https_redirect. It also does not mention prerequisites like the hostname needing to belong to the given Linux hosting domain, or when disabling would be preferred over deleting a certificate.

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?

Annotations already indicate this is non-read-only, idempotent, and non-destructive. The description adds the operation semantics (enable/disable and set size), but does not disclose additional behavioral details such as prerequisites, effects on existing cache state, or what happens when apcu_size is omitted.

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?

A single, well-structured sentence that front-loads the core action and includes the size unit. No redundant or filler content.

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 simple setter with flat parameters and no output schema, the description plus schema is largely sufficient. It lacks explicit guidance on parameter interplay (e.g., whether apcu_size is only relevant when enabled), but this is a minor gap given the tool's low complexity.

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 only 33% schema coverage, the description compensates by clarifying the 'enabled' parameter through 'Enable or disable' and the 'apcu_size' parameter through 'set its size (in MB)'. The 'domain_name' parameter is not explicitly described, but its role is strongly implied by the resource 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 states a specific verb ('Enable or disable'), a specific resource ('PHP APCu caching on a Linux hosting'), and the size-setting capability. This clearly differentiates it from sibling tools like set_php_version or set_gzip.

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 usage context is implied: use this when you need to manage APCu caching for a Linux hosting. However, the description does not explicitly mention alternatives or state when not to use this tool, relying on the tool name and general semantics.

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?

Annotations already declare the operation is non-read-only, idempotent, and non-destructive, and the description is consistent with them. The description adds no behavioral detail beyond the unit ('in MB') and target scope, so it earns only a neutral score rather than credit for extra context.

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

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

One short sentence that front-loads the action and target, with no filler. It is appropriately sized for such a simple setter.

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 two-parameter setter with an idempotent annotation and no output schema, the description plus schema is nearly sufficient to invoke correctly. It might be strengthened by naming domain_name explicitly as the hosting identifier, but that is easily inferable from the operation.

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 documents memory_limit with unit and example, and the description reinforces 'in MB'; domain_name has no schema description, and the description only indirectly identifies it as a Linux hosting. Since schema coverage is only 50%, the description must compensate somewhat, and it does minimally but not fully; the parameter names themselves are fairly 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 uses a specific verb ('Set'), a clear resource ('PHP memory limit'), and a scope ('Linux hosting'). It is immediately distinguishable from sibling tools such as set_php_version, set_php_apcu, or set_gzip, so an agent can identify when it applies.

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 the intended use—changing the PHP memory limit for a Linux hosting—but it gives no explicit when-to-use guidance, exclusions, or alternative tools. The tool name and scope make the situation inferable, but the agent is left to connect it to 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?

The description discloses a significant behavioral trait—the change affects every website on the hosting immediately—which is not captured by the annotations. Annotations already provide readOnlyHint=false, destructiveHint=false, and idempotentHint=true, but the description adds valuable context about the scope of impact. It does not contradict annotations.

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

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

The description is two concise sentences with no wasted words. The primary action is front-loaded, and the side effect is stated separately. It is efficiently structured and easy to parse.

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

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

For a simple tool with two parameters and no output schema, the description covers the key behavioral impact (side effect) and relies on the schema for parameter details. It is complete enough for an agent to understand the tool's purpose and immediate consequences, though it could optionally mention that the version must be from the provided list.

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 provides no information about the parameters. The schema documents 'version' (with an example) but 'domain_name' lacks any description, and the schema coverage is only 50%. Since the description fails to compensate for the missing parameter semantics, it scores low on this dimension.

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 ('Change the PHP version') and the resource ('Linux hosting'), and the side effect clarifies the scope. It is unambiguous and distinct from sibling tools like set_php_memory_limit or set_php_apcu, which target different settings.

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 the tool is used when changing the PHP version of a Linux hosting, but it does not explicitly state when to use it versus alternatives or any prerequisites. The side-effect warning offers some guidance but no explicit exclusions or conditions 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?

Annotations already declare readOnlyHint=false, idempotentHint=false, and destructiveHint=false, so the mutation profile is established. The description adds value beyond annotations by disclosing that the folder must pre-exist (this operation does not create paths) and that Combell defaults to '/subsites/<subsite domain>' when path is omitted. It does not disclose return value, error behavior when the path is missing, or whether creation is synchronous or async — a notable gap given the sibling combell_provisioning_jobs_get suggests a job-based workflow.

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?

Two sentences, both of which earn their place. The first sentence front-loads the purpose (verb + resource + scope), and the second packs the critical precondition and default-path behavior without fluff, adjectives, or repetitive phrasing. 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?

For a simple 3-parameter, fully schema-documented tool, the description covers the purpose and the main failure precondition (nonexistent path) well. However, with no output schema, the description is the only place that could disclose what the call returns — e.g., a provisioning job reference or a success status — and it is silent on this. It also does not address error behavior or idempotency consequences of re-creating the same subsite, leaving an agent partially uninformed about post-invocation expectations.

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 100%, so the baseline is 3. The description adds meaning beyond the schema by explaining the consequence of omitting the optional 'path' parameter ('when omitted Combell uses /subsites/<subsite domain>'), which the schema does not state. It also reinforces that 'path' must reference an existing folder, aligning with the schema's 'Existing folder on the hosting' wording. The other two parameters are fully covered by the schema with clear examples, so the description does not need to repeat them.

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 states a specific verb and resource: 'Create a subsite (an extra webite) on a Linux hosting.' The parenthetical '(an extra webite)' clarifies the Combell domain concept and scopes the operation to Linux hosting, distinguishing it from the many other create tools in the sibling list (e.g. combell_mysql_users_create, combell_mailboxes_create). However, it does not explicitly name its inverse sibling (combell_linux_hostings_subsites_delete), leaning on the naming convention rather than the description for sibling 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 provides one genuine usage precondition: 'The folder path must already exist on the server' — useful because it tells the agent not to expect the tool to create directories. It also explains the default path behavior when 'path' is omitted. However, it gives no guidance on when to use this tool versus alternatives, no exclusions, and no mention of the inverse delete operation, so routing to this tool vs. siblings relies on implication from the tool name.

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

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

Annotations already declare destructiveHint=true, but the description goes further by disclosing the concrete consequence: the website stops being served while files remain on disk. This is valuable behavioral detail beyond what the annotations convey.

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?

Two short, purposeful sentences. The action is front-loaded and the side effect is isolated as a clear warning. No filler or repetition.

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 simple two-parameter destructive action, the description plus annotations cover the core safety and behavioral concerns. The main gap is the undocumented domain_name parameter, which the description does not help clarify.

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?

Only site_name has a schema description; domain_name is undocumented. The prose does not explain the relationship between the two parameters or clarify what domain_name refers to. With only 50% schema coverage, the description should compensate but does not.

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?

States a specific verb ('Delete') and a specific resource ('a subsite from a Linux hosting'). This clearly differentiates it from related siblings like combell_linux_hostings_subsites_create and other resource-specific delete 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 makes the intended operation obvious and the SIDE EFFECT note adds decision-relevant context: use this when you want the website to stop being served but keep the files on disk. It does not explicitly name alternatives or when-not-to-use scenarios, so it falls just short of the highest level.

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

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

Annotations already indicate this is a write operation (readOnlyHint=false), and the description's 'Create' matches that. It adds one helpful dependency hint about account discovery but does not describe side effects, response behavior, or post-creation steps. Annotations carry much of the burden, so this is acceptable but not rich.

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

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

Two short sentences, with the primary action stated first and the prerequisite second. There is no filler or redundant restatement of the tool name.

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

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

For a simple create operation with three fully described parameters and no nested objects, the description covers what the agent needs to invoke it correctly. The only contextual requirement—how to obtain account_id—is explicitly provided.

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 100%, and each parameter already has a clear description. The tool description does not add meaning beyond the schema; it merely repeats the account_id sourcing hint already present in the parameter 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 names a specific action and resource: 'Create a mailbox on a mail zone account.' This clearly distinguishes it from related mailbox tools like deletion, listing, password updates, and mail zone alias/catch-all creation.

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

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

It gives a concrete prerequisite: find account_id in the mail zone's available_accounts via combell_mail_zones_get. This tells the agent where the required identifier comes from, though it does not explicitly discuss when to prefer this over sibling mailbox 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?

The description explicitly states 'SIDE EFFECT: irreversible', which adds meaningful behavioral context beyond the annotations. The annotations already declare destructiveHint=true, but the description reinforces the permanence and specifies that all e-mail is deleted, not just the mailbox. This is valuable context for an agent deciding whether to invoke the tool.

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

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

The description is two short sentences with zero waste. The core action is front-loaded, and the critical side effect is stated immediately after. Every word earns its place.

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 delete tool with destructiveHint=true in annotations and a clear side-effect warning in the description, the context is largely complete. The only minor gap is that it doesn't describe the return value or confirmation behavior, but with no output schema and a simple delete operation, this is not a significant omission.

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 100%, so the schema already documents the single parameter (mailbox_name) as 'The mailbox e-mail address to delete'. The description does not add additional parameter semantics beyond what the schema provides, but the baseline of 3 is appropriate given full schema coverage.

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

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

The description states a specific verb ('Delete') and resource ('a mailbox and all its e-mail'), which clearly distinguishes it from sibling tools like combell_mailboxes_get or combell_mailboxes_create. It does not explicitly name a sibling alternative, but the resource and action are 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 when to use the tool: when a mailbox and all its e-mail need to be permanently removed. It does not provide explicit exclusions or alternatives, but the destructive nature is clearly flagged, which serves as a cautionary usage guideline. No explicit 'when not to use' is given.

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?

Annotations already declare readOnlyHint=true and idempotentHint=true, covering safety. The description adds value by detailing the returned fields (login, sizes, auto-reply/forward settings), which is beyond the annotation scope. It does not cover edge cases like errors or rate limits, but for a simple read operation this is sufficient given the annotation coverage.

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

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

The description is a single, efficient sentence that front-loads the action and resource, then lists the key return contents. There is zero waste, and every word contributes to understanding the tool's 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?

The description adequately covers what the tool returns (login, sizes, auto-reply/forward settings), and the single parameter is well-documented in the schema. Since there is no output schema, the description provides the essential return-value context. No critical information is missing for an agent to invoke this tool correctly.

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

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

The input schema fully documents the sole parameter mailbox_name with a clear description and example. The tool description does not add any additional semantics about the parameter, so it contributes no value beyond the schema. With 100% schema coverage, the baseline of 3 is appropriate.

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

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

The description clearly states the action 'Get a mailbox' and specifies the resource and the exact information returned (login, sizes, auto-reply/forward settings). It is distinct from sibling tools like combell_mailboxes_list, which enumerates mailboxes, and from mutation tools. The verb+resource combination is specific and unambiguous.

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

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

The description implies usage for retrieving a single mailbox's details by requiring mailbox_name, and the sibling combell_mailboxes_list clearly serves the alternative of listing all mailboxes. However, it does not explicitly state when not to use this tool or name the alternative, so it lacks explicit exclusions but provides clear 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the description need not repeat safety. It adds the output detail of including maximum and used size, but does not disclose any further behavioral traits such as pagination, ordering, or error conditions. With annotations covering the safety profile, a 3 is appropriate.

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

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

A single, well-formed sentence that front-loads the main action and result. No unnecessary words or repetition. Ideal length for the 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 simple list tool with one parameter and no output schema, the description covers the core purpose and the key output (max and used size in MB). It does not specify the exact structure of the returned list (e.g., mailbox identifiers, aliases), but given the simplicity and annotation coverage, it is reasonably 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 coverage is 100% and the parameter description is already clear ('The domain name whose mailboxes to list'). The tool description adds no extra semantic detail beyond what the schema provides, so the baseline 3 is correct.

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 uses a specific verb ('List') and resource ('mailboxes of a domain') and adds the distinguishing detail that it returns maximum and used size in MB. This clearly separates it from sibling tools like combell_mailboxes_get, which targets a single mailbox.

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 a domain's mailboxes need to be listed, but it does not explicitly mention when to prefer this tool over alternatives like combell_mailboxes_get. The context of siblings provides the contrast, but the description itself offers no direct 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?

Annotations already provide idempotentHint=true and destructiveHint=false, covering safety. The description adds the 'optionally keeping a copy' behavior, but this mirrors the schema. It does not disclose what happens when enabled=false or whether existing forwarding settings are overwritten.

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?

One concise sentence with the action and resource front-loaded, no filler or redundant phrasing. Every clause earns its place.

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?

The description covers the core purpose but omits important behavioral details such as how to turn off forwarding (enabled=false) and whether email_addresses are required when enabled. Without an output schema, these gaps create some ambiguity, though annotations mitigate safety concerns.

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 describes copy_to_myself and email_addresses, but not mailbox_name or enabled. The description adds some meaning ('one or more addresses', optional copy), partially compensating for the 50% schema coverage, but leaves enabled and mailbox_name semantics unexplained.

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 states a specific verb ('Configure') and resource ('automatic forwarding of a mailbox'), and includes the optional copy-keeping behavior. This clearly differentiates it from sibling tools like combell_mailboxes_set_auto_reply.

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 when to use the tool—when automatic forwarding is needed—but does not explicitly mention alternatives or how to disable forwarding. There are no exclusions or when-not-to-use notes.

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?

Annotations already declare readOnlyHint=false, idempotentHint=true, and destructiveHint=false, so the agent knows this is a safe, idempotent write operation. The description adds the semantic context that this configures the out-of-office auto-reply, which is useful. However, it doesn't disclose any additional behavioral traits such as whether enabling auto-reply without a message is valid, whether existing settings are overwritten, or any side effects on other mailbox settings. With annotations covering the safety profile, a 3 is appropriate.

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

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

The description is a single, concise sentence that front-loads the verb and resource. It earns its place by clarifying the domain-specific term 'auto-reply' with the parenthetical '(out of office)', which aids an agent's understanding. No wasted words, though it could have added a bit more context without becoming verbose.

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 simple configuration tool with 4 parameters, no output schema, and annotations covering idempotency and safety, the description is adequate but not complete. It doesn't explain the relationship between 'enabled' and the optional 'message'/'subject' parameters (e.g., whether message/subject are required when enabled=true), nor does it mention any validation rules. An agent could call the tool correctly with the schema, but edge cases around the auto-reply content are left ambiguous.

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 50%: the 'message' and 'subject' parameters have descriptions, while 'mailbox_name' and 'enabled' do not. The description adds no parameter-level detail beyond what the schema already provides. The tool description does clarify the overall purpose (auto-reply configuration), which helps interpret the parameters, but it doesn't compensate for the undocumented 'mailbox_name' and 'enabled' fields. Baseline 3 is appropriate since the schema covers half the parameters and the description adds minimal extra meaning.

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

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

The description states a specific verb ('Configure') and resource ('auto-reply (out of office) of a mailbox'), which clearly identifies the tool's function. It distinguishes it from sibling tools like combell_mailboxes_set_auto_forward and combell_mailboxes_set_password by naming the specific feature being configured, though it doesn't explicitly contrast with those siblings.

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 the tool is used when a mailbox's auto-reply/out-of-office settings need to be changed, but it provides no explicit guidance on when to use this tool versus alternatives like combell_mailboxes_set_auto_forward or combell_mailboxes_set_password. The context is clear enough for an agent to infer the use case, but there are no exclusions or alternative routing.

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

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

Annotations declare readOnlyHint=false, idempotentHint=true, and destructiveHint=false. The description merely says 'change the password,' which aligns with these hints but adds no additional behavioral context. It does not disclose effects on existing sessions, authentication requirements, or any side effects beyond the action itself. With annotations already covering idempotency and non-destructiveness, the description adds minimal value.

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

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

The description is a single short sentence, which is concise and front-loaded with the verb. However, it is so minimal that it under-specifies the tool. It avoids unnecessary words but at the expense of providing needed context. It is appropriately short but not sufficiently informative.

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 output schema and two parameters, the description is very incomplete. It does not explain what happens after the password is changed, any required permissions, or how to verify the change. Given the tool's simplicity, more context could be provided without much overhead.

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 coverage is only 50% (password has a description, mailbox_name has none). The description does not mention either parameter, so it fails to compensate for the undocumented mailbox_name. The agent must rely entirely on the schema, which lacks context for mailbox_name. The description adds no semantic meaning to the 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 action and resource: 'Change the password of a mailbox.' It names the specific operation on a mailbox, which distinguishes it from MySQL user password tools or other mailbox operations. However, it does not explicitly differentiate it from other 'set_password' siblings, though the mailbox resource is explicit enough.

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. It does not mention prerequisites, typical scenarios, or exclusions. The agent is left to infer that it is for changing mailbox passwords, but no context is given about when this is appropriate compared to other mailbox 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?

Annotations already indicate readOnlyHint=false, destructiveHint=false, and idempotenceHint=false. The description adds the useful forwarding behavior ('forwards to one or more destination addresses') but does not disclose edge-case behavior such as duplicate alias handling, propagation delays, or permission requirements. It does not contradict the annotations.

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

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

A single, front-loaded sentence that states the action and the core behavior with no unnecessary words. Every part earns its place.

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

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

For a simple create operation with three required parameters and no output schema, the description is mostly adequate, but it omits the relationship between domain_name and email_address and gives no indication of return values or what happens if the alias already exists. An agent could invoke it correctly with the schema alone, but there are still gaps.

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 coverage is 67%, with email_address and destinations already documented. The description adds the forwarding relationship between the alias and destinations, which helps clarify destinations semantics, but domain_name remains undocumented in both the schema and description, and the description does not explain that the alias belongs to the given domain.

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 uses a specific verb ('Create') and resource ('e-mail alias') and adds the defining behavior: forwarding to one or more destination addresses. This clearly distinguishes it from sibling tools like combell_mail_zones_aliases_update, combell_mail_zones_aliases_delete, and combell_mail_zones_catch_all_create.

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?

Usage is implied by the verb 'Create' in context with sibling aliases_update and aliases_delete, but the description does not explicitly state when to prefer this over alternatives or warn against creating an alias that already exists. No exclusion or alternative guidance is provided.

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

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

Annotations already declare destructiveHint=true, but the description adds valuable side-effect context ('mail to the alias will bounce') that goes beyond the annotation. This informs the agent of the consequence, which is helpful. No contradiction; description aligns with destructive hint.

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 extremely concise: one sentence for the action and a clear side-effect note. It is front-loaded with the primary purpose and has zero 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?

For a simple delete operation with two parameters, no output schema, and annotations covering destructive nature, the description covers the essential side effect. It does not mention prerequisites or idempotency, but these are less critical given the simplicity and annotations. The lack of domain_name documentation is a minor gap.

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 50%: email_address has a description ('The alias address to delete'), but domain_name has none. The description does not compensate for this gap, adding no meaning to either parameter. The tool name suggests domain context, but the description offers no clarification.

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 states a specific verb ('Delete') and resource ('an e-mail alias'), clearly distinguishing it from sibling tools like combell_mail_zones_aliases_create and combell_mail_zones_aliases_update. The action is unambiguous.

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

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

The description does not explicitly state when to use this tool versus alternatives, but the side-effect warning ('mail to the alias will bounce') implies caution and suggests it is for removing an alias. It lacks explicit when/when-not guidance or mention of sibling delete tools like combell_mailboxes_delete or combell_mail_zones_catch_all_delete.

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?

Annotations already communicate non-read-only, idempotent, and non-destructive behavior. The description adds valuable behavioral context by noting that the change is processed asynchronously and returns 202 Accepted. This goes beyond the structured annotations.

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

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

The description is a single, front-loaded sentence that states the core action and the key asynchronous behavior. Every word earns its place; there is no repetition or filler.

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 simple three-parameter tool with no output schema, the definition is nearly complete: required parameters are clear, the mutation behavior is stated, and the async 202 response is disclosed. The main gaps are the undocumented domain_name parameter and no mention of how to check completion, but these are minor given the tool's simplicity.

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

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

The schema describes destinations as 'The full new list of destination addresses' and email_address as 'The alias address,' which covers two of three parameters. The description reinforces these meanings but adds no semantic detail for the undocumented domain_name parameter, leaving a moderate 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 uses a specific verb and resource: 'Replace the destination addresses of an existing alias.' This clearly distinguishes the tool from sibling tools like combell_mail_zones_aliases_create and combell_mail_zones_aliases_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 implies this tool is for updating an existing alias's destinations rather than creating or deleting alias records, but it does not explicitly name alternatives or state when not to use it. The context is clear enough to infer, but no direct routing guidance is provided.

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?

Annotations already declare the operation as non-readonly, non-idempotent, and non-destructive. The description adds the core routing behavior, but it does not disclose consequences such as whether an existing catch-all gets replaced or how the API responds on success. No contradiction with annotations.

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

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

The description is a single, front-loaded sentence with no filler. Every part contributes to understanding the function and key parameters.

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 simple two-parameter create operation, the description is adequate but incomplete. It does not clarify behavior when a catch-all already exists, possible validation rules for the email address, or how to verify/remove the created catch-all. The lack of an output schema also leaves return value expectations unspecified.

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 50%; email_address already has a schema description ('Destination for all unmatched e-mail'), and the tool description reinforces it. However, domain_name has no schema description, and the tool description does not clarify important constraints like whether the address must be a local mailbox or whether the domain must be a specific format.

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 states a specific verb ('Set') and resource ('catch-all') and explains the exact behavior: e-mail to non-existent addresses is delivered to a specified address. This clearly distinguishes it from related siblings such as catch_all_delete or aliases_create.

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 intended usage is implied by the clear function: use when you need a catch-all for a domain. However, there is no explicit guidance about when not to use it or reference to alternatives, such as the sibling combell_mail_zones_catch_all_delete for removing a catch-all.

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?

The description aligns with the destructiveHint annotation by specifying that the catch-all address is the object removed. It adds a small amount of context about what gets destroyed, but does not disclose effects such as stopped mail delivery or whether the operation is reversible once executed.

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 a single short sentence with no filler. It front-loads the verb and immediately identifies the resource being affected.

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 simple two-parameter destructive operation with a destructiveHint annotation and no output schema, this description is nearly sufficient. The only real gaps are the implicit domain_name semantics and the absence of any guidance about expected errors or post-removal 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?

The schema already documents 'email_address' as 'The catch-all destination address to remove', and the description echoes that concept. However, 'domain_name' is left undocumented in both the schema and description; the phrase 'from the mail zone' only weakly implies its role as the zone identifier.

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 uses a specific verb ('Remove') with a clear resource ('catch-all address') and location ('mail zone'). It clearly distinguishes this deletion tool from the sibling creation tool 'combell_mail_zones_catch_all_create'.

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 intended use is implied by the clear delete purpose, but the description does not explicitly state when to use it versus alternatives, nor does it mention any prerequisites or exclusion conditions. It names no sibling or context-based routing.

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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is fully covered. The description adds value beyond these by detailing what the response contains and noting that the account_id is needed to create mailboxes, which is useful operational context. No contradiction with annotations.

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

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

A single, front-loaded sentence beginning with the core action ('Get the mail zone of a domain') followed by an efficient list of response components. It is dense but every clause earns its place; it could be split into two sentences but is not bloated.

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 simple read tool with one well-documented parameter, annotations covering safety, and no output schema, the description is complete: it states what is retrieved and enumerates the response elements an agent needs. The only minor gap is the absence of explicit sibling routing, which is a usage concern rather than 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?

Schema description coverage is 100% — the domain_name parameter is already documented in the schema with a format example ('example.be'). The description adds no parameter detail beyond that, so the baseline 3 applies since the schema carries the full semantic load.

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 states a specific verb ('Get') and resource ('mail zone of a domain') and enumerates the response contents — mail enabled status, mail accounts with account_id, aliases, anti-spam level, catch-all, and SMTP domains. This content list differentiates it from siblings like combell_mailboxes_get (which focuses on mailboxes) and the various mail_zones mutation tools, so an agent can tell it apart without opening schemas.

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?

Usage is only implied — a GET tool for a broad domain mail overview. It does not explicitly state when to prefer this over combell_mailboxes_get or combell_domains_get, nor does it name alternatives or exclusions. The purpose is clear enough to infer typical use, but explicit routing guidance is absent.

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?

Annotations already declare readOnlyHint=false, idempotentHint=true, and destructiveHint=false. The description adds the requirement to check allowed_types, which hints at validation behavior, but does not describe side effects, return values, or failure modes. Given annotations cover safety, this adds modest context beyond them.

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

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

Two concise sentences, no redundancy. The purpose is stated first, followed by a necessary prerequisite. Every word earns its place.

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 simple setter with only two parameters and no output schema, the description covers the core action and a key prerequisite. It could mention error handling or return value, but these are less critical given the idempotent and non-destructive annotations. Overall, it's adequately 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 coverage is 0%, but the description adds meaning by listing the enum values and instructing to check allowed_types, which links the type parameter to the zone's allowed set. This compensates for the lack of parameter descriptions in the schema, though domain_name remains unexplained.

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 (set), the resource (anti-spam level of mail zone), and enumerates the allowed values (none, basic, advanced). The mention of checking allowed_types distinguishes it from other mail zone operations, making the tool's specific role 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?

It provides a clear prerequisite: check allowed_types on the mail zone first. This implicitly instructs the agent to call mail_zones_get before setting. While it doesn't explicitly contrast with sibling tools, the guidance on when to use this tool is present.

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?

Annotations already indicate this is non-read-only, non-idempotent, and non-destructive. The description adds useful behavioral context by explaining the effect on mail routing. However, it does not disclose what happens on duplicate creation, whether domains must already be registered/verified, or other side effects that would matter for a write operation.

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

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

The description is a single, front-loaded sentence. It leads with the action, then gives the behavioral rationale. There is no filler, repetition, or unnecessary detail.

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

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

For a two-parameter create operation with fully described parameters and no output schema, the description plus schema provides enough to select and invoke the tool correctly. It could be more complete by noting duplicate-handling or domain-verification requirements, but nothing essential for basic invocation is missing.

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 100%, so the baseline is 3; the schema already explains 'extra domain' and 'main domain (mail zone)'. The description reinforces the relationship between the two parameters but does not add meaningful detail beyond 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 states a specific verb and resource: 'Add an extra SMTP domain to the mail zone.' It also explains the operational purpose: mail to that domain is caught by matching addresses on the main domain. It does not explicitly name or contrast sibling tools like smtp_domains_update/delete, but the 'add/create' semantics and resource type make it reasonably distinguishable.

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?

Usage is implied rather than explicit: an agent can infer this is for adding a new extra SMTP domain to a mail zone. There is no when-to-use/when-not-to-use guidance, no mention of prerequisites, and no direct comparison with alternatives such as aliases or catch-all 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?

Annotations already declare destructiveHint=true, and the description says 'Remove,' which is consistent. However, the description adds no further behavioral context—no mention of permanence, side effects, or reversibility. Given the annotations cover the destructive nature, the description adds minimal value beyond the structured data.

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 a single, concise sentence with no fluff. It states the core purpose efficiently. However, it is so brief that it forgoes useful context, but that is more a completeness issue than a structure issue.

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 two required parameters and no output schema, the description is severely incomplete. It lacks parameter explanations, effect descriptions, and any caveats. An agent cannot safely and correctly invoke this tool without additional external knowledge, making it inadequate for autonomous 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%, and the description does not explain what 'hostname' and 'domain_name' refer to. The agent must guess that 'hostname' is the mail zone hostname and 'domain_name' is the SMTP domain to delete. This is a significant gap for a tool with only two parameters, both required.

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 (Remove) and the resource (extra SMTP domain from the mail zone). It is distinct from sibling tools like create/update for SMTP domains, though the term 'extra' could be ambiguous regarding whether it means a domain beyond the primary or any SMTP domain. Still, the core purpose is clear.

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

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

No guidance is provided on when to use this tool versus alternatives. It does not mention any prerequisites, conditions, or contrast with other mail zone operations. An agent would have to infer from the sibling list that this is the delete counterpart, but no explicit direction is given.

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

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

Annotations already declare readOnlyHint=false, destructiveHint=false, and idempotentHint=true, covering the write and safety profile. The description adds a valuable behavioral detail: 'The change is processed in the background (202 Accepted).' This informs the agent that the operation is asynchronous, which is not disclosed by the annotations. No contradictions with annotations.

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

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

The description is a single concise sentence with no fluff. The primary action is front-loaded, and the async note is appended. It is efficient and easy to scan, though it could be more structured to include parameter hints. It earns its length.

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 lack of parameter descriptions, no output schema, and no sibling differentiation, the description is inadequate for an agent to call the tool correctly. It omits what domain_name and hostname refer to, the prerequisites (e.g., domain must already exist), and the full effect of enabling/disabling. The description leaves major knowledge gaps that an agent would need to resolve elsewhere.

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%, and the description does not compensate. It only hints at the 'enabled' parameter via the phrase 'Enable or disable,' but provides no explanation of domain_name or hostname. An agent cannot infer what these parameters represent or their expected formats. This is a critical gap for a 3-parameter tool with no schema 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: 'Enable or disable an extra SMTP domain on the mail zone.' It identifies the verb (enable/disable), the resource (SMTP domain on mail zone), and the state change. It distinguishes from create/delete siblings by implying an update operation, though it doesn't explicitly say 'update an existing domain.' The action is specific enough for an agent to grasp the core purpose.

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 explicit guidance on when to use this tool versus alternatives. It doesn't mention that this is for existing domains, nor does it contrast with combell_mail_zones_smtp_domains_create or delete. There is no 'use this when' or 'instead of' language. The agent must infer usage from the action, which is minimal.

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?

Annotations only say the tool is not read-only, not idempotent, and not destructive. The description adds valuable behavior beyond that: the database name is prefixed, the operation runs in the background, and the result is a provisioning job to poll. This gives the agent needed execution expectations without contradicting annotations.

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 three sentences with no filler. The core action is front-loaded, and each sentence adds necessary information: what is created, how the name is changed, and how the async result is delivered.

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?

With no output schema, the description correctly tells the agent to expect a provisioning job to poll and to use the returned resource link. It could be more complete by naming the provisioning job lookup tool or describing the job field, but for a create action with three well-documented parameters, it is largely sufficient.

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 coverage is 100% and each parameter already has a meaningful description. The tool description mostly repeats the prefixing behavior already present in the database_name schema descriptionahanhasil. It does not add much parameter-level meaning beyond what the schema provides, so the baseline of 3 applies.

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

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

The description clearly states the action: create a MySQL database on an account and set up a first read/write user. It distinguishes this tool from mysql users tools and mysql database list/get/delete tools by specifying the creation and provisioning 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 gives clear operational context such as async execution and polling, but it does not explicitly say when to use this tool over alternatives like combell_mysql_users_create or combell_mysql_databases_get. Usage is implied rather than stated.

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

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

Annotations already flag the operation as destructive and non-idempotent. The description adds value by explicitly warning that the side effect is irreversible and that all data is removed, going beyond the annotation flags.

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

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

The description is extremely concise: two short sentences with no filler. The core action and object come first, and the irreversibility warning is clearly isolated. Every word contributes meaning.

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 delete operation, the description covers the action, the object, the full data scope, and the irreversible consequence. The annotations cover the destructive nature, and the schema fully documents the parameter, so no critical information is missing.

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 100% and the only parameter, database_name, is already described as 'The provisioned database name'. The description does not add further parameter-level detail beyond what the schema provides.

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 uses a specific verb ('Delete') and resource ('MySQL database'), and explicitly states the scope ('all its data'). It clearly distinguishes this from sibling tools like combell_mysql_databases_list and combell_mysql_databases_create.

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 states what the tool does but provides no guidance on when to use it versus alternatives, prerequisites, or exclusions. It does not mention whether the database must exist or if there are any preconditions 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds the 'provisioned' naming detail, which is useful, but does not disclose anything else like error behavior or return format. With annotations covering the main traits, the description adds modest value.

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?

A single sentence with no filler. The key information (verb, resource, parameter) is front-loaded and immediately clear. Every word earns its place; it is appropriately minimal for such a simple read operation.

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 low complexity (one parameter, no output schema, annotations covering safety), the description is nearly sufficient. It clearly indicates the operation and the required input. It could mention that the return value is the database details, but that is implicit for a get operation. The lack of response description is a minor gap, not a critical one.

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 already documents the parameter with a clear description including an example. The tool description repeats the 'provisioned' wording but adds no new meaning. With 100% schema coverage, the baseline of 3 applies; the description does not compensate or enrich beyond 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 (Get) and resource (MySQL database) with the key parameter (provisioned name). It distinguishes from list and create/delete siblings by implying single-item retrieval, but does not explicitly name the alternative tools. The 'provisioned' qualifier adds useful specificity.

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?

No guidance is given on when to use this tool versus the list or other database tools. It does not mention that the database name must be known beforehand, or that list should be used to discover names. The description provides no context for selection.

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

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

Annotations already cover read-only, idempotent, and non-destructive behavior. The description adds value by clarifying the account scope and the specific fields returned, which is useful since there is no output schema. It does not disclose pagination behavior, but skip/take parameters already hint at that.

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?

A single sentence that is front-loaded with the core action and resource, followed immediately by the useful return-field details. There is no redundant or filler content.

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

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

For a simple, read-only list operation with full schema coverage and safety annotations, the description provides enough context: account scope, output fields, and the resource type. It could be slightly richer by mentioning pagination or the absence of filtering, but those are minor gaps.

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 fully documents both parameters (skip and take) with descriptions, so the baseline is 3. The description adds no extra meaning about these parameters, but none is needed given the 100% schema coverage.

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 uses a specific verb ('List'), names the exact resource ('MySQL databases on your Combell account'), and enumerates the returned information ('hostname, sizes, user count and account id'). This clearly differentiates it from sibling tools like combell_mysql_databases_get, create, and 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 implies this tool is for getting an account-level overview of MySQL databases, but it does not explicitly state when to choose it over combell_mysql_databases_get or when not to use it. The intended use is inferable from 'List', but no alternative routing is provided.

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?

Beyond annotations (readOnlyHint false, destructiveHint false), the description adds that the operation 'Runs in the background (202 Accepted)', informing the agent that it is asynchronous and will not return the created resource directly. It also discloses that new users get 'read_only rights', which is a behavioral trait not captured in annotations. No contradiction with annotations.

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

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

The description is two concise sentences with no filler. The core action is front-loaded, followed by two key behavioral details (read_only rights and async execution). Every word adds value, and it is immediately scannable.

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 simple create operation, the description covers the essential behavioral context: async execution with 202 Accepted, and the read_only rights assignment. It does not describe the response format or mention any prerequisites like an existing database, but the schema covers required parameters and the output is not specified. Given the simplicity and annotations, it 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 67% (two of three parameters have descriptions). The description does not add meaning beyond the schema for the parameters, but the covered parameters (name and password) have clear constraints. The database_name parameter lacks a description, and the tool description does not compensate for that gap. Since coverage is moderate, a baseline of 3 is appropriate.

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 'Add a user to a MySQL database' with a specific verb and resource. It distinguishes from sibling tools like list/delete/set by indicating creation, and the mention of 'read_only rights' adds specificity. However, it does not explicitly contrast with other create tools like combell_mysql_databases_create, but the resource is clearly different.

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 such as combell_mysql_users_list or combell_mysql_users_set_status. It only implies usage through the action, but does not state prerequisites, scenarios, or exclusions. The async note is behavioral, not usage 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?

Annotations already mark destructiveHint=true and idempotentHint=false, but the description adds meaningful behavioral context beyond that: the operation is irreversible and only read_only users qualify. This aligns with the annotations and gives the agent risk-relevant information.

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 short and information-dense: it states the action, the qualifying condition, and the irreversible side effect in three sentences. There is no filler or repetition, and the key action 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 simple delete tool with no output schema, the description covers the core action, eligibility, and irreversibility. However, it does not clarify the meaning or expected values of database_name and user_name, and it could usefully state what happens to associated privileges or whether deletion fails for non-read_only users. The provided information is adequate but not fully complete.

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

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 for the two string parameters, user_name and database_name. It does not explain their format, relationship, or how database_name scopes the user deletion. The tool name and first sentence imply that user_name is the user to delete, but specific parameter semantics are left undocumented.

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 states a specific verb and resource: 'Delete a MySQL database user.' It clearly distinguishes this tool from siblings like combell_mysql_users_list, combell_mysql_users_create, combell_mysql_users_set_status, and combell_mysql_users_set_password. The extra constraint about read_only rights further disambiguates its scope.

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 gives an important eligibility condition ('Only users with read_only rights can be deleted') but does not explicitly guide the agent on when to prefer this tool over alternatives or what to do when the constraint is not met. It implies usage rather than naming sibling tools or 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is fully covered by structured data. The description adds minimal behavioral context beyond the annotations by stating the output includes rights and status, but it does not disclose behavior such as behavior on a non-existent database, pagination, or ordering. No contradiction with annotations.

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

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

A single sentence that front-loads the verb and resource, then appends exactly the distinguishing detail (rights and status). Every phrase earns its place, and there is zero redundant wording.

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 low-complexity read-only tool with a single parameter and a full safety profile in annotations, the description is nearly complete. It tells the agent what will be returned (users with rights and status) even though no output schema exists. Only minor details like pagination or empty-result behavior are absent, which is acceptable for a list operation.

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 carries the burden of explaining database_name. It partially compensates: 'users of a MySQL database' conveys that database_name identifies which database's users to list. However, it stops at that level and provides no format, validation, or prerequisite details. The parameter name is self-descriptive, which softens the gap, but the description adds only minimal semantic value.

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 uses a specific verb ('List') with a clear resource ('users of a MySQL database') and specifies the returned content (rights: read_and_write or read_only, plus status). This distinguishes it from user-management siblings like combell_mysql_users_create, combell_mysql_users_set_status, and combell_mysql_users_delete, as well as from combell_mysql_databases_list.

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 usage context is implied by the verb and resource ('List the users of a MySQL database'), so an agent can reasonably infer when to call it versus the user create/update/delete siblings. However, there is no explicit when-to-use language, no exclusions, and no named alternative for cases where rights or status detail is needed differently.

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?

Annotations already state readOnlyHint=false, idempotentHint=true, and destructiveHint=false. The description only confirms a mutation and adds no additional behavioral context, such as whether changing the password disconnects active sessions, requires privileges, or takes effect immediately. There is no contradiction with annotations.

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

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

The description is a single front-loaded sentence with no filler, and every word carries meaning. It is concise, but the terseness contributes to under-specification in other dimensions, so it does not receive full marks.

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 three required parameters, two of which are undocumented in both schema and description, and no output schema, this description is not complete enough for an agent to call it with full confidence. It lacks guidance on prerequisites, side effects, and how it relates to sibling MySQL user operations.

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 only 33%, and only 'password' is documented in the schema. The tool description does not explain 'user_name' or 'database_name' or their relationship, so it fails to compensate for the largely undocumented parameter set.

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 uses a specific verb, 'Change', and a clear resource, 'password of a MySQL database user'. This distinguishes it from siblings such as combell_mysql_users_create, combell_mysql_users_delete, and combell_mysql_users_set_status, and the 'MySQL' qualifier separates it from combell_mailboxes_set_password.

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 gives no guidance on when to use this tool versus alternatives, no prerequisites, and no exclusions. An agent must infer from the tool name and sibling list that this applies to an existing MySQL user, and there is no mention of when set_password should be preferred over create or set_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?

Annotations already declare readOnlyHint=false, idempotentHint=true, and destructiveHint=false. The description merely states the action without adding context about side effects, reversibility, or impact on existing sessions. It adds minimal value beyond the annotations.

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

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

The description is a single, efficient sentence with no fluff. It is appropriately sized for a simple operation, though the lack of detail is a completeness issue rather than a conciseness issue.

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 three parameters and zero schema coverage, the description is under-specified. It does not clarify parameter meanings, expected values, or prerequisites, leaving the agent to infer critical information. The description should compensate for the missing schema documentation but does not.

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