DomainKits

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

Annotations already cover the read-only/idempotent/non-destructive profile, and the description adds genuinely new behavioral facts: which ccTLDs are visible depends on the caller's plan, an out-of-plan TLD returns an explanatory message rather than an error, and TLD browse mode requires a registered account. It also clarifies TLD family semantics ('br' vs 'com.br') that affect result scope.

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 scope statement is front-loaded and each sentence carries information (corpus size, ccTLD nuance, plan gating, use-case framing) with no filler. The ccTLD parenthetical is dense and overlaps slightly with the schema, keeping it just short of ideal economy.

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 an output schema present and 100% parameter coverage, the description need not explain return values. It supplies the missing context an agent needs for a 12-parameter search tool: corpus scope, plan-based visibility limits, and the registered-vs-available distinction.

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

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

Schema description coverage is 100% and 12 of 12 parameters are documented in the schema with enums and defaults. The description's parameter-related content (tld family expansion, keyword-omitted browse mode) largely restates what the schema already says, so it adds little beyond the structured baseline.

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

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

The description states a specific verb and resource ('Search active registered domains') and defines the corpus (360M names, generic plus 100+ ccTLDs). It explicitly distinguishes itself from the availability siblings by stating 'results are registered domains, not available for registration,' so an agent will not confuse it with `available` or `bulk_available`.

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 a clear context of use ('a market-analysis instrument for keyword distribution and saturation') and rules out the availability use case, plus names related tools (expired, whois, dns). It stops short of saying when to prefer each of those relatives over this tool, so the routing guidance is implied rather than explicit.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint=false, and destructiveHint=false, so the safety profile is covered. The description adds the useful behavioral note that results are live, owned domains (not registrable), which is genuine context beyond the annotations. But it says nothing about pagination limits, rate limits, or result shape beyond the registered-only constraint.

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 delivers purpose and filters, the second delivers the critical usage constraint, and the trailing 'Related:' line provides routing with minimal tokens. Front-loaded and waste-free.

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 14 optional parameters, an output schema, and full annotation coverage, the description provides the essential distinguishing context (live/owned vs registrable) an agent needs. It stops short of explaining pagination behavior or result fields, but the output schema exists and the most critical ambiguity is resolved.

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

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

Schema description coverage is 100%, so the schema already documents all 14 parameters, including the enum values and the tld_count_min/max range pattern. The description's generic list of filter axes ('keyword, TLD, age range, length, and sale status') adds no syntax or format detail beyond what the schema provides, so baseline 3 applies.

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

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

States a specific verb and resource ('Search currently registered domains') with a precise qualifier (5-20+ years of history) and enumerates the filter axes. The key sentence 'These are live domains owned by someone, not free to register' crisply distinguishes it from siblings like 'available' and 'unregistered_ai'.

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 'Related: expired, whois, dns' line explicitly names alternatives, and the 'not free to register' clause implies when this tool is preferred over 'available'. However, it doesn't state when to choose this over 'expired'/'deleted' or what those siblings return instead, so the routing guidance is suggestive rather than decisive.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so safety is covered. The description adds genuinely new behavior: concurrent invocations are rejected and return no data, which the agent cannot infer from structured fields. It stops short of detailing rate limits or pricing-source caveats, so not a full 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?

Four short sentences, front-loaded with the core purpose before the routing rule and the concurrency warning. The trailing 'Related:' list adds navigational value without padding the prose.

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?

An output schema exists, so return values (price, registrability) need not be explained here, and the description mentions the price dimension anyway. With safety covered by annotations and the concurrency hazard called out, nothing an agent needs to invoke this correctly is missing.

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

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

Schema description coverage is 100% and the single parameter is documented as a full domain with TLD including an example. The description adds only the 'single domain' scoping, not format or syntax detail, so baseline 3 applies.

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

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

