DomainKits

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 genuine context beyond that: the ~240M domain corpus size, the market-analysis framing, and the crucial caveat that returned domains are registered (not acquirable). It omits auth/account requirements and 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 tight sentences front-load what the tool is and its most important caveat, followed by a compact 'Related:' routing line. No filler, though the Related line is slightly thin compared to a full alternatives statement.

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 all 12 parameters are covered by the schema and annotations. The description supplies the essential framing (market analysis, registered-not-available) an agent needs to select it correctly; only explicit alternative-routing guidance 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 all 12 parameters are documented in the schema itself. The description only restates the filter categories (keyword, TLD, length, character set) without adding syntax or defaults, so the baseline of 3 applies when structured data 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+resource ('Search active gTLD domains') with concrete scope ('~240 million registered domains') and enumerates the filter dimensions. It explicitly distinguishes itself from the sibling 'available' tool by clarifying results are 'registered domains, not available for registration', so an agent can tell it apart 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?

Frames the use case as 'a market-analysis instrument for keyword distribution and saturation' and clarifies the registered-vs-available distinction, which implicitly routes registration checks to 'available'. It names related tools (expired, whois, dns) but stops short of explicit when-to-use/when-not phrasing for each alternative.

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=true, idempotentHint=true, and destructiveHint=false. The description adds the scope ('single domain') and output focus ('registrability and price') but no further behavioral traits such as rate limits or error handling, so it offers modest value beyond 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 sentences: the first states the action and scope, the second reinforces authority, and the Related line adds cross-reference. No extraneous 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?

With a single parameter, a complete schema description, strong annotations, and an output schema present, the description adequately covers what the tool does and when to use it. The related-tools pointer adds contextual completeness.

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

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

The only parameter, 'domain', is fully documented in the schema with format example. The description adds no additional parameter semantics, leaving this at the baseline for high schema coverage.

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

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

The description states 'Confirm a single domain's registrability and price' with a specific verb and resource, and explicitly contrasts with bulk_available, whois, and monitor via the 'Related' line, effectively distinguishing this tool from siblings.

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 notes it is for a single domain, implying bulk_available is for multiple, and lists whois and monitor as related alternatives. This provides clear context for when to use this tool, though it stops short of explicit 'use X instead' 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 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 establish read-only, idempotent, non-destructive behavior, so the bar is lowered. The description still adds real value: it defines what each result state means and warns that a failed check must not be treated as available, which is non-obvious failure semantics an agent could otherwise get wrong.

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 first sentence front-loads purpose and scope, and the status glossary is compact and information-dense rather than padded. The enumeration is slightly long, but every clause defines a distinct state the caller must interpret.

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-shape explanation is unnecessary, and the description instead supplies the interpretation layer for the status values plus failure semantics. The only real gap is guidance on when to prefer this over a single-domain or monitoring alternative.

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

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

There is a single parameter with 100% schema description coverage, so the schema already documents format and the 50-domain cap. The description only echoes the limit and adds no syntax or format detail beyond the schema, making the baseline 3 correct.

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 ('Check the registration status of ... domains') and adds scope ('up to 50', 'at a point in time'). It is clearly distinguishable from status-oriented siblings like available or tld_check, though it never names the single-domain sibling it complements.

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?

Bulk usage is strongly implied by 'up to 50 domains' and 'at a point in time', which hints this is a snapshot rather than a monitoring tool. However, there is no explicit when-to-use, when-not-to-use, or named alternative (e.g. available for a single domain, monitor for ongoing tracking).

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 cover read-only and idempotent behavior, so the bar is lower. The description adds valuable behavioral context: matching on code, aliases, or category; the ability to list all codes when query is omitted; and the nature of output (explanation of meaning, severity, actions). These are not redundant with annotations and enhance transparency.

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

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

Three sentences, front-loaded with purpose, then usage details, then context. No fluff, every sentence contributes value. Efficient and well-structured.

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

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

For a simple lookup tool with one optional parameter, an output schema, and safe annotations, the description covers all essential aspects: what it does, how to invoke it, what to expect, and when to use it. No gaps identified.

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 already explains the query parameter (code, alias, or category, omittable). The description adds extra clarity by emphasizing aliases and categories and reinforcing the listing behavior when query is omitted. This is a minor enhancement over the schema, so a 4 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 exactly what the tool does: 'Explain domain EPP status codes' with detail on what aspects it covers (meaning, why set, severity, holder actions). Clearly distinguishes from siblings like whois by positioning itself as an interpretation layer for the status field returned by whois. The description is specific and actionable.

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

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

Provides explicit when-to-use guidance: 'Use this to interpret the status field returned by whois instead of relying on recall.' Also clarifies the invocation pattern for both query and no-query cases. Does not explicitly state when not to use it, but the context is clear enough for an agent to decide.

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 known. The description adds valuable behavioral context beyond annotations: registrars may renew a domain after expiry, the data is gathered through multiple channels, and some statuses may not match live WHOIS. This is a meaningful, honest disclosure about data freshness and reliability that an agent needs when interpreting results.

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

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

The description is concise and front-loaded: the first sentence states the core purpose, the second clarifies the domain state and acquisition window, and the note provides an important reliability caveat. The 'Related' line aids tool selection without bloat. Every sentence earns its place, and there is no redundant restating of schema or annotations.

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

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

