domani

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

Describes the full process (RDAP sourcing, anonymous outreach, negotiation) and risk of unreachable owners. Discloses commission-only, no upfront fee. With no annotations, this provides adequate behavioral 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?

Two clear sentences with key details, plus a note and scope requirement. No unnecessary words. Well structured, front-loaded with the 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?

Covers the acquisition process, risk, and required scope. Missing details on return value or success indicators, but no output schema exists. Adequate for a domain acquisition tool in a larger ecosystem.

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 clear descriptions for both 'domain' and 'max_budget'. Description adds context about the acquisition process but does not deepen parameter understanding beyond schema. 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?

Clearly states the tool acquires taken, unlisted domains via anonymous negotiation. Distinguishes from siblings like buy_domain (listed domains) and make_offer (listed domains). Includes specific process 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?

Explicitly indicates when to use (taken, unlisted domains) and includes a critical caveat about unreachable owners. Mentions required scope ('deals:write'). Could more directly contrast with alternatives but context from siblings clarifies.

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

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

No annotations are provided, so the description carries full burden. It states the tool publishes a record at the registry to enable DNSSEC, but does not disclose potential destructive behavior (e.g., overwriting existing DS records), required permissions, or side effects. For a mutation tool with no annotations, this is insufficient.

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

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

The description is two concise sentences. The first sentence states the core action and purpose, the second provides practical guidance. No superfluous 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?

Given 7 parameters (5 required), no output schema, and no annotations, the description is too brief. It does not explain return values, error conditions, or post-actions (e.g., verifying with get_dnssec). The agent lacks information needed for correct invocation.

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

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

Schema description coverage is 100%, with each parameter already well-described. The description adds context about sourcing DS values from the zone provider, but this does not significantly enhance parameter understanding beyond the schema.

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

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

The description clearly specifies the verb 'publish', the resource 'DNSSEC delegation-signer (DS) record', and the outcome 'enable DNSSEC'. It also mentions obtaining DS values from the zone provider, distinguishing it from related tools like delete_dnssec and get_dnssec.

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

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

The description provides a prerequisite ('Get the DS values from your zone provider after signing the zone') but lacks explicit guidance on when not to use the tool or comparisons with alternatives. The context signals a need for deeper usage context given the many 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 carries the full burden. It mentions the domain constraint and the API endpoint, which adds some behavioral context. However, it does not disclose what happens on duplicate alias attempts, whether the operation is idempotent, or what the response looks like upon success.

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 succinct, consisting of two sentences and an API endpoint reference. Every sentence adds value: the first states the action and benefit, the second provides usage guidance and a constraint. No superfluous wording.

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

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

For a simple create tool with all required parameters documented, the description provides necessary context for invocation. However, it lacks information about post-conditions (e.g., success response or error handling) and does not mention any prerequisites like mailbox existence, which would be helpful given no output schema.

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

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

The schema covers 100% of parameters with descriptions. The description adds limited semantic value beyond the schema, primarily reinforcing the same-domain constraint for the alias parameter. The baseline of 3 is appropriate as the schema already provides adequate meaning.

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

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

The description clearly states the tool adds an alias that delivers into an existing mailbox without using a mailbox slot, and provides a concrete use case (multiple public addresses landing in one inbox). This distinguishes it from creating a new mailbox and from other sibling tools like remove_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?

The description gives a specific use case and notes that the alias must be on the same domain as the mailbox, providing contextual guidance. However, it does not explicitly state when not to use this tool or compare it to alternatives such as creating another mailbox.

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. It explains rule matching, actions, priority, and first-match-wins behavior, but lacks details on limits, side effects, or confirmation of non-destructive nature.

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 concise—three sentences—with key information front-loaded and no redundant 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?

Given 9 parameters and no output schema, the description covers rule behavior, actions, matching, and priority well. Minor gaps: no mention of maximum rules or error conditions.

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%, but the description adds meaning beyond the schema, especially for action and action_arg (explaining 'forward' destination and 'label' value) and priority order, earning above baseline.

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 specifies a clear verb ('Add') and resource ('inbound filtering rule to a mailbox'), and details match fields and actions, distinguishing it from sibling tools like list_mail_rules and remove_mail_rule.

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

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

The description does not provide guidance on when to use this tool versus alternatives, nor does it mention exclusions or 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. It does not disclose behavioral traits such as idempotency, what happens if the address already exists, or authorization requirements. The API endpoint is mentioned but adds limited 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 extremely concise with two sentences, front-loading the main action. Every sentence provides essential information without waste.

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

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

For a simple tool with two parameters and no output schema, the description covers the purpose, use case, and API endpoint. It could benefit from a brief note about the response or potential errors, but it is largely complete.

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

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

The input schema has 100% coverage, so the baseline is 3. The description adds minimal value beyond the schema, merely restating that 'address' is the email to suppress and that 'reason' defaults to manual. It does not explain the enum values beyond what is in the schema.

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

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

The description clearly states the verb 'add' and resource 'address to your suppression list', and distinguishes between manual additions and automatic ones. However, it does not explicitly differentiate from sibling tools like list_suppressions or remove_suppression.

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 explains when to use this tool (for addresses you want to stop emailing) and notes that hard bounces and complaints are added automatically, providing context. It does not mention when not to use it or alternatives like remove_suppression.

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 indicates a read operation via 'browse' and 'returns', implying no side effects. It adds context about returning active listings with prices, which is sufficient for this simple 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?

Three sentences, front-loaded with purpose, then output, then sibling guidance. No fluff; every sentence adds 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?

Given three optional parameters and no output schema, the description is mostly complete: it states what it does, what it returns, and links to the purchase tool. Missing a note about sorting/filtering but those are in schema.

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

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

Schema coverage is 100%, so baseline is 3. The description does not add any additional meaning to the parameters (sort, order, max_price) 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 clearly states 'Browse domains for sale on the Domani marketplace' with specific verb and resource. It also mentions returns all active listings with prices, and distinguishes from the sibling buy_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 explicitly directs to buy_domain for purchase, providing clear context for when to use an alternative. However, it does not explicitly state when not to use this tool or other alternatives, leaving some ambiguity.

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

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

No annotations provided, so description carries full burden. It describes the purchase action and the USDC flow steps (402 -> pay -> retry with payment_tx), but does not detail what happens after purchase (e.g., domain transfer to account, confirmation of ownership). Also no mention of permissions or rate limits. Adequate but not comprehensive.

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

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

Four sentences, front-loaded with main purpose, then conditions, then alternative. Every sentence adds value. No fluff. Well-structured for quick parsing.

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?

No output schema, so description must explain return values. It does not mention what the tool returns (e.g., success status, transaction details, domain object). Also missing error handling or post-purchase state. For a transactional tool with 5 parameters, this is a significant 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 has 100% coverage with good descriptions. The description adds context for the USDC flow ('USDC works like buy_domain (402 -> pay -> retry with payment_tx)') which clarifies payment_tx usage, but mostly reiterates schema info. Baseline 3 is appropriate as 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 clearly states the tool's purpose: 'Buy a taken domain that's listed for sale on an aftermarket... at its buy-now price'. It uses specific verb 'buy' and resource 'aftermarket domain', and distinguishes from siblings like buy_domain and acquire_domain by referencing buyable vs make-offer and the native process.

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

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

Provides explicit when-to-use: 'Use when search shows a domain with for_sale.buyable = true'. Also gives user confirmation requirement, max_price cap usage, and alternative tool for make-offer listings: 'use acquire_domain (broker) to negotiate instead'. This is thorough and 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, description fully discloses behavior: accepts single or array, bulk card-only, USDC flow with 402 response, price ceiling mechanism, and user confirmation requirement. Covers error handling and retry logic.

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?

Description is slightly long but every sentence adds necessary operational detail. Front-loaded with purpose and confirmation instruction. Could be slightly more concise, but no redundancy.

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

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

