Domain Intelligence

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

Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, covering the safety and network profile. The description adds one genuine behavioral trait beyond that—'resolved in parallel'—but says nothing about timeouts, partial failures, or rate limits for a live-DNS 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 dense sentence, front-loaded with the resource and immediately followed by the record types produced. No filler 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?

An output schema exists, so return-value documentation is not required, and the description lists record types plus the parallel-resolution behavior. For a single-parameter read tool this is nearly sufficient, with the only real shortfall being the undocumented domain format.

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

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

Schema description coverage is 0% and the single 'domain' parameter is undocumented in the schema. The description says 'for a domain' but adds no format or syntax guidance (e.g., apex vs subdomain, trailing dot, URL handling), so it fails to compensate for the coverage gap.

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 clear verb+resource ('DNS records for a domain') and enumerates the concrete record types returned (A, AAAA, MX, TXT, NS, CAA, SOA), so the agent knows exactly what data it yields. However, it does nothing to distinguish itself from the sibling domain_lookup, which likely retrieves overlapping information.

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

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

There is no guidance on when to pick this tool over the similarly-named siblings (domain_lookup, email_security, ssl_certificate). No prerequisites, no exclusions, no alternative routing—the agent must infer usage entirely.

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

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

Annotations already cover the safety profile (readOnly, idempotent, openWorld), and the description adds value beyond them: per-section failure isolation ('comes back as an object with an `error` field and the rest is unaffected') and the latency tradeoff of wait=true ('up to about 20 s'). It does not mention rate limits, auth requirements, or cost, which keeps it from a 5.

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

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

Three dense sentences, front-loaded with scope, then usage, then the two behavioral caveats. Every sentence adds decision-relevant information and nothing is repeated from the annotations or schema.

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

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

An output schema exists, so return-value documentation is not required, and the description still adds the per-section error-object shape. For a read-only open-world aggregator with three params it is nearly complete; the only real gap is the unexplained subdomain_limit and any coverage/truncation limits on the sections.

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 carry parameter meaning. It explains wait=true well (wait for every subdomain source vs the fast first result, ~20 s), but subdomain_limit is never mentioned and domain is left to the schema. Only the most non-obvious of three parameters is covered, so partial compensation.

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

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

States a specific verb and resource ('Full report on a domain') and enumerates exactly the five data sections (WHOIS/RDAP, DNS, SSL, subdomains, email auth) that map to the five sibling tools, so an agent immediately sees this as the aggregator rather than a single-section lookup. The phrase 'in one call' makes the contrast with the granular siblings explicit.

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

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

