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

No annotations are provided, so the description carries the behavioral disclosure burden. It discloses some behavior via the Args (use_cache = TTL cache with 5-minute default, include_raw = verbose payload) and Returns (status, registrar, dates, nameservers), which adds context. However, it does not disclose network latency considerations, rate-limit behavior, or what happens with unsupported TLDs, which could matter for a network-dependent checking tool with sibling list_supported_tlds.

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 reasonably concise and well-structured with Args/Returns sections. The Args section repeats parameter names that already exist in the schema, but adds meaningful commentary with examples and defaults. Each line earns its place; no filler. Could be slightly tighter but is efficient overall.

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

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

Given this is a network-dependent tool with a an output schema, the description is decently complete: it covers inputs, outputs, and cache behavior. However, it lacks guidance on edge cases like invalid domains, unsupported TLDs (despite a sibling list_supported_tlds suggesting TLD awareness matters), and expected behavior when RDAP/WHOIS fails. The absence of annotations increases the burden the description must carry, and this falls slightly short for a tool with real-world network dependencies.

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

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

Schema description coverage is 0%, so the description must compensate for all parameter meaning. It does explain each parameter: domain (with example including internationalized 'bücher.de'), include_raw (verbose), use_cache (in-memory TTL cache, 5 min default). While this adds value beyond the bare schema, the explanation is light — it doesn't detail return value structure for include_raw or how cache invalidation works, though the output schema partially mitigates this.

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 if a single domain is available or registered, using a specific verb ('Check') with a resource ('single domain'). It distinguishes itself from the sibling check_domains (batch) by explicitly noting 'a single domain', providing differentiation. The Args section and Returns section add clarity to the purpose.

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 'single domain' which implicitly differentiates from check_domains (batch), suggesting when to use this vs the batch tool. However, it doesn't explicitly state when NOT to use it or call out alternatives by name like domain_info or list_supported_tlds. Usage guidance is implied through the 'single domain' keyword rather than being explicit about exclusions or alternatives.

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

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

With no annotations, the description carries the full burden and does well: it discloses that results are returned in input order (a key behavioral trait), that include_raw can produce 'large responses' (size concern), that caching is in-memory and TTL-based (implying cache can go stale), and notes parallel execution with rate-limit friendliness. This is richer behavioral context than typical.

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

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

The description is compact and front-loaded: the first line states the core purpose and key differentiator (parallel bulk check, rate-limit friendly). The Args section uses clear docstring formatting, and the Returns line is a single efficient sentence. Every sentence earns its place with no 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 has an output schema that documents the return structure, so the Returns line adequately summarizes. The three parameters are all documented in the Args section with useful detail. Given the moderate complexity (bulk parallel operation with caching and raw payload options), the description covers the essential behavioral and usage context well, though it could note potential cache-staleness implications of use_cache.

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

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

Schema coverage is 0%, so the description must compensate for all three parameters, and it does reasonably well: domains has a max-recommended count, include_raw signals size tradeoff via 'large responses', and use_cache is described as 'in-memory TTL cache'. This adds meaningful semantic context beyond the bare schema titles, though it lacks nuance on what 'raw' actually contains.

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 multiple domains in parallel, distinguishing it as a bulk operation. However, it doesn't explicitly differentiate from the sibling 'check_domain' beyond the plural/bulk implication, nor does it state what 'check' means (availability, DNS, WHOIS, etc.) — the verb 'check' remains ambiguous about the specific domain attribute being verified.

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's 'rate-limit friendly' and specifies a max recommended 50 domains per call, which gives useful context for when to prefer this bulk tool. However, it doesn't explicitly state when to use check_domains vs the single check_domain sibling, nor when to toggle include_raw or use_cache — the when/when-not guidance for these params is implied rather than explicit.

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

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

No annotations are provided, so the description carries full burden of behavioral disclosure. The description states the action (clear cache) but doesn't disclose side effects—does this invalidate domain checks for all domains? Does it require privileges? Is there any persistence impact? With zero annotations, this is under-specified for a mutating tool.

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

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

