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

With no annotations present, the description carries the full disclosure burden and uses it well by warning that the tool 'can invoke destructive operations' and is gated by ISPCONFIG_READONLY. This flags the two most decision-relevant behaviors for an open-ended passthrough. It stops short of disclosing auth requirements or failure/error behavior for invalid methods, but the core risk is squarely stated.

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 with zero padding: the first declares function and scope, the second delivers the safety warning. The verb and resource are front-loaded, and the most safety-critical information is placed in an attention-capturing NOTE.

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 generic dispatcher whose method space is unknowable, the description covers the two essential facts: it exists for uncovered methods and it can be destructive/disabled. No output schema exists, and the description cannot enumerate returns for arbitrary methods, so nothing critical for selection is missing. Additional response or error-shape context would help but is not essential for a passthrough.

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%, with 'method' described by name and example ('mail_fetchmail_add') and 'params' described as 'Method parameters.' The description adds no param-level detail, which is acceptable because the schema fully documents both parameters and the second is intentionally a catch-all object.

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 ('Call'), resource ('any ISPConfig API method'), and frames itself as an 'escape hatch for methods not covered by other tools,' which clearly distinguishes it from the 60+ sibling tools that each wrap one specific method. An agent can immediately identify this as the universal fallback rather than a duplicate of a specific-operation tool.

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 phrase 'escape hatch for methods not covered by other tools' is an explicit when-to-use rule: prefer dedicated siblings and fall back only when no sibling covers the method. The note that it is 'disabled when ISPCONFIG_READONLY=true' additionally signals when the tool is unavailable and hints that it may be blocked in read-only contexts.

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

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

With no annotations provided, the description carries the full burden. 'Create a new client' only indicates a creation operation; it does not disclose side effects, required authorization, behavior on duplicate usernames, or any related resource creation.

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 wasted words. It is appropriately concise for the simplicity of the operation.

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

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

The tool is a create operation with nested params and no output schema. The description offers no usage context, behavioral details, or return-value expectations, relying entirely on the schema for parameter information. This is inadequate for a mutation tool with no annotations.

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 documented in the schema. The description adds no extra semantic meaning beyond the schema, so a baseline score of 3 is appropriate.

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

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

The description, 'Create a new client', has a specific verb and resource. It clearly distinguishes this tool from sibling client_get, client_update, and client_delete, and from add tools for other resource types.

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

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

There is no guidance on when to use this tool versus alternatives, no prerequisites, and no mention of conditions such as reseller context or required permissions. The name implies the purpose, but the description provides no explicit use-case guidance.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. 'Delete a client' signals mutation and likely irreversibility, but it does not explain side effects, cascading deletions, permission requirements, or whether the operation can fail. A destructive tool with no annotation coverage needs more transparency.

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

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

The description is very short and front-loaded, but it is more under-specified than helpfully concise. While no words are wasted, the lack of behavioral or usage context means brevity comes at the expense of completeness.

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?

Although the tool is simple with one parameter and no output schema, it is a destructive operation with no annotations. The description does not address deletion impact, irreversibility, or possible failure modes, so an agent has limited information to safely invoke it.

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 covers the only parameter, client_id, with a 'Client ID' description at 100% coverage. The tool description adds no additional meaning about how the parameter is used, so the baseline score of 3 is appropriate.

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

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 client'), making the core purpose immediately clear. It is distinguishable from sibling tools like client_add, client_update, and client_get by operation type, though it does not add any scope or caveat details.

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

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

There is no guidance about when to use this tool versus alternatives, no prerequisites, and no caution about consequences. The operation type itself implies deletion, but the description does not clarify contexts such as whether a client must exist first or what happens to associated resources.

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

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

No annotations are provided, so the description carries the behavioral disclosure burden. 'Get' implies a read-only operation with no side effects, but the description does not mention not-found behavior, permissions, or response structure. This is minimally adequate for a simple getter, but adds little beyond the obvious.

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 or redundant information. Every word contributes to identifying 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?

For a low-complexity tool with one well-documented required parameter and no output schema, the description is nearly complete. It would benefit from a brief note on what 'details' includes or behavior when the client ID does not exist, but the current level is adequate for correct selection and 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%, and the schema already defines client_id as a number with description 'Client ID'. The description's 'by ID' adds no new semantic meaning beyond what the schema provides, so the baseline of 3 is appropriate.

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

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

The description uses a specific verb ('Get') with a clear resource ('client details') and a precise identifier ('by ID'). This clearly distinguishes it from sibling tools like client_add, client_update, and client_delete, and from other *_get tools targeting different resources.

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 context is clear: this tool is for fetching a single client's details using a client ID. It does not explicitly state when not to use it or name alternatives, but the operation is unambiguous given the sibling set, so the guidance is sufficient though not exhaustive.

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

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

With no annotations, the description carries the full burden of behavioral disclosure, but 'Update a client' only restates the tool name. It does not explain side effects, whether the update is partial or full replacement, permission requirements, or what happens to omitted fields.

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 with no filler, and the core action is front-loaded. It is appropriately terse, though it sacrifices informative detail for brevity.

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

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

This is a state-changing tool with no annotations, no output schema, and a nested params object whose allowed fields are completely unspecified. The description does not tell an agent what fields are updatable, how reseller_id is used, or what the response looks like, so it is inadequate for reliable 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?

The schema covers all three parameters with descriptions, so the baseline is 3. The description itself adds no parameter semantics, and the schema's 'Fields to update' for params is vague, but coverage is 100%, so no additional burden falls on the 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 names a specific verb ('Update') and resource ('a client'), which clearly identifies the operation and differentiates it from sibling tools like client_add or client_delete. However, it offers no detail on which client attributes can be updated, so it is clear but minimal.

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 client_add, client_get, or client_delete. There is no mention of prerequisites, required context, or situations where sibling tools 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?

With no annotations provided, the description carries the full burden of behavioral disclosure, but it only says 'Create a cron job.' It does not mention persistence, validation requirements, whether client_id must reference an existing client, idempotency, or what happens on duplicate submissions.

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 clear sentence that immediately conveys the core action. It is efficient and front-loaded, though it could have incorporated additional behavioral or usage 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?

This is a creation tool with a nested, loosely-specified params object, no output schema, and no annotations. The description does not explain required fields inside params, execution schedule semantics, response format, or side effects, leaving significant gaps for an agent that must 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?

The schema already documents both parameters with 100% coverage: client_id as 'Client ID' and params with a description listing example keys like server_id, parent_domain_id, command, run_min, and run_hour. The description itself adds no parameter information beyond what the schema provides, so the baseline of 3 is appropriate.

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

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

The description states a specific action and resource: 'Create a cron job.' This clearly identifies the operation as the creation counterpart to sibling tools like cron_list, cron_update, and cron_delete, though it does not add detail about what constitutes a cron job beyond the name.

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

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

There is no guidance about when to use this tool versus alternatives — no mention of using cron_update for modifications or cron_list for viewing existing entries. The intended usage is only implied by the tool name and description, with no exclusions or context.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states the operation without mentioning permanence, side effects, idempotency, or required permissions, which is a significant gap for a destructive action.

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

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

A single sentence with no filler; the essential verb and object are front-loaded. It is appropriately small for a one-parameter tool, though terse.

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 delete operation with no annotations and no output schema, the description is thin. It omits behavioral context such as irreversibility, whether the job must exist, or what happens if deletion fails, making it minimally viable but not complete for safe invocation.

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

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

The input schema covers the single required parameter cron_id at 100% coverage, so the description does not need to re-explain it. The description adds no extra parameter meaning, matching the baseline for high schema coverage.

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

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 ('cron job'), making the tool's core function immediately clear. It does not explicitly name sibling alternatives, but the delete action is distinct from cron_add, cron_update, and cron_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?

There is no guidance on when to use this tool versus cron_update or cron_list, nor any mention of prerequisites or conditions. The only usage cue is the tool name and generic action, requiring the agent to infer when deletion is 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?

The word 'List' implies a read-only operation and 'all' indicates no filtering, which is useful behavioral context. With no annotations provided, the description carries the full burden, but it does not disclose return format, pagination, authentication requirements, or whether any side effects occur.

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

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

The description is a single efficient sentence with no wasted words. 'All' adds meaningful scope, and the key information is front-loaded.

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

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

For a zero-parameter list operation with no output schema, the description is largely adequate for invoking the tool correctly. It would benefit from clarifying what fields are returned or what 'all' means in terms of system scope, but these are minor gaps 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 tool has zero parameters, so the baseline is 4. The description correctly implies there is no input to provide, and the schema's empty properties confirm this. No parameter explanation is needed.

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 (cron jobs), clearly distinguishing this read operation from sibling mutation tools like cron_add, cron_update, and cron_delete. However, it does not elaborate on scope or distinguish itself from other domain-specific list tools beyond the resource name.

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

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

