GoMain

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

Annotations already establish readOnly/idempotent/non-destructive, so safety is covered, and the description goes beyond them by disclosing the actual payload: sale listing and asking price, drop timing, estimated value, buy-chance, an ordered option list, and priced alternatives. It even flags a data caveat ('when the sale page shows one'), though it says nothing about latency or caching for what is clearly an open-world lookup.

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 dense sentence, but it is front-loaded with the scoping condition and every clause adds distinct information about the return. The nested parentheticals and comma-spliced option list make it slightly hard 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?

With no output schema, the description does the right thing by enumerating the fields the report contains, and it covers all six sections an agent would need to relay. Missing pieces are minor: input format and any note on how slow the open-world lookups may be.

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

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

Schema coverage is 0% and the single 'domain' property has no description, so the description carries some burden. It does implicitly constrain the input to an already-owned domain, which is genuine semantic information, but gives no format guidance (TLD required, subdomain handling, etc.).

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 scoping clause 'For a domain someone already owns' plus the enumerated report contents make it clear this is an acquisition-intelligence report for taken domains, which separates it from check_availability and search_domains_for_sale. It never states a verb ('returns a report on...') and reads as a content list, so it stops short of a crisp verb+resource statement.

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

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

The phrase 'For a domain someone already owns' gives an implicit when-to-use condition and rules out available domains, which is real routing value. However, it names no alternatives or exclusions (e.g. appraise_domain for value only, make_offer to act, request_acquisition to buy), so the agent must infer when this broad report beats the narrower 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?

Annotations already declare the safety profile (readOnly, idempotent, non-destructive, openWorld). The description adds genuinely new behavioral context: the result is a 'rough' heuristic estimate derived from stated signals and is explicitly not a sales-based valuation, which sets the agent's expectation about output precision.

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, front-loaded with the core output, then the factors, then usage and exclusion. 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?

