DomainKits

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

Annotations already provide readOnlyHint=true, destructiveHint=false, and idempotentHint=true, establishing a safe, idempotent read operation. The description adds value by clarifying that results are registered (not available) domains and noting the database size (~240 million). This supplements the annotation's safety profile without contradiction, though it does not disclose pagination behavior or rate limits.

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 exceptionally concise: two sentences plus a 'Related' line. The main action and result type are front-loaded. Every sentence delivers distinct value without redundancy. No unnecessary words or elaboration.

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 search tool with 10 parameters and 27 siblings, the description covers the core purpose, data scope, and result semantics. The output schema exists to document returned fields, so the description does not need to detail return values. Minor omissions include lack of mention about pagination or minimum keyword length (2 chars), but overall the description is sufficient given the rich schema and annotations.

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 all 10 parameters. The description only lists generic filter categories (keyword, TLD, length, character set) already covered by the schema. It does not add new meaning or clarify parameter interactions (e.g., how position interacts with keyword). Since the schema already documents each parameter adequately, a baseline score 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's purpose: 'Search active gTLD domains... filtered by keyword, TLD, length, and character set.' It also clarifies the database scope (~240 million registered domains) and explicitly distinguishes the result nature from registration availability. The mention of related tools (expired, whois, dns) helps differentiate it 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 positions the tool as a 'market-analysis instrument for keyword distribution and saturation' and notes that results are registered domains, not available for registration. This gives strong context for when to use it (market analysis) and implies alternatives (available, expired) via the 'Related' line. However, it lacks explicit when-not-to-use guidance or a direct comparison to siblings like 'available' or 'aged.'

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 mark readOnlyHint=true and destructiveHint=false, so the safety profile is clear. The description adds important behavior: domains are live/owned, filtered by age range 5-20+, and the keyword length nuance is explicitly disclosed. No contradictions with 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 concise at two sentences followed by a related tools note, front-loading the core purpose. Every sentence adds value—no waste, and the formatting is clean and scannable.

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

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

Given the tool's complexity (12 parameters, 6 enums, output schema present), the description covers the primary behavior and key edge cases (keyword length limitation). However, it does not mention pagination behavior or result limits, which would be helpful for an agent planning to iterate over many results. The output schema likely covers return format.

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

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

Schema description coverage is 100%, so each parameter already has a description. The tool description goes further by explaining the overall filtering (age, TLD, etc.) and the critical nuance about 2-character keywords matching only start of name. This adds value beyond the schema alone, though some parameter details are already clear from 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 it searches currently registered domains with 5-20+ years of history, filtered by keyword, TLD, age range, length, and sale status. It explicitly differentiates from siblings 'expired' and 'whois' by noting these domains are live and owned, not free to register.

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

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

The description provides explicit guidance on when to use this tool (search aged live domains), includes related tools such as 'expired', 'whois', and 'dns' for alternatives, and highlights the key constraint that these are not free to register. The keyword parameter itself clarifies behavior with 2 vs 3+ character searches, further aiding correct usage.

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, destructiveHint=false, and idempotentHint=true, so the safety profile is known. The description adds no further behavioral details (e.g., rate limits, data freshness, or side effects). It focuses on output content, which is purpose rather than behavior. With strong annotation coverage, a score of 3 is appropriate.

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 consists of two short sentences: the first states the core functionality with a clear list of outputs, and the second names related tools. There is no fluff, and the key information is front-loaded.

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

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

The tool is simple (one parameter), has an output schema, and the annotations cover safety. The description adequately covers what the tool does and points to related tools. Nothing important is missing for an agent to select and invoke 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?

The schema has 100% coverage for the single parameter 'domain' with a clear description ('Domain name (no protocol or path)'). The description itself does not add parameter-level detail beyond what the schema provides, 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?

The description clearly states the tool returns a domain's backlink profile and lists specific metrics (domain rank, backlinks, referring domains, spam score, link distribution). The verb 'Return' plus the resource ('domain's backlink profile') makes the purpose unmistakable and differentiates it from other SEO tools like whois and safety.

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 mentions 'Related: whois, safety' which hints at related tools, but it does not explicitly state when to use this tool versus alternatives. There is no direct exclusion or condition, so the usage is mostly implied by the tool name and the listed output. This is adequate but not explicitly guided.

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

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

