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

There are no annotations and no output schema, so the description carries the full behavioral burden. It does not mention authentication, response format, error behavior, rate limits, or whether raw endpoints can perform destructive mutations. It only restates the operation.

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

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

The description is a single, front-loaded sentence with no redundancy. 'Advanced' adds a compact signal about intended use, though the overall terseness limits the behavioral and selection guidance it can provide.

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

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

Given no annotations, no output schema, and a set of sibling tools that should usually be preferred for domain/DNS/mail operations, the description leaves tool selection and behavioral expectations to inference. The parameter schema covers invocation, but the tool's role and safety profile are incomplete.

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 both parameters include useful descriptions and examples. The description adds no parameter-level information, but the schema fully documents the inputs, 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 action ('Call') on a clear resource ('any adm.tools API endpoint') and the word 'directly' signals this is the raw, generic access path. It distinguishes itself from the sibling wrappers by scope, though it does not explicitly name an 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?

There is no guidance about when to use this raw endpoint versus sibling tools like adm_domains, adm_dns_records, or adm_balance. 'Advanced' implies it is not for routine use, but no exclusions, preferences, or alternative routing are given.

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

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

The verb 'Get' implies a read-only operation and 'current' suggests point-in-time state, but with no annotations the description carries the burden of behavioral disclosure. It does not explicitly confirm side-effect-free behavior, authentication needs, or response format, though this is sufficient for a simple parameterless retrieval.

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. Every word contributes to understanding the tool's purpose.

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

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

For a parameterless read-only balance lookup, this description is nearly complete. It leaves the response format and exact unit or currency unspecified, but given the tool's minimal complexity, no essential invocation detail 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 has zero parameters and the schema properties object is empty, providing 100% coverage by definition. The description does not need to document argument semantics, and it appropriately omits any parameter details.

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

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

The description uses a specific verb ('Get') and resource ('current account balance'), clearly identifying the operation. It also distinguishes this tool from sibling tools focused on domains, DNS, and mailboxes.

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

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

The intended use is implied: call this tool when you need the current account balance. However, the description does not explicitly discuss alternatives, when-not-to-use, or any prerequisites, though the tool's simplicity makes this less critical.

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 'Add' and gives no information about side effects, duplicate handling, validation, propagation, permissions, 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 one short, front-loaded sentence with no filler. It communicates the core operation efficiently and is appropriately sized for a tool whose parameters are fully documented in the schema.

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 schema fully covers parameter semantics, but the description alone does not explain when to use this tool or what happens after adding a record. With no annotations and no output schema, the definition is minimally adequate but leaves behavioral and contextual gaps.

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

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

Schema description coverage is 100%, with descriptions for domain_id, type, record, data, and priority, including enum values and a default for priority. The description itself adds no parameter-specific meaning beyond what the schema already provides.

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

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

The description 'Add a DNS record to a domain' names a specific action and resource. It clearly distinguishes this tool from sibling tools like adm_dns_records and adm_dns_delete, so an agent can tell them apart without opening the schema.

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

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

The description provides no guidance on when to use this tool versus alternatives such as adm_dns_records, adm_dns_delete, or adm_domain_zones. There are no criteria, exclusions, or references to other tools.

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

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

With no annotations provided, the description carries the full burden of disclosing behavior. 'Delete' already signals destructiveness, and '(careful!)' adds a cautionary tone. However, it does not explicitly state that deletion is irreversible or describe any side effects, so depth is limited.

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. 'Delete a DNS record' is immediately actionable, and '(careful!)' is a compact, useful warning that 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?

This is a simple one-parameter delete tool with no output schema, and the schema fully documents the only parameter including its source. The description plus schema is sufficient for an agent to invoke the tool correctly, though it could have explicitly mentioned irreversibility.

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 explains that subdomain_id is the DNS record ID from adm_dns_records. The tool description itself adds no parameter-level detail beyond the domain context, so it meets the baseline but does not exceed it.

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 ('Delete') and a clear resource ('DNS record'), so an agent immediately knows what the tool does. It is also easily distinguished from sibling tools such as adm_dns_add and adm_dns_records, which handle creation and listing rather than deletion.

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

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

The description gives no explicit guidance on when to use this tool versus alternatives, and it does not mention any prerequisites or exclusions. The 'careful!' warning implies cautious use, but there is no clear routing to or away from sibling tools.

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

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

There are no annotations, so the description carries the full burden of behavioral disclosure. It states that the tool lists records, but it does not disclose whether the operation is read-only, what the response shape is, whether pagination or filtering applies, or what happens if the domain does not 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?

One sentence, no filler, and the core action and object are front-loaded. Every word earns its place.

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

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

The tool is simple with one documented parameter, but the absence of any usage guidance, behavioral caveats, or return-format description leaves noticeable gaps. An agent can infer the basic operation from the schema and purpose, but the description alone is only minimally complete.

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

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

Schema description coverage is 100%, and the single parameter domain_id is documented with 'Domain ID (from adm_domains)'. The description itself adds no parameter-specific meaning, so the baseline score of 3 is appropriate since the schema already explains the parameter.

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

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