The intended usage is implied: use this tool to view all cron jobs. However, there is no explicit guidance about when to prefer this over alternatives, nor any mention of prerequisites or exclusions.

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

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

There are no annotations and no output schema, so the description must carry the burden of disclosing side effects, permissions, idempotency, or reversibility. 'Update a cron job' only names the mutation and gives no behavioral detail beyond that.

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

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

The description is short, but it mostly restates the tool name and provides no explanatory substance. This is under-specification rather than effective conciseness, so the structure does not add value.

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

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

For a mutation tool with no annotations, no output schema, and an opaque 'params' object, a single sentence is insufficient. An agent cannot determine what fields can be updated, what a successful update returns, or what happens if the cron_id or client_id does not exist.

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 as the schema documents each parameter. The description adds no extra meaning about the parameters, and 'params' remains an unconstrained object with no hints about what fields are valid.

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 ('Update') and the resource ('a cron job'), so the core purpose is unambiguous. However, it does not differentiate this tool from cron_add, cron_delete, or cron_list, and it does not say which aspects of a cron job can be modified.

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 when-to-use or when-not-to-use guidance is provided. The verb 'Update' weakly implies the job must already exist, but there are no explicit directions about choosing this over cron_add, cron_delete, or cron_list, nor any mention of prerequisites.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. 'Create a new database' only states the action, without mentioning potential side effects, required server, failure conditions, or whether the operation is reversible. This is minimal 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 extremely concise, using a single sentence with no filler. It is front-loaded with the core action, but the brevity edges into under-specification, though it remains appropriate for the small amount of information it conveys.

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

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

For a tool with no annotations and no output schema, the description is insufficiently complete. It omits context about required fields, the meaning of the nested params object, return values, and error/edge-case behavior. The schema partially compensates, but the description itself does not provide enough situational context.

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

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

Schema description coverage is 100%, so the baseline is 3. The schema already describes client_id and lists example params fields; the tool description itself adds no additional parameter semantics. The schema's examples provide some clarity, but the description contributes nothing beyond that.

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 'Create a new database' with a specific verb and resource, clearly identifying the tool's purpose. It is distinct from sibling tools like database_list and database_delete, and there is no ambiguity about what operation it performs.

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 database_list or database_delete. It lacks context about prerequisites or scenarios, leaving the agent to infer usage purely from the 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?

With no annotations provided, the description must carry the full behavioral burden. It only says 'Delete a database' and does not disclose irreversibility, cascading effects, permission requirements, or consequences for dependent 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 very short and free of fluff, front-loading the core action. It is concise but not under-specified to the point of being a pure tautology.

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

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

For a destructive operation with no annotations and no output schema, more context is needed about safety, dependencies, or expected outcomes. The current description is technically clear but contextually thin.

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 parameter description already explains database_id. The tool description adds no extra meaning beyond what the schema provides, so the baseline score of 3 is appropriate.

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

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

The description states a clear verb and resource: 'Delete a database.' It is unambiguous about what the tool does, though it does not explicitly differentiate itself from sibling tools beyond the database_* naming pattern.

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, what prerequisites are needed, or how it compares to alternatives like database_add or database_list. The description gives no exclusionary context or 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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It signals a read-only intent via 'List', but does not describe the return format, scope, pagination, ordering, or error behavior.

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

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

The description is a single, front-loaded sentence with no filler. It is concise without being bloated, though it remains terse and could have included a bit more context.

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 zero-parameter list operation, the description is largely complete: the agent knows the action and resource and can invoke the tool without inputs. The lack of output schema and annotations limits behavioral context, but the simplicity of the tool reduces the risk of incorrect 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?

The tool has zero parameters, and the schema is fully self-contained with 100% coverage. The description adds no parameter information, but none is needed because there are no inputs to configure.

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 ('databases'), making the operation unambiguous. It does not explicitly differentiate from sibling list tools like dns_zone_list or mail_domain_list, but the resource name is sufficient to distinguish intent.

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: whenever an agent needs to list databases. It provides no explicit contrast with alternatives or conditions for when not to use it, but the simple list semantics make the intended usage reasonably 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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states the action and gives no information about whether existing records are overwritten, validation behavior, side effects, or required permissions. This is a mutation tool with minimal behavioral context.

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

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

The description is a single compact sentence with no wasted words. It front-loads the core action and target resource effectively.

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 opaque nested 'params' object and the absence of an output schema or annotations, more context is needed for an agent to invoke this correctly. The description does not explain how to identify the zone, what record fields are required, or what happens after a successful add. These are critical gaps for a tool with this 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?

The input schema documents the top-level parameters and even provides some meaning for 'params' by listing example record components like zone, name, data, and ttl. However, the nested 'params' object is open-ended, and the description adds no further parameter-level detail. Since schema coverage is high at the top level, a baseline score of 3 is appropriate.

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

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

The description states a specific action and resource: adding a DNS record to a zone. It distinguishes this from sibling tools like dns_zone_add, dns_record_update, and dns_record_delete, though it does not explicitly call out those alternatives.

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 about when to use this tool versus related tools such as dns_record_update or dns_zone_add. It also does not mention prerequisites like whether the target zone must already exist. The usage context is only implied by the tool name and description.

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

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

Annotations are absent, so the description carries the full burden of behavioral disclosure. 'Delete a DNS record' names the mutation but does not state that deletion is irreversible, whether dependent records or zone integrity are affected, what happens if record_id does not exist, or any permission/precondition requirements. The description adds essentially nothing beyond what the tool name already conveys.

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

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

The description is four words, front-loaded with the verb, and contains zero filler. It is appropriately brief for a simple operation, though it could have added usage and behavioral context in one or two extra sentences without becoming 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?

With no output schema and no annotations, the description should explain return values, irreversibility, and preconditions, but it does none of this. The two parameters are well covered by the schema, yet the destructive operation itself is under-described, leaving the agent to guess what a successful delete returns or how to confirm the record was removed (e.g., via dns_record_get).

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%: 'type' documents the allowed enum of record types and 'record_id' is described as 'Record ID', so the baseline is 3. The description text adds no further parameter meaning, such as how to obtain a valid record_id or whether the zone is implied by the record. The schema does the heavy lifting, and the description neither helps nor hurts.

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 DNS record), clearly marking this as the destructive counterpart to dns_record_add, dns_record_update, and dns_record_get. It also distinguishes from dns_zone_delete by targeting records rather than zones. It is clear, though minimal, with no elaboration on scope or effect.

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

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 dns_record_update (e.g., removing a record entirely vs editing it) or how it relates to dns_zone_delete. Prerequisites are absent — nothing states the record and its zone must already exist, or that deletion affects live DNS resolution. With roughly 70 siblings, the agent receives no routing help.

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

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

With no annotations, the description must carry behavioral disclosure. 'Get' conveys a read-only lookup, and 'by type and ID' explains the access pattern. However, it does not state response behavior, error conditions for missing records, or any permissions, so the disclosure is adequate but not rich.

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

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

The description is a single front-loaded sentence with no filler or repetition. Every word adds necessary information, making it concise and easy to parse.

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

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

Given the tool's simplicity (2 required params, no output schema, no annotations), the description states the core operation and lookup keys but does not mention return value shape or error behavior. It is sufficient for a basic get but lacks details an agent might need for robust 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?

The input schema already provides 100% coverage for both parameters, describing 'type' as a record type enum and 'record_id' as a number. The description's 'by type and ID' adds no new meaning beyond what the structured schema already states.

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 ('DNS record'), and identifies the two defining parameters (type and ID). It is unambiguous about what the tool does, though it does not explicitly contrast with sibling tools like dns_record_update or dns_record_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 guidance is provided about when to use this tool versus alternatives. Sibling names such as dns_zone_get, dns_record_update, and dns_record_delete indicate related operations, but the description does not mention them or give a decision rule.

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

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

With no annotations, the description alone must convey behavioral details. It states the mutation operation but does not disclose whether the update is partial or full, how the 'params' object affects existing values, what happens if the record does not exist, or whether any permissions or prerequisites are required. This is a bare statement rather than a behavioral disclosure.

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

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

The description is a single, front-loaded sentence with no redundant content. It conveys the core action without unnecessary elaboration, making it easy to parse quickly.

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

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

For a mutation tool with four required parameters, a nested 'params' object, no annotations, and no output schema, the description is too minimal. It does not explain how to construct the dynamic 'params' object (e.g., which fields are valid for each DNS record type) nor what the API returns. This leaves significant gaps for an agent attempting to invoke the tool correctly.

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

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