Beyond annotations, the description adds valuable behavioral context: it states that the status is point-in-time, that MCP does not infer availability from failures, and that affiliate fields are removed from the upstream response. These details help the agent interpret results correctly and set expectations about response sanitization.

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

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

The description is a single well-structured paragraph that front-loads the core purpose, then explains status values and behavioral nuances. It is slightly lengthy due to the status definitions, but each sentence serves a purpose and there is no redundancy or fluff.

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 output schema exists, the description does not need to document return format. It explains all domain status meanings, the limits, and key behavioral quirks. It does not mention potential errors or rate limits, but for a batch read-only tool with one parameter, it is largely 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 schema already fully describes the 'domains' parameter (comma-separated, max 50). The description repeats the 50-domain limit but does not add new parameter-level information, such as formatting or validation details. Hence, the description adds minimal semantic value beyond the schema, so baseline 3 is appropriate.

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

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

The description clearly states the tool returns point-in-time availability status for up to 50 domains, with a specific verb ('Return') and resource ('Availability service'). It also defines each possible status value, distinguishing this batch tool from singular alternatives like 'available'.

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

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

The description implies usage for batch queries by specifying 'up to 50 domains' and explaining the status semantics. It does not explicitly name alternatives or exclusion criteria, but the batch scope and threshold provide clear context for when this tool is appropriate.

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, which cover safety. The description adds value by specifying the exact categories returned (taken, available, listed for sale) and the batch-processing nature, going beyond the annotations without contradicting them.

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 delivers the core purpose and outcome, and the second sentence points to related tools. Every word is purposeful, with no redundancy or fluff.

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 simple (one parameter) and has an output schema and rich annotations. The description covers the main behavior and outcome categories. However, the lack of explicit guidance on when to prefer this over related tools and the minor singular/plural wording issue prevent it from being fully complete.

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

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

The schema fully documents the 'keywords' parameter (comma-separated, max 50), so the baseline is 3. The description adds the TLD-checking context but introduces a slight inconsistency by saying 'one keyword' while the schema permits multiple keywords. This does not clarify parameter usage 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 action ('Check registration status'), the resource ('one keyword across many TLDs'), and the outcome ('returning which TLDs are taken, available, or listed for sale'). It also distinguishes itself from siblings by emphasizing 'at once' and listing related tools like tld_check and available.

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

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

The description implies bulk usage through 'across many TLDs at once' and references related tools, but it does not explicitly state when to use this tool vs alternatives. There is no direct 'use tld_check for single TLD' guidance, so the usage context is only implied.

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, which cover safety and idempotence. The description adds value by clarifying that results are limited to deletion-cycle-completed domains available immediately. No contradictions with annotations. However, it does not disclose pagination behavior (even though 'page' param exists) or rate limits, so it does not go beyond what is minimally expected.

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: first sentence explains purpose and filters, second lists related tools. It is front-loaded with the core purpose. No redundant words. Could be considered slightly dense for a tool with 12 parameters, but it efficiently conveys high-level functionality without trying to repeat schema details.

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 has an output schema, 12 parameters, and annotations covering behavioral traits, the description is sufficiently complete for an experienced domain searcher. It explains the key semantic constraint (only completed deletion cycle). Adding a note about how pagination works or how large result sets are handled could make it a 5, but the existing information with schema support is adequate.

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% with all 12 parameters having detailed descriptions. The description repeats a summary of filter types but does not add new semantic information beyond what is already in the schema. For high coverage, baseline is 3. The description does not compensate with extra parameter guidance, so 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 specifies 'search domains that have completed the deletion cycle and are open for immediate registration at standard cost', naming the resource and the action. It lists filter dimensions (keyword, TLD, age, length, character set) and references related sibling tools like 'available' and 'bulk_available', but does not explicitly distinguish at what point to use this versus sibling search tools, so not a 5.

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

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

The description states these are domains 'open for immediate registration at standard cost', setting context for when to use (looking for just-deleted domains available). It lists 'Related: available, bulk_available, whois' as alternatives. However, it does not say when NOT to use this tool or give precise guidance on when to prefer siblings like 'expired' or 'aged', so it is slightly incomplete.

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, covering safety. The description adds that results include nameservers and hosting-related records, which is useful behavioral context. However, it does not disclose response format or other behaviors beyond what annotations provide, so it adds moderate value.

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, consisting of two sentences. The first sentence states the primary purpose, and the second lists related tools. There is no waste or redundancy, and the information is front-loaded.

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

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