For a read-only appraisal with no output schema, the description conveys that the return is a value range and lists the drivers. It stops short of saying how the range is expressed or whether confidence/caveats accompany it, a minor gap given the absence of an 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 coverage is 0% and the single 'domain' parameter has no description, so the description carries the burden but only implies the input is a domain. It adds no format guidance (e.g., 'example.com' vs bare label) or edge-case handling, though the parameter is largely self-evident.

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 (appraise) and resource (a domain's value) and enumerates the exact factors used (length, pronounceability, TLD, age, same-name registrations). It also carves itself away from siblings by explicitly disclaiming a comparable-sales appraisal, which is what compare_prices/price_history do.

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 a concrete trigger (set a realistic budget before trying to buy a taken name) and an explicit exclusion (not a comparable-sales appraisal). An agent can route between this and the price_history/compare_prices siblings without opening schemas.

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

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

Annotations already declare readOnlyHint, idempotentHint and non-destructive, so safety is covered. The description adds that view access is gated on a status_key issued at creation, which is genuinely useful context. It does not disclose what happens on an invalid/mismatched key or how much 'history' is returned.

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

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

A single, front-loaded sentence with no wasted words. The primary resource (status/history) comes first and the identifier conventions are parenthetically appended.

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

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

For a two-parameter read tool with full annotations, the description covers what the tool returns (status and history) and where the required inputs come from. Lacking an output schema, it could say more about the shape of 'history' and failure behavior, but nothing essential to invoking it 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 0%, so the description must carry both parameters. It does add meaning for both: id carries an object-type prefix (d_ deal vs w_ watch) and status_key is a credential obtained at creation time. It still gives no format or validation detail for status_key, so compensation is partial.

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 resource and action: retrieve the status and history of a brokerage deal or watch. The d_…/w_… prefix convention lets an agent distinguish which object type the id refers to. It is clear on its own, though it doesn't explicitly name the mutating siblings (watch_domain, request_acquisition) that create these records.

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: it tells you the call requires an id and status_key 'returned when it was created', which is a precondition. There is no explicit when-to-use vs. when-not guidance and no named alternatives, so the agent must infer that this is the read counterpart to the creation tools.

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

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

Annotations already declare readOnly, idempotent, openWorld and non-destructive, so the safety profile is covered; the description goes further by explaining that lookups hit the TLD registry directly, enumerating the possible status values, and warning that a lookup is not a reservation. It stops short of covering rate limits, auth requirements, or pagination 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?

Three sentences, front-loaded with the core purpose, then the return values, then the caveats. Dense but each sentence carries information; the status enumeration is slightly long but genuinely useful since no output schema exists.

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 takes on the job of explaining return values (registered / available / likely_available / unknown, plus registrar, dates and prices). It also covers the batch limit and the reservation/premium caveat, so an agent has everything needed to call and interpret this 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% for the single 'domains' parameter, so the schema already documents the array, its item format, and the 1–20 bounds. The description restates the 20-name cap and adds nothing about accepted input syntax beyond the schema's own examples, 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 ('Check whether domain names are registered') and even names the mechanism (RDAP, direct registry queries), which separates it from suggestion or appraisal tools. It never explicitly names a sibling such as check_name or search_domains_for_sale, so differentiation is inferred rather than 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 gives the batch limit ('Up to 20 names per call') and a warning about what a lookup does not guarantee, which implies usage, but it never says when to prefer this tool over check_name, suggest_names, or search_domains_for_sale. No exclusions or alternatives are offered.

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 readOnly, idempotent, openWorld, non-destructive, so the safety profile is covered. The description adds genuine value beyond that: it notes prices are included and that trademark and social-handle checks are NOT automated (links only), which is an important scope limitation an agent should know.

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: a front-loaded framing question followed by the concrete coverage list. Every clause earns its place, with no redundant restatement of the name or title.

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 does the work of sketching the return (domain results with prices, availability signals, and outbound links). Combined with annotations that fully cover safety, this is close to complete, only thin on how results are structured.

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

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

Schema description coverage is 100% — both `name` and `tlds` (with default and maxItems) are documented in the schema itself. The description adds nothing parameter-specific beyond the already-covered notion of checking across TLDs, 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?

The description gives a specific verb (checks) and enumerates the exact resources covered — domains across TLDs with prices, GitHub, npm, PyPI, crates.io — plus non-automated trademark/social lookups. This clearly distinguishes it from the narrower check_availability sibling, though it never names that sibling explicitly.

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 opening question ('Is a project name usable everywhere it'll be needed?') implies the use case — a broad pre-launch naming check — but there is no explicit when-to-use vs. check_availability, appraise_domain, or suggest_names guidance and no stated exclusions.

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

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

Annotations already declare readOnly, idempotent, openWorld, non-destructive. The description adds real value beyond them: data freshness ('refreshed daily'), source breadth (40+ registrars), currency and unit (USD per year), default sort rationale, and that offers link out to a purchase 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?

Three tight sentences, each carrying distinct information: scope/source/currency, sorting default plus the reason it matters, and the outbound buy links. Nothing is repeated from the schema and the rationale 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 read-only, open-world lookup with no output schema, the description adequately conveys what comes back (per-registrar offers with links) and the cost basis being compared. Only the sort options and result cap remain unspecified for an agent tuning the call.

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

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

Schema coverage is only 33% – just the 'tld' param is documented, and the description usefully explains the default 'three_year' sort and the annual USD basis. But the other three enum values (registration, renewal, transfer) and the 'limit' param (default 10, max 60) get no semantic treatment in either place, so the low-coverage schema is not fully compensated.

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 resource and scope: every tracked registrar's price for one TLD, in USD per year, sourced from 40+ registrars, with buy links. That is far more concrete than the title and clearly separates it from temporal tools like price_history, though no sibling is named explicitly.

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 – the framing 'sorted by 3-year cost ... because a cheap first year often hides an expensive renewal' hints at the comparison use case, but there is no explicit when-to-use, no exclusion of price_history for historical data, and no prerequisites stated.

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

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

Beyond the annotations (readOnly/openWorld/idempotent/non-destructive), the description discloses real behavior: it checks live DNS to show what is already in place, warns about clashes such as duplicate SPF records, and flags provider-generated values. That is meaningful operational context; it only stops short of noting rate limits or lookup failure 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?

Three sentences, front-loaded with the deliverable before the live-check and warning behavior. Dense but each sentence carries information; slightly list-heavy with the parenthetical platform enumerations.

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 carries the return-value burden itself and does so — records to add, live DNS status, clashes, and marked per-account values. Combined with read-only annotations, an agent has what it needs; only the domain input format remains unaddressed.

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

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

Schema description coverage is only 25% (only 'account' is documented in the schema). The description partly compensates by grouping the enum values into website hosts vs email providers, clarifying what the 'website' and 'email' enums mean, and its line about account-generated values touches the 'account' param. It still says nothing about the required 'domain' parameter's expected format, so it doesn't fully close the gap.

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

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

The description names the specific output — the exact DNS records for a website host and an email provider, plus a DMARC policy — and enumerates the supported platforms, which map to the enum values. No sibling tool (all domain-marketplace names) does anything similar, so an agent can differentiate instantly.

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

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

It gives clear context: use this when a domain needs to serve a website and receive email. It does not name alternatives or exclusions, but no sibling covers DNS, so the omission is minor and the usage window is unambiguous.

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

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

Annotations already signal a non-read-only, non-idempotent, non-destructive write. The description adds genuinely new behavioral context: the ownership-verification round-trip, the fact that a repeat call is required to activate, and that sales settle via Escrow.com. It does not cover failure/auth conditions or what happens if the TXT record is missing, so it is useful but not exhaustive.

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 tight sentences: purpose first, then the workflow, then the price-visibility distinction, then the escrow detail. No filler and the ordering matches how an agent would reason about invoking the tool.

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

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

With no output schema, the description correctly explains what the first call returns (a DNS TXT record), which is the key missing return-value context. It omits the withdraw and listing_key paths and does not describe the terminal success state beyond "activates the listing," but for a 6-param mutation tool it is nearly 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 low (33%) so the description must compensate, and it does explain asking_price (visible to buyers) and floor_price (auto-accept threshold, never shown) meaningfully. However, withdraw and listing_key behavior is left largely to the schema, and floor_price's automatic-acceptance semantics are only half-explained, leaving the low-coverage gap partly unfilled.

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 a domain the user owns for sale") that cleanly separates it from siblings like search_domains_for_sale (buying) and make_offer. The ownership constraint is explicit and front-loaded, so an agent can route correctly without opening the schema.

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

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

The description lays out the two-step activation workflow clearly: first call yields a DNS TXT record, and a second call with the same domain and email activates the listing once it is added. It gives strong when-and-how context but never names the alternative tools (e.g., make_offer or withdraw flows), so it stops short of explicit 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?

Annotations already flag non-read-only, open-world, non-idempotent, non-destructive, but the description adds the behavior that matters: automatic counter-offer negotiation bounded to three rounds, seller adjudication, and an Escrow.com transaction that releases funds only on domain delivery. It also mandates user confirmation, which is real behavioral context beyond the annotation set.

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, each carrying distinct load: purpose, pricing/negotiation rule, escrow consequence, and pre-call/counter-offer instructions. Front-loaded with the core action and zero filler.

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

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

For a mutation tool with no output schema, it covers the transaction lifecycle and the preconditions well. It only lightly implies that deal_id and status_key are returned values the agent must capture, which is the one detail an agent needs to complete the counter-offer loop.

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

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

Schema coverage is only 40%, leaving domain, deal_id, and status_key undocumented in the schema. The description compensates by explaining that deal_id and status_key come 'from the last answer' and are used to respond to a counter-offer, and that amount is confirmed with the user. Only 'domain' is left implicit.

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 ('Offer to buy a domain listed with GoMain') and immediately distinguishes itself from the passive listing/search siblings by describing the transaction path. An agent knows this is the purchasing action, not a search or appraisal 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?

Explains the decision rule (at/above asking buys outright, lower is auto-negotiated up to three rounds), instructs confirmation of amount and email before calling, and tells the agent exactly which condition selects the alternate invocation path (deal_id + status_key to answer a counter-offer). This is explicit when/how guidance.

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

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

Annotations already declare readOnly/idempotent/openWorld/non-destructive, so safety is covered. The description adds genuinely new behavioral context: chronological ordering, the meaning of a registrar's first entry (archive start or first sale), and that prices are annual and USD-denominated. It does not discuss result size or pagination, 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?

Three tight sentences with zero filler, front-loaded with what the tool returns, then scoping/ordering, then unit semantics. Every sentence 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?

With no output schema, the description carries the return-value burden and does so reasonably: it explains the entry sequence and price units. It leaves out volume/shape of results (e.g., how many registrars are typically returned) and the dangling `currency` reference is unexplained.

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 are already documented; the description adds only the ordering guarantee and currency semantics. It references a `currency` field that is not a parameter in the schema, which adds mild ambiguity rather than clarity, so this stays at the 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?

States a specific result (every recorded price change for one TLD) plus ordering (oldest first) and data source (GoMain's daily archive). An agent can distinguish this from compare_prices (cross-registrar comparison) and tld_info (static registry facts) without opening a 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: the description explains what the data means once you call it, but never says when to reach for it over tld_info or compare_prices, nor any prerequisites. Adequate for an obvious lookup tool, but no explicit routing or exclusions.

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

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

Annotations cover only the safety profile (readOnly=false, openWorld=true, idempotent=false, destructive=false). The description goes well beyond that: it discloses the anonymous approach to the owner, that negotiation is bounded by the budget and the owner never sees it, that closing happens through Escrow.com, and that the call returns a deal id plus a status key. That is exactly the extra context the annotations cannot convey.

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

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

Three sentences, front-loaded with the action and scope, followed by the precondition and the return contract. Every clause carries information an agent needs; nothing is restated from the title or schema.

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

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

With no output schema, the description correctly names the return values and routes to broker_status. It also covers the user-confirmation prerequisite. What it omits is the cost/fee implications of engaging a brokerage and what happens if the owner refuses or the budget is exceeded — relevant for a non-idempotent, open-world mutation.

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 75% (domain is undocumented), and the schema already explains email, notes, and max_budget. The description still adds genuine semantics for max_budget — it is a hidden ceiling the owner never sees, not a public offer — which changes how an agent should set it. It adds nothing for notes or domain.

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

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

States a specific verb and resource ('Ask GoMain's brokerage to acquire a domain someone else owns') and immediately distinguishes itself from direct-offer siblings like make_offer by specifying the domain must be owned by a third party. The agent can tell this apart from appraise_domain, check_availability, or make_offer without reading 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?

Gives a concrete precondition — confirm the buyer's email and budget with the user before calling — which is real when-to-use guidance. It does not, however, name the alternatives (e.g. use make_offer when the domain is already listed for sale, or check_availability first), so the routing between siblings still requires 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 cover readOnly/idempotent/openWorld/non-destructive, so the bar is lower. The description adds real value beyond them: it discloses that only verified-control listings appear and that asking prices are only returned where set, which matters for interpreting sparse 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?

Two tight sentences, front-loaded with the core action and the verification qualifier following. No filler; every clause conveys 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 read-only search with no output schema and annotations covering the safety profile, this is nearly complete: it explains the source of listings and the return of asking prices. It stops short of covering max_price behavior or result limits/pagination.

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

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

Schema coverage is only 50%: keywords is documented but max_price has no schema description and is not addressed anywhere in the description. The description adds no filtering syntax or semantics, leaving the price-bound parameter undocumented in both places.

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 (search domains listed for sale with GoMain) and clarifies the trust scope (owners proved control). It implicitly separates itself from list_domain_for_sale (listing your own name) and make_offer (the buying action), so an agent can pick it 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?

It routes the agent to make_offer for buying/negotiating, which is useful usage context, but never states explicitly when to reach for this tool versus siblings like check_availability or compare_prices. Usage is implied rather than 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 readOnly/idempotent/non-destructive and openWorld, so the safety profile is covered. The description adds genuinely new behavioral detail: the generation strategy (words joined, common prefixes/suffixes, several TLDs), the fact that every candidate is registry-checked, and that only available results with prices come back. It does not say what happens to unavailable candidates or note any rate/timeout limits on the registry lookups.

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 core pipeline, with the sibling routing deferred to the end where it belongs. The parenthetical about generation strategy is dense but earns its place; nothing is redundant 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?

There is no output schema, so the description must convey the return shape, and it does ('return the available ones with prices'). Combined with full schema coverage on the three parameters and annotations covering safety and open-world behavior, an agent has enough to invoke correctly; only the handling of unavailable candidates remains unstated.

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 tlds, limit, and keywords each documented in the schema, so the baseline is 3. The description only loosely paraphrases keywords ('turn a few keywords into...') and adds no syntax, ordering, or interaction detail (e.g., how keyword spacing affects the prefix/suffix generation) 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?

Names a specific action chain (generate candidates from keywords, check each against its registry, return available ones with prices) and explicitly routes the user away from the sibling check_availability for their own ideas. An agent can distinguish this from check_name, check_availability, and search_domains_for_sale without opening a 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 states the condition that selects the alternative: 'For your own name ideas, use check_availability.' The tool's own trigger (turn a few keywords into candidates) is also stated, so the when-to-use/when-to-use-instead split is unambiguous.

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

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

Annotations already declare readOnlyHint, idempotentHint and non-destructive, so the safety profile is covered. The description usefully states the data provenance (IANA) and that pricing is 'cheapest first-year, renewal and 3-year', which adds context beyond the annotations. It says nothing about failure behavior for unknown TLDs, currency, or freshness of prices.

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 compact sentence enumerates exactly what the agent gets back, with no filler or restating of the name. It is slightly dense as a comma-list but 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?

With no output schema, the description carries the burden of describing returns and does so comprehensively across registry, delegation, servers and pricing. Gaps remain around edge cases (invalid TLD, pricing source/variance), which is why it is not a 5.

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

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

Schema description coverage is 100% and the single tld parameter already documents accepted forms ('ai', '.co.uk', 'example.ai'), including the domain-derived shorthand. The description adds no extra syntax or normalization detail, 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 gives a precise verb-less but specific resource listing: registry operator, TLD type, delegation date, IANA lookup servers, and cheapest prices. An agent immediately knows this is a TLD metadata/facts lookup. It stops short of naming how it differs from price-oriented siblings like compare_prices or price_history, so it is not a 5.

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

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

There is no when-to-use guidance, no prerequisites, and no mention of the adjacent tools (compare_prices, price_history) that also expose pricing. The only usage signal is implicit in the name and the field list.

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

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

Annotations already flag this as a non-read-only, non-idempotent, open-world operation. The description adds meaningful context beyond them: it explains the daily polling cadence, the email-notification trigger conditions, and that it returns a watch id and status key. It does not disclose auth requirements or how to cancel a watch, keeping it just short of 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 tight sentences that front-load the core behavior and place return values last. No wasted words, though it could be slightly tighter given how few concepts it covers.

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 monitoring tool with no output schema, the description covers what it does, when it notifies, and what it returns. Missing only peripheral details like watch lifecycle/removal, which is minor at this complexity.

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

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

Schema description coverage is 0%, so the schema provides no semantics for the two parameters. The description implies email is the notification address ('emails when...') and domain is the watch target, but it never explicitly defines either field, leaving some inference to the agent.

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 + resource ('checks a domain daily') and clearly states the monitored events (drops, changes hands, listed for sale). It distinguishes itself from siblings like check_availability by describing an ongoing, notification-based service rather than a one-off 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?

Usage is implied — you call this to set up recurring monitoring and later use the returned status key with broker_status. However, there are no explicit when-to-use/when-not statements, no mention of how it compares to check_availability or make_offer, and no prerequisites stated.

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