StableDomains

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

No annotations are provided, so the description carries the full behavioral burden. It discloses that funds are spent from a prepaid balance, but says nothing about insufficient-balance behavior, whether the charge is final or reversible, whether availability is validated first, or what happens to the idempotency key — significant gaps for a financial mutation.

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 filler — the action and the payment source appear immediately. Brevity is a virtue here, though the terseness contributes to the coverage gaps scored elsewhere.

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 money-spending mutation with no annotations, no output schema, and zero parameter documentation, the definition is too thin. An agent cannot predict the cost source, failure modes, or return value from what is given.

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% across three parameters, so the description must compensate and largely does not. It covers only the idea of a domain; `years` (registration term) and especially `idempotency_key` are left completely undefined in both schema and description.

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

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

States a specific verb and resource ("Register a domain") plus the payment mechanism ("prepaid balance"), which separates it from renew_domain and from the two-step create_order/pay_order flow. It stops short of naming those siblings explicitly, so the agent must infer the distinction from the phrase "in one call".

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

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

The phrase "in one call" implicitly signals this is the combined register-and-pay shortcut versus the multi-step alternatives, but the description never states when to prefer it over create_order + pay_order, nor any precondition such as sufficient balance or domain availability.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It implies a read operation by saying 'Get,' but does not state permissions, whether next actions are computed or returned directly, rate limits, or any other behavioral traits beyond the bare purpose.

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

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

The description is a single front-loaded sentence with no wasted words. However, its extreme brevity contributes to under-specification rather than efficient completeness.

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

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

For a tool with a required undocumented parameter, no annotations, and no output schema, the description is too thin. It does not explain what 'order status' includes, what 'next actions' means, or how the required order_id should be supplied.

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% and the description says nothing about the required order_id parameter, its expected format, or where to obtain it. The description fails to compensate for the undocumented schema parameter.

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

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

The description uses a clear verb ('Get') and resource ('order status and next actions'), making the tool's purpose easy to understand. It distinguishes check_order from mutation siblings like create_order and pay_order, though it doesn't explicitly name an alternative.

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

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

There is no explicit guidance on when to use this tool versus alternatives such as pay_order or create_order, nor any prerequisites or exclusions. The usage is only implied by the tool name and description.

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

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

With no annotations, the description carries the behavioral burden and does well: it discloses the 20-domain batch cap, the exact-total 402 payment requirement, per-domain registration with refunds to prepaid balance on failure. It omits idempotency behavior and the response shape, which keeps it 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 compact sentences, front-loaded with the core capability and batch limit, then the payment/refund semantics. No wasted words.

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

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

For a mutating, payment-bearing tool with no annotations and no output schema, the description covers the critical payment and refund semantics but leaves gaps: idempotency_key purpose, nameservers effect, ref meaning, and what the caller gets back per domain are all 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 coverage is only 33%, and the description only adds meaning for 'domains' (max 20, must be available). chain and token are documented in the schema, but ref, nameservers, and idempotency_key get no explanation anywhere, so the description does not fully compensate for the coverage 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 uses a specific verb+resource ('Register ... domains') and adds scope detail (batch of up to 20, single payment). It does not explicitly distinguish itself from close siblings like create_order or buy_with_balance, so an agent must infer the distinction from the payment 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?

Usage is only implied: the 'ONE payment' and '402' language signals a batch x402 payment flow, but the description never states when to choose this over create_order, buy_with_balance, or pay_order. No exclusions or prerequisites are given.

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

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

With no annotations, the description carries the full behavioral burden. It usefully discloses that the tool returns payment requirements, including exact amount and address, and that balance payment is immediate, but it omits important traits such as whether the order reserves the domain, how long it remains valid, auth requirements, and idempotency behavior.

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

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

The description is three short sentences and front-loads the core action. It is efficient, though it could put the payment-return behavior and balance shortcut into clearer relation to the order lifecycle.

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

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

This is an 8-parameter payment/order tool with no annotations, no output schema, and low schema description coverage. The description explains only the basic return shape and one payment enum value; it does not cover the order lifecycle, idempotency, nameservers, years, or how this step relates to check_order and pay_order.

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 38%, so the description needs to compensate for undocumented parameters such as domain, years, pay_with, nameservers, and idempotency_key. It only clarifies the balance value of pay_with, leaving most parameters without added meaning beyond the schema.

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

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

The description states a specific verb and resource: 'Create a registration order.' That is clear enough to act on, but it does not explicitly distinguish this tool from close siblings such as create_cart, pay_order, or buy_with_balance.

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 mention that 'pay_with=balance pays instantly from prepaid balance' implies one usage path, but the description does not say when to use this tool versus create_cart, pay_order, or buy_with_balance. There are no exclusions or prerequisites.

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

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

No annotations are provided, so the description carries the full burden; it does disclose the transport (DNS-over-HTTPS), the graded output, and that concrete fixes are returned, which reveals it is a read-only audit. It does not state auth requirements, rate limits, or whether selectors fall back automatically in a deterministic way.

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

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