For a simple lookup tool with one parameter, an output schema, and comprehensive annotations, the description is fairly complete. It explains the scope of the lookup (nameservers, hosting records) and mentions related tools. However, it could be more explicit about when to prefer this tool over the related ones, which prevents a perfect 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 schema has 100% parameter coverage with 'domain' described as 'Domain name'. The description adds no further meaning beyond this, such as format, examples, or constraints. Since the schema already documents the parameter adequately, 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 resolves a domain's DNS records, specifying nameservers and hosting-related records as included content. It uses a specific verb ('Resolve') and a resource ('a domain's DNS records'), but it does not explicitly differentiate from sibling tools like whois or ns_reverse, only listing them as 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?

The description mentions 'Related: whois, ns_reverse,' which implies these are alternatives but does not provide explicit guidance on when to use dns versus those tools. The usage context is implied by the description's focus on DNS records, but no exclusions or direct comparisons are given.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds the rolling 7-day window and the filtering behavior (by reason and length), which is useful context beyond the annotations. It does not 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 a single, well-structured sentence that front-loads the main purpose with a clear verb ('List') and resource ('registration and status changes'). The 'Related' line adds useful pointers without being verbose, though it could be seen as slightly redundant.

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

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

Given the tool has an output schema and rich annotations, the description is sufficiently complete. It covers the scope (premium .com, 7-day rolling window) and key filters, but does not detail return value structure or pagination, though output schema likely covers that. A more explicit mention of 'premium' definition could help but is minor.

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 all 7 parameters described in detail. The description adds that filters are for 'premium' domains and mentions 'change reason and length', which supplements the schema. However, it does not explain parameter interactions or defaults beyond schema, so baseline 3 is appropriate.

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

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

The description clearly states the tool lists registration and status changes to premium .com domains over a rolling 7-day window, with specific filters. It distinguishes itself from siblings by mentioning 'premium' and the 7-day window, setting it apart from broader tools like 'deleted' or 'expired'.

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 a monitoring use case (rolling 7-day window) and lists related tools (whois, ns_reverse) as alternatives, but does not explicitly state when not to use this tool. It's clear it's for recent changes, but could be more explicit about why to choose it over similar 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 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 provide readOnlyHint, idempotentHint, and destructiveHint as false, so transparency burden is lower. The description adds context about the domain lifecycle (registrant hold, time-sensitive windows) which is useful but doesn't disclose additional behavioral traits like rate limits or edge cases. It congrats with annotations, no contradiction.

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 plus a related tools list, which is efficient. The first sentence clearly states the purpose, the second adds context. Could be slightly tightened by removing the related tools list or integrating it into the text, but overall it's well-structured and 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 13 parameters (all documented in schema), an output schema, and annotations covering safety/idempotency, the description handles the remaining context: lifecycle window, search behavior nuances, and sibling differentiation. Complete enough for an agent to use correctly without surprises.

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

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