Schema description coverage is 100%, so all four top-level parameters are documented in the input schema. The description adds no additional meaning beyond what the schema already provides. The 'params' field is described only as 'Fields to update', which is helpful but appears in the schema as well.

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 clear verb and resource: 'Update a DNS record'. It sufficiently identifies the operation and differentiates it from sibling tools like dns_record_add, dns_record_delete, and dns_record_get. However, it could more explicitly state that it modifies an existing record, which would strengthen 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?

No guidance is provided about when to use this tool versus alternatives such as dns_record_add or dns_record_delete. The description neither states conditions for use nor mentions any exclusions, leaving the agent without clear selection criteria.

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

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

With no annotations, the description carries the burden of disclosing behavior, but it only says 'Create a new DNS zone.' It does not mention potential side effects, duplicate-origin handling, required existing server/client entities, or response behavior.

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

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

A single sentence with zero wasted words and the main operation front-loaded. It is concise, though very sparse for a tool with 11 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?

The description is not complete enough for a complex 11-parameter tool with no annotations and no output schema. It omits prerequisites, return value, duplicate behavior, and how this relates to sibling zone/record 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?

Schema description coverage is only 55%, leaving six parameters (ttl, retry, active, expire, minimum, refresh) without semantic descriptions. The tool description does not compensate or add any 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 states a specific verb ('Create') and resource ('a new DNS zone'), making the operation clear. It differentiates from sibling DNS tools by zone-level scope, though it does not explicitly contrast with dns_record_add or dns_zone_update.

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 such as dns_zone_update or dns_record_add. The description only states the action, leaving usage entirely implied.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure, but 'Delete a DNS zone' only restates the action already implied by the tool name. It does not disclose that deletion is likely irreversible, whether associated DNS records are cascadingly removed, what permissions are required, or error behavior for non-existent zones.

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 clean sentence with zero filler and the action front-loaded. It is appropriately brief, though it errs toward under-specification rather than being merely concise.

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 mutation tool with no annotations and no output schema, this description is the bare minimum. It omits critical operational context such as side effects on records, irreversibility, success/error return behavior, and how it fits into the broader DNS zone CRUD workflow (dns_zone_list/get/add/update/delete).

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%, as zone_id is documented as 'Zone ID to delete' in the schema itself. The description adds no parameter meaning beyond the schema, so the baseline of 3 applies.

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

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 ('DNS zone'), making the core purpose unambiguous. However, it does not differentiate itself from the sibling set (dns_zone_add, dns_zone_update, dns_zone_get, dns_zone_list), relying entirely on the verb to carry that distinction.

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 siblings. It does not mention prerequisites (e.g., zone must exist), conditions that would make deletion inappropriate, or alternatives like dns_zone_update for modifying instead of removing.

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

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

No annotations are provided, so the description carries the burden. 'Get' conveys a non-mutating read operation, but the description does not disclose error behavior, required permissions, or what is returned when the zone is not found.

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 with no filler; the key action, resource, and lookup key are front-loaded. It is appropriately minimal for a single-parameter read tool.

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 simple and the single required parameter is fully documented, but there is no output schema and no annotation, so the description leaves return shape and failure behavior unstated. Adequate for a straightforward getter, but it relies on the agent's assumptions about 'Get'.

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%: zone_id is already documented as 'The zone ID'. The description only reinforces the 'by ID' lookup and adds no new parameter semantics beyond what the schema provides.

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

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

States a specific verb ('Get') and resource ('DNS zone') with a precise selection criterion ('by ID'), which clearly distinguishes it from dns_zone_list and the other dns_zone_* mutations among the 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?

No guidance about when to use this tool versus dns_zone_list or other sibling tools. The 'by ID' phrasing implies direct retrieval when the zone_id is known, but no alternatives or when-not conditions are 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?

With no annotations, the description carries the full burden of behavioral disclosure. It merely states the operation without mentioning whether it is read-only, what the returned data looks like, whether pagination exists, or any other behavioral trait. Minimal transparency for a zero-parameter list tool.

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

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

The description is a single, front-loaded sentence with zero filler. Every word earns its place, 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, parameterless list operation, the description is largely complete: an agent knows what action to take and that no arguments are needed. However, the absence of an output schema and any mention of return structure or pagination keeps it from being fully complete, though this is a minor gap for such a straightforward 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 tool has zero parameters and the schema reflects that with an empty properties object, so there are no parameter semantics to explain. The description is not expected to add parameter detail; baseline 4 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 'List all DNS zones' uses a specific verb and resource, clearly identifying it as a list operation. It distinguishes itself from sibling tools like dns_zone_get by indicating collection-level behavior ('all') rather than single-zone retrieval.

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 for when to use this tool versus alternatives such as dns_zone_get, dns_zone_add, or dns_zone_delete. The usage context is only implied by the word 'list' and the tool's name, not explicitly 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?

There are no annotations, so the description must carry behavioral disclosure. It only says 'Update', a generic mutation verb, without explaining permissions, consequences, validation rules, or how existing zone settings are affected. It does not contradict annotations because no annotations exist.

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

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

The description is a single sentence with no wasted words, which is concise. However, it is under-specified for a mutation tool with a nested params object and no output schema, so the brevity reflects insufficient content rather than well-structured completeness.

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 has three required parameters, a nested free-form params object, no annotations, and no output schema, the description is too thin. It does not explain what fields params can contain, what 'updating' a DNS zone means, or what the expected result is, so an agent cannot confidently invoke it correctly.

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

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

Schema description coverage is 100%, so the schema already documents the parameter names and basic purposes. The description adds no value to parameter understanding, and the 'params' field remains opaque ('Fields to update'), so the baseline of 3 is appropriate.

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

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

The description states a specific verb ('Update') and resource ('DNS zone'), clearly distinguishing this from creating or deleting a zone. It doesn't specify what parts of the zone can be updated, but it is not tautological or misleading.

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 about when to use this tool versus siblings like dns_zone_add, dns_zone_get, or dns_record_update. The word 'existing' only weakly implies it is for zones already created, with no explicit alternatives 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?

No annotations are present, so the description carries the full burden of behavioral disclosure. It states that an FTP user is created, but does not explain side effects, required permissions, whether the operation is reversible, or what happens if the username already exists. This is minimal behavioral information for a mutating tool.

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

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

The description is extremely concise: a single five-word sentence with no filler or redundancy. It is front-loaded with the essential action. However, its brevity borders on under-specification, since it omits useful context that could fit in one or two more sentences.

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 has nested parameters, no output schema, and no annotations, yet the description only states the basic action. An agent has no information about required nested fields like server_id or parent_domain_id, the response format, or any constraints. For a user-creation operation with this complexity, the description is not complete enough.

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 describes both parameters: client_id and a params object with an example list of FTP user properties. Schema description coverage is 100%, so the description adds no additional parameter meaning. The 'etc.' in the schema leaves the nested fields partially open, but the description provides no compensation for that ambiguity.

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

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

The description states a clear action and resource: 'Create an FTP user.' It identifies the operation (create) and object (FTP user), distinguishing it from sibling operations like ftp_user_update, ftp_user_delete, and ftp_user_list. However, it does not explicitly differentiate it from other creation tools such as shell_user_add or clarify which sibling is the alternative.

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 usage guidance is provided. The description does not state when to use this tool versus alternatives, nor does it mention any prerequisites, such as needing an existing server or domain. The agent must infer intended usage solely from the verb 'Create'.

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

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

No annotations are present, so the description carries the full burden of disclosing that this is a destructive operation. It only says 'Delete an FTP user' and omits permanence, side effects on files/directories, idempotency, and behavior for nonexistent IDs, leaving an agent unable to anticipate consequences.

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

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

The description is a single, front-loaded sentence with no filler, which is appropriately concise for a one-parameter tool. It loses a point for being so terse that it omits useful cautionary context, though that gap is better reflected in other dimensions.

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 delete tool with no annotations and no output schema, the definition is incomplete: it does not state whether deletion is permanent, what exactly is deleted (account vs. data), what a successful call returns, or how to verify the result. The fully documented parameter mitigates but does not cure the 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 100%: user_id is already documented as 'FTP user ID'. The description adds no parameter-level information, so the schema carries the semantic weight and 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 uses a specific verb ('Delete') and resource ('FTP user'), making the tool's action and target unambiguous. It also differentiates from sibling tools such as ftp_user_add, ftp_user_update, and ftp_user_list by signalling this is the deletion 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?

There is no explicit guidance about when to use this tool versus alternatives, no mention of prerequisites such as obtaining the user_id from ftp_user_list, and no warning that it should only be used when deletion is intended. The verb conveys the obvious case but does not help an agent select it under real-world 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?