A single clear sentence with no waste. It's appropriately brief for a zero-parameter tool. Could arguably benefit from one additional clause explaining when to invoke, but the current form is efficient.

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

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

While an output schema exists, this is a mutating cache-clearing operation with no annotations and no usage guidance. For a tool with side effects, additional context (side effects, prerequisites, frequency of need) would meaningfully improve agent decision-making. The current description is bare-minimum.

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

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

There are 0 parameters, and schema description coverage is 100%. The baseline for 0 params is 4 since there is nothing for the description to compensate for. The description adds nothing beyond what's needed, and none 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 states it clears the in-memory domain check cache, giving a clear verb and resource (clear + cache). However, it doesn't distinguish clearly from siblings—given sibling tools are check_domain, domain_info, etc., the cache-clearing purpose is reasonably distinct, but the description doesn't explain what the cache is used for or why an agent might want to clear it.

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?

No guidance on when to use this tool. It doesn't explain scenarios (e.g., after updates to domain rules, when stale check results are observed) or when NOT to use it. For a cache-clearing maintenance tool with no schema parameters, usage context is entirely absent.

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

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

With no annotations provided, the description carries the burden. It discloses the check is the same underlying as check_domain and mentions the optional include_raw flag behavior. However, it doesn't describe the output format, error behavior for unregistered domains, rate limits, or what fields populate when include_raw is false. Adequate but sparse for an unannotated tool.

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

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

Two compact paragraphs plus a structured Args list. Front-loaded with purpose, then usage guidance, then parameters. Every sentence earns its place with zero filler.

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

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

For a 2-parameter tool with an output schema present and decent description coverage, this is reasonably complete. The description explains the tool's purpose, its relationship to check_domain, and parameter intent. Could add error handling or unregistered-domain behavior, but given the tool's simplicity and output schema availability, the coverage is sufficient.

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

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

Schema coverage is 0%, so neither schema nor description documents parameter semantics beyond names. The description mentions 'domain' and 'include_raw' in the Args section but only restates what the names imply—no format hints, no example values, no types beyond the schema defaults. The description adds minimal meaning beyond the parameter names.

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

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

Description clearly states it retrieves registration details (registrar, expiry, nameservers) for a domain. It explicitly differentiates from check_domain by noting they share the same underlying check but this tool is preferred for WHOIS-like metadata on already-registered domains. Verb+resource+scope are all specific.

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

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

Explicitly states when to prefer this tool ('prefer this when you need WHOIS-like metadata for a domain you already know is registered') and names the alternative (check_domain). Lacks an explicit 'when not to use' clause, but the positive guidance and sibling differentiation are clear.

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

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

No annotations are provided, so the description carries the burden. It discloses that the list is not exhaustive (via WHOIS fallback note), which is useful behavioral context about coverage limitations. However, it doesn't describe return format, ordering, or whether this reflects real-time vs cached data.

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

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

Two compact sentences with zero waste. Front-loaded with the core purpose, followed by one useful caveat. 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?

The tool is a simple read-only list with no parameters and an output schema available. The description covers the essential purpose and a critical caveat (WHOIS fallback). An output schema exists, so return values don't need description. Slightly more behavioral context (caching, freshness) could push it higher.

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 0 parameters, so schema coverage is 100% and there are no parameters to document. The description reasonably describes what is being listed without needing to explain parameter syntax, satisfying the baseline 4 for a zero-parameter tool.

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

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

Description clearly states 'List TLDs with known RDAP endpoints (IANA bootstrap + overrides)' — a specific verb (list) and specific resource (TLDs with known RDAP endpoints) with scoping detail. The mention of IANA bootstrap + overrides distinguishes scope from a generic TLD listing.

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

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

The description explicitly notes that 'TLDs missing from this list may still work via WHOIS fallback', providing important context about when this list is not exhaustive. It doesn't explicitly state when to prefer this over siblings, but the fallback caveat gives useful usage direction.

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