Schema coverage is 100%, so baseline is 3. The description goes further by detailing the keyword parameter's behavior (2-char vs 3+ char matching, position limitation) which adds significant semantics beyond the enum/schema. Other filters like 'status' get lifecycle context. This justifies a 4.

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 starts with 'Search domains in the deletion cycle' which is a specific verb+resource, and immediately clarifies the context (expired, redemption, pending delete). It also distinguishes from siblings like 'monitor', 'deleted', and 'whois', making it clear what this tool covers vs. others.

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 mentions 'still held by the current registrant, with time-sensitive acquisition windows', giving usage context. Related tools are listed. However, it doesn't explicitly say when not to use this tool or contrast with specific sibling behaviors beyond names, so it's slightly short of a 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 readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so safety is covered. The description adds valuable behavioral detail beyond annotations: domains are resolved to their first IPv4 address, and location is IP-level and approximate (not the site's physical address). This clarifies output semantics and limitations, earning a strong score given the existing annotation coverage.

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 and a related-tools line. It wastes no words: the first sentence states the core function and output fields, the second adds a critical caveat, and the final line lists related tools. All content is information-dense and front-loaded. There is zero fluff or redundancy.

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

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

The tool has a single parameter and an output schema (indicated by 'Has output schema: true'), so return value documentation is handled structurally. The description covers the operation, input normalization (domain→IPv4), and approximation caveat, and points to related tools. For a simple read-only tool with rich annotations process, this is fully complete.

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

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

The input schema already describes the single parameter 'query' with detail (types and auto-stripping of scheme/port/www). Schema coverage is 100%, so the baseline is 3. The description adds extra meaning: 'Domains are resolved to their first IPv4 address before lookup,' which clarifies behavior not in the schema. This additional semantics justifies a score above baseline.

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

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

The description opens with a specific verb-resource pairing: 'Resolve an IP address or domain name to its network operator and approximate location,' listing concrete attributes (region, city, coordinates). It explicitly distinguishes itself from related tools by naming dns, whois, and ns_reverse, and clarifies a key behavioral nuance (domain resolution to first IPv4 address). This is a clear, unambiguous purpose statement that leaves no doubt about what the tool does.

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 contextual guidance by stating the tool's focus (IP-level location) and explicitly listing related tools ('Related: dns, whois, ns_reverse'), which implies alternative choices. However, it does not explicitly state when to choose this tool over those alternatives (e.g., 'use whois for registrar info'). The intent is clear but not fully prescriptive, so it falls short of a 5 but exceeds a 3.

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 known. The description adds the data fields returned but does not provide additional behavioral context such as pagination, rate limits, or error conditions. It neither contradicts annotations nor adds significant behavioral insight beyond them.

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 concise sentences. The first sentence states the core function clearly, and the second adds a related-tool pointer. No filler or redundancy; every word 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 presence of a full output schema and annotations, the description is sufficient for a simple lookup tool. It covers the primary return data, mentions a related tool for alternative use cases, and avoids needing to explain return structure. It is complete for its complexity level.

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 both 'keyword' and 'country', including the country enum and default. The description does not add extra parameter semantics beyond mentioning 'keyword' as the central input, which is already obvious from the schema and tool name.

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 search-volume, CPC, and competition data for a keyword, using a specific verb and resource. It also distinguishes itself from the sibling tool keywords_trends by naming it as related, clarifying the scope.

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

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

The description gives a hint about related tool keywords_trends, implying an alternative exists, but it does not explicitly state when to use this tool versus the alternative. The usage context is only implied, not clearly defined.

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?

The description adds valuable behavioral context beyond annotations: it discloses that results are 'representative samples, not a complete registry feed, demand measurement, valuation, or investment recommendation.' It also warns that scope=com is not available for prefix, which is a non-obvious constraint. This complements the readOnly/idempotent annotations well.

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

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

The description is three sentences, each earning its place: purpose, type/scope semantics, and caveat. It is well-structured, front-loaded with the main action, and contains no redundant or filler 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?

Given the tool's moderate complexity (2 enum params, output schema present), the description fully covers what the tool does, the meaning of each parameter, and important limitations. The output schema handles return format details, so nothing else is needed.

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?

Although schema descriptions cover 100% of parameters, the tool description enriches them significantly. It explains that 'hot' and 'emerging' cover rolling keyword cohorts, while 'prefix' returns prefix activity buckets, and further details the difference between scope=all and scope=com including availability restrictions. This adds real meaning beyond the enum lists.

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 and resource: 'Return provider-computed keyword registration statistics.' It clearly distinguishes itself from sibling tools by focusing on keyword trends (vs. tld_trends, keyword_data) and explains the three data types (hot, emerging, prefix) with enough specificity to orient the agent.

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 the tool by explaining the meaning of each type and scope option. It doesn't explicitly name alternative tools or exclusion scenarios, but the information given is sufficient for an agent to decide when this tool is appropriate.

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, destructiveHint=false. The description adds value by stating results are 'live domains owned by someone', implying market inventory vs registrable inventory, and the parameter docs add behavioral details (e.g., 2-char keywords only match start, not contain/end), which goes beyond 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?

The core description is concise at 3 sentences, front-loading the primary purpose. The related tool note is efficient. However, for 11 parameters, the description section itself is very brief, and behavioral nuances are carried in parameter descriptions rather than the top-level description, which could be better 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?

Given 11 parameters (including nuanced keyword behavior), rich enums, and an output schema (present), the description plus parameter docs cover the core functionality well. The TLD browse mode hint is useful. Minor gaps: Could mention what 'marketplace listing data' means (price? seller?) and that results are paginated, but the page parameter implies this. Overall quite complete for a search tool.

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

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

Schema description coverage is 100%, so baseline is 3. The description of the 'keyword' parameter adds significant semantic detail beyond the schema about minimum length (2 chars), matching behavior for short keywords (start only), and implications for total_found. The 'position' parameter also explains default behavior and when it's ignored. This adds real value, warranting a 4.

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 specific verb+resource ('Search currently registered domains that carry marketplace listing data') and clearly distinguishes from siblings by noting these are 'domains owned by someone' and referencing related tools keyword_data and tld_check, which helps differentiate from available, expired, and other domain search tools.

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

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

Explicit when-to-use context is provided: 'Use to find live domains with marketplace listings.' It also gives important usage nuance with 'Provide WITHOUT keyword to enter TLD browse mode (gTLDs only)' and mentions related sibling tools, clearly guiding when an agent might consider alternatives like keyword_data.

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 read-only, idempotent, and non-destructive behavior. The description adds meaningful behavioral detail by enumerating possible return statuses and the 'when available' price condition, as well as the Sedo-only data source. This goes beyond what the annotations state.

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

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

The description is compact and front-loaded with the core purpose, followed by return behavior and scope limitation. Each sentence contributes useful information, and the related-tool reference is brief and relevant.

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, the presence of an output schema, and strong annotations, the description covers all necessary context: purpose, return values, data source exclusivity, and related tools. No critical behavioral or usage information 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?

The schema fully documents the single 'domain' parameter with an example, so the description does not need to add parameter-level detail. The description's mention of 'domain' adds no new semantic information beyond what the schema already provides.

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

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

The description uses a specific verb ('Check') and resource ('Sedo aftermarket listing price for a domain'), and clearly states what it returns (status and price). It also distinguishes itself from other marketplaces and related tools, making its purpose unambiguous.

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

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

The description clearly identifies when to use the tool by limiting scope to Sedo and explicitly excluding other marketplaces. It names related tools but does not provide an explicit when-to-use vs. when-not-to-use comparison beyond the data source boundary.

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?

The annotations declare destructiveHint:false, implying no destructive operations. But the description explicitly lists 'delete: remove a monitor,' which is a destructive operation on the user's stored monitors. This is a direct contradiction. The description adds other behavioral context (AES-256-GCM encryption, account-tier maximums) but the contradiction is severe enough to make transparency score 1.

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 well-structured: a short intro paragraph followed by an action list, with prerequisites at the end. It is longer than typical descriptions, but that length is justified given five actions and nine parameters. There is minor redundancy (e.g., the schema already states action-scoped parameters), but overall it is scannable and 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?

The description covers purpose, actions, storage location, and prerequisites, and the presence of an output schema relieves it from explaining return values. However, the unresolved contradiction with destructiveHint leaves the side effects of 'delete' ambiguous, and there is no mention of error conditions, rate limits, or other operational constraints. These gaps matter for a tool that can modify persistent state.

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, so the baseline is 3. The description does add some meaning by grouping parameters to actions (e.g., 'set only', 'update only') and noting that 'dns' and 'whois' are 'backward compatibility' fields, but these details are already present in the schema's parameter descriptions. No additional semantic meaning is provided beyond what a structured schema would offer.

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

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

The description clearly identifies the tool's purpose: 'Manage cross-platform domain monitoring tasks that track changes in WHOIS, DNS, and host-supplied page content.' It also lists the actions (get, set, update, delete, history), which gives a specific verb+resource scope. However, it does not explicitly distinguish itself from the sibling 'domain_changes' tool, which could be confused with the history action, so it stops 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?

Implied usage is present: the description says the tool 'tracks changes' and explains when to use 'get' vs 'history' ('get compares against the previous check only; history answers when a domain changed'). It also states a prerequisite ('Requires a registered account with memory enabled'). Yet it never explicitly says when to choose 'monitor' over sibling tools like 'whois', 'dns', or 'domain_changes', leaving external selection guidance implicit.

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 significant behavioral context beyond that: continuous ingestion ('folded in continuously, typically 15 to 20 minutes after registration'), day-level granularity, and gTLD-based coverage with country-code TLDs only in the last few days. These are exactly the kind of non-obvious traits an agent needs.

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

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

The description is front-loaded with the core function and scope, then filters, then data freshness, then coverage limits, then the pointer to nrds_live. Every sentence adds distinct value, and the structure moves from most to least critical information. No filler 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?

For a tool with 13 parameters, full schema coverage, an output schema, and annotations, the description provides everything an agent needs to select and invoke it correctly: scope, coverage limitations, freshness, filtering capabilities, and the alternative tool for specific needs. Nothing essential is missing.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds minimal parameter-level meaning: it mentions filters by recency, registration term, length, character set, and sale status, which map to the schema fields, and 'cross-TLD count' gives context for the tld_counter sort options. However, it does not go beyond the schema in explaining parameter syntax or relationships.

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 and resource: 'Search newly registered domains from the last 60 days by keyword, or browse a single TLD without a keyword.' This clearly distinguishes the tool from siblings by stating the exact data scope and the two usage modes. It also names related tools, reinforcing differentiation.

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

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

The description explicitly states when to use nrds_live instead: 'When you need the exact registration time, the name split into words, or full country-code coverage, use nrds_live, which holds the last three days.' This provides a clear when-not plus a named alternative, satisfying the highest bar for usage 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 cover readOnlyHint and destructiveHint, so safety is clear. The description adds behavioral value by disclosing that it returns exact registration and expiry timestamps, splits names into words, and that names usually appear within minutes of registration (real-time feed). It hints at pagination limits via 'deeper paging' reference, though the exact 10000 limit is only 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?

The description is compact—two short paragraphs. The first sentence immediately states purpose, followed by key outputs and timing. The second paragraph gives routing guidance without fluff. No redundant or irrelevant 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?

With 10 optional parameters and an output schema present, the description covers purpose, scope, real-time behavior, and explicitly mentions alternatives for limitations. The 10000-page limit is only in the schema, but the 'deeper paging' comment implies it. Overall, the description is adequate for an agent to decide when to use it and what it does.

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 covers all 10 parameters with descriptions (100% coverage), so baseline is 3. The main description adds no extra parameter-specific meaning; it provides context about TLD scope and time window, but that doesn't augment the semantics of individual parameters beyond what the schema already states.

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

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

The description states a specific verb (Search) and resource (domains), with a clear time window (last three days) and scope (all TLDs, including ccTLDs like .ai and .io). It explicitly differentiates from the sibling nrds by noting that nrds handles history beyond three days, making the purpose unambiguous.

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

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

It explicitly lists conditions for using nrds instead: history beyond three days, registration-term or for-sale filters, cross-TLD count, or deeper paging. It also explains that nrds carries most recent names but with day-level dates and gTLD focus, giving clear guidance on when to choose an 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=true, idempotentHint=true, and destructiveHint=false, covering safety. The description adds that it finds all gTLD domains with filtering, but it does not disclose pagination behavior or other operational details beyond 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?

The description is two concise sentences: a front-loaded purpose statement and a related-tools reference. It contains no fluff and every word contributes value.

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 has 11 parameters, but the schema documents all of them and an output schema exists. The description captures the core purpose and key filters, making it sufficiently complete for a read-only lookup, though it could mention pagination implications given the 'all' claim.

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% with detailed descriptions for all 11 parameters. The description mentions TLD and keyword filters but adds minimal meaning beyond the schema, so the baseline of 3 is appropriate.

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

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

The description clearly states a specific action—'find all gTLD domains hosted on a specific nameserver'—with scope and filters. It distinguishes itself from related tools by explicitly naming whois and dns as 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 includes 'Related: whois, dns' which hints at alternative tools but does not explicitly state when to use this vs. those. The context implies this is for reverse NS lookups but lacks clear exclusions or decision 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?

Annotation Contradiction: The description states 'delete: permanently erase all stored user data (GDPR Article 17)', indicating destructive behavior, while annotations declare destructiveHint: false. This is a direct contradiction, forcing a score of 1 despite otherwise valuable transparency about encryption and consent requirements.

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 well-structured: a one-line purpose summary, a brief security note, and a bulleted list of actions. Every sentence serves a clear function, and the action list is front-loaded and easy to scan.

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

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

The description provides rich context: encryption, per-user isolation, action semantics, consent requirements, and GDPR erasure. It also references related tools and the output schema exists. However, the contradiction with annotations on destructiveness undermines reliability, and usage differentiation could be stronger.

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 covers 100% of parameters with descriptions, so baseline is 3. The description adds minimal extra parameter semantics beyond schema, mostly reiterating the memory_enabled prerequisite also noted in the schema. No new behavioral details for individual parameters are 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 manages user preferences and memory settings, then enumerates three specific actions (get, set, delete) with distinct behaviors. It also names related tools (monitor, strategy), which helps distinguish scope.

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

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

The description implies usage context by explaining actions and prerequisites (e.g., memory_enabled must be true, explicit consent for set), but it does not explicitly state when to prefer this tool over siblings like monitor or strategy, nor does it provide exclusion 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 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 declare readOnly, idempotent, and non-destructive nature. The description adds valuable context about the data (e.g., 60% are shells, parent_entity information) and the fields returned, without contradicting 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 concise, consisting of two sentences plus a related-tools line. It contains no fluff or redundancy, and efficiently conveys all necessary 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?

The description fully explains the tool's function, the returned data, and even a domain-specific nuance (parent entities for shells). It is complete for a simple lookup tool, though it doesn't elaborate on output format or pagination details, which are likely covered by 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?

The input schema already provides thorough descriptions for both 'query' and 'page' parameters (e.g., 'Registrar name, alias, or IANA ID'). The description adds no new information beyond what schema provides, so baseline score 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?

The description clearly states the verb 'look up' and the resource 'ICANN-accredited registrars', with specific search criteria (name, alias, IANA ID). It also lists the returned fields, making the tool's purpose unambiguous and distinct from sibling tools like whois or available.

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

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

The description implies usage when registrar information is needed, and mentions related tools (whois, available, expired) but does not explicitly state when to use this tool over those alternatives. However, the context is clear enough for an agent to select it appropriately.

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

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

Annotations already declare readOnlyHint and idempotentHint, establishing a safe read operation. The description adds the specific data source (Google Safe Browsing) and the nature of the result (status), which slightly expands beyond annotations, though no further behavioral details are given.

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, with the main action in the first and a related-tools pointer in the second. No redundant content.

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, output schema present, robust annotations), the description is sufficient and includes a helpful related-tools note. Complete for its context.

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 fully describes the single domain parameter with 100% coverage. The description does not add parameter details beyond the schema, so the baseline of 3 is appropriate.

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

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

