DomainKits

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

Annotations already mark the tool as read-only, idempotent, and non-destructive, so the bar for extra disclosure is lower. The description adds valuable context about the database size, the active/registered domain status, and the intended analytical use, which helps the agent reason about results without contradicting 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 compact and front-loaded, with the core action in the first sentence. The only minor inefficiency is repeating that domains are registered in both the first and second sentence, but overall it 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 12 parameters, an output schema, and strong annotations, the description provides enough contextual grounding: it identifies the domain universe (active gTLD), the analytical use case, the registered status, and related tools. Nothing essential for selecting and invoking the tool is missing.

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

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

Schema coverage is 100%, so the schema fully documents all 12 parameters. The description adds only a high-level summary of filter categories (keyword, TLD, length, character set) and does not provide deeper meaning beyond what the schema already offers.

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 active gTLD domains from a database of ~240 million registered domains.' It clearly defines the tool's scope and differentiates it from siblings such as expired and available by stating results are registered domains, not available for registration.

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

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

The description gives clear context: this is a market-analysis instrument for keyword distribution and saturation, and it excludes domains available for registration. It also lists related tools (expired, whois, dns), though it does not explicitly state when to choose each sibling over the others.

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

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

Annotations already declare the operation read-only, idempotent, and non-destructive, so the description does not need to restate safety. It adds that results are live owned domains rather than registrable names, which is useful context, but it does not disclose operational details such as pagination behavior; the output schema covers some of that.

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 search action and resource, followed by the key caveat and related tools. Every sentence earns its place, and there is no filler or redundant restatement of the title.

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

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

For a 14-parameter read-only search tool with a complete input schema and output schema, the description covers the essential context: what is being searched, result nature, and related tool categories. Minor ambiguity in '5-20+ years' is resolved by the age_range enum, so no critical 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?

Schema description coverage is 100%, and every parameter is individually documented. The description adds only a high-level grouping of filters (keyword, TLD, age range, length, sale status), which is helpful but does not add meaning beyond the schema.

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

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

States a specific action and resource: 'Search currently registered domains with 5-20+ years of history'. It also distinguishes itself from the expired sibling by clarifying these are 'live domains owned by someone, 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?

Provides clear context that this tool is for live, registered aged domains and points to related tools (expired, whois, dns). It does not explicitly state when to choose each related tool, but the 'not free to register' caveat effectively routes users away from expired/availability use cases.

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=true, idempotentHint=true, and destructiveHint=false, and the description aligns with these rather than contradicting them. The description adds useful state information ('completed the deletion cycle', 'open for immediate registration at standard cost'), but it does not discuss pagination, defaults, or other runtime behavior.

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

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

Two compact, information-dense sentences: the first front-loads the core purpose and filter scope, the second points to related tools. There is no filler or redundant restating of the tool name.

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 14 parameters but the schema covers them fully, output schema exists, and annotations cover the safety profile. The description supplies the essential behavioral context—what makes a domain 'deleted' and registrable—and the only real gap is usage differentiation among related tools, which is already reflected in the usage_guidelines 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?

Schema description coverage is 100%, so the schema already documents all 14 parameters in detail. The description names several filter categories (keyword, TLD, age range, length, character set) that map to properties, but it adds no parameter-level semantics 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 names the exact resource ('domains that have completed the deletion cycle') and a specific verb ('Search'), with a clear list of filter dimensions. It does not explicitly distinguish itself from related siblings such as available or bulk_available, but the deletion-cycle context provides enough differentiation for most cases.

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

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

The 'Related: available, bulk_available, whois' line names alternatives but gives no conditions for choosing one over another. There is no explicit when-to-use, when-not-to-use, or preference guidance, leaving the agent to infer the distinction from the deletion-cycle wording.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

The description gives clear context for when this tool is appropriate: searching domains in the deletion cycle with time-sensitive acquisition windows. It names related tools ('monitor, deleted, whois') and the 'still held by the current registrant' clause implies when not to use it, but it does not explicitly explain when to choose expired over each alternative. This is clear context with no explicit exclusions, so it falls short of a full 5.

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

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

Annotations already declare 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, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds useful behavioral context: results are live, currently registered domains owned by someone rather than available or unregistered names. No contradiction with annotations exists, and this extra context helps interpret the result set.

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

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

The description is compact and front-loaded: the first sentence states the action, resource, and filters; the second clarifies the result population; the third points to related tools. Every sentence contributes useful information with no filler.

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

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

Given the rich input schema, output schema, and complete annotations, the description covers what an agent needs for selection: it defines what the tool searches and that results are live owned domains. The only notable gap is explicit when-to-use guidance relative to keyword_data and tld_check, but this is a minor omission given the strong schema and annotation support.

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

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

Schema description coverage is 100%, so the schema already documents all 13 parameters. The description summarizes key filter dimensions but adds no new parameter-level detail beyond what the schema provides, matching the baseline for full 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 opens with a specific verb ('Search'), names the exact resource ('currently registered domains that carry marketplace listing data'), and enumerates the filter dimensions. It also distinguishes itself from sibling tools like 'available' by explicitly stating 'Results are live domains owned by someone.'

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 identifying the domain population and listing 'Related: keyword_data, tld_check', but it never explicitly states when to choose market over those alternatives or provides exclusions. The guidance is present but only at an implied level.

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 readOnly, idempotent, and non-destructive. The description adds valuable behavioral context beyond that: continuous ingestion with 15–20 minute delay, day-level date granularity, gTLD-based coverage with only partial ccTLD presence, and the note that live rows carry a count of 1. No contradiction 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 dense but efficient. It front-loads the core purpose, then adds three chunks of high-value context (freshness, coverage limits, and sibling routing). No filler; every sentence earns its place. The structure guides the agent from 'what' to 'when' to 'alternatives'.

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 15 parameters, an output schema, and no required fields, the description covers the essential decision points: the two search modes, data freshness boundaries, coverage limitations, and the exact scenario where nrds_live should be used. It also mentions the returned cross-TLD count. An agent can correctly invoke this tool with the information provided.

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

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

Schema coverage is 100%, so the baseline is 3. The description does not elaborate on any specific parameter beyond listing filter categories ('recency, registration term, length, character set, and sale status') which the schema already documents. It adds no syntax or format details beyond what the schema 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 opens with a clear, specific verb ('Search') and resource ('newly registered domains from the last 60 days'), then immediately distinguishes two modes (by keyword or by single TLD). It explicitly names the sibling alternative (nrds_live) and the conditions that select it, so an agent can differentiate without probing further.

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 routing: it names nrds_live as the alternative for exact registration time, word-split names, or full ccTLD coverage, and states that nrds itself is gTLD-based with day-level dates. This gives clear when-to-use and when-not-to-use guidance, exceeding the typical sibling differentiation.

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

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

Annotations already cover 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.