With no annotations, the description carries the burden of disclosing behavior. The verb 'List' communicates a non-destructive read operation, which is helpful. However, the description does not disclose whether all FTP users are returned, whether pagination or filtering exists, or what the response structure looks like.

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 filler or redundant wording. It states the operation and the resource in a front-loaded, efficient manner that is appropriately sized for a zero-parameter list tool.

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, empty parameter schema, and no output schema, the description is largely sufficient. It clearly identifies a simple read operation. The only minor gap is that it does not elaborate on the return payload or filtering semantics, but these are not necessary for basic 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?

The tool has zero parameters and the schema coverage is 100%, so no parameter documentation is needed. The description inherits the baseline of 4 for a no-parameter tool; it does not need to add 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 uses a specific verb ('List') and a clear resource ('FTP users'), stating exactly what the tool does. It distinguishes the tool from its sibling FTP tools, which are all mutation operations (ftp_user_add, ftp_user_update, ftp_user_delete), and there is no competing FTP listing tool.

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 is implied: an agent would call this to retrieve FTP users rather than to modify them. However, the description does not explicitly state when to prefer this tool over alternatives or mention any exclusions or prerequisites, so guidance 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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It only says 'Update an FTP user', which merely states the operation type without revealing what happens during the update: whether existing values are replaced or merged, whether any fields are immutable, whether the operation is idempotent, or what the response contains. This is no more informative than the tool name itself.

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 short and front-loaded, but it does not earn its place: it is redundant with the tool name and lacks any structure that aids an agent. Brevity here reflects under-specification rather than efficient, valuable communication.

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 has a required nested 'params' object with no defined shape, no output schema, and no annotations. The description provides zero context about valid update fields, prerequisites, side effects, or invocation examples. For an agent to correctly construct a call, the description is almost entirely inadequate, especially given the large sibling tool set.

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 schema describes client_id, user_id, and params. The description adds no extra meaning to these parameters; 'params' remains an opaque object with additionalProperties allowed. However, because the schema already documents the parameters at a basic level, 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 'Update an FTP user' is essentially a word-for-word restatement of the tool name 'ftp_user_update'. It provides no clarifying detail about which FTP user attributes are affected or how this differs from the actual update semantics, so it qualifies as a tautology rather than a distinct purpose statement.

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

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

The description gives no guidance on when to use this tool versus alternatives. Sibling tools like ftp_user_add, ftp_user_delete, and ftp_user_list exist, but no conditions, exclusions, or routing hints are provided. An agent is left to infer the appropriate context from the name alone.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states that a mail alias is created, without explaining side effects, default values, permission requirements, or behavior on duplicate aliases.

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 wasted words. It is appropriately brief for a simple create operation, though it sacrifices useful context for brevity.

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

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

For a mutation tool with no annotations, no output schema, and a nested params object with four undocumented fields, this description is insufficient. It does not explain the alias parameters, expected results, or when to use the tool, leaving significant gaps for an agent.

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

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

Schema description coverage is 100%, so the schema already documents both parameters at a basic level. The description adds no parameter semantics beyond what the schema provides, but the baseline of 3 is appropriate since the schema handles the heavy lifting.

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

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

The description 'Create a mail alias' uses a specific verb and resource, making the core action immediately clear. However, it does not actively distinguish itself from sibling tools like mail_forward_add or mail_catchall_add, which are conceptually similar.

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 such as mail_forward_add or mail_user_add. No context, prerequisites, or exclusions are provided.

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

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

No annotations are provided, so the description carries the full burden of disclosing behavior. 'Delete' indicates the destructive nature, but the description does not mention whether deletion is permanent, whether it affects email routing or forwarding rules, or what error behavior 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?

The description is a single, focused sentence with no filler. It is front-loaded with the action and resource, making it appropriately concise for a simple delete 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 of a one-parameter delete operation, the description plus schema provide enough information to invoke the tool correctly. Missing behavioral details are notable but do not prevent correct usage in a straightforward context.

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

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

The schema already fully documents the single parameter with a clear description ('Alias ID'), so schema coverage is 100%. The tool description adds no additional semantic detail beyond what the schema provides, meeting the baseline of 3.

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 'Delete a mail alias' uses a specific verb and resource, making the tool's purpose immediately clear. It also distinguishes itself from siblings like mail_alias_add and mail_forward_delete 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?

There is no guidance on when to use this tool versus alternatives, no prerequisites, and no mention of what happens if the alias does not exist. The description is not misleading, but it provides no usage context beyond the action itself.

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

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

No annotations are provided, so the description must carry the full burden of behavioral disclosure. It only says 'Create', implying a mutation, but does not state what happens to an existing catchall, whether the operation is idempotent, what side effects occur, or whether privileges are required. This is a meaningful gap 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, short sentence that is easy to parse and immediately states the core operation. It contains no filler or redundant content. The main weakness is that its brevity leaves out important context, but it is appropriately 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?

The tool has no annotations, no output schema, and a loosely constrained nested params object, yet the description only states the action. It does not explain how server_id, source, and destination should be used, what a catchall's behavior is, or how this relates to other mail tools. An agent would lack enough context to invoke this tool reliably.

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 describes both parameters: client_id as 'Client ID' and params as 'Catchall params (server_id, source, destination)', with 100% schema description coverage. The tool description adds no parameter-level meaning beyond the schema. The nested params object is still vague due to additionalProperties: {}, but the schema itself provides the basic 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 states a clear verb ('Create') and a specific resource ('a catchall for a mail domain'), which distinguishes it from the many mail alias and forward tools in the sibling list. It is concise and directly conveys the operation. However, it does not explain what a catchall functionally does, leaving some ambiguity about its mail-routing 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?

No guidance is given about when to use this tool versus alternatives like mail_alias_add or mail_forward_add. There is no mention of prerequisites such as an existing mail domain being required. The user must infer usage entirely from the tool name and sparse 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?

No annotations are provided, so the description carries full disclosure burden. It reveals only that the tool creates something, with no information about side effects, duplicate domain handling, default behavior of 'active', dependencies on existing resources, or response expectations.

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 five-word description is front-loaded with the verb and contains no filler. However, this brevity results from omitting usage and behavioral content rather than from dense compression, so it borders on under-specification.

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 creation tool with no annotations, no output schema, and a loosely-typed nested params object, the description is inadequate. It does not explain the semantics of the params keys, what a successful call returns, or how it fits with the adjacent mail_* creation tools, leaving the agent to infer too much from the schema alone.

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 of 3 applies. Both client_id and params have descriptions, with params enumerating the keys (server_id, domain, active), but the schema only gives key names with no type or semantic detail for 'active' or 'server_id', and the tool description adds no parameter explanation 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?

States a specific verb and resource ('Create a new mail domain') that accurately describes the operation. The verb distinguishes it from sibling mail_domain_list, mail_domain_get, and mail_domain_delete, though these are not explicitly named.

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 such as web_domain_add, dns_zone_add, or mail_catchall_add. No prerequisites (existing client, server) or exclusion conditions are 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?

No annotations are provided, so the description carries the full burden of behavioral disclosure, and it only says what the tool does without any consequences. It does not disclose whether deletion cascades to associated mail users, aliases, forwards, or catchall settings, whether the operation is reversible, or whether safety checks or permissions apply. For a destructive operation this is a significant gap.

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

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

The description is maximally concise with zero wasted words and front-loads the action. However, it is so terse that it borders on under-specification rather than disciplined brevity, offering nothing beyond a restatement of the 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?

Complexity is low (one parameter) and the schema fully covers that parameter, but the tool is destructive and has no annotations and no output schema. The description omits critical context an agent needs before invoking a delete operation, such as cascade effects on mail users/aliases/forwards, reversibility, or what a successful deletion returns. The definition is not complete enough for safe 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 100% — the single required parameter domain_id is documented as 'Mail domain ID' in the schema itself, so the baseline of 3 applies. The description adds no parameter-level meaning beyond the schema. Since there is only one simple numeric parameter, this is adequate.

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 a specific resource ('a mail domain'), so an agent can clearly tell this is the removal operation for mail domains. The resource qualifier inherently distinguishes it from siblings like web_domain_delete, dns_zone_delete, and database_delete. However, it is essentially a paraphrase of the tool name and does not explicitly differentiate itself from mail_domain_add, mail_domain_get, or mail_domain_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 provides no guidance on when to use this tool versus alternatives, no prerequisites, and no workflow context. It is a single declarative sentence with no mention of conditions, exclusions, or related tools such as mail_domain_get or mail_domain_list. The only usage signal an agent gets is the literal meaning of '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?