States a specific verb and resource ('Confirm a single domain's registrability and price') and explicitly narrows scope to one domain, calling itself 'the definitive availability check for one domain.' This lets an agent separate it from siblings like bulk_available, tld_check, and whois without opening any schema.

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

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

Gives an explicit routing rule ('For two or more domains call bulk_available once instead of repeating this tool') plus an operational constraint on call sequencing (one call, wait, then next; parallel calls rejected). Both when-to-use and how-not-to-use are spelled out.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, openWorldHint=false and destructiveHint=false, so the safety profile is fully covered elsewhere. The description adds only a list of returned metrics, which is largely redundant with the existing output schema, and says nothing about rate limits, caching, or failure modes.

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

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

Front-loaded with the action and payload in a single efficient sentence, followed by a short pointer. No filler or repetition of the title. The 'Related: whois' fragment is minimal but doesn't clutter.

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 a rich output schema and full annotation coverage on a read-only, idempotent single-parameter tool, the description is close to sufficient. Its only real gap is the absence of guidance about when this analysis is the right one to call relative to the many sibling SEO tools.

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

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

The single 'domain' parameter has 100% schema description coverage, including format constraints (bare domain, no protocol/path/port, punycode for IDN), so the schema carries the full burden. The description adds no additional parameter meaning, which matches the baseline 3 for high coverage with a non-zero parameter count.

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 (Return) and resource (a domain's backlink profile) and enumerates the profile components (domain rank, total backlinks, referring domains, spam score, link distribution). It does not differentiate itself meaningfully from the many sibling analysis tools beyond a bare 'Related: whois' pointer, which is about a different tool rather than a contrast.

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 when-to-use guidance, no prerequisites, and no statement of when another sibling (e.g. keyword_data, tld_rank, whois) would be the better choice. The trailing 'Related: whois' hints at adjacency but offers no selection criteria.

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

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

Annotations already cover readOnly/idempotent/destructive safety, and the description adds genuinely new behavioral facts on top: parallel calls are rejected and return no data, and a failed check does not count as available. The concurrency restriction and failure semantics are exactly the kind of context annotations cannot express.

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 purpose, then the concurrency constraint, then the value glossary, so a reader can stop early if they only need the summary. The value glossary is slightly long, and some of it may overlap with the output schema, but each sentence carries information.

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

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

For a single-parameter, read-only, output-schema-backed tool, the description covers purpose, batching limit, concurrency rules, result-value semantics, and failure handling. Nothing an agent needs in order to call it correctly is missing.

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

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

Schema coverage is 100% and there is only one parameter, so the schema already documents the comma-separated FQDN format and the 50-domain maximum. The description restates the 50-domain limit but adds no new syntax or formatting detail. Baseline 3 is appropriate when the schema does the heavy lifting.

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

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

States a specific verb and resource ('Check the registration status of domains') with an explicit scope of 'up to 50 domains at a point in time.' An agent can immediately tell this is the batch variant of a single-domain check, though the description never names the sibling 'available' or 'bulk_tld' to make the routing explicit.

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 clear operational guidance: concurrent calls are not supported, send one batch, wait for the result, then send the next. This tells the agent how and when this tool may be invoked (serial use only). It stops short of naming an alternative tool for single-domain or TLD-specific checks, so it is not a full 5.

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

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

Annotations already cover the safety profile (read-only, idempotent, non-destructive, closed-world). The description adds genuinely useful behavior beyond that: the output is counts only, it does not enumerate TLDs, and it tracks a bounded TLD set rather than all TLDs. That scope and output-shape disclosure is the kind of context annotations cannot convey.

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

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

Two tight paragraphs, front-loaded with the core behavior and scoping, followed by the routing line. Every sentence carries information and none 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?

An output schema exists, so return formatting need not be explained, yet the description still clarifies that counts (not lists) are returned. Combined with annotations covering safety, nothing an agent needs to select and call this tool is missing.

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

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

Schema coverage is 100% and the single 'keywords' param already documents itself with the max-50 constraint. The description adds the exact-match semantics (each name is evaluated as keyword.tld), which is meaningful, but otherwise restates the schema. Baseline 3 is appropriate.

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

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

States a specific verb and resource: count how many TLDs each exact name is registered in, with the scope ('among the TLDs DomainKits tracks') and the breakdown (popular/country-code/other gTLDs). It also names the sibling tools it is not (tld_check, bulk_available), so it is distinguishable without opening any schema.

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

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

The 'Related' line routes the agent well: tld_check for per-TLD status on one keyword and bulk_available for specific domain status, plus the 'does not list individual TLDs, check availability, or report sale status' exclusions. It stops short of an explicit 'use this when you want aggregate counts across keywords' trigger, but the context is clear.

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

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

Annotations already cover the read-only/idempotent/non-destructive profile, and the description adds genuinely new behavioral context: results reflect the latest data update and are not re-checked at query time, so a name may have been re-registered. That staleness caveat is exactly the sort of thing structured fields cannot convey, though pagination and rate-limit behavior are 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 front-loaded sentences with no padding; the freshness caveat and the verification step are placed where an agent will read them. The trailing 'Related:' list duplicates sibling names that are already visible in the tool list, a minor redundancy.

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

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

With an output schema present and rich annotations, the description needn't explain return values, and it covers the one non-obvious risk (stale results). Nothing essential is missing, though the interplay of tld_count_min/max and the exclusion flags is left to the schema.

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

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

Schema coverage is 100% across 14 parameters, and the description's filter list (keyword, TLD, age before deletion, length, character set, hold flag) largely restates what the schema already documents in detail. No syntax or interaction guidance is added, so the baseline 3 applies.

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

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

States a specific verb ('Search') and a precisely scoped resource ('domains that were deleted after expiring'), and lists the filter dimensions. This distinguishes it from siblings like expired, active, and available without any schema inspection.

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

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

Explicitly says to confirm with 'available' or 'bulk_available' before registering, naming the alternatives and the condition that selects them. It stops short of stating when NOT to use this tool versus 'expired' or 'aged', so it is clear but not complete.

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

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

Annotations already cover the safety profile (readOnly, idempotent, openWorld, non-destructive), yet the description still adds substantive context: how to read underscore-prefixed records and, critically, that _for-sale TXT strings starting with v=FORSALE1; are the holder's own unverified claim. That interpretation guidance is exactly the kind of value structured fields cannot convey.

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

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

Front-loads verb and resource, then layers edge-case handling in short, self-contained paragraphs. Efficient, though the _for-sale paragraph is dense enough that it could be trimmed slightly 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?

With an output schema present, return values need not be described, and the description still covers record types, name syntax, and result interpretation. The only thin spot is explicit routing versus whois/ns_reverse, which is named but not explained.

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

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

Schema coverage is 100% and the domain parameter's own description already covers bare hostname vs. fuller name, punycode, and the no-protocol/no-port rule. The description slightly reinforces this with underscore examples, but adds little beyond the schema, so the baseline 3 applies.

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

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

States a specific verb ('Resolve') and resource ('a DNS name's records') and enumerates the supported record types (A, AAAA, MX, NS, TXT, CNAME, SOA). This is clearly distinct from siblings like whois or ns_reverse, so an agent can pick it without opening the schema.

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

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

Gives concrete usage context for edge cases: underscore-prefixed names (_dmarc, _domainkey) and the RFC 10023 _for-sale convention. It names related tools (whois, ns_reverse) but does not state when to prefer this tool over them, so routing is left partly to inference.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds one genuinely useful behavioral fact — that the window is a rolling 7 days — but says nothing about result caps, pagination behavior, or how the 'premium' pool is defined.

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

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

One dense sentence front-loads the scope, followed by a short cross-reference line. No waste, though the cross-reference names tools without explaining the relationship, making it marginal rather than earned.

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 an output schema present and all 7 params documented in-schema, the description covers the essentials for a read-only filtered listing. It falls short only on disambiguating from siblings that surface expired/deleted domains.

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

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

Schema description coverage is 100% with 7 well-documented params including four enums, so the schema already carries the semantics. The description's 'filtered by change reason and length' merely restates two schema fields and adds no syntax, defaults, or format detail beyond them.

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 (List), resource (registration and status changes), and a precise scope (premium .com domains, 1-4 letter and high-value single-word names, rolling 7-day window). That is far more specific than most siblings, though it does not explicitly differentiate itself from overlapping siblings such as expired and deleted.

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 only routing aid is 'Related: whois, ns_reverse,' which names adjacent tools but never says when to use this one instead of expired, deleted, aged, or market. The reason enum ('Domain Expired', 'New Registration') overlaps siblings' territory without any disambiguation.

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

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

Annotations already declare readOnly, idempotent, non-destructive, and closed-world, so the safety profile is covered. The description adds meaningful behavioral content: which lookup keys match (code, alias, category), the no-query listing mode, and what each answer contains. No contradictions.

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

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

Front-loaded with the purpose, then the matching semantics, then the critical whois-then-code workflow and the caution against recall. Every sentence carries distinct information; 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?

An output schema exists, so return values need not be explained. For a single-optional-param reference tool with full annotation coverage, the description supplies purpose, usage routing, and matching semantics — nothing an agent needs to call it correctly is missing.

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

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

Schema description coverage is 100%, so the single 'query' parameter is already fully documented in the schema, including aliases/categories and the omit-to-list behavior. The description restates this rather than adding new syntax or format detail, so baseline 3 applies.

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

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

States a specific verb+resource: explains what a domain EPP status code means, why it is set, how serious it is, and what the holder can do. It also distinguishes itself from the closest sibling by noting it takes a code, not a domain name, unlike whois.

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?

Explicit routing: 'to see a domain's current codes call whois first, then pass each code here,' plus the no-argument listing behavior. It even states the intent (interpret the whois status field rather than relying on recall), leaving nothing to inference.

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

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

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds genuinely non-obvious context: registrars may renew after expiry and statuses come from multiple channels, so results can diverge from live WHOIS. It stops short of describing pagination behavior despite a 'page' parameter.

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 blocks: the capability and scope come first, the reliability caveat second, then a one-line pointer to related tools. Every sentence carries distinct information and nothing is 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 15 optional params, rich annotations and an output schema, the description covers what an agent most needs: what population is searched, why timing matters, and that data may be stale versus WHOIS. The main omission is any note on result volume/pagination, which matters for a 15-filter search tool.

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

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

Schema description coverage is 100% and the enums are already well documented (e.g. the status enum explains auction/redemption/drop timing). The description's 'Filter by lifecycle status, TLD, age range, length, character set, and registrar' merely recaps a subset of the filters without adding syntax or interaction details. Baseline 3 applies when the schema carries the load.

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 domains in the deletion cycle') and enumerates the exact lifecycle states covered (expired, redemption, pending delete). The phrase 'Still held by the current registrant' is the key differentiator from the sibling 'deleted' tool, so an agent can separate them without opening a schema.

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

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

Usage is implied rather than stated: 'time-sensitive acquisition windows' signals the acquisition use case, and the trailing 'Related: monitor, deleted, whois' points at alternatives. However, it never says when to pick monitor/deleted/whois over this tool or when this tool is the wrong choice, leaving 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?

Annotations already declare readOnly, idempotent, and openWorld, so the safety profile is covered. The description adds genuine behavioral context beyond them: domains are resolved to their first IPv4 before lookup, and results are IP-level/approximate and not the site owner's address. This is useful postcondition and limitation disclosure.

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 tightly packed sentences plus a short related-tools line. The purpose and result set are front-loaded ahead of the caveat and related list, with no wasted text.

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?

An output schema exists, so return values need no explanation, and annotations carry the safety profile. The description still covers purpose, input forms, domain-handling behavior, and the approximate-location caveat, leaving nothing an agent needs 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 100% and the query param is already documented (scheme/port/path/www stripping). The description adds meaning beyond the schema by clarifying that domains are accepted and resolved to their first IPv4 address, which the schema does not state.

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

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

The description opens with a specific verb ('Resolve') and precise resource ('an IP address or domain name'), then enumerates the returned fields (ASN, organization, country, region, city, coordinates, timezone). It names related siblings (dns, whois, ns_reverse), so an agent can distinguish this geolocation/ASN tool from adjacent lookups.

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 'Related: dns, whois, ns_reverse' line points at siblings but never states when to choose this tool over them or any exclusions. Usage is only implied by the returned fields and the domain-resolution note, with no explicit routing condition.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered by structured data. The description adds only the metric list, not caching behavior, rate limits, or whether data is live vs. cached. Adequate but thin beyond what annotations provide.

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

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

Two sentences, no filler, with the metric list front-loaded before the sibling reference. Every phrase earns its place in a description this short.

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?

An output schema exists, so return values need not be explained, and annotations carry the safety profile. Parameters are fully documented in the schema. The definition is functionally complete for invocation, with only the usage-routing gap keeping it from a 5.

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

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

Schema description coverage is 100%, with the country enum and default (US-EN) and the keyword parameter fully documented in the schema. The description adds no format, syntax, or constraint detail beyond that, so the baseline of 3 applies.

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

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

States a specific verb and resource: returns search-volume, CPC, and competition data for a keyword. It names the exact metrics returned, so an agent knows what it does at a glance. It hints at the sibling keywords_trends via 'Related' but does not articulate how the two differ, so it falls short of a 5.

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

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

The only guidance is the bare line 'Related: keywords_trends.' There is no statement of when to use this tool versus that sibling, no prerequisites, and no exclusions. The agent is left to infer all routing decisions.

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

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

Annotations already establish the safety profile (readOnlyHint, idempotentHint, openWorldHint=false), so the bar is lower, yet the description adds genuinely useful context beyond them: results are representative samples rather than a complete registry feed, and explicitly not demand measurement, valuation, or investment advice. It also flags the constraint that scope=com is unavailable for prefix, a behavioral limit not visible from annotations alone.

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 dense, front-loaded sentences with no filler; the core purpose leads and the scope caveats follow. Slightly long, but each sentence carries distinct 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 an output schema present, return values need no explanation, and annotations carry the safety profile; the description covers parameter meaning and the sampling disclaimer. The only notable gap is the absence of explicit routing guidance against sibling trend/keyword tools.

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

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

Schema coverage is 100%, so the baseline is 3, but the description goes beyond the thin schema text ('Trend dataset to return') by explaining that hot/emerging represent rolling keyword cohorts and prefix represents prefix activity buckets. That adds real semantic meaning to the enum values rather than restating 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 ('Return provider-computed keyword registration statistics') and explains what the three type values produce, so the agent knows exactly what the tool yields. It does not, however, explicitly contrast itself with near-siblings like keyword_data or tld_trends, leaving that differentiation 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?

The description clarifies what each type and scope value covers ('hot and emerging cover rolling keyword cohorts; prefix returns prefix activity buckets'), which implicitly guides selection among the enum values. It gives no explicit when-to-use or when-not-to-use guidance relative to alternative tools such as keyword_data or tld_trends.

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

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

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds the useful behavioral fact that results are live, owned domains (not parked or unregistered), but omits the account requirement for TLD browse mode (present only in the schema) and says nothing about result volume or pagination behavior.

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

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

Two sentences plus a short related-tools pointer, front-loaded with the core scope statement and no filler. Every clause earns its place.

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

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

With an output schema handling return values, 100% schema coverage on 14 params, and annotations covering the safety profile, the description provides enough to call the tool correctly. The remaining gap is sibling routing – nothing tells the agent why to choose market over market_price or available – which a 14-parameter tool in a crowded namespace would benefit from.

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

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

Schema description coverage is 100% with 6 enums, so the schema already documents every parameter in detail (including browse mode and count ranges). The description merely names the filter categories (keyword, TLD, TLD type, listing status, length, character set) without adding syntax or format meaning beyond it, which is the baseline 3 case.

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: 'Search currently registered domains that carry marketplace listing data,' with the filter axes enumerated. 'Results are live domains owned by someone' implicitly separates it from the available/deleted/expired siblings, but it never names an alternative (e.g. market_price) or sharply delimits itself, so it stops short of full sibling differentiation.

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

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

The 'Related: keyword_data, tld_check' line is a routing hint but does not say when to prefer this tool over them, nor when not to use it versus market_price or available. Usage is only implied by the scope sentence about live registered domains, not stated as an explicit condition.

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

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

Annotations already declare readOnly, idempotent, non-destructive and non-openWorld, so the safety profile is covered. The description adds real value beyond that: it enumerates the outcome states (for_sale, make_offer, not_found) and explains that not_found is scoped to a few marketplaces rather than a definitive negative, which aligns with and enriches openWorldHint=false.

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

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

Front-loaded with the core purpose, followed by return states and the coverage caveat — all earning their place. The trailing 'Related: available, aged.' is a thin, unqualified dangling line that slightly dilutes the structure.

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 an output schema, this is nearly complete: it explains outcome semantics and the coverage limitation so an agent will not over-interpret not_found. The remaining gap is sibling disambiguation against 'price' and 'market', which the description does not address.

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

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

With schema description coverage at 100% and only one parameter, the schema already documents 'domain' including an example. The description adds no format, normalization, or TLD constraints beyond that, so the baseline 3 applies.

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

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

States a specific verb and resource ('Check whether a domain is listed for sale on a supported aftermarket... the asking price'), and names the related siblings available and aged. An agent can distinguish this from a general price or market tool without opening the schema.

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

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

The 'Related: available, aged.' line implies related tooling but gives no condition for choosing between them, and critically does not differentiate from the sibling tools literally named 'price' and 'market'. The coverage caveat ('not_found does not mean the domain is not for sale elsewhere') is useful interpretive guidance, but explicit when-to-use routing is absent.

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

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

Annotations already declare destructiveHint=true and readOnlyHint=false, so the safety profile is covered; the description adds non-obvious context beyond that: AES-256-GCM encryption in a per-user directory, the requirement of a registered account with memory enabled, and that set is capped by the account tier's maximum. It lacks detail on pagination or failure behavior, but the additions are substantive.

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

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

Front-loads the purpose sentence, then a scannable action list, then prerequisites. Every line earns its place, though the action list is slightly verbose relative to the information density needed.

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 an output schema present, return values need not be explained, and annotations cover the safety profile. The description supplies prerequisites, encryption, tier limits, and action meanings, leaving little an agent needs for correct invocation, though sibling routing remains unaddressed.

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

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

Schema coverage is 100%, so the baseline is 3, but the description goes further by explaining what the action values actually do (get/set/update/delete/history) and clarifies the get-vs-history relationship, which the bare enum list in the schema does not convey.

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 ('Manage cross-platform domain monitoring tasks that track changes in WHOIS, DNS, and host-supplied page content'), which clearly conveys what the tool does. It does not, however, differentiate itself from plausible siblings like domain_changes or whois/dns, so an agent must infer which of the overlapping tools to use.

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

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

Provides explicit per-action semantics and a genuinely useful distinction between get (compares against the previous check only) and history (when a domain changed and what it changed from). It stops short of naming sibling alternatives or when NOT to use this multi-action tool over e.g. domain_changes.

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

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

Beyond the read-only annotations, the description discloses freshness ('15 to 20 minutes after registration'), date granularity ('day-level, not clock times'), plan-based visibility of ccTLDs, and the error behavior when a plan-excluded TLD is requested. These are valuable operational details not captured in structured fields.

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 with the core purpose and then adds detail in a logical order, but it is somewhat long. Every sentence contributes useful information, though a few details (e.g., TLD category exclusions) could be trimmed.

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

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

Given the tool's complexity (19 parameters) and the presence of an output schema, the description covers all essential context: TLD scope, plan limitations, data freshness, date granularity, and available filters. Nothing critical is missing for correct invocation.

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

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

Schema description coverage is 100%, so each parameter is already fully documented. The description provides a high-level summary of available filters but adds no syntax or format details beyond what the schema provides, making the baseline 3 appropriate.

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

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

The description states a specific verb ('Search') and resource ('newly registered domains from the last 60 days') with clear scope. It distinguishes itself from generic search tools by emphasizing recency, but does not explicitly name which sibling tools (e.g., 'active', 'aged') are alternatives for different time windows.

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 two usage modes (keyword search or TLD browsing) and notes that browsing requires a registered account. However, it gives no explicit when-to-use vs alternatives among the many sibling tools, leaving the agent to infer selection criteria.

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

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive), so the bar is lower. The description adds genuine behavioral context: comma-separated nameservers resolve to an AND/intersection rather than an OR, and that capability is gated to higher plans. No rate limits or result-size behavior are mentioned.

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

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

Three short sentences, front-loaded with the core purpose before the intersection nuance and the sibling pointer. Efficient and free of filler, though the trailing 'Related: whois, dns.' is a thin addition rather than a routing instruction.

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

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

For a read-only lookup tool with rich annotations, a 100%-covered 11-parameter schema, and an output schema, the description supplies everything an agent needs to select and invoke it correctly. Return format and pagination are handled by the output schema and parameter docs respectively.

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

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

Schema description coverage is 100%, so the baseline is 3. The description's explanation of intersection semantics largely restates what the 'ns' parameter description already says verbatim, and it says nothing about page, sort, or the length/character filters, so it does not meaningfully exceed 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 and resource: 'find gTLD domains hosted on a specific nameserver', which is precisely the inverse of a forward DNS lookup and clearly distinct from sibling tools like dns and whois. The added scoping ('filtered by TLD and keyword') and the 'Related: whois, dns' pointer make the tool's identity immediately legible.

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

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

Gives a concrete usage context (find domains on a nameserver) plus the multi-nameserver intersection pattern and the plan-tier caveat, which tells the agent when the feature is even available. It lacks explicit 'when not to use' guidance or a direct alternative to route to for forward lookups, keeping it out of the top band.

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

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

Goes well beyond the annotations by disclosing AES-256-GCM encryption at rest, isolated per-user directories, the memory_enabled gating dependency, an explicit-consent requirement for writes, and irreversible GDPR-scoped deletion. The 'permanently erase all stored user data' line concretely backs the destructiveHint=true annotation rather than merely restating it.

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

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

Front-loads the purpose sentence, then a scannable action list, then related tools — a clean, well-ordered structure. The encryption sentence slightly interrupts the purpose statement but is short and load-bearing. No filler sentences.

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 an 8-parameter, multi-action tool with annotations and an output schema, the description covers the key operational facts: action semantics, prerequisites, consent, and data-handling/destruction behavior. Return values are delegated to the output schema, which is appropriate. Only minor gaps remain (e.g., behavior of omitted set fields).

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

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

Schema coverage is 100%, so the baseline is 3. The description adds meaning beyond the schema by stating that memory_enabled must be true before preferences, monitors, or strategies can be stored, and by flagging the consent prerequisite — an ordering/precondition detail the schema only partially conveys. It does not clarify partial-update or default behavior for unset fields.

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 (manage user preferences and memory) with three clearly differentiated actions (get/set/delete), each with its own one-line behavior. It distinguishes itself from siblings by naming 'monitor' and 'strategy' as related but separate tools. The umbrella verb 'manage' is broad, but the action breakdown removes ambiguity.

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?

Each action carries actionable context: get reports memory status, set requires memory_enabled=true and explicit user consent before storing preferences/monitors/strategies, delete is for GDPR erasure. It routes the agent toward monitor/strategy for related work. It stops short of explicit when-not-to-use guidance, but the per-action prerequisites are strong.

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

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

Annotations already declare readOnlyHint=true and idempotentHint=true, so the safety profile is covered. The description adds the detail that it returns both registration and renewal pricing, which is useful context beyond the annotations. However, it does not disclose whether pricing is current, cached, or subject to variation, so it only partially complements the annotations.

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

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

The description is extremely concise at one sentence plus a related note. Every word earns its place, and the key information is front-loaded. It is not overlong, though the 'Related: available' line could be seen as slightly tacked-on rather than integrated.

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

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

Given the tool's simplicity (one parameter), the presence of a full output schema, and strong annotations, the description covers the core functionality adequately. It states what is returned and hints at a related tool. It lacks a bit of context about edge cases (e.g., unsupported TLDs), but for a simple pricing query it is sufficiently complete.

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

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

The input schema has 100% description coverage for the sole parameter 'tld', explaining comma-separated multiple TLDs. The description does not add any additional parameter semantics beyond what the schema already provides, so the baseline of 3 is appropriate.

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

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

The description clearly states the tool returns 'standard registration and renewal price for a TLD', specifying the resource and action. It is not a tautology and provides a concrete function. However, it does not explicitly distinguish from siblings like 'market_price' or 'tld_trends', so it misses the top score.

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 only usage hint is the vague 'Related: available', which implies a connection to availability checks but does not explain when to use this tool vs alternatives. There is no explicit when-to-use or when-not-to-use guidance, and sibling names like 'market_price' remain unaddressed.

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

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, openWorld), so the description earns credit for adding domain semantics instead: it explains that ~60% of registrars are reseller shells and that parent_id reveals the actual operator. That is genuine behavioral context beyond the structured fields, though pagination behavior is left unmentioned.

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

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

Three sentences, front-loaded with the action and the return shape, followed by the parent_id insight that actually affects interpretation. The shell-statistic framing is somewhat verbose but it is the highest-value content in the definition, so little 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?

An output schema exists, so return values need not be spelled out; the description goes further and flags the semantically important field (parent_id). With annotations covering safety and the schema covering both parameters, nothing essential is missing for correct invocation.

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

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

Schema description coverage is 100% with only 2 parameters, so the schema already documents 'query' and 'page'. The description repeats the accepted query forms without adding format or syntax detail beyond what the schema provides, and says nothing about the pagination parameter. Baseline 3 applies.

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

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

States a specific verb ('look up') and resource ('ICANN-accredited registrars') plus the three lookup keys (name, alias, IANA ID), and enumerates the returned fields. It also names related siblings (whois, available, expired), so an agent can locate it in the toolset without opening the schema.

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

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

The description gives clear context for when this tool applies (looking up a registrar by name/alias/IANA ID) and points at related tools, but it lists those siblings without stating the conditions under which one should be preferred over registrar. No explicit when-not guidance.

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

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

Annotations already declare destructiveHint=true, readOnlyHint=false, and idempotentHint=false. The description adds value beyond that by disclosing encrypted per-user storage and the auth/memory prerequisite. It stops short of explaining what a delete destroys or how update merges fields, so it is good but not exhaustive.

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

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

Two tight sentences, purpose front-loaded before the exclusion list, with no filler. Slightly awkward phrasing ("in encrypted per-user storage") but efficient overall.

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?

An output schema exists, so return values need not be described. The description covers purpose, the prerequisite, and the exclusions, and annotations carry the safety profile. Nothing critical to correct invocation is missing.

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

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

Schema description coverage is 100%, so the schema already documents all five parameters and the action enum. The description echoes the strategy and result concepts but adds no format, length, or update-semantics detail beyond what the schema provides, so the baseline 3 applies.

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

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

States a specific verb+resource ("Store user-authored strategy text") and scopes what is persisted (strategy text, timestamps, latest result). The negative clause lists what the tool does NOT do, which helps distinguish it, though it never names the get/set/update/delete actions that the 'action' param enables.

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

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

The description provides a prerequisite ("Requires a registered account with memory enabled") and excludes several adjacent capabilities (presets, opportunities, domains, workflow execution), which is useful context. However, it gives no guidance on when to choose get vs set vs update vs delete, and names no alternative tool.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is known. The description adds behavioral context by specifying the return shape (per-TLD status and aggregate counts) and the scope (core TLDs), which goes beyond the annotations. It doesn't contradict annotations.

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

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

The description is two sentences, front-loaded with the action, and includes a compact pointer to related tools. Every sentence contributes value; no redundancy or filler.

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

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

This is a simple read-only tool with one parameter and an output schema present. The description sufficiently communicates what it does and what it returns, and the output schema handles detailed return values. The mention of 'core TLDs' and aggregated counts completes the contextual picture without being verbose.

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

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

The schema description for the single 'prefix' parameter is highly detailed ('Keyword without extension, e.g., openai'), providing 100% coverage. The tool description adds no parameter-level detail, so the schema carries the full burden. Baseline of 3 is appropriate.

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

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

The description clearly states the tool checks registration of a prefix across core TLDs and returns per-TLD status plus aggregate counts. It uses a specific verb ('check') and resource ('prefix across core TLDs'), and explicitly names related tools (bulk_tld, available), distinguishing its cross-TLD scope from bulk and single-TLD alternatives.

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

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

The description provides clear context for when to use this tool: when you need to see how a prefix is registered across multiple TLDs. It names related tools (bulk_tld, available) as alternatives, but stops short of explicit 'use this instead of X when...' guidance. Still, the purpose and related tools give enough signal for appropriate selection.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, indicating a safe read operation. The description adds little beyond that—'related metrics' is vague, and 'chosen period' is inaccurate given the parameter schema. It does not contradict the annotations, but also does not provide additional meaningful behavioral disclosure.

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

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

The description is two short sentences: one for the core purpose and one pointing to a related tool. It is front-loaded and every word earns its place, with no unnecessary elaboration or repetition.

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

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

Given the tool's simplicity (2 optional params, output schema present) and strong annotations, the description is minimally viable. However, it lacks details about what 'related metrics' include, how the ranking is ordered, and the 'chosen period' phrase creates confusion because no period parameter exists. This gap is significant enough to prevent a higher score.

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

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

The input schema has 100% coverage, as both 'type' and 'limit' have descriptions. The description does not add meaning beyond the schema and actually introduces a 'chosen period' concept that does not map to any parameter. Since the schema already explains the parameters, the baseline of 3 is appropriate, but no additional semantic value is provided.

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

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

The description clearly states the tool ranks TLDs by registration volume, which is a specific verb and resource. It also mentions 'related metrics' and points to tld_trends as a sibling, providing some differentiation. However, the phrase 'over a chosen period' is misleading because the type parameter only allows 'newly' (today) or 'active' (total) with no actual date range selection.

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 only says 'Related: tld_trends,' which implies an alternative exists but does not explain when to use tld_rank versus tld_trends. No explicit conditions, prerequisites, or exclusions are given. The usage context is thus implied rather than clearly stated.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint false, so the safe read-only behavior is covered. The description adds mode and comparison context but does not disclose additional behavioral traits such as data-source coverage, rate limits, or response characteristics beyond what the schema and output schema provide.

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

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

The description is two sentences, front-loaded with the core action and resource, and includes related tool names without unnecessary verbosity. Every sentence contributes useful context.

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 rich schema, full parameter coverage, annotations, and an output schema, the description is sufficiently complete for a read-only trend tool. It communicates the core modes and related tools, though it leaves sibling differentiation to the reader.

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

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

Schema description coverage is 100%, so all five parameters are already documented in the input schema. The description mirrors the modes (active-total vs newly-registered, single vs compare) but does not add new semantic detail beyond the schema.

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

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

The description clearly states the tool returns registration trend data for a TLD over time or multiple TLDs in active/newly-registered modes. It is specific about verb and resource, but it does not explicitly differentiate itself from the related sibling tools tld_rank and keywords_trends beyond 'Related'.

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

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

Usage is implied by the description and elaborated by the schema's mode descriptions, but there is no explicit when-to-use guidance or direct comparison to tld_rank or keywords_trends. The gTLD-only exclusion is present only in the parameter schema, not in the description itself.

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

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

Annotations already declare readOnly, idempotent, non-destructive, and non-open-world behavior, so the safety profile is covered. The description adds real value beyond that by disclosing the mutation taxonomy and the exact per-result fields (variant domain, mutation type, prefix TLD count, registration date), plus the caveat that registration date is only known sometimes.

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 core action, then result shape, then use cases, then related tools. Dense but every sentence carries information; no filler or restatement of the title.

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

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

With an output schema present and annotations covering safety, the description need not explain return values, and it still describes the result fields usefully. The only shortfall is that the listed related tools are not qualified with when each applies, leaving tool selection partly to inference.

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

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

Only one parameter, and the schema documents it at 100% coverage with its own example (example.com). The description adds no format or constraint details beyond what the schema already provides, so this is the baseline case where the schema does the work.

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 (generate permutations) and resource (domain variants), then enumerates the ten mutation classes it produces. Distinctly different from siblings like dns, whois, or nrds, which are lookups rather than permutation generators.

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

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

Explicitly names three motivating scenarios (brand protection, phishing detection, defensive registration planning) and lists related tools. It stops short of saying when to prefer a sibling (e.g. nrds vs whois) or when not to use this tool, so it is clear context without real differentiation.

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

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), so the description's real added value is the data-freshness caveat ('at the latest data update', 'Not re-checked at query time') and the auth-tier gating of results and filters. It stops short of describing pagination depth or rate limits beyond the passing plan reference in the schema.

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

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