The description clearly states the tool returns Google Safe Browsing status for a domain, using a specific verb and resource. It also names related tools (whois, backlink_summary) to help distinguish it 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 names related tools but does not explain when to prefer safety over whois or backlink_summary. There is no explicit usage context or exclusion criteria, so only an implicit sense of purpose guides 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?

With all annotation hints set to false, the description carries the transparency burden. It adds important behavioral context: encrypted storage, per-user isolation, and the requirement for memory-enabled accounts. It also implies automatic execution timestamps. It does not describe action-specific side effects (e.g., overwriting on set) or idempotency, but the exclusions and storage details are valuable 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?

The description is three sentences with no wasted words: first sentence states purpose, second lists exclusions, third gives requirements. It is front-loaded and structured logically, making it easy for an agent to parse quickly. Every sentence adds distinct value without 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?

Given the tool has 5 parameters, 0 required, an action enum, and an output schema, the description covers the essential context: purpose, exclusions, and access requirements. It does not explicitly describe the CRUD nature (get/update/delete) beyond the schema, but the output schema and parameter schema fill that gap. The description is complete enough for an agent to understand the tool's role and constraints.

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 does not add per-parameter meaning beyond the schema; it mentions 'strategy text' and 'result' but does not clarify interaction between parameters (e.g., id required for update/delete) or constraints like maximum length, which the schema already documents. The description's value is contextual rather than parameter-specific, so a 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's function: 'Store user-authored strategy text, execution timestamps, and the most recent result in encrypted per-user storage.' This specific verb+resource pair distinguishes it from siblings like 'preferences' and other domain tools. The exclusions ('does not provide presets, define opportunities, choose domains, or execute a workflow') further clarify its limited scope, aligning with the tool's role as a state storage utility.

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 usage context by stating exclusions ('does not provide presets, define opportunities...') and a prerequisite ('Requires a registered account with memory enabled'). This helps an agent know when NOT to use it, but it does not explicitly say 'use this when you need to persist strategy state' or compare to alternatives. Given the absence of similar sibling tools, the exclusions are sufficient 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, 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 cover readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds meaningful behavioral context: it details the output fields (variant domain, mutation type, prefix TLD count, registration date) and explains the permutation generation process. It also clarifies that it checks registration status, which is a read-only behavior consistent with the annotations. No contradictions or missing side effects are apparent.

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 well-structured: it opens with the core purpose, then lists generated variant types, then result fields, then use cases, and ends with related tools. Every sentence provides unique value; there is no fluff or repetition. The front-loaded purpose ensures immediate understanding.

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

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

