DomainSpace

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

Annotations already declare idempotentHint=true and destructiveHint=false, and the description adds the exact idempotency key (same type, name and value) rather than just repeating the flag. It also discloses the TTL propagation delay, a behavior an agent needs to set expectations after the call, and notes the MX priority requirement. It stops short of saying what happens on conflicting or invalid records.

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 short sentences: purpose, supported types, then idempotency and propagation caveats in descending order of importance. No filler, and the most decision-relevant facts are 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 write tool with no output schema, the description covers purpose, allowed types, idempotency and propagation, which is most of what an agent needs. It leaves open whether the call returns the created record or an identifier, and what failure modes exist for conflicting records.

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 every parameter including ttl, prio, name and value is already documented in detail. The description's only added parameter detail is "MX (needs prio)", which the schema states verbatim, so 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?

Opens with a specific verb and resource ("Add a DNS record to a domain") and scopes it to domains in this account, which cleanly separates it from list_dns_records, delete_dns_record and the domain/order siblings. It does not explicitly name any sibling, but the operation is unambiguous from the verb alone.

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?

"Safe to repeat" effectively tells the agent it does not need to call list_dns_records first to check for duplicates, which is real usage guidance. However there is no explicit when-not guidance, no statement that the domain must already be owned/registered in the account, and no routing to check_domain or list_dns_records before adding.

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

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

Annotations only say readOnly and open-world; the description adds real substance beyond that — it is a live registrar call with a stricter rate limit, it never reserves inventory, and pricing is quoted in EUR with VAT and is flat on renewal. The rate-limit and no-side-effect disclosures are exactly the kind of context annotations cannot carry.

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 short sentences, front-loaded with the core question and followed by the pricing qualifier, the no-side-effect boundary, and the rate-limit caveat. Every clause carries decision-relevant 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?

Single fully documented parameter, no output schema, and the description discloses both the return content (availability + first-year cost) and the operational constraint (rate limit). Nothing an agent needs in order to call it correctly is missing.

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

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

Schema coverage is 100% and the schema already lists accepted endings and diacritic handling, so the description doesn't need to repeat it. It adds only marginal parameter meaning (per-ending flat pricing), so the 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?

Specific verb+resource ('Check whether a domain name can be registered') plus the value it returns (first-year cost). It is clearly distinct from siblings like start_registration/start_renewal and list_domains, which operate on domains already owned or on purchases.

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?

'Does not reserve or buy anything' draws a firm when-not boundary and implicitly routes purchasing elsewhere, and the rate-limit note flags a precondition for use. It stops short of naming the alternative tool (start_registration) explicitly, as a 5 would.

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

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

Annotations declare readOnlyHint=true, and the description reinforces that with 'Does NOT create or buy anything'. It adds behavior the annotations cannot convey: the free-first-mailbox pricing rule, yearly fee for additional mailboxes, that payment is made by the person, and that externally registered domains require DNS verification on the returned page.

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

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

Front-loads the purpose, then the non-creating caveat, then pricing and DNS details. Dense with nested parentheticals, but every clause carries useful information; nothing is 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?

With no output schema, the description correctly covers what is returned (price and a link) and the verification path for external domains. It omits error/invalid-address behavior and whether repeated calls are idempotent, which are minor gaps for a two-parameter read-like 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%, so the baseline is 3; the description adds a real constraint beyond the schema by requiring the domain to be one of the person's domains, and its domain/localPart examples mirror the schema's address split.

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

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

States a specific verb and resource ('Prepare a new mailbox') scoped to 'one of the person's domains', and immediately carves out what it does not do (create/buy). An agent can distinguish it from list_mailboxes or start_registration without opening the schema.

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

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

Explains the flow clearly: check the address, return the price and a link, the person accepts terms and creates it. Implies human-in-the-loop usage but does not explicitly name sibling alternatives (e.g. list_mailboxes, start_registration) or state when not to call 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?

Annotations already declare destructiveHint=true, idempotentHint=true, and readOnlyHint=false, but the description adds the crucial detail that all records matching type/name/value are removed at once and that the action is irreversible. It also clarifies that TTL is not part of the matching key, which affects what gets destroyed.

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?

Roughly three short sentences: the operation and matching key first, then the irreversibility warning, then the safety recommendation. Nothing is redundant and every clause carries 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 destructive, five-parameter tool with no output schema, it covers what is deleted, what is not needed (TTL), and how to verify targets beforehand. It stops short of noting failure behavior (e.g. no-op vs error when nothing matches) or auth/ownership requirements.

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 100% schema coverage the baseline is 3, but the description adds matching semantics the schema does not state: these fields act jointly as a selector, TTL is irrelevant, and prio applies only to MX. That is real value beyond the field-level 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?