Without annotations, the description must carry behavioral disclosure. The verb 'Get' clearly signals a non-mutating read operation, which is useful, but the description does not mention return format, error behavior if the domain ID is not found, or authentication requirements. Adequate for a simple getter 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?

One sentence of seven words, verb first, with no filler. Every word earns its place and the key scoping detail ('by ID') is front-loaded.

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

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

For a single-parameter getter with no nested objects, the description is largely complete: an agent can call it with a domain_id. The absence of an output schema leaves the return shape undocumented, but the tool's purpose makes the result predictable. Minor gap around handling unknown IDs.

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 defines domain_id with a description at 100% coverage. The description's 'by ID' reinforces the parameter's role but adds no new semantic information 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 action ('Get') and resource ('mail domain') with a clear scope ('by ID'). It distinguishes from mail_domain_list (which lists domains) and from add/delete operations, though it doesn't explicitly name alternatives.

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

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

No guidance is given on when to use this tool versus alternatives such as mail_domain_list, nor are prerequisites mentioned (e.g., needing a domain_id from a list call). Usage is only implied by the verb and the parameter.

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

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

With no annotations, the description carries the behavioral burden. 'List all' signals a read-only enumeration and no filtering, but it does not disclose response shape, potential pagination, ordering, or whether disabled domains are included. This is adequate but not rich.

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

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

The entire description is one short, front-loaded phrase with no filler or redundant 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 zero-parameter, low-complexity list operation this is nearly complete. The absence of an output schema means an agent must infer the returned fields, but nothing about how to invoke the tool correctly is missing.

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

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

The tool takes zero parameters and the schema documents 100% of them, so no parameter explanation is required. The baseline for zero-parameter tools is 4.

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 identifies the exact resource ('mail domains') with an explicit scope ('all'). This clearly distinguishes it from sibling tools like web_domain_list and mail_domain_get.

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: call this when you need a full enumeration of mail domains. However, it provides no explicit guidance about when not to use it or which alternative like mail_domain_get or mail_domain_add to prefer for other needs.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure, but it only restates the create operation. It does not mention side effects, required permissions, idempotency, activation behavior, or what happens to existing forwards.

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 wasted words. It is concise to the point of being terse, but it communicates the core action efficiently.

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

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

For a tool with nested params, no annotations, no output schema, and many similar siblings, this description is far too sparse. An agent cannot determine what inputs are required, what the response looks like, or how this differs from adjacent mail 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 documents both parameters, including the nested forward fields (server_id, source, destination, active), so schema coverage is high. The description adds no meaning beyond this baseline, leaving a 3 as the appropriate score.

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

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

States a specific action and resource: 'Create a mail forward'. While it is nearly a restatement of the tool name and does not differentiate from siblings like mail_alias_add or mail_forward_delete, it is unambiguous about the core 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?

No guidance is given about when to choose this tool over related creation tools such as mail_alias_add or mail_catchall_add, nor does it mention prerequisites, exclusions, or scenarios. The intended usage must be inferred entirely from the tool name and sibling list.

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

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

With no annotations, the description carries the full burden of behavioral disclosure. It states the destructive action but does not mention permanence, side effects, what happens if the forward_id is invalid, or any required context. No behavioral detail is added beyond the obvious 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 with no filler. It is as concise as possible while remaining a complete, understandable statement.

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 one-parameter delete operation, the description states the core action and the parameter is fully covered by the schema. However, with no output schema and no annotations, the agent lacks information about return values, idempotency, or error behavior. The simplicity of the tool prevents a lower score, but gaps remain.

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

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

The schema already documents forward_id as a required number with description 'Forward ID', and schema description coverage is 100%. The description adds no additional meaning about the parameter, so a 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 'Delete a mail forward' uses a specific verb and resource, clearly stating the operation. It distinguishes the tool from siblings like mail_forward_add and mail_alias_delete, leaving no ambiguity about what action it performs.

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 choosing between mail_forward_delete and mail_alias_delete, or any prerequisites like the forward needing to exist. The only usage signal comes from the tool name itself.

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

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

With no annotations, the description carries the full burden of behavioral disclosure. It conveys that the operation is an add/insert, but does not mention whether duplicates are rejected, whether the change is immediate, what server_id implies, or whether existing blacklist entries are affected.

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

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

The description is a single front-loaded sentence with no filler. It is appropriately concise, though it achieves brevity at the cost of necessary behavioral and parameter context.

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 a nested params object containing five undocumented subfields, no annotations, and no output schema, this description is incomplete. It does not explain required params semantics, valid values, or what the API returns on success or failure.

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's 'email/domain to spamfilter blacklist' broadly maps to the email parameter, but it adds no meaning for server_id, wb, priority, or active beyond their names.

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') and the target resource ('email/domain to spamfilter blacklist'), and the word 'blacklist' distinguishes it from the sibling mail_spamfilter_whitelist_add. It loses a point because it doesn't clarify whether email and domain are separate entry types or can be combined in a single call.

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 about when to use this tool versus the closely related mail_spamfilter_whitelist_add or any other mail filtering sibling. The description provides no exclusions, prerequisites, or routing context.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure, but it only names the action without explaining side effects, idempotency, overwrite behavior, or whether existing whitelist entries are updated. It does not state permissions, reversibility, or what happens on duplicate adds, which is a significant gap for a mutation tool.

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

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

The description is a single, front-loaded sentence with no wasted words. It is concise and readable, though it sacrifices detail for brevity; the compactness is appropriate for the simple stated action.

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 has a nested params object with five implied fields, no output schema, and no annotations, yet the description provides no context about how to construct params, which fields are required, allowed values, or expected response. This is incomplete for a tool with moderate structural complexity and no other documentation sources.

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%: both client_id and params have descriptions, so the baseline is 3. The tool description adds no new parameter information beyond what the schema already supplies; the nested params fields are listed but their meaning and syntax remain unclear.

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 ('Add'), a concrete resource ('spamfilter whitelist'), and the target type ('email/domain'). It clearly distinguishes this tool from its sibling mail_spamfilter_blacklist_add, so an agent can tell them apart without inspecting 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?

The description gives no guidance on when to use this tool versus alternatives, such as whitelist versus blacklist, or how it relates to other mail filtering tools. There are no prerequisites, conditions, or exclusions stated, leaving the agent to infer usage context.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It only says 'Create a new mailbox' and does not reveal whether duplicate email addresses are rejected, what permissions or preconditions are required, whether the action is reversible, or what the response contains. For a mutating operation with zero annotation coverage, this is a significant gap.

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

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

The description is a single, front-loaded sentence with no wasted words. It is concise and immediately understood. However, it is so minimal that it reads more like a label than a complete tool definition, so it loses a point on structure despite being efficient.

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

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

The tool has nested parameters, no output schema, and no annotations, so the description needs to compensate with context. It does not cover preconditions (e.g., existing client and mail domain), required vs optional mailbox fields, duplicate handling, or response behavior. An agent calling this tool would have to infer most operational context from the schema and sibling tool names.

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 describes both parameters, with client_id labeled 'Client ID' and params labeled 'Mailbox params (server_id, email, password, name, quota, etc.)'. Because schema description coverage is 100%, the description does not need to add much; it correctly identifies the resource and provides example param names inside the schema itself. The tool description itself adds no extra parameter detail, so a baseline score of 3 is appropriate.

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

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 ('mailbox'), making the operation immediately clear. It distinguishes from siblings like mail_user_update, mail_user_delete, mail_domain_add, mail_alias_add, and mail_forward_add by targeting the mailbox resource and the add action. It does not explicitly contrast with these siblings, but the resource naming is sufficient for basic identification.

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. It does not mention that a mail domain must already exist, that client_id must reference a valid client, or that mail_user_get/update/delete cover related lifecycle operations. Usage context is only implied by the tool name and generic 'create' wording.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It signals a destructive mutation but does not state that deletion is permanent, whether aliases or forwards are affected, or what happens to the mailbox's 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 clear sentence with the action verb front-loaded and no filler. It is concise and easy to parse, though it sacrifices potentially useful behavioral 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 destructive one-parameter tool with no annotations and no output schema, this description is too minimal. It does not explain consequences, irreversibility, or dependencies with other mail objects, leaving the agent without enough context to assess impact.

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 single parameter user_id as 'Mail user ID' with 100% description coverage. The description adds no parameter-level meaning, so the baseline score of 3 applies because the schema does the heavy lifting.

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

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

The description states a clear verb ('Delete') and a specific resource ('a mailbox'), which maps directly to the mail_user_delete tool and distinguishes it from sibling tools that delete domains, aliases, or forwards. It is not merely a restatement of the tool name, though it could be more explicit that it refers to a mail user rather than a mailbox alias.

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 about when to use this tool versus alternatives such as mail_alias_delete, mail_forward_delete, or mail_domain_delete. The agent must infer usage entirely from the tool name and sibling list.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. The verb 'Get' conveys a read-only, side-effect-free operation, but the description does not mention response format, missing-ID behavior, or permission requirements. This is adequate but not detailed.

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

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