The description uses a specific verb ('List') with a clear resource ('all DNS records') and scope ('for a domain'). It is immediately distinguishable from write-oriented siblings like adm_dns_add and adm_dns_delete, and from domain-level tools like adm_domains.

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

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

No guidance is provided about when to use this tool versus alternatives, such as adm_dns_add or adm_dns_delete. The only usage signal is the verb 'List', but the description does not mention prerequisites, exclusions, or conditions that would route an agent to a sibling.

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 responsibility for behavioral disclosure. While 'Add a domain to NS servers' conveys the basic action, it does not disclose side effects, idempotency, prerequisites, whether the action is reversible, or what the response looks like. For a mutating DNS operation, this leaves meaningful behavioral ambiguity.

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

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

The description is a single, front-loaded sentence with no redundant words. It efficiently captures the action, target resource, and domain context, earning its place without padding.

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 (one required parameter, no output schema, no annotations), so the description plus schema cover the basic invocation. However, the definition lacks usage differentiation from similar tools and omits behavioral details such as side effects or response behavior. It is adequate but leaves clear gaps for an agent deciding between this and related DNS 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 coverage is 100%, and the single parameter domain_name is already documented as 'Domain name to add' in the schema. The description adds only the context that the domain is being added to NS servers, but does not provide extra format, validation, or usage detail beyond the schema. Baseline 3 is appropriate given the high schema coverage.

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

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

The description uses a specific verb ('Add') and resource ('a domain to NS servers'), with a clarifying parenthetical ('for DNS management') that distinguishes it from related tools like adm_dns_add (DNS records) and adm_mail_domains (mail domains). It clearly states what the tool does at a domain level rather than a record level.

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

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

The parenthetical 'for DNS management' implies the intended context, but the description does not explicitly state when to use this tool instead of alternatives such as adm_dns_add, adm_domain_check, or adm_domain_zones. There are no explicit exclusions or alternative routing statements, so the agent must infer usage from the tool name and siblings.

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

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

No annotations are provided, so the description must carry the burden of explaining behavior. It correctly indicates a non-destructive read-only check, but it does not disclose the expected response format, whether the result is a boolean, or any domain normalization/availability nuance. 'Check if available' is transparent enough for a simple query, but it could more explicitly state that it does not register the domain.

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, concise sentence with no wasted words. The core action and target outcome are front-loaded, and the description is appropriately minimal for this simple 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 input is fully specified, so invocation is clear. However, there is no output schema and the description does not explain what the agent should expect as a result (e.g., boolean, message, availability status). For a one-parameter check tool this is not a major omission, but it is a completeness 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% and the domain parameter already includes an explanatory description and example ('e.g.com.ua'). The tool description adds no additional meaning beyond what the schema provides, so the baseline score of 3 is appropriate.

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

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

The description states a specific verb ('Check') and resource ('domain name ... available for registration'), making the tool's purpose immediately clear. It also distinguishes it from sibling tools such as adm_domain_add and adm_domains, since it explicitly covers availability checking rather than listing or registering.

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 'available for registration' supplies clear context: use this tool to determine whether a domain can be registered, which also implies it is an alternative to adm_domain_add for the pre-check step. It does not explicitly list exclusions or alternative scenarios, but the intended use case is unambiguous.

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

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. The verb 'List' signals a read-only operation and 'all domains in your account' specifies the result scope. It does not disclose output format, pagination, or auth needs, but for a simple no-parameter list tool these are minor gaps.

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

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

The description is a single six-word sentence with no filler, and the core action is front-loaded. 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 no-parameter listing tool, 'List all domains in your account' is nearly complete and sufficient for an agent to invoke it correctly. It could be richer by explicitly stating that the response is a list of domains or mentioning pagination, but the tool's simplicity keeps this gap small.

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

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

The input schema has zero parameters, so the description has no parameter burden. Baseline 4 applies because the empty schema fully covers the parameter surface and no parameter-level 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 uses a specific verb ('List') with a clear resource and scope ('all domains in your account'). The word 'all' distinguishes it from sibling tools like adm_domain_check or adm_domain_zones, making the tool's purpose unambiguous.

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

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

The description clearly implies when to use the tool: when you need to enumerate all domains in the account. However, it provides no explicit guidance about when not to use it or which sibling tool to prefer for narrower domain operations, so usage context is only implied.

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

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

There are no annotations, so the description carries the burden. 'List' clearly signals a read-only operation and the description states what is returned (domain zones and prices). It does not disclose details like pricing currency, ordering, pagination, or authentication requirements, but for a zero-parameter list tool this is a reasonable level of 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 filler or repetition. Every word adds meaning: it names the action, the resource, and the relevant output 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 simple zero-parameter, no-output-schema tool, the description is largely complete: it tells the agent what the tool lists and what data is included. It could mention return format or the meaning of 'available', but the absence is a minor gap 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 description does not need to explain parameter semantics. The baseline of 4 applies, and the description adds value by clarifying that the output includes prices.

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

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

The description uses a specific verb ('List') and resource ('available domain zones') plus the scope of returned data ('with prices'). It is clearly distinguishable from siblings like adm_domains or adm_domain_check, so an agent can tell what this tool does without opening any schema.

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

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