A single dense sentence with the resource and method front-loaded and no filler. The enumeration of record types makes it long but every clause maps to a capability the 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 2-parameter read-only audit tool with no output schema, the description covers what is inspected and the shape of the result (grade plus fixes). Only minor gaps remain, such as expected inputs for domain format and any auth/quota expectations.

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 50%: 'domain' has no description and 'dkim_selectors' is only marked 'comma-separated'. The description compensates partially by clarifying that DKIM selectors may be common (default) or explicitly given, which explains what omitting the parameter does.

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 resource and action: a DNS plus email security audit enumerating A/AAAA/MX/NS/CAA, SPF, DKIM, DMARC, plus an A-F grade and fixes. This is clearly distinguished from the sibling get_dns (likely raw record retrieval) by the email-security and grading scope.

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

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

The description implies the usage context (checking a domain's DNS and email-auth posture), but never states when to prefer this over get_dns or whois_lookup, nor any prerequisites or exclusions. Usage must be inferred from the listed checks.

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

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

With no annotations, the description carries the burden well: it discloses the default result cap (summary plus top 25), the contents of each row (quality reasons, est. value, price, pre-built create_order/watch bodies), and a concrete cost/path for bulk retrieval ($0.01 x402, up to 500 rows). It omits auth prerequisites, rate limits, and whether the paid path is a separate tool call or a raw HTTP request the agent must make itself.

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

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

Front-loads the identity and filter capability, then drops into result shape and the two escalation paths. It is a dense single paragraph with some clause packing, but no sentence 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?

Return shape is described thoroughly enough that the absence of an output schema is not a problem, and the bulk/alert escalation paths are covered. However, for a tool with twenty unfiltered parameters and no annotations, the definition leaves too much of the input surface undefined for an agent to build a precise query.

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?

Twenty parameters with 0% schema description coverage means the description must define them, and it only gestures at filter families (TLD, length, keywords, value, quality, drop date). The six preset values are helpfully enumerated, but enums for sort and status, and parameters like min_age, starts_with, ends_with, no_digits, no_hyphen, dictionary, max_price and limit are left entirely undocumented.

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 resource (domain drops) and enumerates the exact filters and presets it applies, so the agent knows this is a filtered drop-listing tool rather than a search or valuation tool. It never explicitly contrasts itself with the near-sibling find_dropping_domains or is_domain_dropping, so sibling differentiation is only implicit.

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 two clear routing rules: use the x402-paid GET /api/v1/drops/full when more than ~25 rows are needed, and use radar_alert for future notifications. It stops short of saying when to prefer this over find_dropping_domains or search_domains, which are the tools an agent is most likely to confuse it with.

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

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

No annotations are provided, so the description carries the full behavioral burden. It usefully discloses that the estimate is 'heuristic' and that the output includes a factor breakdown and availability, but it does not state whether the operation is read-only, whether it incurs cost, or whether any rate limits or permissions apply.

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

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

The description is a single front-loaded sentence that states the estimate type and resource first, then enumerates the valuation factors. The parenthetical list is dense but every item contributes relevant scope 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 annotations and no output schema, the description should be more explicit about return values and parameter expectations. It mentions factor breakdown and availability but does not describe output structure, and it leaves the domain format unspecified, though it is adequate for a simple one-parameter estimator.

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%, and the only parameter, 'domain', is not described in the schema. The description says 'for any domain' but does not specify expected format, such as root domain versus URL, punycode/IDN handling, or examples, so it does not compensate for the missing schema documentation.

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: 'Heuristic USD value estimate for any domain.' It also lists the signals used (length, TLD, dictionary words, brandability, Wayback age, backlinks) and mentions a factor breakdown, making the tool's purpose clear. It stops short of explicitly distinguishing it from siblings such as quote_domain or whois_lookup.

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

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

The description says it works 'for any domain' but gives no guidance on when to use this estimator versus alternatives like quote_domain, whois_lookup, or search_domains. There are no stated prerequisites, exclusions, or decision context for the agent.

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

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

With no annotations, the description carries the full burden and does substantial work: it explains how the quality score is built (Wayback site-vs-parked sampling, Common Crawl, brandability, spam heuristics), states the Majestic-backlink gating rule, discloses that parked/spam names are hidden by default, and notes quality_reasons ships per item. It omits auth, pagination and rate-limit behavior, but the disclosure of ranking logic and filtering defaults is well beyond typical.

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 resource and ranking concept before the methodology and routing clauses, and every clause carries information (score inputs, defaults, tier cap, purchase path). It is dense and long-ish but not padded; a slight trim of the heuristic list would improve it.

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 15-parameter tool with no annotations and no output schema, the description covers the essentials: filtering defaults, ranking semantics, result cap, per-item quality_reasons and the follow-up purchase action. The main residual gap is that the sort enum's seven values and result pagination are 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 description coverage is only 20% across 15 parameters, so the description should compensate and largely does not. It adds meaning only for the hide-by-default flags (show_parked, include_spam) and the status=available path; q, tld, sort's seven enum values, min_brand, min_quality, min_backlinks and the length/price filters are left to infer from their names.

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

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

States a specific verb and resource ('Find expiring, pending-delete and just-dropped domains') and defines the ranking signal (verified 0-100 quality score) plus its inputs. It clearly distinguishes itself from drop_radar, which is named as the alternative for presets, estimated value, multi-TLD and keyword filters.

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?

Names drop_radar explicitly with the conditions that select it (presets, estimated value, multi-TLD, keyword filters), and routes buying to create_order for status=available names. It also flags the free-tier cap of 25 results, which sets expectations. It stops short of covering other plausible siblings like search_domains or is_domain_dropping, so it is strong routing rather than exhaustive.

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

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

No annotations are provided, so the description carries the full behavioral burden. It does not confirm this is a read-only operation, nor does it describe permissions, rate limits, or what happens on a missing slug.

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 redundant or filler content. Nothing could be trimmed without losing meaning.

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

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

For a one-parameter read tool with no output schema and no annotations, the description should at least sketch what the profile contains or the not-found behavior. It is adequate to start a call but leaves the agent guessing about results and errors.

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 one parameter at 0% schema description coverage, so the description must compensate. 'By slug' identifies the parameter's role but adds nothing about slug format (handle vs. URL path, casing, uniqueness), which is the main ambiguity an agent would hit.

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?

Uses a specific verb ('Get') and a specific resource ('agent directory profile'), narrowed to a single record fetched 'by slug'. It is distinguishable from search_agents and list_my_agent by the singular/one-profile scope, 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?

The phrase 'by slug' implies usage (call this when you already know the agent's slug), but there is no explicit when-to-use or when-not-to-use guidance and no pointer to search_agents for when the slug is unknown.

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

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

No annotations are provided, so the description carries the full disclosure burden. It implies a read but never states that it is read-only, whether it requires authentication, what the balances are denominated in, or how much ledger history comes back. For a zero-argument account-information tool this leaves meaningful gaps.

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

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

It is certainly concise, but the terseness comes at the cost of a verb and any scope statement, so it reads as a stub rather than a front-loaded summary. Extra length is not the problem; missing substance is.

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, no annotations, and no parameters, so the description is the only carrier of information — and it does not say what the response contains (current balance only? currency? ledger entries and their fields?), nor any precondition such as being logged in. Given the total absence of structured support, this is insufficient.

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; the baseline for a parameterless tool applies. No parameter-level omissions to penalize.

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 resource ('prepaid balance and ledger'), which adds information beyond the tool name by indicating both a balance figure and transaction history. However, it is a bare noun phrase with no verb, so it never explicitly says it retrieves/returns these values. It is loosely distinguishable from mutation siblings like topup_balance and buy_with_balance, but only by implication.

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 at all: nothing says to call this before buy_with_balance to check funds, or how it relates to topup_balance or referral_stats. The agent must infer the context from the tool 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?

With no annotations, the description carries the full behavioral burden. It discloses the ownership constraint and enumerates the record types returned, which is useful, but it does not explicitly state that the operation is read-only, what happens if the domain is not owned, or whether the lookup is live or cached.

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 most important information, what is retrieved, is stated immediately.

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

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

For a simple one-parameter read tool with no annotations or output schema, the description gives the key return categories and ownership constraint. It is reasonably complete, though it could clarify error behavior and output shape 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%, so the description must compensate for the single domain parameter. It adds the meaningful constraint that the domain must be owned by the caller, but it does not specify expected format (apex vs. subdomain, IDN handling, trailing dot) beyond that.

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

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

The description states a clear resource: nameservers and specific DNS record types for a domain. It is specific enough for an agent to understand the tool retrieves DNS data, though it does not explicitly differentiate itself from siblings like set_dns or dns_email_check.

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

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

It implies a prerequisite ('a domain you own') but gives no explicit guidance on when to use this versus alternatives such as dns_email_check, whois_lookup, or set_dns. The agent must infer usage context entirely from the tool name and description.

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

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

With no annotations, the description carries the full burden, and it does disclose non-obvious business behavior: a 30-day attribution window and 10% of margin on paid orders from referred parties. It does not explicitly state that the call is read-only with no side effects or whether agent/partner status is required, which keeps it below 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 with no filler; the return value and link format are front-loaded, and the second sentence adds only the payout rule and the propagation instructions 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?

There is no output schema, and the description compensates by naming what comes back (code and shareable link) plus the attribution terms. Given a zero-parameter read tool, the only real gap is the lack of explicit differentiation from get_referral_stats.

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 the baseline is 4. The description additionally explains the ref=<code> token syntax and where that token is consumed, which is useful even though it applies to sibling tools rather than to this call itself.

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 concretely what the tool returns: the caller's referral code and a shareable link with the ?ref=<code> format. It is clear and specific, but it never mentions the closely related sibling get_referral_stats, so the agent must infer the split between 'get my link' and 'get my referral performance'.

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 downstream usage context — pass ref=<code> on create_order, create_cart, or transfer_domain — which tells the agent exactly what to do with the output. It stops short of explicit when-to-use/when-not guidance relative to get_referral_stats or of stating prerequisites such as an authenticated agent account.

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

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

With no annotations, the description must carry the behavioral burden. It usefully discloses the payout mechanics (USDC on Base, weekly batching, $5 minimum, capped, admin-approved, sent to the payout address), which is real context. It does not state read-only nature, auth/account requirements, or whether values are cached/live, so gaps remain for a no-annotation tool.

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

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

Two tight sentences: the first front-loads the returned metrics, the second qualifies the payout semantics. Every clause conveys distinct information with 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?

With no output schema, enumerating the return fields (clicks, referred users, sales, USD buckets, recent sales and payouts) is exactly the right compensation, and the payout details round it out. Minor gap: no mention of time range or scope of the aggregates.

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 the baseline is 4. The description requires no parameter explanation, and there is no ambiguity to resolve.

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 opens with 'Referral dashboard' and enumerates exactly what is returned (clicks, referred users, sales, USD buckets, recent sales and payouts), so an agent can tell this is the stats-viewing tool rather than get_referral_link or set_payout_address. It lacks an explicit verb like 'retrieve', but the resource and its contents are unambiguous.

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

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

The usage context is implied: it is a reporting/dashboard read distinct from get_referral_link (getting a link) and set_payout_address (configuring payouts). However, the description never states when to call it versus those siblings, nor any prerequisites such as needing an existing referral account.

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

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

With no annotations, the description carries the full disclosure burden. It implies a read ('get', 'list') and itemizes the returned fields — which is genuinely useful — but says nothing about permissions, whether the vault figure is live or cached, or what 'ledger' contains. The read-only safety profile is only inferred from the verb, not stated.

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

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

Two tight sentences: the payload enumeration first, the parameter rule second. No filler and nothing repeated from the schema.

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

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

With no output schema, the description must convey the return shape, and it does by listing six returned values — enough to decide whether to call it. The only gap is that opaque fields like 'ledger' and 'shortfall' are named but not characterized.

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 sole parameter is undocumented structurally; the description compensates fully by explaining that supplying 'domain' scopes to one domain and omitting it enumerates all owned domains. That is exactly the semantics an agent needs for this optional parameter.

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

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

Names a specific resource — the auto-renew vault for a domain — and enumerates exactly what it returns (balance, 1-year price, coverage, shortfall, days to expiry, ledger). This clearly distinguishes it from the account-level get_balance or renew_domain, though it never names those siblings 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 'omit domain to list all' sentence gives a clear behavioral rule for the optional parameter, but there is no guidance on when to reach for this tool versus renew_domain, get_balance, or quote_domain — the agent must infer that from the described return fields.

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

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

No annotations exist, so the description carries the full burden. It usefully discloses the return shape (lifecycle enum values, estimated drop date, backlink data, and the 'if in our drop feed' condition), which is valuable with no output schema, but says nothing about cost, rate limits, or behavior for domains outside the feed beyond that conditional.

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 purpose question is front-loaded, then the return contents. No wasted words; the only minor cost is that the question form delays the concrete 'this returns drop status' framing by a few tokens.

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

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

For a simple one-parameter read tool with no annotations and no output schema, the description covers what it does and what comes back, including the conditional nature of backlink/drop-feed data. Missing only the out-of-feed case handling and expected domain input format.

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?

One required parameter with 0% schema description coverage, so the description must compensate. It implies the parameter is the domain to check but adds no format guidance (apex vs. subdomain, with/without TLD, IDN handling), which is the main gap for a domain-lookup tool.

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

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

The description names a specific verb+resource ('Is an expired domain about to become available?') and enumerates the returned lifecycle states, so the agent knows exactly what the tool answers. It is distinguishable from find_dropping_domains (bulk discovery) only implicitly, without naming the sibling.

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 by the question form — check one known domain's drop status — but there is no explicit statement of when to prefer it over find_dropping_domains, watch_domain, or whois_lookup, nor any exclusions. The agent must infer the single-domain vs. discovery split from the sibling names 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?

With no annotations provided, the description carries the entire burden and delivers almost nothing: read-only behavior is only implied, and there is no word on pagination, result limits, ordering, or whether expired/pending domains are included. For a listing tool with zero annotation coverage this leaves the agent guessing about invocation 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?

Six words with no waste, but the terseness crosses into under-specification rather than efficient front-loading. A single short sentence is appropriate in size but does too little work.

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, no annotations, and no parameters, so the description is the only source of information about the return value — and it says nothing about shape (array of names? objects with expiry dates?), ordering, or pagination. Given a complex domain-management toolset, this is not sufficient.

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 no parameters, so the baseline is 4; the phrase 'owned by the caller' usefully confirms that scoping is implicit rather than filterable. There is nothing further for the description to document.

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 fragment 'Domains owned by the caller' names the resource and a scope qualifier (caller-owned), which implicitly separates it from search_domains and find_dropping_domains. But it omits any verb (list/retrieve) and never states whether expiry, transfer status, or DNS records are included, so the purpose is only partially pinned down.

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

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

There is no guidance on when to call this versus search_domains, suggest_domains, or watch_domain; the agent must infer from the name alone. No prerequisites, no exclusions, no mention of whether an authenticated account is required.

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

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

With no annotations, the description carries the full burden. It usefully discloses the returned content (all statuses plus review notes) and notes that submission is auth-gated and moderated, but says nothing about whether this listing itself requires auth, whether results are paginated, or their ordering.

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 with the core scope front-loaded. The second sentence about the POST submission route is slightly off-scope for a listing tool, but it earns its place by preventing a mistaken submit attempt through this 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?

No output schema and no annotations mean the description must cover return shape; it names the statuses and review notes but omits pagination, ordering, and whether an empty list or auth failure is possible. Adequate for a zero-parameter lister, but not 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?

Zero parameters, so there is nothing for the description to disambiguate; baseline 4 applies. The description correctly implies a no-argument call returning the caller's own submissions.

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 with scope: 'Agent profiles you submitted (any status: pending, approved, rejected)'. The 'you submitted' qualifier cleanly separates it from search_agents/get_agent, though it never names those siblings 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?

Implies the use case (reviewing your own submissions and their review notes) and redirects submission to POST /api/v1/agents. It gives no explicit when-not guidance and does not name get_agent or search_agents as alternatives for viewing other agents.

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

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

With no annotations, the description carries the full behavioral burden. It discloses useful input behavior such as EVM hash versus Solana signature and gasless x402 EIP-3009 payment, but it does not state whether payment changes order status, is irreversible, requires prior steps, or what happens on failure.

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 a single front-loaded sentence with no wasted text. The colon structure and "or" cleanly separate the two payment options.

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 payment mutation with no annotations and no output schema, the description is incomplete. It does not explain the required order_id, the lifecycle effects of submitting payment, idempotency, or expected response behavior.

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 description must compensate. It explains tx_hash and x_payment with useful format details, but it omits any explanation of the required order_id parameter, leaving a meaningful gap for a 3-parameter tool.

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

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

The description uses a specific verb, "Submit payment," and explains the two accepted payment modes, tx_hash and x_payment. It is clear what the tool does, but it does not explicitly say it pays a specific order or distinguish itself from siblings such as buy_with_balance or topup_balance.

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: tx_hash is described as coming from "your transfer," and x_payment is a gasless payload, suggesting the tool is used after funds have been sent or an x402 payload exists. There is no explicit when-to-use guidance, no prerequisites, and no mention of alternatives like buy_with_balance or check_order.

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

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

No annotations are provided, so the description carries the full disclosure burden, yet it only asserts the quote is 'live' — nothing about currency, quote validity/expiry, whether it is binding for a subsequent create_cart/create_order, or whether pricing depends on years. For a pricing tool that feeds a purchase flow, these are material gaps.

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

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

One short, front-loaded sentence with no filler. It is efficient, though partly because it omits required information rather than because it is well-edited.

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 annotations, no output schema, and 0% schema description coverage across two parameters, the description should explain the 'years' input and the shape/validity of the returned quote. It does neither, leaving the agent unable to call the tool correctly in a purchase workflow.

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% and the description only clarifies that 'domain' is a single value. The 'years' parameter — which presumably scales the quoted price — is never mentioned, so the agent gets no guidance on its meaning, default, or allowed range.

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 sentence names a specific verb ('Live price quote') and resource ('one domain'), so an agent can tell this apart from search_domains or buy_with_balance. It does not explicitly distinguish itself from the adjacent estimate_domain_value, which is the closest sibling and the likeliest source of confusion.

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 statement of when to call this versus estimate_domain_value (valuation) or search_domains (availability/pricing search), and no prerequisites such as whether the domain must be registered or a TLD supported. The agent must infer the call context entirely.

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

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

With no annotations provided, the description carries the full burden and does so thoroughly: it names the webhook event, signature header and HMAC scheme, returned secret, email double opt-in, account/IP limits, and daily event cap.

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?

Despite being a single dense sentence, it is front-loaded with the core action and every clause adds operational value: webhook format, opt-in behavior, limits, and filter compatibility. There is 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?

Given the missing output schema and annotations, the description is substantially complete, covering delivery channels, security signing, limits, and trigger behavior. It still leaves the optional `name` parameter and exact response shape slightly underspecified.

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

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

The description adds useful meaning for `filters` by pointing to `drop_radar`, and clarifies the `email` and `webhook_url` behavior. However, schema coverage is only 25%, and the `name` parameter remains unexplained in both the schema and description.

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

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

The description states a specific action and resource: saving a Drop Radar search to receive alerts. It clearly distinguishes this persistent alert setup from the one-off sibling `drop_radar` by describing ongoing webhook/email notifications.

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 explains the trigger conditions well, covering new matches and pending-delete drops, and references `drop_radar` for filter fields. It does not explicitly say when to choose this over alternatives like `watch_domain`, but the intended use is clear.

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

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

With no annotations, the description carries the burden well: it discloses the two-step payment behavior (returning USDC payment requirements with a 402) and the instant balance-based path, plus the ownership prerequisite. It omits idempotency behavior and whether repeated renewals stack years.

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 the action and followed by the payment-mode distinction; no wasted words.

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

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

For a mutating, 6-parameter tool with no annotations and no output schema, the description covers the core flow but leaves gaps: how to complete the 402 payment, default years, and idempotency guidance are all missing, which an agent may need to call it correctly.

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

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

Schema coverage is only 33%, so the description should compensate more. It usefully explains pay_with=balance semantics (instant renewal from prepaid balance), but says nothing about 'years' (duration of renewal) or 'idempotency_key', both of which remain undocumented; chain/token partials are covered in the schema.

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

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

States a specific verb+resource ('renew a domain you own') and immediately distinguishes the two renewal paths (402 payment vs pay_with=balance). It is clear what the tool does, though it doesn't explicitly differentiate itself from the related set_auto_renew sibling.

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 by 'renew a domain you own' and by the pay_with alternative, but there is no stated when-not, no prerequisite detail (e.g., must be near expiry), and no pointer to set_auto_renew for automatic renewal.

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

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

No annotations are provided, so the description carries the full burden. It usefully discloses the directory is curated ('approved') and enumerates the returned fields, but says nothing about pagination, default/maximum result counts, sorting, or whether results are ranked by relevance.

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 verb and resource, with the field enumeration serving a real purpose since no output schema exists. Nothing is redundant.

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

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

The return-shape sentence compensates well for the missing output schema, and the curated-directory framing sets expectations. The remaining gap is parameter behavior (limit, matching rules), but for a read-only keyword search the description is largely sufficient to call it correctly.

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

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

Schema description coverage is 0%, so the description must carry parameter meaning, and it only partially does. It maps 'keyword' to q and 'capability' to capability but never explains matching semantics (exact vs substring, which fields q searches), and the 'limit' parameter is not mentioned at all.

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 ('Search the StableDomains.net agent directory') and scopes it ('approved AI agents and MCP servers'). It does not explicitly distinguish itself from the sibling get_agent, so an agent must infer that 'search' is for discovery and 'get' is for lookup by identifier.

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?

Mentions 'by keyword or capability', which implies the two search modes, but gives no explicit when-to-use guidance or exclusions. It never names get_agent or list_my_agent as the alternative for retrieving a single known agent, leaving that routing 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?

No annotations exist, so the description carries the full burden. It does disclose the return content (availability plus USD price per TLD), which is valuable, but says nothing about whether results are cached/live, rate limits, or how many TLDs are scanned.

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

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

One short sentence with the action and the two returned values front-loaded. Nothing wasted, nothing buried.

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 tool with no output schema, the description covers the essentials of what comes back. However, the input format for 'q' and the scope of the TLD scan remain unspecified, which are the details an agent most needs.

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

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

The single parameter 'q' has 0% schema description coverage. The phrase 'for a name across TLDs' hints that q is the label without an extension, but this critical ambiguity (can q include a TLD?) is never resolved explicitly.

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: checks availability and USD price for a name across TLDs. This distinguishes it reasonably from siblings like buy_with_balance, quote_domain, and estimate_domain_value, though it never names those siblings 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 usage is only implied: an agent can infer this is the pre-purchase availability check, but there is no statement of when to prefer it over quote_domain, estimate_domain_value, or whois_lookup, and no prerequisites or exclusions are given.

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

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

With no annotations, the description carries the full burden. It discloses key behavior: deposit_usd and withdraw_usd move USDC from the prepaid balance, and the daily job renews 1 year at ≤30 days if the vault covers the price, otherwise sending reminders at 30/14/7/1 days. It also states ownership requirement, leaving only edge cases like simultaneous deposit/withdraw or failure modes unaddressed.

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

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

Three sentences with zero waste. The core purpose is front-loaded, followed by vault mechanics and renewal automation, each sentence earning its place.

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

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

For a mutation tool with no annotations and no output schema, the description provides the essential context: ownership prerequisite, fund flow between prepaid balance and vault, and the renewal schedule. It omits return value details and failure conditions, but covers enough for correct invocation.

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

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

Schema description coverage is 0%, so the description must compensate. It clearly defines deposit_usd (moves USDC from topup_balance into the domain's vault) and withdraw_usd (moves it back), and implies enabled via 'turn auto-renew on/off'. The domain parameter is obvious from the purpose. However, it does not clarify whether deposit_usd and withdraw_usd can be used together or what happens if enabled is omitted.

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

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

The description clearly states a specific verb and resource: toggle auto-renew for a domain and fund/withdraw its renewal vault. It distinguishes this from sibling tools like renew_domain (immediate renewal) and topup_balance (prepaid balance top-up) by explaining the vault mechanics.

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

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

The description implies when to use the tool (to enable auto-renew or manage the vault) but does not explicitly name alternatives such as renew_domain for immediate renewal or get_renewal_balance for checking balance. The daily-job behavior gives useful context but no explicit exclusion guidance.

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

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

With no annotations, the description carries the full behavioral burden. It usefully discloses that this is a replace operation and that the full desired record set must be supplied, but it does not cover permissions, rate limits, partial-update behavior, error cases, or propagation effects.

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

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

The description is front-loaded, compact, and every sentence adds useful operational information. The inline records example is especially efficient.

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

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

For a DNS mutation tool with no annotations or output schema, the description covers the key replace semantics, record shape, and get_dns workflow. It is mostly complete, though nameserver replacement details and failure behavior are left implicit.

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 description must compensate. It does well for the complex records parameter by explaining type values, '@' versus subdomain names, optional ttl, and MX-only priority, but it leaves the nameservers parameter only named rather than explained.

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

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

The description states a specific verb and resource: replacing the DNS record set and/or nameservers of a domain. It clearly distinguishes this write/replace operation from the sibling get_dns read 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?

It gives the critical usage rule: pass the FULL desired set, and call get_dns first when appending. It also implies the prerequisite that the caller must own the domain.

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

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

With no annotations, the description carries the full burden. It usefully discloses what triggers delivery (domain.expiring at 30/7/1 days, domain.renewed, domain.transfer_completed), which is real behavioral detail. But it omits whether the webhook is singular/account-wide (implied by 'Account webhook' but not stated), whether setting a new URL overwrites the previous one, and the HTTP delivery contract (method, payload shape, retries) an agent would need to predict effects.

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 terse fragments, zero padding, with the event enumeration and the null-removal escape hatch both front-loaded. Slightly clipped to the point of reading as notes rather than a sentence, but 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 one-parameter, no-output-schema tool this is close to sufficient: the agent knows what event types it subscribes to and how to unset it. What's missing is the overwrite/singleton behavior and delivery mechanics, which matter because a mutation with no annotations has nothing else to lean on for safety expectations.

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 schema only types the parameter as string-or-null without explaining the null case. The description supplies that meaning explicitly ('null to remove'), which is exactly the kind of semantic the agent cannot infer from `type: [string, null]`. Minor gap: no URL format or HTTPS requirement.

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

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

The description names the resource (account webhook) and enumerates the exact lifecycle events it covers, which is genuinely specific. However it omits the verb – it reads as a noun phrase ('Account webhook for lifecycle events') and relies on the tool name to convey that this configures/sets the endpoint. The concrete event list rescues it from vagueness, but a reader of the description alone doesn't get an explicit action.

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?

'null to remove' is the only usage instruction, covering teardown but not setup context. There is no statement of prerequisites (e.g. ownership, account-level scope), no mention of whether this replaces an existing webhook, and no guidance relative to any sibling tool, all of which are domain/payment operations with no webhook parallel.

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

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

With no annotations, the description must carry the behavioral burden, and it does disclose useful traits: the payout cadence (weekly), the network/asset (Base USDC), and the destructive-ish null-to-clear semantics. It omits address-format validation, whether an existing address is overwritten, auth requirements, and when the new address takes effect — meaningful gaps for an unannotated mutation.

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 zero waste; the core action comes first and the null-clearing edge case is tucked into a parenthetical.

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 mutation with no output schema and no annotations, the description covers the what, the parameter's meaning, and the clear case — enough to call it correctly. Missing permission/validation and effect-timing details keep it from being fully complete.

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

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

Schema coverage is 0%, so the description has to explain the single parameter, and it does: the value is a Base USDC receiving address for referral payouts, and null clears it. The only shortfall is that the expected address format (e.g., EVM 0x-prefixed) 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+resource ('Set the Base USDC address') and adds the purpose (receives weekly referral payouts), so an agent immediately knows what changes. It does not explicitly contrast with any sibling, though no sibling (set_dns, set_auto_renew, get_referral_stats) plausibly overlaps, so the ambiguity risk is low.

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: an agent can infer this is the tool for directing referral payouts, and 'null to clear' signals the unset case. There is no explicit when-to-use guidance, no prerequisites (authentication, existing referral earnings), and no mention of alternatives or timing of effect.

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

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

With no annotations, the description does substantial work: it discloses a live registrar check, returns only available names, includes USD price, checkout_url, and a create_order body, and notes a free limit of top 10 of 24 checks. It still leaves some behavioral details unstated, such as rate limits beyond the free cap and whether the operation has any side effects.

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

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

The description is compact and front-loaded: it states the core action, then the return behavior, then the free quota. Every sentence carries useful information with 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 tool with no output schema and no annotations, the description usefully explains the return shape and availability behavior. However, it does not document the tlds and max_price parameters, and it omits some operational context needed to call the tool confidently.

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 33%: idea is documented, but tlds and max_price have no schema descriptions. The tool description does not compensate by explaining what tlds or max_price do, so two of three parameters remain semantically unclear.

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

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

States a specific verb and resource: generate brandable domain names for a product idea, with live availability checks. It is clear what the tool does, but it does not explicitly distinguish itself from sibling tools such as search_domains.

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

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

The use case is implied by 'for a product idea' and the availability check, but there is no explicit when-to-use guidance, exclusions, or comparison to alternatives like search_domains or quote_domain.

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

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

No annotations are provided, so the description must carry the full behavioral burden. It discloses that this creates an order and that payment follows the normal order flow, but it omits critical details such as authentication requirements, idempotency behavior, order expiration, and what the returned order looks like.

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

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

The description is a single front-loaded sentence with no filler. It is efficient, though its terseness contributes to gaps in completeness rather than being a structural flaw.

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

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

This is a mutating, multi-parameter tool with no annotations and no output schema. The description covers the core purpose and amount range but omits essential context about idempotency, authentication, error/failure behavior, and how the created order is paid or returned.

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 50%: chain and token have enum descriptions, but amount_usd and idempotency_key are undocumented in the schema. The description compensates partially by specifying the allowed amount range (USD 5–5000) for amount_usd, but it still says nothing about idempotency_key or its semantics.

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

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

The description states a specific verb and resource: 'Create a top-up order', and adds the amount range (USD 5–5000). It is clear what the tool does, but it does not explicitly differentiate itself from siblings like buy_with_balance or pay_order beyond saying 'pay it like any 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?

Usage is implied: use this to add funds to a balance via a top-up order, then pay it like any other order. However, there is no explicit when-to-use versus when-not-to-use guidance, nor does it name alternatives such as buy_with_balance or direct payment options.

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

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

With no annotations, the description carries behavioral weight well: it discloses the payment method (USDC), the effect on the registration (+1 year), an external prerequisite (unlock at current registrar), and that completion is asynchronous over ~5-7 days. It omits what happens on failure (refund/charge timing) and whether funds are pulled immediately.

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 compact sentences, all front-loaded: what it does, how it's paid, prerequisite, then duration. No filler and nothing an agent must scan past.

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

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

Covers the essentials for a paid, slow mutation (cost currency, prerequisite, duration) but a tool with 8 parameters, 25% schema coverage, no annotations and no output schema needs more — particularly payment-source semantics (pay_with vs. token/chain) and what the call returns (order id, status to poll via check_order).

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 25% (chain and token are described; domain, auth_code, years, pay_with, ref, idempotency_key are not). The description clarifies auth_code as the EPP code and token default as USDC, but leaves years, pay_with (crypto vs balance), ref, and idempotency_key unexplained, and 'adds 1 year' leaves the relationship to the `years` parameter ambiguous.

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 ('transfer a domain in from another registrar') plus the mechanism (auth/EPP code) and payment currency, which cleanly separates it from renew_domain, create_order, and buy_with_balance. An agent can tell immediately this is an inbound registrar transfer.

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 prerequisite ('Unlock it at the current registrar first') and a timing expectation (~5-7 days), which is real usage guidance. It stops short of naming when to prefer this over siblings like create_order/pay_order or what to do if the transfer fails.

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

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

With no annotations, the description carries the full behavioral burden and does well: webhook is active immediately, it POSTs named JSON events (domain.status_changed / domain.available) whose payload is a ready order_api body, email requires double opt-in, and the service is free. It stops short of disclosing authentication requirements, watch duration or limits, and how to cancel a watch.

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 plus a parenthetical, front-loaded with the outcome ('Get notified when...') before the mechanics. Every clause adds information an agent needs to call the tool correctly; nothing is redundant.

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 and no annotations, so the description must stand alone; it covers delivery channel, activation timing, event names, payload shape, opt-in flow and cost. Missing pieces are lifecycle details — how long a watch persists and how to undo it — which matter for an agent managing state but are secondary to the initial 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 description coverage is only 33% (only webhook_url is annotated, as 'public https URL'), so the description must compensate — and it does, explaining that webhook_url is active immediately and what it POSTs, and that email uses double opt-in. The domain parameter's role is conveyed only by implication ('an expiring domain'), which is the remaining 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 uses a specific verb and resource — get notified when an expiring domain changes status or becomes registrable — so an agent can immediately tell this is a monitoring/watching tool rather than a search or purchase tool. It never names a sibling (e.g. is_domain_dropping or set_notification_webhook) to contrast with, which is the only thing separating it from 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?

Usage is implied through the 'and/or' construction: use webhook_url for push delivery, email for inbox delivery, or both. There is no guidance on when to prefer this tool over is_domain_dropping or find_dropping_domains, no stated prerequisites, and no mention of how or whether a watch can be removed.

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

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

No annotations are supplied, so the description must carry the behavioral load; it does signal that this is a passive read of public registration data and names the categories returned. It does not disclose rate limits, whether queries hit the live registry, or what happens for unregistered/invalid domains — meaningful gaps for a registry-facing 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 front-loaded sentence whose clause after the colon does real work by naming the returned fields. No filler, no redundancy with the schema.

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

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

For a single-parameter read tool with no output schema, the description supplies the essential missing piece: what data the response contains. The remaining omissions (domain input format, unregistered-domain behavior) are small but real for a tool with 23 siblings in a domain-management server.

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 is the only place to explain the sole required parameter, yet it only says 'any domain' without naming the parameter or clarifying format (bare apex vs. www, registrable domain vs. subdomain, IDN/punycode handling, whether a TLD is required). That is well short of compensating for the undocumented 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+resource ('RDAP (modern WHOIS) lookup for any domain') and enumerates exactly what it returns: registrar, created/expires dates, status codes, nameservers, DNSSEC. That field list clearly separates it from siblings like get_dns or dns_email_check, which cover DNS and email configuration rather than registration 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?

The scope 'for any domain' implicitly frames usage, and the returned-field list hints at the questions it answers (ownership age, expiry, delegation). But there is no explicit when-to-use/when-not, no mention of siblings such as get_dns or dns_email_check, and no note on prerequisites like a registered vs. unregistered domain.

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