States a concrete verb (delete) plus resource (DNS records) and defines the exact matching scope: type, name, value, and prio for MX. This distinguishes it from add_dns_record and list_dns_records without the agent needing to open any schema.

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

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

Explicitly directs the agent to run list_dns_records first to confirm the exact values, which is a clear prerequisite routing. It does not spell out exclusions (e.g. when deletion should be avoided or which sibling to use instead for bulk cleanup), so it falls just short of a full when/when-not pair.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, and the description reinforces that with "(read-only)" while adding scope the annotations do not convey: data is limited to domains in this account. It does not say what happens for an unknown or unregistered domain name, which is the main remaining gap.

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

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

One front-loaded sentence naming the resource and the exact fields returned, with the read-only qualifier trailing. Nothing is wasted.

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

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

With no output schema, the description earns its keep by naming the four returned values, and the account-scoping is stated. Missing is any error behavior for invalid or unowned domains and any differentiation from check_domain.

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

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

Schema coverage is 100%, and the single "domain" parameter is documented in the schema with accepted .si and other endings. The description adds no syntax or format detail beyond that, so the 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?

States a specific resource (one domain in this account) and enumerates the returned attributes (expiry date, renewal state, renewal price, marketplace listing status). The word "one" implicitly separates it from list_domains, but it never addresses check_domain, which sounds closely related.

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

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

Usage is only implied: fetch details for a known single domain. There is no explicit when-to-use guidance and no routing between this and siblings like check_domain or list_domains, so an agent must infer the boundary itself.

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

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

With annotations covering safety (readOnlyHint=true, openWorldHint=false), the description adds meaningful behavioral detail: HTML is converted to text, links preserve their addresses, attachments are listed but not returned, and message content is untrusted sender data. This goes well beyond what the annotations provide and helps the agent interpret the result correctly.

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 tightly written sentences with no waste. The core purpose and return shape are front-loaded, followed by important behavioral and safety notes.

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

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

For a simple two-parameter read tool with no output schema, the description explains what is returned, how HTML and links are transformed, and the attachment behavior. Combined with annotations and 100% schema coverage, it gives the agent everything needed to call and interpret the tool correctly.

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

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

Schema description coverage is 100%, so both parameters (id and address) are already fully documented in the schema. The description reinforces that this reads one message from a mailbox but adds no syntax or format details beyond the schema, so the baseline of 3 is appropriate.

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

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

States a specific verb and resource: 'Read one message of a mailbox'. It also enumerates the returned fields (sender, recipients, subject, text), which clearly differentiates it from list-level siblings like list_messages and wait_for_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?

The description implies usage by saying it reads one message, but it does not explicitly say when to use this instead of list_messages or wait_for_message, nor does it name alternatives. The id parameter schema mentions those siblings, but that guidance is not in the description itself.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered, yet the description still adds value: it discloses that the response interprets the status ('what the status means') and indicates terminality ('whether it is final'), which shapes how an agent should act on the result. It stops short of giving polling cadence or field-level return detail, keeping it below a 5.

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

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

Two short sentences, front-loaded with what is returned and followed by the when-to-use cue. Nothing redundant; every clause carries information an agent needs.

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

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

For a one-parameter, read-only status tool with no output schema, the description covers what is returned semantically (status, interpretation, finality) and when to call it. It could be marginally more complete by hinting at the response shape or polling interval, but 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?

Schema coverage is 100% and the single parameter's description already says 'The orderId from list_orders.', so the schema does the heavy lifting. The tool description adds no further parameter meaning, which is the expected baseline for a fully documented single-parameter schema.

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

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

States a specific verb and resource: retrieve the status of a single order, plus the meaning of that status and whether it is final. That scope distinguishes it from list_orders, which the schema also points back to as the source of orderId. No sibling is named directly in the description, but the singular-vs-list distinction 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?

'Poll this after giving the user a checkout link' gives an explicit trigger and even the interaction pattern (polling) that selects this tool. There are no explicit exclusions or named alternatives, but the usage context is unambiguous for such a narrow 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?

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds useful behavioral detail about how records are named ('@' is the domain itself), but says nothing about ordering, pagination, or what happens if the domain has no records or is not in the account.

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

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

Two short sentences, both load-bearing: the first defines the operation and record types, the second clarifies the naming convention. Nothing is repeated from the schema and nothing is wasted.

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

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