The description implies the use case: call this when you need available domain zones and their prices. However, it provides no explicit guidance about when not to use it or how it compares to sibling tools such as adm_domains or adm_domain_check.

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 states the operation ('get ID') without mentioning read-only nature, possible errors, response format, or that behavior may vary by object type. This is insufficient for a tool with zero annotation support.

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

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

The description is a single, front-loaded sentence that efficiently conveys the operation and scope. The parenthetical '(utility)' adds minimal value and could be trimmed, but it does not harm comprehension.

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

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

For a simple two-parameter tool, the description is still incomplete. It does not specify what the tool returns (e.g., raw ID, object with ID), how the output should be used with sibling tools, or how type/name combinations map to valid objects. Since there is no output schema or annotations, the description should have covered these gaps.

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

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

Schema description coverage is 100%, with both parameters ('type' and 'name') having short descriptions. The main description merely restates the parameters ('by type and name') without adding new semantics or examples beyond the schema's 'e.g. domain, hosting'. Baseline 3 applies because the schema already documents the parameters.

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

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

The description clearly states a specific verb ('Get') and resource ('object ID') scoped by type and name. It is distinguishable from the sibling toolset, which focuses on domains, DNS, and mail operations rather than generic ID lookup. The term 'utility' is slightly vague but doesn't obscure the core purpose.

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

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

No guidance is provided on when this utility should be used versus alternatives, nor does it describe a typical workflow such as using the returned ID in other adm_* calls. The description leaves the agent to infer appropriate usage from the tool name and siblings.

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

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. 'Delete a mailbox (careful!)' hints at destructiveness but does not explain consequences such as irreversibility, cascading deletions, or impact on related mailbox data. It adds little beyond what the tool's name already implies.

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

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

The description is one short, front-loaded sentence with no wasted words. 'careful!' is a concise warning that reinforces the destructive nature of the operation. It is appropriately sized for a single-parameter 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 has a simple signature and a fully documented parameter, but the description omits key behavioral context for a destructive operation. Without annotations, an agent cannot tell whether deletion is permanent or has side effects. The phrase 'careful!' acknowledges risk but does not explain 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%, and the single parameter mail_box_id is already described as 'Mailbox ID (from adm_mailboxes)'. The tool description adds no extra parameter meaning, 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?

The description states a clear verb and resource: 'Delete a mailbox.' This distinguishes it from sibling tools like adm_dns_delete or adm_mailboxes, though it does not explicitly reference alternatives. The warning '(careful!)' does not add purpose clarity but does not harm 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?

No guidance is provided on when this tool should be used versus alternatives. There is no mention of prerequisites, conditions, or exclusions. The only contextual hint is 'careful!', which is a caution rather than concrete usage guidance.

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

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

With no annotations provided, the description carries the behavioral transparency burden. 'List' implies a read-only operation, which provides some transparency. However, it doesn't disclose details like pagination, result limits, or sorting behavior, which would be useful for an agent. The core behavior of listing is stated, but deeper behavioral context is missing.

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

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

The description is a single sentence with no wasted words. It is concise and front-loads the primary action of the tool. Every word contributes meaning.

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

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

For a simple list tool with one parameter, 100% schema coverage, and no output schema, the description is mostly adequate. The tool has no annotations, so the description could have added a bit more context about expected return format or any operational caveats. It's sufficient but not rich.

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

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

Schema description coverage is 100%, so the schema already documents the single parameter mail_id. The description itself doesn't add parameter meaning beyond the schema. Baseline 3 applies since the schema handles the documentation burden.

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

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

The description states a specific verb and resource: 'List all mailboxes/redirects for a mail domain'. It clearly identifies the output of the tool. However, it doesn't explicitly differentiate it from sibling tools beyond the domain-specific context, so it doesn't earn a 5.

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

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

The description implies the tool is used to retrieve mailboxes for a given domain. It provides the context of needing a mail_id from adm_mail_domains via the schema, but doesn't explicitly state when to use this tool versus alternatives or when not to use it. Usage is implied rather than explicit.

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

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

There are no annotations, so the description carries the behavioral disclosure burden. It does convey that this is a read-only listing operation scoped to the account's mail domains, which is useful, but it does not mention output format, pagination, or behavior when no domains 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 clear sentence with no filler or repetition. It states the action and scope immediately, making it easy for an agent to parse.

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

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

For a zero-parameter list tool, the description provides enough core context to select and invoke the tool: it identifies the resource type, scope, and action. The lack of an output schema and usage alternatives is a minor gap given the simplicity of the operation.

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

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

The input schema has zero parameters, so there are no parameter semantics for the description to clarify. The baseline for a zero-parameter tool is 4, and the description adds no unnecessary parameter-related detail.

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

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

The description states a specific verb and resource: 'List all mail domains on your account.' It is clear about what the tool does and the 'mail' qualifier hints at a distinction from the sibling adm_domains, though it does not explicitly contrast them.

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

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

No guidance is provided about when to use this tool versus alternatives such as adm_domains or adm_mailboxes. The description implies a listing use case, but it does not state conditions, prerequisites, or exclusions.

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