Given the tool's complexity (many mutation types and output fields), the description fully covers what it does and what it returns. The output schema exists and the description explicitly mentions the key return fields, so no need to describe the return format further. It also lists related tools and use cases, making it complete for an AI agent to decide when to invoke it.

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%, with the single parameter 'domain' well-described in the schema ('Domain to scan (e.g. example.com)'). The description does not add new meaning to the parameter itself, but it reinforces that the domain is the input for generating permutations. Since the schema fully documents the parameter, a baseline score 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's function: 'Generate typosquat permutations for a domain and check which variants are registered.' It lists specific mutation types (omission, transposition, keyboard-adjacent replacement, etc.), which distinguishes it from related lookup tools like whois, dns, and ns_reverse. The verb 'Generate' and 'check' with resource 'domain' is specific and unambiguous.

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

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

The description provides clear use cases: 'Use for brand protection, phishing detection, and defensive registration planning.' It also lists related tools (nrds, ns_reverse, dns, whois, safety), which suggests alternatives for other tasks. However, it does not explicitly state when not to use this tool or differentiate it from those related tools beyond the mutation-generation focus.

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?

The annotations already mark this as read-only, idempotent, and non-destructive, so the bar for additional disclosure is lower. The description adds useful context by specifying that it returns domains 'still available for registration' and lists concrete pattern shapes, which behaviorally clarifies the result set. It does not mention pagination or rate limits, but the schema parameter descriptions cover some of that (e.g., page depth).

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 consists of just two sentences: the first clearly states the tool's core function and any pattern caveats, and the second names related tools. It is front-loaded with the main purpose, contains no filler, and every sentence earns its place.

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

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