Given 7 parameters, no output schema, and no annotations, the description provides complete workflow guidance including error handling, user interaction, and step-by-step payment instructions. Covers all essential aspects.

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?

Adds significant value beyond 100% schema coverage by explaining the USDC flow (payment_tx, payment_chain), max_price ceiling, and payment_method override context. Clarifies bulk constraint and user confirmation requirement.

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

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

Description clearly states 'Purchase one or more domains' with specific verb and resource. Distinguishes from sibling tools like acquire_domain or buy_aftermarket by focusing on new domain purchases and bulk constraints.

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

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

Explicitly instructs to 'Always confirm with the user before calling' and details the USDC two-step flow. Provides context on when to use card vs. USDC, but doesn't explicitly name alternative tools for similar actions.

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 behavioral traits. It reveals a key constraint (state requirement) but does not describe side effects, reversibility, or other behavioral aspects like whether cancellation triggers notifications or refunds.

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 consists of two short, focused sentences with no wasted words. It front-loads the main action and then adds the constraint 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?

Given the simplicity of the tool (1 parameter, no output schema), the description covers the core purpose and a key usage constraint. It is complete enough for effective use, though could mention expected outcome or error conditions.

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 'id' parameter is described). The tool description does not add additional meaning beyond what the schema already provides, meeting the baseline expectation.

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 ('cancelling a backorder') and the resource ('backorder'), with a specific verb 'Stop watching a domain'. This distinguishes it from siblings like 'create_backorder'.

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

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

It explicitly states the condition for use: 'Only backorders in the 'watching' state can be cancelled.' This provides clear when-to-use guidance, though it doesn't explicitly mention alternatives or when-not-to-use, the condition implies the limitation.

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, and the description only specifies the required scope. It does not disclose side effects, reversibility, or what happens if the request is not active.

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, with two sentences that convey the action and a key prerequisite. No wasted words.

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

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

Given the lack of output schema, the description omits what the tool returns (e.g., success/failure). It adequately covers the single parameter but lacks completeness for the return value.

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 describes the parameter (100% coverage). The tool description adds no additional meaning beyond stating the scope requirement.

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 (cancel) and the resource (active domain acquisition request). It does not explicitly distinguish from siblings like 'cancel_backorder', but the name and context make the purpose clear.

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

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

The description mentions a prerequisite (deals:write scope) but provides no guidance on when to use this tool versus alternatives such as 'cancel_backorder' or when not to use it.

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

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

Discloses key behavior: subscription ends at billing period end, reverts to free plan, and returns cancellation date. Covers the main effects without annotations.

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

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

Two efficient sentences with zero waste. Every word adds 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?

The description is complete for a zero-parameter, no-output-schema tool. It covers purpose, effect, and return value.

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?

No parameters exist (100% schema coverage), so there is nothing to add. 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 clearly states 'Cancel the user's Pro subscription' with a specific verb and resource. It distinguishes from sibling tools like cancel_backorder, which deal with 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?

Implies usage for canceling a Pro plan. No explicit when-not-to-use or alternatives, but the behavioral details (active until billing end) provide good context.

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

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

No annotations are provided, so the description carries the full burden. It discloses what DNS records are checked and that the provider is auto-detected. However, it does not describe the response format, whether the operation is read-only, or any prerequisites. For a simple check tool, the detail is adequate but not comprehensive.

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

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

The description is two sentences, front-loaded with the purpose. Every sentence adds unique value: the first lists the specific records checked, the second adds the auto-detection behavior. No wasted words.

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

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

Given the simplicity of the tool (single parameter, no output schema, no annotations), the description covers the main purpose and behavior. However, it does not describe the return format or any error conditions, which would be helpful for an agent to interpret the response. Still, it is fairly complete for a basic DNS check tool.

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

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

Schema coverage is 100% with one parameter (domain) described in the schema. The description adds extra context that the tool auto-detects the email provider from MX records, which adds meaning beyond the schema definition. 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 the tool checks email DNS health for a domain, listing specific records (MX, SPF, DMARC, DKIM) and mentions auto-detection of the email provider. This is a specific verb+resource that distinguishes it from siblings like dns_check or list_email_messages.

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

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

The description does not explicitly state when to use this tool versus alternatives, nor does it provide when-not-to-use guidance or mention sibling tools. The usage context is implied through the domain parameter and the mention of email DNS health, but no exclusions or alternatives 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?

No annotations provided, so description carries full burden. It discloses the 'no sending' and 'no quota' behavior, but does not elaborate on specific checks performed or other behavioral traits like idempotency.

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

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

Three concise sentences: purpose, usage guidance, API endpoint. No extraneous information, well-structured.

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

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

Tool has 8 parameters, no output schema. Description covers purpose and usage but does not describe the return type or structure. Agent would benefit from knowing what the tool returns.

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 baseline is 3. Description does not add any parameter-level details beyond what 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?

Clearly states it runs deliverability and abuse-safety checks identical to send_email without sending or consuming quota. Distinguishes from send_email sibling by specifying no sending/quota usage.

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

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

Explicitly advises use before authentication, payment, onboarding, or high-volume messages. This provides clear context for when 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 full burden. It discloses that the tool returns price, eligibility status, and blockers (unsupported TLD, ICANN waiting period, domain locked). It implies a read-only check. While not exhaustive (e.g., no mention of rate limits or auth), it is transparent enough for a simple check tool.

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

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

Two succinct sentences, front-loaded with the action. Every sentence adds value: first explains what it does, second gives usage guidance. Zero waste.

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

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

For a simple tool with one parameter and no output schema, the description sufficiently covers return values, blockers, and usage order relative to siblings. No gaps for this complexity level.

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% for the single parameter 'domain'. The description adds nothing beyond the schema's own description ('Domain to check, e.g. mysite.com'). 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 the tool's purpose: pre-check domain transfer eligibility. It identifies the specific verb 'pre-check' and resource 'domain transfer', and distinguishes itself from sibling 'transfer_domain' by indicating it should be called first.

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

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

Explicitly states 'Always call this before transfer_domain', providing clear guidance on when to use. Also mentions 'show the user the price', which implies its use in a user-facing flow.

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 full burden. It describes the return as detailed status with actionable hints, implying a read operation. It does not explicitly state side-effects, auth needs, or safety, but the verb 'check' suggests read-only.

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, first sentence front-loaded with core action, second sentence adds valuable output detail. No redundancy or filler.

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

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

Given one parameter, no output schema, and no annotations, the description covers purpose and output types. It lacks return structure details and error conditions, but remains mostly sufficient for a simple status check.

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% (domain parameter described). The description adds no extra parameter meaning beyond the schema, only output context. Baseline 3 applies.

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

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

The description clearly states it checks the status of an inbound domain transfer, distinguishing it from siblings like check_transfer_eligibility and transfer_domain. It specifies the resource (inbound domain transfer) and the action (check status).

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

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

The description implies usage for inbound transfer status checks by naming the resource and listing possible statuses, providing clear context. However, it does not explicitly exclude outbound transfers or mention alternatives, missing full when-not 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, so description carries burden. Discloses creation of a free identity with profile page, but omits details on permissions, rate limits, or whether it's reversible.

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

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

Two sentences with no waste. First sentence delivers core purpose immediately; second adds optional fields and upgrade path 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?

Simple creation tool with well-documented parameters. Absence of output schema is acceptable; return values are implied. Sufficient for agent to use correctly.

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

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

Schema coverage is 100%, baseline 3. Description merely lists optional fields (name/bio/emoji/email/links), adding no new semantic value beyond schema descriptions.

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

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

Clear verb 'claim' and resource 'free identity' with specific URL pattern. Distinguishes from sibling tools like 'acquire_domain' and 'buy_domain' by emphasizing free, instant nature.

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?