The tool is well-supported by structured data: 15 parameters all described in the schema, 7 enums, an output schema, and safety annotations. The description adds the missing behavioral nuance about data staleness and renewal risk, which is essential for interpreting search results. An agent has everything it needs to select and invoke this tool correctly.

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

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

Schema description coverage is 100%, so the input schema already documents every parameter thoroughly, including enums and meaning. The description briefly lists the filter dimensions (lifecycle status, TLD, age range, length, character set), which maps to the schema but adds no new parameter-level meaning. Baseline 3 is appropriate because the schema carries the full burden and the description does not need to compensate.

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

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

The description states a specific action and scope: 'Search domains in the deletion cycle' and enumerates the exact lifecycle statuses covered: expired, in redemption, or pending delete. It also distinguishes this from sibling tools by noting these domains are 'still held by the current registrant,' which separates it from already-deleted domains. The purpose is unambiguous and clearly differentiated from nearby tools like deleted and monitor.

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 is appropriate: searching domains in the deletion cycle with time-sensitive acquisition windows. It names related tools ('monitor, deleted, whois') and the 'still held by the current registrant' clause implies when not to use it, but it does not explicitly explain when to choose expired over each alternative. This is clear context with no explicit exclusions, so it falls short of 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 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 readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds the important behavioral fact that results are live, owned domains – but omits pagination/result-volume behavior and the TLD-browse account requirement, which only appears 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?

Two tight sentences: purpose and scope first, siblings second. No filler. Could be marginally tighter but is well front-loaded.

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

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

With an output schema present and 100% schema coverage, the description needn't explain returns or parameters; it correctly focuses on scope and sibling routing. It stops just short of full completeness by omitting the TLD-browse account requirement and pagination behavior.

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

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

Schema description coverage is 100%, so the schema fully documents all 13 parameters; the description only paraphrases the filter axes. Baseline 3 is appropriate since the description adds no syntax, defaults, or interaction rules 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?

States a specific verb+resource ('Search currently registered domains that carry marketplace listing data') and enumerates the filter axes, plus adds a crucial scoping fact ('Results are live domains owned by someone') that distinguishes it from registration-availability siblings. The 'Related:' line explicitly routes to keyword_data and tld_check.

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

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

Names two related alternatives (keyword_data, tld_check), giving the agent a routing signal. However, it does not state when to use market vs. market_price, available, or expired, all of which are adjacent sibling tools in the same list.

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

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

Annotations already 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?

Annotations already establish read-only/idempotent/non-destructive, but the description adds substantial context: the 60-day window, which ccTLDs and second-level registrations are covered, that categories like government/education are excluded, that plan limits produce an explanatory message rather than an error, and the 15-20 minute ingestion latency. This is exactly the kind of behavior an agent cannot infer from 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?

Front-loaded with purpose and scope, and every sentence carries information (coverage, exclusions, latency, sibling routing). It is a dense single block, however, and the TLD enumeration is lengthy where a compact list or structure would read faster.

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

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

For a 15-parameter tool with full schema coverage, an output schema and rich annotations, the description supplies everything needed to call it correctly: scope, coverage limits, account/plan constraints, data freshness and the sibling to use for exact timestamps. Return values need not be described since an output schema exists.

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 7 of 15 parameters carry enums, so the schema already documents each filter. The description largely restates the same filter set and the tld family behavior that the schema's tld description already explains, adding little beyond it; 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 newly registered domains from the last 60 days') plus the alternate browse mode, and explicitly contrasts itself with nrds_live. An agent can tell it apart from siblings like nrds_live, whois and dns 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?

Gives clear routing ('when you need the exact registration time, use nrds_live') and a real prerequisite ('browsing requires a registered account'), plus plan-dependent TLD visibility. It names the key alternative with its condition but does not say when this tool should be avoided versus the other domain siblings (whois, dns, typosquat) beyond the related-tools list.

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

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

Annotations only declare readOnly/openWorld/idempotent/destructive hints; the description adds real behavioral context beyond them: plan-gated TLD visibility with an explicit error-message behavior, a 60-day vs few-day coverage asymmetry between ccTLD and generic TLDs, and category exclusions (government, military, education, non-profit). This is unusually rich disclosure for a read-only tool.

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

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

Front-loaded with purpose and scope before the alternative-tool routing, and every sentence carries information. It is dense and long for an MCP description, with the TLD coverage enumeration consuming considerable space, but nothing is pure padding.

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 10-parameter zero-required open-world search with an output schema present, the description covers everything the agent needs: coverage windows, plan limits, family-TLD behavior, category exclusions, and alternate-tool routing. Return-value explanation is correctly omitted since an output schema exists.

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, and the description does contribute cross-parameter semantics: the 'br'-style family behavior when combined with a keyword, and the practical paging limit ('narrow the filters to reach beyond' 10000 matches). However, most filter semantics (sort, length, type, position, exclude) are left entirely to the schema, so it earns only a modest lift over 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?

Opens with a specific verb+resource ('Search newly registered domains from a live feed') and immediately narrows scope with timestamps and freshness ('names usually appear within minutes of registration'). It also explicitly distinguishes itself from the sibling nrds, so an agent can route correctly 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?

Gives explicit when-to-use conditions (best for the most recent three days; ccTLDs reach back 60 days) and a detailed when-not-to-use list routing to nrds for older generic-TLD history, second-level suffixes, registration-term/for-sale filters, cross-TLD counts, and deeper paging. It also warns that which ccTLDs are visible depends on the plan and what happens when one is out of plan.

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.