With an output schema present, the description does not need to explain return values. The tool has 8 optional parameters, and the description gives enough context about its scope (short .ai domains, pattern filtering, availability check). It could be more explicit about the relationship to 'available' and 'bulk_available', but overall it is complete for a read-only search tool.

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

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

Schema description coverage is 100%, so every parameter already has a description (type, sort, exclude, keyword, etc.). The tool description does not add extra meaning beyond what the schema provides; it only hints at pattern types (CVCV, CVCC) which are already enumerated in the type parameter. Thus, 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 uses a specific verb+resource construction: 'Search unregistered short .ai domains by pattern' and details the pattern types (CVCV, CVCC, other 3-4 letter shapes). It also names related tools (available, bulk_available), which helps distinguish it from siblings that likely perform broader availability checks.

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 through its purpose statement and the 'Related: available, bulk_available' line suggests alternatives, but it does not explicitly state when to choose this tool over the related ones. There is no clear when-not-to-use guidance or differentiator beyond the pattern-search focus.

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 readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds value by enumerating the data fields returned (registrar, dates, status, nameservers), providing useful context 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?

The description is two concise sentences, front-loaded with the action and key data fields. The 'Related' line is brief and non-redundant, with no wasted words.

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

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

For a single-parameter lookup tool with a strong annotation profile and an output schema, the description adequately covers purpose and data scope. Minor gap is the lack of explicit usage guidance beyond the related-tools hint.

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%, with the sole parameter 'domain' already described as 'Domain name'. The description adds no additional parameter-level detail, so it does not improve upon the schema's clarity.

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 WHOIS/RDAP registration data for a domain, listing specific data elements (registrar, dates, status, nameservers). This distinguishes it from siblings such as dns and safety, which likely handle other aspects.

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 only a brief 'Related: dns, safety' line, which hints at related tools but does not explicitly state when to use this tool versus alternatives. It implies usage for registration data but lacks clear exclusion or selection guidance.

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