The description is a single compact sentence with no filler or redundant information. It front-loads the action and resource, 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?

For a simple one-parameter lookup with no nested objects or output schema, the description is nearly sufficient. The main missing piece is explicit detail about the return value or error behavior, but the tool's purpose and invocation requirements are 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?

The input schema already provides 100% coverage for the single parameter, documenting user_id as 'Mail user ID'. The description's 'by ID' merely reinforces the schema without adding new meaning, so the baseline of 3 applies.

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

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

The description states a specific action ('Get'), a precise resource ('mail user/mailbox'), and the lookup mechanism ('by ID'). This distinguishes it clearly from sibling mutation tools like mail_user_add, mail_user_update, and mail_user_delete.

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

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

The description provides no explicit guidance about when to use this tool versus alternatives, nor any exclusions or prerequisites. The read vs. mutation split is implied by the verb and sibling names, but the description itself does not articulate it.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure, yet it only conveys that a mutation occurs. It does not state whether params replaces or merges existing settings, whether changes are reversible, what side effects might occur on related objects (aliases, forwards), or what permission/authorization is required.

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 only four words, which is terse but not meaningfully concise—it is under-specification. Nothing is front-loaded because there is no information to front-load; the sentence says nothing beyond what the tool name already communicates.

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 has high complexity: a free-form nested params object, no output schema, no annotations, and a large sibling family of mail_* tools. The description contributes essentially nothing an agent needs—valid updatable fields, replacement vs merge semantics, return value, or prerequisites—so an agent cannot safely invoke it correctly.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds no parameter-level meaning, and the schema's own descriptions are thin ("Client ID", "Fields to update"), but per the rubric the schema is doing the heavy lifting here. The free-form nature of params is left entirely 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?