Gives concrete when-to-use cases ('triage a suspicious domain or profile a company's domain'), which is real routing guidance. It stops short of stating when NOT to use it (e.g., when you only need one section and should call dns_records or whois_lookup instead), so the alternative-selection condition is left implicit.

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

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

Annotations already declare readOnlyHint, idempotentHint and openWorldHint, so safety is covered. The description adds genuinely useful behavioral context the annotations do not: DKIM is discovered by probing about 29 common selectors (Google, Microsoft 365, Mailchimp, SendGrid), and custom selectors may not be found. That sets correct expectations about completeness of 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?

Two sentences, no waste. The core scope is front-loaded and the selector-probing caveat follows immediately where it is most useful.

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

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

An output schema exists, so return values need not be explained, and the read-only annotations cover safety. The description adequately covers scope and result limitations; the only shortfall is the undocumented domain parameter format.

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

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

Schema description coverage is 0% and the single 'domain' parameter has no description, so the description carries some burden. It says the tool works 'for a domain,' which implies a bare domain input, but it does not clarify accepted format (bare domain vs URL vs subdomain). Baseline 3 given limited added meaning.

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

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

The description names a specific resource and scope: 'Email authentication for a domain: SPF and DMARC records, and DKIM keys.' An agent can distinguish this from siblings like dns_records, ssl_certificate, or whois_lookup. It stops short of explicitly naming the sibling it is not, so it lands at 4 rather than 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?

Usage is implied by the resource ('for a domain'), but there is no explicit when-to-use guidance and no mention of alternatives such as dns_records or domain_lookup. Nothing tells the agent when this tool is the wrong choice versus a general DNS lookup.

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 openWorldHint, so the safety profile is covered. The description adds genuine context by disclosing that results come from a live TLS handshake (network-dependent, potentially slow/failing) rather than a local cache, but it says nothing about failure modes (no cert, TLS error, timeout) or handshake 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?

A single dense sentence that front-loads the essential fact (live TLS handshake on port 443) and then enumerates returned fields. No filler, though the field enumeration is largely recoverable from the output schema.

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

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

For a one-parameter read-only lookup with an output schema and full annotation coverage, the description supplies the key non-structured fact (live handshake vs. cached data) and the scope of returned data. Only the input domain format and error behavior are left unaddressed.

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

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

Schema description coverage is 0% for the single required `domain` parameter, so the description must compensate. It only indirectly hints at parameter semantics by fixing the port at 443; it never states whether `domain` should be a bare hostname, a URL, or include a port. The output-field list does not help with input format.

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?

Names the specific resource (the TLS certificate a domain serves on port 443) and the mechanism (a live handshake), which clearly separates it from whois_lookup, dns_records and the other siblings. It is a noun phrase rather than a verb+object, so it reads slightly as a data definition, but the intent is unmistakable.

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?

"From a live TLS handshake" implicitly tells the agent this is a real-time probe rather than cached registry data, which is a useful usage cue. However, it never states when to prefer this over domain_lookup or dns_records, nor any exclusion or prerequisite, so guidance remains 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 cover the safety profile (readOnly, idempotent, openWorld), so the bar is lower, and the description still adds meaningful behavior: multiple source backends, incremental result richness across repeated calls, and an explicit ~20s upper bound on wait. This is useful operational 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?

Three sentences, front-loaded with the resource and sources before the behavioral detail. However, the `live`/`subdomains`/`pools` clause consumes a full sentence without a corresponding parameter or observable to anchor it, so it does not fully earn 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?

An output schema exists so return values need not be documented, and the wait behavior is covered. But the description references `live`/`subdomains`/`pools` modes with no matching input parameter, and leaves `limit` undefined, so an agent cannot fully resolve how to select a mode or bound results.

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 carries the burden. It explains `wait` well (blocks for all sources, up to ~20s), but `limit` (default 100) is never explained — limit of what is left to inference — and `domain` gets no format guidance.

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+resource (subdomain enumeration of a domain) and names its data sources (certificate transparency logs, passive DNS, DNS brute force), which clearly separates it from siblings like dns_records and domain_lookup. The dangling `live`/`subdomains`/`pools` tokens muddy it slightly, since none correspond to a visible parameter.

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

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

It gives real usage context: first lookup returns a fast snapshot, later lookups are fuller, and `wait=true` waits for every source up to ~20s — enough for an agent to decide on a call strategy. It does not, however, state when to prefer this over the sibling 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 the safety profile (readOnly, idempotent, openWorld), so the bar is lower, and the description still adds real behavioral context: an RDAP-first strategy with IANA bootstrap and 22 fallback servers, port-43 WHOIS for 60+ TLDs, and a `_source` field identifying which backend answered. It does not mention rate limits or failure modes when all backends miss.

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, all front-loaded: what it returns, how it resolves it, and when to use it. No filler or repetition of the schema.

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

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

An output schema exists so return values need not be explained, and the description covers backend behavior and the `_source` discriminator well. The only omission is acceptable-input format for `domain`, which an agent calling this cold would benefit from.

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

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

There is one parameter with 0% schema description coverage, and the description never states the expected domain format (bare registrable domain vs. URL vs. subdomain, IDN handling). The parameter name is self-explanatory, so this is a minor but genuine gap rather than a severe one.

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 gives a specific verb+resource (registration data for a domain) and enumerates the exact fields returned (registrar, created/updated/expiry, nameservers, status), so an agent knows what it gets. It does not explicitly differentiate from the sibling domain_lookup, which is the only real gap.

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 states a clear use case: 'Use it for domain age, expiry or registrar checks.' That is a concrete selection cue. There is no explicit when-not or naming of the overlapping siblings (domain_lookup, dns_records), so it stops short of a 5.

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