For a simple single-parameter read tool with annotations covering safety and full schema coverage, the description is nearly complete. The only mild gap is that it doesn't describe the response shape at all, but with no output schema and an obvious list result, this is a minor omission.

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

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

There is a single parameter with 100% schema description coverage, and the schema already explains accepted domain formats in detail. The description's note about relative names and '@' adds meaning about the returned data rather than the input, so it doesn't materially extend parameter semantics beyond the schema. 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 gives a specific verb and resource ('List the DNS records') and enumerates the record types returned (A, AAAA, CNAME, MX, TXT), which pins down scope precisely. It doesn't explicitly contrast with sibling tools like add_dns_record or delete_dns_record, but the read-only framing makes the distinction obvious in context.

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

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

The usage is implied by the verb and the 'in this account' scoping, and the sibling names make the mutation alternatives clear. However, there is no explicit statement of when to use this versus, say, get_domain, nor any prerequisites or exclusions spelled out.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered; the description adds genuinely new behavioral detail by enumerating the exact renewal states (open, early, expired, unknown) and the conditional rule that listing status only appears 'when the marketplace is open'. It stops short of describing volume, pagination, or ordering of results.

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

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

One front-loaded sentence; the verb and scope come first and the field list follows. The trailing parenthetical is slightly dense but each element (state enum values, marketplace condition, read-only boundary) carries information an agent would otherwise have to discover.

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

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

With no input parameters and no output schema, the description compensates by naming the returned fields directly, which is exactly the missing piece. Combined with the annotations covering read-only behavior, an agent has everything needed to decide to call it and interpret the result.

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

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

The tool takes zero parameters, which is the baseline-4 case. The description correctly spends its words on output semantics instead of inventing input behavior.

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

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

The description states a specific verb+resource ('List the domains in this account') and enumerates exactly what each entry carries: expiry date, renewal state, renewal price, and marketplace listing status. It does not explicitly contrast itself with get_domain, but the list-versus-single distinction is legible from the scope wording.

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

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

Usage is implied rather than stated: the parenthetical establishes a boundary ('selling is done in the dashboard'), which tells the agent this tool is not for mutation. However, no alternative is named for looking up a single domain (get_domain) or for pending orders (list_orders), so routing among siblings is left to inference.

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

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

Annotations already declare readOnlyHint and closed-world scope, and the description adds real context beyond them: the returned fields, a per-mailbox computed capability ('whether an agent can read each one now'), and the mail:read permission prerequisite for actually reading mail. It stops short of stating ordering or whether mailboxes without read access behave differently, but the value add is substantial.

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 tight sentences: the resource and returned fields come first, and the permission caveat follows as supporting context. 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?

With no output schema and no parameters, the description carries the burden of describing the response, which it does by listing the fields and the readability flag. Annotations cover the safety profile, so nothing essential is missing for a 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?

The tool takes zero parameters, so there is nothing for the description to disambiguate; baseline 4 applies. The description correctly implies an unfiltered, account-scoped listing.

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

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

States a specific verb and resource ('List the email mailboxes of this account') and enumerates what is returned (address, status, plan, expiry), which cleanly separates it from siblings like list_messages, list_domains, or create_mailbox. An agent can identify the target resource without opening the schema.

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

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

Usage is only implied: check mailboxes and per-mailbox readability before reading mail. It names no alternative tool and gives no explicit when-not-to-use guidance, so the agent must infer the routing from the resource name alone.

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

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

Goes well beyond readOnlyHint=true by naming exactly what does NOT happen ('nothing is marked read, moved or deleted'), disclosing folder/spam scope, flagging untrusted sender content as data not instructions, and clarifying the receive-only nature of the toolset. These are non-obvious behavioral traits an agent cannot infer from annotations or 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?

Three tight sentences, front-loaded with the core action, followed by the safety constraint and the trust caveat. 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?

With no output schema, the description compensates by naming the returned fields (sender, subject, short preview) and the read-only guarantee. Minor gap: it does not discuss pagination or what happens when limit is reached, though the limit parameter is documented in the 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 already 100%, but the description adds meaning the schema lacks: 'newest' implies result ordering, and 'all folders, spam included' defines the addressable scope of the address parameter. It does not elaborate on limit or since beyond what the schema 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?