"Update a mailbox" is nearly a tautology of the tool name mail_user_update. It identifies a generic verb and resource but adds no specificity about what fields or aspects of the mailbox are affected. It also introduces terminology drift ("mailbox" vs the schema's "Mail user ID"), which is ambiguous given the sibling family uses "mail_user" naming.

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 mail_user_add, mail_user_delete, or mail_user_get. No prerequisites are stated (e.g., whether the user or mail domain must already exist), and no conditions are provided for choosing an update over a create or 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?

Since no annotations are provided, the description carries the full behavioral disclosure burden. It reveals a critical behavior: the tool only generates commands and does not execute the transfer. It also names the command families (rsync/mysqldump). It doesn't mention output format or authentication requirements, but the core non-execution behavior is clearly disclosed.

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

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

The description is two sentences with no wasted words. It front-loads the primary purpose, then immediately communicates the most important operational constraint (manual execution). Every phrase 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 purpose, scope, and execution model well enough for an agent to decide to call it. With no output schema, a small mention of the output shape (e.g., a list of shell commands) would improve completeness, but the absence is not severely harmful given the tool's straightforward generation role.

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?

Input schema coverage is 100%, so the schema already documents all parameters. The description adds only a high-level mapping to 'files, mail, databases' which mirrors the enum. It does not add parameter-specific details beyond the schema, so the baseline score of 3 is appropriate.

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

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

The description clearly states a specific action ('Generate rsync/mysqldump commands') and a specific resource ('actual data (files, mail, databases) between servers'). It also distinguishes itself from the config-focused migrate siblings by explicitly noting that the MCP handles config only, so an agent can tell it apart.

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: use this tool when you need commands to transfer actual data, and the commands must be run manually. It does not explicitly name alternatives or state when not to use it, but the 'MCP handles config only' line effectively excludes config-management tasks.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states the export action and scope; it does not describe side effects, whether the operation is read-only, where the bundle is returned/stored, or how secrets redaction behaves at a behavioral level.

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 that front-loads the core purpose and scope. It contains no filler, redundancy, or irrelevant 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?

There is no output schema, and the description does not explain what the agent should expect as a result, such as a file, an id, or a download path. Given the migration-tool sibling context, more detail about the export artifact and follow-up steps would be needed for a complete calling experience.

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 are already documented in the schema. The description adds minimal value beyond this, only reinforcing that the export covers a client and its associated domains; it does not add format, constraints, or interaction details for 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 identifies the specific action ('Export'), the resource ('a client account'), and the scope ('all associated domains as a migration bundle'). It also differentiates from sibling tools like migrate_export_web_domain and migrate_export_dns_zone, which target individual sub-resources.

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 exporting an entire client account, distinguishing it from domain-specific export tools. However, it does not explicitly state when to prefer this over the sibling export tools, nor does it mention prerequisites or related migration workflow steps.

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

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

No annotations are provided, so the description carries the behavioral transparency burden. The word 'export' implies a non-mutating read operation, and the description usefully discloses the JSON bundle format and that all records are included. However, it does not explicitly state that the operation is read-only, describe how the bundle is delivered, or mention any permissions or size considerations.

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 states the action, resource scope, and output format with no filler. Every word contributes to understanding what the tool does, making it a compact and effective definition.

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 export tool with full schema coverage and no output schema, the description adequately states what the bundle is and what it contains. It falls slightly short of full completeness by not explaining delivery mechanics or explicitly contrasting with dns_zone_get, but the migration label covers much of that context.

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

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

Schema description coverage is 100%, with both zone_id and include_secrets clearly documented in the input schema. The description adds no parameter-level information, but that is acceptable because the schema already handles both parameters adequately, setting the baseline at 3.

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 opens with a specific verb 'Export' and identifies the exact resource: 'a DNS zone with all its records as a migration bundle (JSON)'. This clearly differentiates the tool from sibling dns_zone_get and the other migrate_export_* tools, so an agent can understand the scope immediately.

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 phrase 'as a migration bundle' clearly signals this tool is intended for migration scenarios and helps distinguish it from ordinary DNS read tools like dns_zone_get. It does not explicitly list exclusions or alternative tools, but the migration-bundle framing provides a solid usage context.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. 'Export' implies a non-destructive read operation, but the description does not state whether it modifies anything, what the response contains, whether the bundle is returned directly or stored, or what permissions are needed. The schema's include_secrets note is not part of the description, leaving key behavioral traits to inference.

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 conveys the action, the resource, the included components, and the output format without any filler. It is appropriately sized for the tool's complexity.

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

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

The description defines the core purpose and scope well, but with no output schema and no annotations, it omits the return value/format, side effects, and prerequisites or migration workflow context. An agent could select this tool correctly but would not know what to expect after invoking it.

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 are already well-documented in the schema. The description adds general context about bundle contents but does not provide additional meaning beyond what the schema already states, warranting the baseline score of 3.

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 ('Export') and clearly defines the resource ('mail domain') and scope ('all mailboxes, aliases, forwards, and catchall') as well as the output ('migration bundle'). This distinguishes it from sibling tools like migrate_import_mail_domain and migrate_export_dns_zone without needing to open 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 phrase 'as a migration bundle' implies the tool is meant for migration workflows, and the sibling set includes migrate_import_mail_domain, suggesting an export/import pairing. However, the description does not explicitly state when to use this tool over alternatives such as mail_domain_get or migrate_export_web_domain, nor does it give exclusion criteria.

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

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

With no annotations provided, the description carries the behavioral disclosure burden. 'Export' suggests a non-destructive read operation and the listed contents show scope, but the description does not state whether export modifies anything, how the bundle is delivered, or any security/caveat beyond the schema's include_secrets flag.

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, dense sentence conveys the core purpose and contents with no filler. Every element in the description 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?

The description is largely complete for invoking the tool: it names the resource, required contents, and export intent, and all parameters are fully documented in the schema. However, there is no output schema and the description only vaguely implies the return mechanism ('as a migration bundle'), leaving delivery/format details underexplained.

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 both parameters with 100% coverage, so the baseline is 3. The description adds no additional parameter-level meaning beyond what the schema provides; it does not explain domain_id or include_secrets any 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 names a specific verb ('Export') and a specific resource ('a web domain') and enumerates included components (FTP users, shell users, databases, cron jobs, subdomains). It is immediately distinguishable from sibling migration exports like migrate_export_dns_zone and migrate_export_mail_domain.

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

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

The phrase 'as a migration bundle' makes the intended context clear, and the resource scope (web domain with associated items) implies this is for full web-domain migration. It does not explicitly mention alternatives or exclusions, so it stops short of perfect 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?

With no annotations, the description bears the full burden of explaining behavioral traits. It mentions the environment variable requirement, which is useful, but it does not disclose whether the import is destructive, whether it replaces an existing zone, whether it is idempotent, or what side effects occur on the destination instance. This is a notable gap for an import operation that clearly writes state.

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 core purpose and includes a key prerequisite. There is no redundant or low-value text. While it is terse, it avoids any filler and remains focused.

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 state-changing import tool with no output schema and no annotations, the description is incomplete. It does not explain what happens after a successful import, how conflicts are handled, or what the return value represents. The destination server requirement and the source of the bundle are implied but not explicitly connected in the description.

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 documents bundle_json, dest_client_id, and dest_server_id with meaningful descriptions. The tool description does not add additional parameter-level nuance 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 names a specific action ('Import'), the resource ('DNS zone migration bundle'), and the target ('destination ISPConfig instance'). This clearly distinguishes it from the sibling migrate_import_mail_domain and migrate_import_web_domain tools. The phrase 'from migrate_export_dns_zone' in the schema further reinforces the exact resource type.

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 one precondition ('Requires ISPCONFIG_DEST_URL to be configured') but provides no guidance on when to choose this tool over alternatives. It does not state that this is part of a migration workflow or that it should be used after migrate_export_dns_zone. The usage context must be inferred from the tool name and sibling tools.

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

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

No annotations are provided, so the description must disclose side effects. It does state that the tool creates domain, mailboxes, aliases, and forwards, and calls out key caveats. However, it does not disclose conflict behavior, idempotency, or what happens if the domain already exists on the destination—important for an import operation.

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

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

The description is compact and front-loaded: it opens with the action and resource, then states the created entities, then provides two essential caveats. Every sentence contributes value without redundancy.

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

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

With only three parameters and good schema coverage, the description covers the core behavior and important follow-up steps. However, there is no output schema and no annotation coverage, and the description leaves out execution expectations such as whether the import can partially fail or whether it overwrites existing data.

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

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

The input schema already documents all three parameters with meaningful descriptions (100% coverage), so the description need not repeat them. The description adds no parameter-level detail beyond what the schema provides, making the baseline score 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?

States a specific verb and resource: "Import a mail domain migration bundle into the destination ISPConfig instance." It also enumerates what the import creates (domain, mailboxes, aliases, forwards), making it clearly distinguishable from sibling import/export 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?

Clearly conveys the intended scenario: importing a mail domain migration bundle. It adds practical caveats (rsync maildir separately, reset redacted passwords), but does not explicitly contrast with alternatives like mail_domain_add or import_web_domain.

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

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

With no annotations provided, the description carries the behavioral disclosure burden. It usefully reveals that the tool creates multiple resource types (site, FTP/shell users, databases, cron jobs) and warns that website files and DB dumps are not transferred by this operation. It does not cover idempotency or overwrite behavior, but the included side effects are meaningful.

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 sentences with no filler. The main action and side effects are front-loaded, and the separate-transfer caveat is placed in a clearly marked note, 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?

For a 3-parameter tool with no output schema, the description covers the core behavior, side effects, and a key operational prerequisite. It could mention result or failure behavior, but the existing content is sufficient for invoking the tool correctly in most cases.

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 and the schema already documents all three parameters. The description adds context about what the bundle produces, but it does not deepen parameter-level semantics beyond the schema's existing 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 states a specific action ('Import a web domain migration bundle') plus the destination ('destination ISPConfig instance') and enumerates what it creates (site, FTP/shell users, databases, cron jobs). This clearly distinguishes it from sibling migration tools like migrate_import_dns_zone and migrate_import_mail_domain.

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

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

The description gives clear context for when to use the tool: importing a web domain migration bundle into a destination ISPConfig instance. It does not explicitly name alternatives or exclusion criteria, but the 'web domain migration bundle' wording and the sibling set make the intended scope reasonably 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?

With no annotations at all, the description carries the full burden, and it earns credit for explicitly declaring non-mutation with 'Does NOT make any changes.' Beyond that, it stays silent on what the plan contains, how it is returned, whether it requires network/API access to the source, and what happens if parts of the source are unreachable.

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 zero filler: purpose first, a clarifying clause second, and the key safety disclaimer last. Every word earns its place, and the critical non-mutation trait is front-loaded in the second sentence.

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 one-parameter tool, the description is adequate on purpose and safety, but it relies on the name 'migrate_plan' and the sibling list to position the tool in the workflow. With no output schema, the agent is left guessing what a generated plan looks like, and 'the source' remains 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 coverage is 100% — the schema documents scope as 'What to inventory,' which mirrors the description's phrase 'inventory what exists on the source.' The description adds no detail about the enum values (all/dns/mail/sites), but none is needed since the schema already covers the semantics. Baseline 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 states a specific verb ('Generate') and resource ('a migration plan'), and clarifies the operation as an inventory of what exists on the source. The closing note, 'Does NOT make any changes,' differentiates it from the mutating siblings and the migrate_import/migrate_export tools. However, 'the source' is left undefined, so an agent must infer it refers to the origin server/panel.

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 colon structure implies the tool is for the planning phase of a migration, but it never says when to reach for it versus migrate_export_*, migrate_verify, or the plain list tools. There are no explicit when-to-use conditions, prerequisites, or excluded alternatives. The guidance is implied rather than stated.

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

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

With no annotations, the description must carry behavioral disclosure. It usefully notes the ISPCONFIG_DEST_URL requirement and implies a read-only comparison, but it does not describe what the comparison returns, whether any writes occur, or how results are reported. This is adequate but not rich.

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

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

Two short sentences: the first states the tool's purpose and timing, the second states a required environment variable. Every sentence earns its place and there is no redundant or filler content.

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

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

For a tool with one enum parameter, no output schema, and clear positional context, the description is mostly complete. It could optionally mention what kind of output the agent should expect, but the purpose, timing, and key requirement are all present.

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 single parameter 'scope' is fully described in the schema with an enum and a description ('What to verify'), so schema coverage is 100%. The tool description adds no additional meaning about the scope values, so baseline 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 states a specific action ('Compare source and destination ISPConfig instances') and a temporal context ('after migration'), making its purpose unmistakable. It is clearly distinguished from sibling migrate_export/migrate_import/migrate_plan tools by being a verification step rather than a data transfer step.

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 phrase 'after migration' provides a clear context for when this tool should be invoked. It does not explicitly name alternatives or state when not to use it, but the post-migration position is a strong usage signal for an agent.

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

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

No annotations are present, so the description carries the full burden of behavioral disclosure. 'Get server information' only implies a read operation; it does not describe what information is returned, whether the section parameter filters the output, or any other behavioral characteristics such as error cases or response format.

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

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

The description is a single short sentence with zero fluff; every word is purposeful. It is concise and front-loaded, though it could have used the space to add sibling differentiation or behavioral 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 tool with no output schema and no annotations, the description is too sparse. It does not explain the return value, the role of the section parameter, or how this tool differs from server_get_by_ip. This incompleteness could lead an agent to pick the wrong getter or misinterpret the response.

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 both parameters documented (server_id as the required ID and section as a config filter). The description adds no extra parameter meaning beyond the schema, so the baseline of 3 applies.

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

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

The description states a clear verb and resource: 'Get server information'. However, it does not explicitly distinguish this from the sibling server_get_by_ip, which also retrieves server information. The name and required server_id parameter imply the distinction, but the description itself does not make it.

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 server_get versus alternatives such as server_get_by_ip, client_get, or other getters. The only hint is the required server_id parameter in the schema, but the description does not state the intended use case or selection criteria.

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

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

No annotations are provided, so the description carries the full burden. 'Find' implies a non-destructive read, but it does not disclose whether the lookup is exact, whether multiple servers could match, what happens on no match, or the response format. This is minimal behavioral transparency.

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

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

The description is a single, front-loaded sentence with no wasted words. It directly states the tool's action and key qualifier in the most concise effective way.

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 one-parameter tool, this is adequate, but with no annotations and no output schema, the description leaves gaps about return behavior and edge cases (e.g., not found). It provides just enough for an agent to know when and how to call it, but no more.

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 ip parameter already described as 'IP address'. The tool description adds no new parameter information, format constraints, or examples. This matches the baseline of 3 for fully covered 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 'Find server by IP address' clearly states the verb (find), resource (server), and the differentiator (by IP address). It is specific enough to distinguish from the sibling tool server_get, which presumably uses a different key, though it does not explicitly name the alternative.

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

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

The description implies the use case: when you have an IP address and need to find the corresponding server. However, it provides no explicit guidance on when to choose this tool over server_get or other server-related tools, and no exclusions or alternative conditions are 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?

There are no annotations, so the description carries the full burden of behavioral disclosure. It only states 'Create a shell user' and does not explain consequences, permission requirements, potential failure modes, or what happens upon success. For a mutation operation, this is a significant gap.

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

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

The description is a single, tightly worded sentence with no filler or redundancy. Every word contributes to the meaning, and the core purpose is immediately visible.

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 creation tool with no annotations and no output schema, the description is incomplete. It does not explain what must be provided inside the free-form params object, what a successful response looks like, or any side effects. An agent would not be able to reliably construct a valid call from this description alone.

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. However, the property descriptions are very shallow: 'Shell user params' and 'Client ID' add little operational meaning, and the params object is a free-form object with no property definitions. The tool description itself adds no parameter detail beyond what the schema already provides.

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

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

The description states a clear verb and resource: 'Create a shell user.' It accurately describes the operation and the resource is distinct from sibling tools like mail_user_add or client_add. However, it offers no additional scope or distinguishing detail beyond the literal action, so it is clear but minimal.

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. An agent must infer from the tool name and resource type that this is the right choice; there is no mention of prerequisites, alternative tools for similar tasks, or conditions under which this tool should not be used.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It merely restates that a user is deleted, without mentioning consequences such as loss of login ability, cascading removal of home directory data, required permissions, or whether the action is reversible. 'Delete' implies destruction but does not explain its extent.

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?

Uses one concise, front-loaded sentence that conveys the core action without any wasted words. For a simple one-parameter operation, this is appropriately sized and structurally clean.

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?

Despite having only one parameter and no output schema, the description lacks essential context due to the absence of annotations: it does not state when to use this tool, whether deletion is permanent, or what side effects occur (e.g., the user can no longer log in, or associated data may be affected). A minimum viable description should at least note irreversibility and contrast with shell_user_add.

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

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

The schema has 100% coverage for the single parameter user_id with the description 'Shell user ID', so the schema already documents the parameter fully. The tool description adds no extra parameter-level meaning, but none is needed given the schema's completeness, so the baseline score of 3 applies.

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

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

States a specific operation ('Delete') on a specific resource ('shell user'), which clearly distinguishes it from sibling add/update tools and from other delete tools like mail_user_delete or ftp_user_delete by the resource type. However, it is quite terse and does not elaborate on what a shell user is or the deletion 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?

Provides no guidance on when to use this tool versus alternatives, no prerequisites, no exclusions, and no mention of whether the deletion is irreversible or has cascading effects. An agent cannot determine from the description whether this is the right deletion tool among the many sibling delete 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?

No annotations are provided, so the description must carry the behavioral disclosure burden. It only indicates a creation action and says nothing about side effects, required parent resources, idempotency, or failure modes.

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

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

The description is a single front-loaded sentence with no filler or redundancy. It is concise, though it does not compensate for the lack of behavioral or parameter 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?

This is a create operation with no annotations, no output schema, and an opaque nested params object; one sentence is wholly inadequate for correct invocation. An agent cannot determine required fields, return shape, or prerequisites.

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 reported at 100%, so the baseline is 3. However, the params object is an unconstrained object with no property definitions, and the description adds no detail about what alias-domain parameters are actually expected.

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 ('Create') and resource ('a web alias domain'), so the basic purpose is clear. It does not distinguish this tool from siblings like web_domain_add or web_subdomain_add, but the resource type is still identifiable.

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 such as web_domain_add or web_subdomain_add. No prerequisites, such as an existing web domain, are mentioned, so the agent must infer usage entirely from the 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?

No annotations are provided, so the description carries the full behavioral disclosure burden. It only states the creation action and does not mention prerequisites, side effects, validation behavior, duplicate handling, or required server context.

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

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

The description is a single, front-loaded sentence with no filler or redundancy. It is appropriately concise, though the brevity comes at the cost of missing behavioral and contextual 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?

This is a creation tool with an open nested params object and no output schema, yet the description provides no guidance on required params, return values, side effects, or how it fits into the broader domain lifecycle. The description is too thin to fully support 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 coverage is 100%, so the schema already documents both parameters. The description adds minimal value by naming example site params like server_id, domain, and ip_address, but it does not explain required nested fields, formats, or constraints, so the baseline 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 a create operation on a website/web domain, which aligns with the sibling web_domain_* family and differentiates from list/get/update/delete. However, it does not explicitly contrast with web_subdomain_add or web_aliasdomain_add, so it stops short of full sibling differentiation.

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

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. Given the large sibling set with similar add tools like web_subdomain_add, dns_record_add, and mail_domain_add, the agent receives no explicit cue about when this specific creation tool is the right choice.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states the destructive action without explaining possible cascading effects, irreversibility, required permissions, or whether related subdomains, DNS records, or aliases are affected. For a delete operation this is a meaningful gap.

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 four words, front-loaded with the action, and contains no filler. Every word earns its place and there is no redundant repetition of the schema or 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 single-parameter deletion tool, the description is minimally adequate: an agent can infer it should call this with a web domain ID. However, the complete absence of behavioral context around a destructive operation leaves some ambiguity about side effects, making it less than 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?

The input schema already provides 100% coverage for the single required parameter 'domain_id' with the description 'Web domain ID'. The tool description adds no parameter-level meaning beyond what the schema supplies, so the baseline of 3 is appropriate.

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

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

Description states a specific verb and resource: 'Delete a web domain'. This clearly differentiates from sibling tools like web_subdomain_delete, dns_zone_delete, and mail_domain_delete by naming the exact resource type being removed.

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 alternative deletion tools, and no prerequisites, exclusions, or contextual conditions are given. The only implied usage is that this is the tool for deleting a web domain, but nothing explicitly addresses selection criteria.

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

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

With no annotations, the description carries the behavioral disclosure burden. 'Get' clearly signals a non-destructive read operation, which is helpful, but the description does not mention error behavior, authentication needs, or return format.

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

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

A single clear sentence with no filler. The essential scoping detail ('by ID') is front-loaded and every word contributes to understanding.

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

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

For a simple get-by-ID tool with a fully documented single parameter, this description is largely sufficient. It does not explain return values in detail since there is no output schema, but the tool's simplicity makes the missing context minor.

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 single parameter domain_id is already well documented in the schema. The description adds only the phrase 'by ID', which confirms the parameter's role but provides no additional semantic value 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?

States a specific verb ('Get'), a specific resource ('web domain'), and the lookup key ('by ID'). This clearly distinguishes it from siblings like web_domain_list, web_domain_update, and web_domain_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 phrase 'by ID' implies this tool should be used when a specific web domain identifier is already known, rather than when listing or searching. However, it does not explicitly mention alternatives or state when not to use this tool.

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

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

With no annotations, the description carries the burden of behavioral disclosure. It clearly implies a read-only listing operation, but it does not describe return format, ordering, pagination, or any access restrictions. For a trivial zero-parameter list, this is minimally viable but not richly transparent.

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

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

The description is a single, direct sentence with no filler. It front-loads the action and resource, 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?

For a zero-parameter list tool, the description is largely sufficient. The main gap is the absence of any return-value description, especially since no output schema exists, but the simplicity of the operation reduces the impact of that 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?

There are zero parameters, so the schema provides complete coverage. The description has no parameter details to add, and the baseline of 4 for parameterless tools 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 uses a specific verb ('List'), a clear resource ('web domains/sites'), and an explicit scope ('all'). This makes the tool's purpose immediately distinguishable from related siblings like web_domain_get, web_domain_add, or web_domain_update.

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 about when to use this tool versus alternatives. It does not mention that web_domain_get should be used for a single domain, nor any context about filtering or prerequisites. The description relies entirely on the tool's name and basic verb.

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

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

No annotations are provided, so the description carries the full burden of disclosing behavior. 'Update a web domain' reveals only that some mutation occurs, with no mention of side effects, destructiveness, permissions, idempotency, prerequisites, or response behavior.

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

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

The description is short and contains no fluff. However, this is under-specification rather than effective conciseness, since the single sentence merely repeats the tool name and provides no operational 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 mutating tool with no annotations, no output schema, and an unconstrained params object, this description is severely incomplete. An agent cannot determine valid update fields, expected outcomes, error conditions, or required context before 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?

The input schema already provides descriptions for all three parameters, so the high-coverage baseline applies. The description itself adds no parameter information; the open-ended 'params' object remains underspecified, but that is a schema-level gap rather than a description-level gap under the baseline rule.

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, 'Update a web domain', is essentially the tool name rephrased rather than a meaningful explanation of what updating entails. It gives no information about which domain properties can be changed, how the update behaves, or what distinguishes it from related operations beyond the verb itself.

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 siblings such as web_domain_add, web_domain_delete, web_domain_get, or the various subdomain and alias tools. The only implied usage is circular: use it when updating a web domain, which is already obvious from the name.

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