States when to use ('frictionless way to start') and upgrade path, but lacks explicit exclusions. Sibling differentiation implies alternative tools for domain purchases.

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

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

The description notes that emails to unmatched addresses will be dropped again, providing some behavioral context. However, with no annotations, it lacks details on whether the action is reversible, what permissions are needed, or if it's destructive. The API hint is helpful but insufficient for full 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 concise with two sentences and an API hint, front-loading the core action. Every sentence contributes 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?

Given the single parameter and lack of output schema, the description covers the main effect (emails dropped) and provides the API endpoint. It could be more complete by mentioning error cases or prerequisites, but it is adequate for a simple tool.

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

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

Schema coverage is 100% with the parameter 'domain' described as 'Domain to clear the catch-all on'. The description does not add extra meaning beyond the schema, meeting the baseline for high coverage without additional value.

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

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

The description clearly states the action ('Remove the catch-all on a domain') and the resource (catch-all on a domain), distinguishing it from sibling tools like set_catch_all. The verb 'remove' is specific and the context of email routing is clear.

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

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

The description implies usage when the user wants to stop emails for unmatched addresses, but it does not explicitly state when to use this tool versus alternatives like set_catch_all. No exclusion criteria or prerequisites are mentioned, leaving the agent to infer the appropriate context.

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

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