Front-loads the resource and scope, then caveats and verification workflow in descending priority; every sentence carries information. The opening sentence is dense, packing six TLDs, two length classes and three pattern notations into one clause, which costs a little readability.

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 an output schema exists, return values need no explanation, and the definition still covers the items an agent must know to call it correctly: data staleness, account-tier limitations on results and filters, and which sibling to use before acting on a result.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds real meaning the schema lacks: it defines the CVCV/VCVC/CCVV pattern notation (C = consonant, V = vowel) that the `type` enum only labels as 'Pattern type filter', and notes that filters are unavailable without an account.

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 precise verb and resource (search short unregistered domain names) plus the exact scope: six TLDs, 3-letter and 4-letter names, and CVCV/VCVC/CCVV shapes. It also names the sibling tools it is not (available, bulk_available), so an agent can route without opening another schema.

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

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

Explicitly gives when-to-use and when-not-to-use: this is a snapshot list, not a live check, so 'confirm with available or bulk_available before registering.' It also states the account-level precondition that changes behavior (without an account only .ai is shown and filters are unavailable).

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds meaningful context by enumerating the exact categories returned (tier, usage, rate limits, quotas) and notes that Monitor and Strategy quotas are 'stateful,' which is useful behavioral insight beyond the annotations.

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

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