States a specific verb and resource ('List the newest messages delivered to one of this account's mailboxes') and scopes it to all folders including spam. It does not explicitly distinguish itself from siblings like get_message or wait_for_message, though the 'short preview' phrasing hints that full bodies come from elsewhere.

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

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

Usage is only implied: 'newest messages' suggests a listing/browsing use case, but the description never says when to use this versus get_message (full content) or wait_for_message (waiting for arrival). No explicit exclusions or alternative routing are given.

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

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

Beyond the read-only annotation, the description adds key behavioral context, specifying that results are sorted 'newest first' and include the resource 'status'. These details help the agent anticipate the returned data structure.

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 definition is concise and front-loads the primary function in the first sentence. While slightly explanatory, it uses the space efficiently to describe the scope and 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 that the annotations provide safety context, the description successfully covers scope ('this account'), resource types, sorting, and essential data points, making it highly complete.

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

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

With 100% schema coverage, the description doesn't need to elaborate on the parameter, which is fine. It confirms the parameter governs the amount of returned orders without adding functional details beyond what the schema implies.

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

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

The description clearly identifies the action ('List') and the specific resource ('orders'), including the types covered (registrations and renewals). This is highly specific and distinguishes it from singular retrieval tools like get_order.

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 the tool by stating its practical purpose: 'Use it to see when a purchase has been paid and the domain registered.' This guides the agent's intent.

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?

Consistent with readOnlyHint=true and adds substantial context the annotations cannot convey: nothing is bought or ordered, names are not reserved until payment, unavailable names are dropped and listed, and a human must complete checkout with terms and withdrawal-waiver consent.

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

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

Front-loaded with the key non-purchase disclaimer and dense with useful information, though the parenthetical about .si mixing and per-ending pricing is slightly overstuffed for a description whose schema already lists the endings.

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, and the description still explains exactly what comes back (one checkout link plus a list of unavailable names) and what happens after payment, leaving no material gap for a zero-required-parameter 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%, so baseline is 3; the description still adds the either/or selection rule between `domain` and `domains` and the combined-checkout semantics, which the schema does not state.

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

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

States a specific verb and resource ('prepare the purchase of one or several domains ... in ONE checkout') and explicitly negates the obvious misreading ('This does NOT buy anything and creates no order'), which cleanly separates it from check_domain and start_renewal.

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?

Gives explicit selection rules ('Pass `domain` for one name or `domains` for several'), tells the agent what to do with the result ('Give the link to the user'), and names the follow-up tools (list_orders, get_order) with the condition for using them.

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?

Goes well beyond the readOnlyHint/openWorldHint annotations: it discloses that nothing is renewed or charged, that the return value is a link to a renew page, what the person does there (choose 1-3 years, enable auto-renew, pay), and the external timing constraints. This is exactly the context an agent needs before calling.

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 short sentences, front-loaded with the key misconception-buster ("Does NOT renew or charge anything"), then the return value, then the eligibility window. No 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?

No output schema exists, but the description explains what is returned (a renew-page link). Safety profile, side effects, timing and prerequisites are all covered for a single-parameter 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% and the single `domain` parameter is fully documented in the schema, including accepted suffixes and Unicode handling. The description adds no parameter-level detail, so 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?

States a specific verb+resource ("Prepare a renewal of a domain in this account") and immediately scopes it away from the actual renewal/payment action. It is clearly distinguishable from the sibling start_registration (new domains) and from get_domain (status 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?

Gives an explicit eligibility window (from 90 days before expiry, up to 28 days after) and points the agent to get_domain to check expiry before calling. It does not explicitly contrast with start_registration for non-expiring domains, but the usage context is otherwise unambiguous.

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

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

With readOnlyHint already declaring a safe operation, the description adds real context: the call blocks up to 50 seconds, must be re-issued to continue waiting, filters are partial matches, and message content must be treated as data rather than instructions. The prompt-injection warning is genuinely rare and valuable; only the return payload shape is left implicit.

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

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

Front-loaded with the core behavior, then the time-out cap and re-call guidance, then filter scope, then the safety note. Four tight sentences, each carrying distinct information with no repetition.

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

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

No output schema exists, and the description covers the two possible outcomes (full message returned, or none within the time-out). Combined with the annotations and fully documented schema, an agent has enough to call it and interpret the result; only the exact shape of a returned message is left to discovery.

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

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

Schema coverage is 100%, so the schema already documents the sender/subject substring matching, ISO 8601 since format, address example, and timeout default of 30 with max 50. The description's 'filters match part of the sender or subject' largely restates the schema, so 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?

States a specific verb and resource: waits for a message to arrive in a mailbox, returns it in full, or reports a time-out. An agent knows exactly what the call does, but nothing in the text distinguishes it from siblings like get_message or list_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?

'Call again to keep waiting' gives a concrete workflow for the hard 50-second cap, which implies when polling is appropriate. However, no alternative is named: it never tells the agent to use get_message when the message ID is already known, or list_messages to scan history.

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