With no annotations, the description carries full responsibility for behavioral disclosure. It explains merge behavior (source wins collisions, keeps target's other records) and replace mode (exact mirror). It does not mention idempotency or rate limits, but for this tool the disclosed behavior is sufficient.

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

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

Two sentences with no redundant information. First sentence states core purpose and provides an example. Second sentence explains both modes concisely. Every word earns its place.

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

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

The description covers the tool's purpose, usage context, and parameter semantics. It does not describe the response format or error handling, but given the simplicity (3 parameters, no output schema), the provided information is largely sufficient for an agent to use the tool correctly.

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

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

Schema coverage is 100%, with each parameter already described. The description adds value by clarifying that domains 'must be yours' and explaining the replace parameter in context ('exact mirror - drop target records the source doesn't have').

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 'Copy the DNS setup of one domain you own onto another' with a helpful example (brand.com → brand.dev). It differentiates from sibling tools like set_dns and snapshot_dns by specifying the cloning action and two modes (merge vs exact mirror).

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

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

The description explicitly indicates when to use (clone DNS between domains) and describes the two available modes (merge and replace). It provides clear context but could be improved by explicitly stating when not to use (e.g., for single record changes).

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 provided, so the description carries the full burden. It discloses auto-detection, automatic DNS setup for platform domains, manual setup for imported domains, and MX replacement error handling. It also mentions response includes next_steps. A 5 would require additional details on permissions or idempotency.

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

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

The description is a single paragraph but is well-structured: starts with purpose, then details on auto-detection, scenarios, error handling, and response. It is front-loaded and efficient, though slightly dense.

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 6 parameters, 1 required, and no output schema, the description explains two key use cases, error scenario, and parameter roles. It mentions response content (next_steps) but could elaborate on return format. Overall, it provides sufficient context for an agent to select and invoke the tool correctly.

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

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

Schema coverage is 100%, so all 6 parameters are described in the schema. The description adds context: it explains the role of dry_run and confirm_replace_mx in the MX replacement scenario and lists supported providers, going beyond the schema descriptions.

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

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

The description clearly states the verb+resource: 'Connect a domain to a hosting or email provider.' It distinguishes between auto-detection and explicit provider, and differentiates from siblings like set_dns or import_domain by focusing on the connection process and provider-specific behavior.

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

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

The description provides explicit when-to-use guidance: for connecting domains to hosting/email providers. It explains two distinct scenarios (bought through platform vs imported) and how to handle MX replacement with dry_run and confirm_replace_mx, giving clear context and exclusions.

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

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

With no annotations, the description discloses important behaviors: polling frequency (every few minutes), payment only on success (no upfront fee), best-effort nature, and requirement for payment method. It does not address limits or timeout behavior, but overall this is sufficient.

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

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

The description is three sentences, each adding value: action, monitoring detail, payment terms, and a caution. No wasted words, and the most critical information (placing a backorder) 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?

Given the complexity (3 parameters, no output schema), the description covers the overall process, risks, and requirements. It explains how the tool works and what to expect. Could add a note about monitoring via list_backorders, but not essential.

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 100% coverage with descriptions for all three parameters (domain, max_price, payment_method). The description adds contextual meaning but does not significantly surpass the schema's explanation. According to the rubric, 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 the tool's purpose: placing a backorder on a domain registered to someone else. It uses specific verbs ('Place a backorder', 'watch', 'automatically register') and distinguishes itself from sibling tools like buy_domain (for available domains) and cancel_backorder.

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 context on when to use (domain taken), prerequisites (card on file or payment method 'balance'), and a caveat about best-effort and specialized drop-catchers. It lacks explicit 'when not to use' guidance but adequately covers key usage 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?

Discloses the provisioning process, DNS publishing, and return data (DNS records, client settings, app password). With no annotations, the description carries the full burden. Lacks details on error handling, idempotency, or side effects like overwriting existing mailboxes.

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

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

Three well-structured sentences: first explains what it does and when to use it, second details outcomes, third gives prerequisites and API. No wasted words, front-loaded 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?

Given no output schema and moderate complexity, the description provides sufficient context: what is created, what is returned, and a prerequisite. Could be enhanced with behavior on duplicate slugs or domain not found, but overall adequate.

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 baseline is 3. The description adds context by explaining that slug is the local part and that the tool returns settings, but doesn't add 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?

Clearly states the tool creates a real IMAP/SMTP mailbox on a domain you own, differentiating it from an 'API mailbox' (likely sibling create_mailbox). Specifies the resource and verb, and gives usage context (connect any mail client).

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

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

Explicitly contrasts with 'API mailbox', guiding when to use this tool. Mentions prerequisite ('Requires a domain in your account'). Could be more explicit about alternatives, but the 'instead of' comparison effectively distinguishes it from create_mailbox.

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 full burden. It discloses DNS auto-configuration for custom domains, manual setup for imported domains, account limits, and force override. While it doesn't cover idempotency or all error cases, it provides solid transparency about the creation 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 concise (a single paragraph) and front-loaded with the main action. It contains multiple pieces of information without being overly verbose. Could be improved with bullet points, but it's efficient.

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

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

Given the complexity (4 params, no output schema, no annotations), the description covers core functionality, domain variations, and limits. However, it lacks details on return values, error handling, or validation scenarios, leaving some gaps for a complete understanding.

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

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

Schema coverage is 100% with descriptions. The description adds significant value by explaining domain type scenarios, limits, and the effect of force=true, which goes beyond the schema's property descriptions.

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

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

The description clearly states 'Create an email address' and specifies the key parameters (slug, domain) and variations for different domain types (custom, imported, domani.run). It distinguishes this creation tool from sibling tools like setup_domain_email or list_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?

Provides explicit guidance on when to use each parameter (slug required, domain optional), conditions for custom vs imported vs domani.run domains, account limits (max 5, 1 free), and force override. Does not explicitly mention alternatives, but context is clear.

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

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

With no annotations, the description carries the full burden. It discloses that the secret is returned only once, which is essential behavioral info. It also mentions the API endpoint but does not cover permissions or exact response structure. However, the key behavioral trait is communicated effectively.

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 with two sentences and an API line. It front-loads the purpose, includes a critical warning, and references the API. No unnecessary information is present.

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 output schema, the description explains that the secret is returned once, which is the most important output. It does not describe the full response structure, but for a credential creation tool, this is sufficient. It is fairly complete for the tool's 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 has 100% description coverage, so the baseline is 3. The description adds a helpful example for the label parameter ('e.g. 'Laptop Mail''), but overall does not provide significant additional 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 clearly states the tool creates an app password for a hosted mailbox, differentiating it from sibling tools like list_mailbox_credentials and revoke_mailbox_credential. It provides a specific verb and resource, and mentions the API endpoint.

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 context on when to use this tool (to get a password for a mail client) and provides a critical usage tip that the secret is returned once and must be stored. It does not explicitly exclude alternatives, but the purpose is clear enough to guide selection among siblings.

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

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

No annotations are provided, so the description carries full burden. It discloses key behavioral traits: one-time key return, scope attenuation (token cannot grant scopes it doesn't have), spend cap enforcement with error code, and detailed scope definitions. This is highly transparent and exceeds 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 description is quite long (over 30 lines) due to the exhaustive scope list. While the detail is justified for clarity, it could be more concise by separating scope definitions into a table or reference. The key points are front-loaded, but overall verbosity reduces conciseness.

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?

No output schema exists, so the description must cover return behavior. It mentions 'full key is returned only once', which is critical. Combined with thorough scope and parameter descriptions, the tool is well-covered for its complexity. Minor gap: does not explicitly state the response format or error structure, but acceptable given the focus on token creation.

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 baseline is 3. The description adds significant meaning: explains each scope line-by-line, clarifies that scopes default to parent's, defines spend cap behavior with error code (SPEND_CAP_EXCEEDED), and gives examples for sub-agent tokens. This adds 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?

The description starts with 'Create a new API token' which is a specific verb+resource. It adds 'with optional scoped permissions and spend caps' to clarify purpose. This clearly distinguishes from sibling tools like revoke_token (delete) and list_tokens (read).

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 critical usage guidance: 'The full key is returned only once - save it immediately', explains scope attenuation, and warns about setting spend caps for sub-agents that can buy. It does not explicitly list when not to use or alternatives, but the context is strong enough for an agent to decide when to invoke.

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. It discloses HTTPS requirement, one-time secret return, and HMAC-SHA256 verification. This is good coverage, though it could mention potential error cases (e.g., invalid URL, duplicate subscription) or rate limits.

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

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

Three concise sentences, each adding essential information. Front-loaded with purpose, followed by constraints and important post-creation note. No wasted words.

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

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

Given no output schema, the description adequately covers return behavior (secret once), verification method, and event selection. It is complete for a webhook creation tool, though it could mention success confirmation or error handling briefly.

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%, but the description adds significant value: HTTPS requirement for 'url', example event types and a hint to use 'list_webhook_events', and post-creation behavior (secret handling). This goes well beyond the schema's minimal descriptions.

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

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

The description clearly states 'Register a new webhook endpoint' identifying the specific verb and resource. It distinguishes from sibling tools like 'list_webhooks', 'delete_webhook', and 'update_webhook' by emphasizing creation. Examples of event types further clarify 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?

Provides clear guidelines: URL must use HTTPS, events must be chosen, and the secret is returned only once. However, it does not explicitly contrast with alternatives like 'update_webhook' or 'list_webhooks', nor does it specify 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?

No annotations are provided, and the description only mentions that removing all DS records disables DNSSEC. It does not disclose other traits like destructive nature, reversibility, or authorization requirements.

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

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

Two concise sentences, front-loaded with the key action, no unnecessary words.

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

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

For a simple destructive tool, the description provides the basic function and a consequence. However, it lacks details on reversibility or required permissions, leaving it moderately complete.

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

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

Schema coverage is 100%, with each parameter described. The description reinforces the keyTag purpose but adds no new 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 clearly states the tool removes a DNSSEC DS record by key tag, which is a specific verb-resource pair. It distinguishes itself from the sibling 'add_dnssec' 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 description provides no explicit guidance on when to use this tool versus alternatives (e.g., add_dnssec), nor does it mention 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?

No annotations are provided, so the description carries full burden. It discloses the destructive nature (deletes mailbox and all messages/attachments), the requirement for confirm=true, and the preview behavior. This adds significant behavioral context beyond the basic 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?

Three concise sentences: core action, requirement, preview instruction, and API endpoint. Every sentence is necessary and front-loaded. No redundant information.

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

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

The description covers the essential aspects: what is deleted (mailbox, messages, attachments), how to safely delete (preview first), and the required parameter. It could mention that deletion is permanent, but overall it is complete for a simple destructive tool with no output schema.

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

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

Schema description coverage is 100%, so baseline is 3. The description adds meaning by explaining the dual role of confirm (preview vs. actual delete) and emphasizing the requirement. It also connects the slug/domain to the mailbox address via the API endpoint.

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 'Delete a mailbox and all its messages (including attachments).' It uses a specific verb and resource, and differentiates from siblings like delete_message (single message) and delete_messages (multiple messages).

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 guidance: 'Requires confirm=true. Call without confirm first to see what will be deleted.' It instructs on how to safely use the tool via a preview pattern. However, it does not explicitly contrast with sibling tools like delete_message or delete_messages.

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 provided, so description carries full burden. It discloses key trait (reversible) and API endpoint, but lacks details on permissions, error states, or behavior for already-trashed messages. Adequate but not thorough.

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

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

Two concise sentences plus API endpoint. Front-loaded with the primary action. No unnecessary words.

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

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

For a simple deletion tool, the description covers the core purpose, reversibility, and endpoint. No output schema needed; completeness is adequate given low complexity.

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

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

Schema coverage is 100%, with all three parameters described in the schema. The description adds no extra meaning beyond what the schema provides, so 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?

Description clearly states action ('Move an email message to Trash') and resource ('email message'). It distinguishes from sibling 'update_email_messages' by noting reversibility.

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

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

Explicitly states that the action is reversible using 'update_email_messages action=restore', guiding the agent on when to use this tool vs. alternatives.

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

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

Discloses that messages are moved to Trash (not permanently deleted) and are reversible. With no annotations, this is valuable context. It does not mention potential side effects like impact on threads or permissions, but is sufficient for a delete-to-trash 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?

Two sentences with no wasted words. First sentence states purpose, second adds key behavioral trait (reversibility) and API endpoint. 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 tool with 3 parameters and no output schema, the description covers what it does, reversibility, and endpoint. Minor gap: no mention of return value or effect on attachments, but adequate for typical 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?

All three parameters have descriptions in the schema (slug, domain, message_ids). The description does not add extra meaning beyond schema, so 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?

Description uses specific verb 'Move multiple messages to Trash' and identifies the resource (multiple messages). It clearly distinguishes from sibling 'delete_message' (singular) and hints at reversibility, differentiating from permanent deletion 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?

Explicitly states the action is reversible via 'update_email_messages action=restore', providing an alternative for restoration. However, it does not explicitly contrast with the singular 'delete_message' or specify when not to use this tool (e.g., for permanent deletion).

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

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

With no annotations provided, the description fully discloses important behavioral traits: the action is irreversible and pending deliveries are cancelled. This goes beyond what the schema provides.

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, impactful sentences. The purpose is front-loaded, and every word adds value. No extraneous information.

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

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

For a simple delete tool with one parameter and no output schema, the description adequately covers the action, consequences, and irreversibility. Nothing essential 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 schema has 100% coverage with a clear description of the webhook_id parameter. The tool description adds no additional meaning to the parameter beyond what the 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 clearly states 'Delete a webhook endpoint' using a specific verb and resource. It distinguishes itself from sibling tools like create_webhook, update_webhook, and list_webhooks.

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?

While it warns about the irreversible action and pending deliveries being cancelled, it does not explicitly guide when to use versus alternatives like update_webhook. The consequences are clear, but usage context could be stronger.

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. It discloses the tool is DNS-based, returns 'taken' (definitely registered) and 'candidates' (potentially available), and notes it has no pricing. It implies a read-only, non-destructive operation, but does not explicitly state it is read-only. A minor gap prevents a perfect score.

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

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

The description is concise, front-loading the core purpose in the first sentence. Every sentence provides necessary information without redundancy, making it easy to scan.

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

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

For a simple check tool with no output schema, the description is complete. It explains the return fields ('taken' and 'candidates'), the default behavior (basic preset), and when to use the extended preset. It appropriately references sibling tools for pricing and alternative use 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 coverage is 100%, so baseline is 3. The description adds value by explaining the 'extended' preset checks '30+ creative/exotic TLDs' and that the basic preset defaults when no TLDs are provided. It also reiterates that the 'name' parameter should be without TLD, reinforcing the schema.

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

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

The description clearly states the tool performs a fast DNS-based domain existence check across multiple TLDs. It distinguishes itself from sibling tools like 'search' by being faster and not providing pricing, and explicitly positions itself as a preliminary step before using search for pricing.

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

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

The description provides explicit guidance on when to use this tool: 'Use this to narrow down before calling search for pricing.' It also advises on using the 'extended' preset when basic TLDs are taken, giving clear context for choosing between presets.

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 provided, so description carries full burden. It discloses what is checked but not behavioral traits like permissions, speed, error handling, or non-destructive nature. Implies read-only but not explicit.

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?

Single sentence, front-loaded with action verb, no wasted words. Efficient and 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?

Given the tool's simplicity (1 param, no output schema), the description covers the core purpose and specifics. Could be enhanced by mentioning output format or caveats, but overall adequate.

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 describes parameter simply as 'Domain to check status for'. Description adds value by listing what aspects are checked (DNS, SSL, email, expiry), providing meaningful context beyond the schema.

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

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

The description clearly states the verb 'Check' and the resource 'domain health', listing specific aspects (DNS, SSL, email, expiry). This distinguishes it from siblings like dns_check or whois_lookup.

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

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

No explicit guidance on when to use this comprehensive check versus individual sibling tools like dns_check or check_email. The description does not mention 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?

With no annotations, the description carries full burden. It discloses that the tool creates an escrow deal, starts transfer, supports multiple payment methods, requires a specific scope, and has a custom error for budget exceeds. It does not mention destructiveness or rate limits, but the behavior is well-covered.

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?

Extremely concise: two sentences. Front-loaded with the main action. Every sentence adds critical information without redundancy. Ideal structure for quick agent parsing.

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 3 parameters and no output schema, the description covers the main action, prerequisites, error handling, and payment methods. It lacks mention of return values or post-conditions, but is sufficient given the tool's straightforward nature.

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 has 67% description coverage; the description adds meaning by clarifying payment methods (card, USDC, x402) though schema uses 'balance' instead of 'x402' — a minor inconsistency. It explains confirm_over_budget's purpose in context of budget exceeded, adding value beyond schema.

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

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

The description clearly states the tool's purpose: 'As the buyer, pay the agreed price to create the escrow deal and start the transfer.' It specifies the verb (pay/finalize), resource (negotiation), and outcome (escrow deal), distinguishing it from siblings like make_offer or buy_domain.

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

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

The description provides explicit context: payment methods align with purchases, requires 'domains:transfer' scope, and explains the BUDGET_EXCEEDED error and how to handle it with confirm_over_budget. It does not explicitly list alternative tools but implies use only after a negotiation is agreed.

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 provided, so description carries full burden. Describes the core behavior (forward, include context, auto-prefix subject, optional note) and gives API endpoint. Missing potential side effects like marking as read or permission requirements, but sufficient for basic understanding.

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 plus API line. Front-loaded with purpose, then details. No redundant information, every sentence adds 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?

No output schema, so description should explain return values. Does not mention what the response indicates (success/error). With many sibling tools, lacking output feedback makes it incomplete for an agent to understand the result of the action.

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%, baseline 3. Description adds minor value: clarifies 'text' is an optional prepended note, and states subject auto-prefixing (not in schema). Does not elaborate on other parameters beyond 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?

Clearly states the verb 'forward', the resource 'email message', and specifies key behavior: includes original context, optional note, auto-prefixed subject. Distinguishes from siblings like 'send_email' and 'reply_to_message' by mentioning auto-prefixing and inclusion of original message.

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?

Implies usage for forwarding emails but does not explicitly state when to use this tool versus alternatives (e.g., reply_to_message). No exclusions or prerequisites mentioned.

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 full burden. It lists return fields and a prerequisite but fails to disclose whether the operation has side effects, requires authentication, or is read-only. The safety profile is unclear.

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, no filler. First sentence lists return fields, second provides a conditional usage note. Efficient and 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?

Adequate for a simple read tool with no parameters. Lists several return fields but omits details like possible values of payment status or format of contact info. No output schema, so more could be said about response structure.

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?

No parameters exist (0 params, 100% schema coverage). Description adds value by detailing what the tool returns, exceeding the schema which only defines type object with no properties.

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

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

Description clearly states it retrieves account details, listing specific fields (payment status, contact info status, referral code). The verb 'get' and resource 'account' are specific and distinguishable from sibling tools.

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

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

Provides a clear condition: 'Contact info must be set before purchasing domains.' This hints at a prerequisite but doesn't explicitly say when to use this tool vs alternatives like other getter tools. Implicitly it's the tool for account-level data.

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

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

Discloses the automatic unlock side effect, which is critical for agents to know; lacks other potential side effects but the primary behavioral trait is covered.

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?

Efficient, no wasted words, key info upfront.

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?

Covers main purpose and side effect but lacks details on return format and error behavior; acceptable for simple tool.

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

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

Schema fully describes the parameter; description adds no further semantic 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?

Clearly states the tool retrieves the EPP/auth code for domain transfer, distinguishes from transfer and eligibility checks by specifying the action and output.

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?

Specifies the purpose and next step (give to new registrar), but does not explicitly state when not to use or compare to alternatives like transfer_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, the description discloses key behaviors: it returns anonymized state, never exposes buyer identity or budget, and lists return fields. It implies a read operation and non-destructive behavior. Lacks specifics on idempotency or rate limits, but is transparent enough for safe invocation.

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: first establishes purpose and behavior, second lists returns and constraints. No redundant phrases, every part earns its place.

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

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

For a simple tool with one parameter and no output schema, the description adequately covers purpose, input, output fields, and privacy constraints. It tells the agent exactly what to expect and what not to expect.

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

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

The description adds context that the token is used 'before acting' and implies it's from the inquiry email. However, the schema already describes 'token' as 'The outreach token from your inquiry email', so the description mostly reinforces rather than adds new meaning.

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

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

The description clearly states the tool polls the anonymized state of a broker inquiry, listing specific outputs (domain, offer, whose move, actions) and what is not exposed (identity, budget). This distinguishes it from siblings like 'respond_to_broker_inquiry' and 'list_broker_requests'.

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 'before acting' implies it should be used prior to other actions like responding. It also specifies it's for the owner-agent read path with their token, providing clear context for usage. No explicit exclusions are given, but the guidance is sufficient.

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 carries full burden. It discloses role-aware behavior (buyer vs seller) and scope requirement, which is good. Missing details on errors or rate limits but acceptable for a simple read tool.

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

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

Two sentences, compact and efficient. First sentence states purpose and key behavior, second adds scope. No wasted words.

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

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

Given no output schema, the description explains what each role sees, which is helpful. Scope requirement covered. Lacks error/edge cases but sufficient for a single-record retrieval.

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

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

The description does not add meaning beyond the schema's description of 'deal_id'. With 100% schema coverage, baseline is 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 clearly states the verb "Get" and the resource "role-aware receipt/statement for a marketplace deal". It specifies buyer vs seller differences, distinguishing it from sibling tools like list_invoices.

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 mentions it works for every payment method and requires the deals:read scope, providing clear context. However, it does not explicitly state when to use this tool over alternatives like list_invoices.

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 provided, so description carries full burden. It discloses return format (stable id, zone_version token) and a behavioral insight (using token with set_dns for conflict detection). This adds significant value beyond schema.

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

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

Two sentences: first states core purpose, second adds critical behavioral context. No filler, efficient and front-loaded.

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

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

For a simple read tool with one param and no output schema, description covers purpose, return artifact details, and a cross-tool hint. Minor gap: does not explain what records contain beyond ids, but acceptable.

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

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

Schema description coverage is 100%. Description restates that domain must be owned, which is already implied by schema. Adds no new semantic detail beyond the schema.

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

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

Description uses specific verb 'Get' and resource 'DNS records' with condition 'for a domain you own'. Clearly distinguishes from siblings like set_dns (modify), clone_dns (copy), etc.

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

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

No explicit when-to-use or when-not-to-use guidance. With many sibling tools (e.g., get_dnssec, dns_check), lacks context on when to choose this tool over alternatives.

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

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

No annotations are provided, so the description carries the full burden. It states the tool lists records and enable status, implying a read-only operation. However, it lacks explicit statements about side effects, authentication requirements (beyond ownership), or return format details. 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 sentences, zero wasted words. Action verb front-loaded. Every sentence adds value: first states purpose and scope, second gives a usage pairing tip.

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 (one simple parameter, no output schema), the description is reasonably complete. It covers what the tool returns (DS records and enable status) and ownership requirement. Minor omissions: no mention of potential multiple records or any limits, but adequate for a straightforward check tool.

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

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

The schema has 100% coverage for the single parameter 'domain' (described as 'Domain name to inspect'). The description adds no additional meaning 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 uses the specific verb 'List' and specifies the resource 'DNSSEC delegation-signer (DS) records' and 'whether DNSSEC is enabled'. It clearly distinguishes from sibling tools like add_dnssec (adds DNSSEC) and delete_dnssec (removes DNSSEC), and from get_dns (general DNS records). The ownership condition is also stated.

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

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

The description provides clear context: use this tool for a domain you own to list DS records and DNSSEC status. It suggests pairing with TLSA records via set_dns for DANE, offering a usage hint. However, it does not explicitly contrast with alternatives or state when not to use it.

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

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

No annotations are provided, so the description carries the full burden. It indicates a read-only check with no side effects. However, it does not explain what 'record status' means in detail, nor does it mention any potential caching or delay. For a simple check, this is adequate but not thorough.

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 of 20 words, front-loaded with the action 'Check'. Every word contributes to the purpose. No redundancy or filler. Ideal for quick parsing by an AI agent.

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

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

For a simple one-parameter tool without an output schema, the description provides the key return values (record status and mailbox count). However, it does not specify the format or meaning of these fields, which could lead to confusion. More detail on the return structure would improve completeness.

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

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

Schema description coverage is 100% for the single parameter 'domain', which is described as 'Domain to check email status for'. The tool description adds context about the purpose of the check (email enabled, DNS verified) but does not add extra semantic meaning beyond the schema. Baseline 3 is appropriate.

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

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

The description clearly states the tool checks email enablement and DNS verification on a domain, and returns record status and mailbox count. This is specific and matches the name. However, it does not explicitly differentiate from siblings like 'check_email' or 'domain_status', so it loses one point for lack of differentiation.

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

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

The description implies usage context (checking email status for a domain), but provides no guidance on when to use this tool versus alternatives (e.g., 'get_domain_info' or 'dns_check'). There are no exclusions or when-not conditions. The purpose is clear, but an agent would benefit from more explicit usage boundaries.

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

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

No annotations are provided, so the description carries the full burden. It describes the action and typical returned fields, but does not disclose authorization requirements beyond ownership, error handling, or rate limits. For a simple read operation, this is adequate but not comprehensive.

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

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

Single sentence, front-loaded with the core purpose, and no redundant words. Highly efficient.

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

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

For a tool with one parameter and no output schema, the description is fairly complete, listing the types of information returned. It could mention that it is a read-only operation, but overall it provides sufficient 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 coverage is 100% with the 'domain' parameter described. The description adds no additional semantics for the parameter beyond the schema; it only lists output fields. 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 uses specific verb 'get detailed information' and resource 'domain you own', and lists specific attributes (auto-renew, security lock, WHOIS privacy, provider data). It clearly distinguishes from sibling tools like 'domain_status' or 'get_dns'.

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 implicitly limits usage to domains the user owns ('domain you own'), but does not explicitly state when to use this tool vs. alternatives like 'domain_status' or 'get_dns'. No exclusions or alternative recommendations 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?

With no annotations provided, the description carries the full burden. It discloses that data is cached for 7 days, which is helpful. However, it does not mention failure modes for invalid domains, authentication requirements, or rate limits. Given the simplicity, a 3 is appropriate.

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

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

Two sentences, front-loaded with the action and resource. Every sentence adds value: the first defines the tool, the second gives a use case and caching detail. No wasted words.

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

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

Given the low complexity (1 param, no output schema, no annotations), the description covers the essential aspects: what it does, why it's useful, and a key behavior (caching). It could optionally describe the return value format but is sufficiently complete for a simple preview 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 covers 100% of parameters, so the baseline is 3. The description adds an example 'e.g. google.com' which is minor but helpful. No further parameter details are 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 explicitly states the verb 'get', the resource 'website preview metadata', and lists specific fields (title, description, image, favicon). It clearly distinguishes from sibling tools like 'get_domain_info' or 'dns_check' by focusing on preview metadata for taken domains.

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

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

The description provides a clear use case: 'useful for understanding what a taken domain is currently used for'. While it does not explicitly state when not to use or name alternatives, the context implies it's for quick previews rather than detailed domain info, which is adequate.

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?

Describes the scope (owner-scoped) and warns that readiness score is not inbox probability. No annotations provided, so description carries full burden and does well.

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 plus API line, no redundancy. Front-loaded with verb and resource.

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?

No output schema, but description adequately lists return components. Additional details like response format would improve, but sufficient for a simple tool.

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

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

Schema coverage 100% with domain description. Description adds context about owner-scoped and API path, but not much parameter-specific meaning beyond 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?

Description clearly states it gets an owner-scoped email health report for a domain, listing specific components. Distinguishes from siblings by focusing on comprehensive health, not just DNS or status.

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

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

No explicit when-to-use or alternatives mentioned. Purpose is clear, but agent must infer usage from sibling tool names like check_email_deliverability.

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 convey behavioral traits. It states it's a GET API call, implying read-only, but does not explicitly confirm non-destructiveness or specify what the response contains beyond 'IMAP/SMTP settings'. This is adequate but not thorough.

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 long, front-loads the main purpose, and includes essential usage details without redundancy. Every sentence serves a clear purpose.

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

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

The tool is simple (no output schema, no nested objects), and the description covers the core purpose and credential info. However, it lacks detail on the response format or what specific IMAP/SMTP settings are returned, which would aid agent understanding.

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

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

Schema coverage is 100%, with both parameters having basic descriptions (slug, domain). The description adds the API path context (GET /api/emails/{address}/client-settings) but does not provide additional semantic depth beyond schema. 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 it gets IMAP/SMTP settings for a hosted mailbox, with specific use cases (Apple Mail, Thunderbird) and the API endpoint. It distinguishes from sibling tools like create_hosted_mailbox or list_mailboxes by focusing on client configuration.

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 tells when to use the tool (to configure a mail client) and provides practical guidance on credentials (username is full address, password is app password). However, it does not explicitly mention when not to use it or list alternative 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 provided, so description carries full burden. Mentions it is a GET request and describes return data, but doesn't explicitly confirm it is read-only or discuss side effects, rate limits, or auth requirements.

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

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

Two sentences; first delivers purpose and output, second adds API path. Economical and front-loaded, though the API path may be unnecessary for an AI agent.

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

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

Given no output schema, the description adequately lists what the tool returns. For a single-resource retrieval with 3 parameters, it covers key aspects like message ID and included data. Minor gap: no mention of pagination or limits, but unlikely needed.

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 basic descriptions. The tool description adds no extra meaning beyond the schema, only contextualizing that the 'message_id' identifies the message. Meets baseline for high 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?

Clearly states the tool retrieves a single message by ID and lists the included data (content, headers, delivery events, attachment URLs). Distinguishable from sibling tools like list_email_messages or delete_message.

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?

Implies usage when full message details are needed, but no explicit guidance on when not to use or comparison with alternatives like list_email_messages for metadata-only 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?

No annotations provided, so description carries full burden. Discloses that empty result leads to DNS operation failure, a useful behavioral insight. Assumes read-only, no side effects mentioned.

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, no redundant words. Front-loaded with action and resource. Efficient and clear.

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

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

Given simple tool (one param, no output schema, no annotations), description covers purpose and behavioral consequence. Lacks output format details but adequate for agent understanding.

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

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

Schema coverage is 100% for the single parameter 'domain' with its own description. The tool description adds no additional parameter meaning beyond 'domain you own', which is consistent but not extra.

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?

Clearly states the verb 'Get' and resource 'authoritative nameservers for a domain you own'. Adds context that empty result causes DNS operation failure, distinguishing it from sibling tools like set_nameservers or dns_check.

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?

Implies usage when checking nameservers for owned domain, but lacks explicit when-to-use vs alternatives or when-not-to-use. No comparison with siblings like dns_check or domain_status.

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

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

With no annotations, the description carries the full burden. It details the specific analytics returned (page views, inquiries, conversion rate, 30-day daily breakdown, 5 recent inquiries). This is transparent about output, though it does not explicitly state it is read-only or address potential limitations.

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: the first lists outputs, the second states the use case. Every word adds value; no filler or redundancy.

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

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

Given the tool's low complexity (single required param, no output schema), the description is mostly complete. It covers the key outputs and use case. It could hint that the domain must be parked, but that is implied by the tool name and 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?

The input schema has 100% coverage with a clear description for the 'domain' parameter. The tool description provides no additional parameter-level detail beyond the schema, so 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 uses a specific verb ('Get') and resource ('parking analytics'), lists concrete outputs (page views, inquiries, conversion rate, etc.), and clearly distinguishes from sibling tools like 'get_domain_info' which likely return different data.

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

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

The description explicitly states when to use the tool: 'Use this to check how much traffic a parked domain gets and whether it's converting.' It does not mention when not to use or alternatives, but the context is clear among many 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 carries the full burden of behavioral disclosure. It only says 'Check the status' without clarifying idempotence, rate limits, or error scenarios. A more informative description would add value beyond the schema.

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

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

The description is two sentences long with no unnecessary words. It is well-structured and front-loaded with the core purpose, earning its place 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?

The description covers the basic purpose and usage context for a simple one-parameter tool without an output schema. However, it lacks information about possible statuses or error conditions, leaving some gaps in completeness.

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

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

The schema has 100% coverage with the 'domain' parameter described. The description adds no additional meaning beyond what the schema already 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 uses a specific verb ('Check') and resource ('status of an outbound domain transfer'). It clearly distinguishes from sibling tools like 'check_transfer_status' and 'get_auth_code' by specifying the outbound direction and the required preceding steps.

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

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

The description explicitly states when to use the tool: 'after getting an auth code and initiating the transfer at the new registrar.' This provides clear context, though it does not mention any exclusions or alternatives.

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

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

No annotations provided, so description carries full burden. Discloses that it returns a TXT record for ownership verification, a key behavioral detail. Could mention if any side effects, but this is sufficient for a non-destructive import.

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 are highly concise, front-loaded with purpose, and every sentence adds 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 simple tool with one parameter and no output schema, the description covers the core functionality, cost, and verification step. Complete and adequate.

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?

Single parameter 'domain' with full schema coverage. Description doesn't add new meaning beyond the schema's description, but confirms format. 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?

Clearly states the tool imports an external domain the user already owns to manage through domani.run, distinguishing it from siblings like transfer_domain or buy_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?

Provides clear context: use for domains you already own from external registrars, free and no transfer. Could explicitly mention when not to use, but context from siblings implies alternatives.

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

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

With no annotations provided, the description discloses ordering (newest first) and event types, but does not mention limitations, rate limits, or authentication requirements. It adequately conveys read-only behavior but lacks depth.

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

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

Three sentences with no redundancy: first states purpose and ordering, second lists event types, third provides usage intent. Front-loaded and efficient.

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

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

Given two optional parameters, no output schema, and no annotations, the description covers the tool's purpose, output order, and event scope. It omits details like pagination behavior but remains largely complete for a simple list tool.

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

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

Schema description coverage is 100%, so baseline is 3. The description implies the 'type' filter by listing event categories but does not add new parameter syntax or format details beyond the schema.

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

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

The description clearly states it lists audit events (security trail) for the account, ordered newest first, and enumerates specific event types. It distinguishes from sibling list tools like list_tokens or list_services by specifying a unique resource 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?

Explicitly says 'Use it to review what the account's tokens have been doing,' providing clear context for when to invoke. However, it does not mention when not to use or suggest alternatives, though no overlapping siblings exist.

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 stand alone. It correctly notes the listing nature but does not explicitly state that the operation is read-only or non-destructive. However, the context implies a safe 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 sentence that efficiently conveys the purpose and optional filter. There is no wasted text, and it is front-loaded with the 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?

Without an output schema, the description should hint at the response, but it does not. It also lacks details on pagination, ordering, or behavior when no backorders exist. Adequate for a simple list tool but 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?

The input schema fully covers the single parameter with an enum and description. The tool description adds 'Optionally filter by status,' which restates the schema. No additional meaning is provided beyond the schema.

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

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

The description clearly states the verb 'List' and the resource 'the user's backorders', specifying the possible statuses (watching, caught, failed, cancelled, expired). This distinguishes it from siblings like create_backorder or cancel_backorder.

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

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

No explicit guidance on when to use vs alternatives. The description implies usage for viewing backorders, but does not mention when not to use or provide alternatives.

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

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

No annotations are provided, so the description must carry the full burden. It states the tool lists requests and their statuses but does not disclose behavioral traits such as whether it is read-only, rate limits, pagination, or response structure. For a list operation, more transparency is expected.

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 plus a scope requirement, with no wasted words. It is front-loaded and efficiently communicates the core purpose and a key constraint.

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 simplicity (1 param, no output schema, no annotations), the description is largely adequate. It covers what the tool does and the status filter. However, it could mention whether results are paginated or sorted, but this is 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?

Only one parameter ('status') exists with schema coverage 100%. The description adds value by listing the possible status values (sourcing/contacted/negotiating/agreed/no_contact/declined) beyond the schema's generic description, aiding correct usage.

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

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

The description clearly states the tool lists domain acquisition requests and their statuses, with specific verb 'List' and resource 'domain acquisition requests'. It also enumerates possible statuses, providing clarity. While it doesn't explicitly differentiate from siblings, the specificity is sufficient.

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 mentions the required scope ('deals:read'), which is useful, but it does not provide guidance on when to use this tool versus alternatives like list_negotiations or make_offer. No exclusions or context for when not to use it.

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

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

With no annotations, the description carries the full burden. It correctly implies a read-only operation and simple listing, but it does not disclose any behavioral traits such as return format, pagination, or rate limits. The description is adequate but minimal.

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 unnecessary words. It is perfectly concise and front-loaded with the action and resource.

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 simplicity of the tool (no parameters, no output schema), the description is adequate but incomplete. It does not specify the return format (e.g., list of domain names or full objects) or mention pagination. Sibling tools like list_services might have similar behavior, but the description alone leaves some ambiguity.

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 schema coverage is 100% by default. The description adds no parameter detail, but none is needed. Baseline 4 is appropriate as the schema already covers everything.

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

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

The description clearly states the verb 'list' and resource 'domains you own,' making the purpose clear. It distinguishes from sibling list tools by specifying 'domains' rather than other resources like backorders or services. However, it does not explicitly differentiate from closely related domain tools like get_domain_info.

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 vs. alternatives. For example, it does not explain when to use list_domains vs. get_domain_info or list_services. The description simply states what it does without usage context.

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

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

With no annotations, the description carries the full burden. It mentions what is returned (folders, counts, capabilities) but does not disclose side effects (none expected), authentication requirements, rate limits, or error behavior for invalid addresses or missing mailboxes.

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

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

The description is concise, using a single sentence plus an API endpoint reference. It is well-structured and front-loaded with the purpose, though some additional context could be added without sacrificing brevity.

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

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

Given 2 simple parameters and no output schema, the description is moderately complete. It specifies the items returned (folders, counts, capabilities) but lacks details on pagination, ordering, or error conditions. It is adequate but not comprehensive.

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 basic descriptions for 'slug' and 'domain'. The description adds no additional parameter semantics beyond what the schema provides, so 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 the verb 'List' and the resource 'mailbox folders', specifying inclusion of virtual views, counts, and backend capabilities. It distinguishes from siblings like 'list_mailboxes' (which lists mailboxes) and 'list_email_messages' (which lists messages), making the purpose unambiguous.

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

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

No guidance on when to use this tool versus alternatives like 'list_mailboxes' or 'get_message'. It does not mention prerequisites such as requiring an existing mailbox or address, nor does it provide context on the expected use case.

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 exist, so the description bears full burden. It discloses that it lists messages, supports pagination, direction, and search filters, and provides the API endpoint. However, it does not disclose potential rate limits, read-only nature, or behavior with empty results. Adequate but minimal.

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 efficient sentences. The first sentence immediately states the core function and scope. 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?

Given 11 parameters and no output schema or annotations, the description covers the main purpose and key features. It could be expanded to mention pagination mechanics or filtering behavior, but it remains sufficiently complete for a list tool.

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

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

Schema description coverage is 100% with detailed parameter descriptions. The description adds context about defaults (Inbox) and supported features (pagination, filters) but does not add significant meaning beyond the schema. Baseline 3 is appropriate.

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

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

The description clearly states the tool lists messages in a system folder or virtual view, with default to Inbox. It specifies support for pagination, direction, and search filters. This clearly distinguishes it from sibling tools like get_message (single message) or list_email_folders.

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

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

The description implies usage context by mentioning defaults and filters, but it does not explicitly state when to use this tool versus alternatives like get_message or list_email_folders. No 'when not to use' guidance is provided.

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

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

The description accurately portrays a read-only listing operation with no side effects. Given no annotations, it provides sufficient behavioral disclosure for a simple list tool. No contradictions or omissions.

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

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

A single, well-formed sentence that efficiently communicates the tool's function without extraneous words. Information is front-loaded and clear.

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

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

Given no required parameters and no output schema, the description fully covers what the tool does. It specifies the output format (<handle>.domani.run) and scope (claimed by user). No 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?

With zero parameters, the schema coverage is complete. The description adds no parameter details, which is acceptable per the baseline rule (0 params = baseline 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 clearly states the verb 'list', the resource 'free agent identities', and the scope 'you've claimed', making the purpose specific and unambiguous. It distinguishes itself from siblings like claim_identity and release_identity.

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

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

No explicit when-to-use or when-not-to-use guidance is given. However, the context of sibling tools (e.g., claim_identity) implies usage when needing to view already claimed identities. No exclusions or alternatives are mentioned.

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

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

With no annotations provided, the description should disclose behavioral traits like read-only nature, authentication needs, or pagination behavior. It only describes the return format and source, but omits these key aspects.

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

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

Two sentences, front-loaded with the key purpose. Every sentence provides essential information 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?

For a simple tool with one parameter and no output schema, the description is largely complete. It explains what is returned and the source. However, missing behavioral transparency details prevent a perfect score.

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

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

Schema description coverage is 100% (limit parameter has a description). The tool description adds no new meaning beyond the schema, 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 clearly states the tool's purpose: 'List the user's payment invoices.' It specifies what is returned (invoice number, amount, date, links) and provides context (generated by Stripe for domain purchases/renewals/transfers). This distinguishes it from sibling list tools like list_domains or list_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 description implied that this tool is used to view invoices generated by Stripe, but it does not explicitly state when to use it versus alternatives. No exclusions or alternative tools are mentioned, so guidance is implicit.

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 fully disclose behavior. It only states the function and API path, failing to mention whether the operation is read-only, if pagination is applied, or potential errors. This is insufficient for full 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 two sentences long with no wasted words. It efficiently communicates the tool's purpose and the API endpoint, earning its place 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?

Given the low complexity (2 parameters, no output schema), the description is largely adequate. However, it lacks any hint about the return format or behavior (e.g., array of strings), which would be helpful for an agent. Nevertheless, it covers the essential purpose.

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 100% coverage with descriptions for both parameters (slug and domain). The description adds no additional meaning beyond what is already in the schema, so a baseline of 3 is appropriate.

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

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

The description clearly states 'List all alias addresses that deliver into a mailbox,' which is a specific verb and resource. It distinguishes from sibling tools like add_mailbox_alias and remove_mailbox_alias by focusing on listing. The API endpoint is also provided, adding clarity.

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

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

The description implies usage for listing aliases of a mailbox but offers no explicit guidance on when to use this tool versus alternatives like list_mailboxes. It does not state prerequisites or exclusions, leaving the agent to infer 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?

Without annotations, description partially covers behavior (opaque cursor, snapshot pattern) and implies read-only via API path, but lacks explicit mention of read-only nature, auth requirements, rate limits, or cursor error handling.

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 plus API endpoint reference are concise and front-loaded. Every sentence adds value: purpose, usage pattern, and technical interface.

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?

Reasonably complete for a sync tool with no output schema: explains initial snapshot, cursor replay, and response contains next_cursor. Lacks details on error states or pagination behavior, but sufficient for typical usage.

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

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

Schema covers 67% of parameters with descriptions. Description adds context for cursor usage pattern but doesn't clarify the limit parameter beyond schema constraints. 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?

Clearly states the tool incrementally syncs a mailbox using an opaque cursor, with explicit verb 'synchronize' and resource 'mailbox'. Distinguishes from sibling list tools like list_email_messages by focusing on incremental changes.

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 explicit usage guidance: call without cursor first for a full snapshot, then use next_cursor for incremental changes. This clearly instructs when and how to use the tool versus alternatives.

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

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

With no annotations, the description carries the burden of transparency. It clearly discloses that the response includes labels and metadata but not the actual secrets, and that secrets are only visible at creation time. This is key behavioral information for an agent deciding whether to use this tool.

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

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

The description is two sentences long with no filler. It conveys purpose, scope, and an important behavioral note (secret visibility) in a compact form. Every word adds 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?

Given the tool's simplicity and the absence of an output schema, the description provides enough context: it names the resource (hosted mailbox), explains what is listed, and adds the secret disclosure. It could mention pagination or sorting, but for a straightforward list tool this is adequate.

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 both parameters (slug and domain) are fully described in the input schema. The description adds no additional meaning or context for parameters, earning the baseline score.

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

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

The description clearly states it lists app passwords for a hosted mailbox, specifies what is returned (labels + metadata), and notes that secrets are not included. It also provides the API endpoint, making the tool's purpose unambiguous and distinguishable from related siblings like create_mailbox_credential and revoke_mailbox_credential.

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?