A single, front-loaded sentence contains zero filler and conveys the full purpose. Every element earns its place.

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

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

Given the zero-parameter complexity and the presence of an output schema, the description sufficiently covers what the tool returns. No further details about return value structure are needed, and the description is complete for an agent to select and invoke the tool correctly.

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

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

The tool has zero parameters, so the description does not need to explain any. Baseline 4 is appropriate because no parameter guidance is required.

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 'Return' and clearly identifies the resource as 'current account tier, per-tool-group usage, rate limits, and stateful Monitor and Strategy quotas.' This precisely distinguishes the tool from siblings like 'monitor' and 'strategy' by framing it as the quota/usage overview.

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

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

The description implies usage for checking account-level limits and quotas but provides no explicit 'when to use' vs alternatives or exclusions. An agent can infer the use case, but the tool does not state when it should be preferred over other information-gathering tools.

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

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

Annotations already declare readOnly, idempotent, openWorld, and non-destructive, so the safety profile is fully covered without the description. The description adds the field categories returned, which is mild context, but discloses nothing about rate limits, auth, or lookup failures -- acceptable given the rich annotations.

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

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

Two tight sentences with zero waste; the core capability is front-loaded before the relational note. Nothing should be cut.

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 an output schema present, return values needn't be explained, and the single required parameter is fully described. The only gap is the missing when-to-use guidance relative to sibling lookups, which matters given the dense sibling set.

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

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

Schema coverage is 100% and the domain parameter is fully documented in the schema (bare domain, punycode, no protocol/path/port), so the description correctly does not duplicate it. Baseline 3 applies because the schema carries all parameter meaning.

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

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

States a specific verb (Return) and resource (WHOIS/RDAP registration data) and enumerates the payload (registrar, dates, status, nameservers), so the agent knows exactly what it retrieves. It gestures at a sibling with 'Related: dns' but does not differentiate from the more ambiguous neighbors registrar, domain_changes, or epp_status.

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

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

'Related: dns' is the only usage cue and it neither states when to prefer this tool nor when to avoid it. No exclusions or prerequisites are given, so the agent must infer that this is the raw registration lookup versus the registrar/status-specific siblings.

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