drwho.me developer tools

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

Discloses backend (Cloudflare DoH), CNAME chain following, 5-second timeout, return format (JSON array with name/type/data), and error behavior (string on failure). Fully transparent given no 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?

Concise, front-loaded with purpose, no wasted verbiage. Each sentence serves a clear function.

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?

Completes the picture with return format, error handling, and relationship to siblings. No output schema, but description covers what's needed for correct invocation and interpretation.

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

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

Schema coverage is 100%, so baseline is 3. Description adds context by listing record types and common use examples. However, note inconsistency: description includes SOA, CAA, SRV but schema enum only has A, AAAA, MX, TXT, NS, CNAME. Still adds value beyond 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?

Clearly states it resolves a single DNS record type and returns raw answers. Distinguishes from dossier_dns (multi-type) and dossier_full (full health check), 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?

Explicitly directs use for quick targeted lookups and suggests alternatives (dossier_dns, dossier_full) for broader audits, providing ideal usage context.

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?

Discloses important traits: single OPTIONS request, 5-second timeout, returns a CheckResult with status and headers or error. No annotations present so description carries full burden; it covers essential 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?

The description is a single paragraph with clear, front-loaded sentences. No unnecessary words, but could be slightly more structured for readability.

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

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

For a tool with 3 parameters and no output schema, the description covers the request, timeout, default behavior, and return format. It is sufficiently complete for an agent to use 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?

Adds meaning beyond schema by explaining default values for method (GET) and origin (https://domainposture.com), and that domain must be a public FQDN. Schema coverage is 100% so baseline is 3, but description adds helpful context.

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

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

The description clearly states it sends a CORS preflight OPTIONS request and returns access-control-* headers. It specifies the domain parameter and distinguishes from sibling tools that focus on other aspects like DNS or headers.

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 explains when to use: to verify CORS policy for a specific origin-method pair or to check if a domain allows cross-origin requests. It mentions defaults but does not explicitly exclude scenarios or name 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?

Even though no annotations are provided, the description fully discloses behavioral traits: querying crt.sh first with fallback to certspotter, capping at 100 unique subdomains, 10-second timeout, and the structure of the return value (CheckResult with subdomains, wildcards, certCount, source). No contradictions.

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 with two sentences. The first sentence front-loads the purpose and key use-case, while the second efficiently packs technical details (fallback, limit, timeout, return structure). 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?

Given the tool's simplicity (one parameter, no output schema), the description provides complete context: it explains what the tool does, its internal behavior, limits, and the exact fields returned (subdomains, wildcards, certCount, source). There is no missing information for an agent to correctly select and invoke the 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?

The single parameter 'domain' has full schema description coverage (100%). The description adds meaning beyond the schema: 'Public FQDN, e.g. example.com. Must be resolvable on the public internet; IPs, ports, paths, and protocol prefixes are rejected.' This provides essential usage constraints.

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

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

The description clearly states the tool's purpose as discovering subdomains from Certificate Transparency logs, specifies its use for attack-surface mapping, and distinguishes it from the sibling tool dossier_full by advising to use the latter for complete audits.

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 provides usage guidance: use for attack-surface mapping, prefer dossier_full for complete audits. It also details fallback behavior (crt.sh then certspotter), limits (100 subdomains), and timeout (10s), giving clear context for when and how to use.

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 full burden. It fully discloses behavioral details: parallel queries to Cloudflare DoH with 5s timeout, query pattern (<selector>._domainkey.<domain>), and the exact return structure (CheckResult with status, found, notFound). This is comprehensive.

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 detailed but well-structured, covering purpose, usage, behavior, and return format in a logical flow. It is slightly verbose but each sentence adds value; no 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?

Despite no output schema, the description fully explains the return format, including both success and error cases. All parameters are explained with constraints, and behavioral details (parallel queries, timeout) are provided. The tool is self-contained and 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?

Schema coverage is 100%, but description adds valuable context beyond schema: domain must be public FQDN without IPs/ports/paths, and for selectors, it lists the built-in common set (default, google, k1, selector1, selector2, mxvault). This enriches parameter understanding.

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

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

The description clearly states the tool's purpose: probing a domain's DKIM public keys by querying DNS. It specifies the resource (domain) and action (probe DKIM keys), and distinguishes from sibling dossier tools by focusing specifically on DKIM.

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

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

The description explicitly states when to use the tool (verify signing configuration or discover active selectors) and provides guidance on when to supply selectors or omit them for probing common selectors. This helps the agent decide appropriate usage.

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

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

No annotations are provided, so the description carries the full burden. It discloses that the tool queries via Cloudflare DoH (1.1.1.1) with a 5-second timeout, and returns a CheckResult with status and tags on success or error reason on failure. This is sufficient behavioral context.

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, with five sentences that front-load the core purpose, then add usage guidance and technical details. Every sentence provides unique value, with no unnecessary 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?

Given the single parameter and no output schema, the description covers the tool's function, usage context, technical behavior, and result structure completely. An agent has sufficient information 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 schema coverage is 100% for the single parameter 'domain', and its description is already informative. The tool description adds value by explaining that the domain is used to construct the _dmarc.<domain> query, going 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 retrieves and parses a domain's DMARC policy from its _dmarc.<domain> TXT record. It specifies the verb (retrieve and parse), resource (DMARC policy), and distinguishes it from sibling tools like dossier_spf and dossier_dkim.

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 use cases: auditing email authentication policy, verifying p and rua settings, and confirming alignment mode. It recommends pairing with dossier_spf and dossier_dkim for complete coverage. It does not explicitly state when not to use, but the context is clear.

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

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

Describes parallel queries to 1.1.1.1 with 5s timeout and return type (CheckResult). No annotations, so the description carries the burden and does well, though could mention potential rate limiting or error specifics.

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, front-loaded with purpose, then usage, then implementation. 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?

No output schema, but description explains the return shape (CheckResult union). Complete for a DNS lookup tool with one parameter.

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%, but the description adds useful constraints (public FQDN, no IPs/ports) that go beyond the schema description.

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

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

The description clearly states it fetches a domain's full DNS profile (A, AAAA, NS, SOA, CAA, TXT) and distinguishes from siblings dns_lookup (single record) and dossier_full (all 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?

Explicitly recommends using as first step of a domain audit and contrasts with alternatives for single record or full checks.

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?

Without annotations, the description carries the burden. It discloses that the tool fires Cloudflare DoH DS and DNSKEY queries with DO=1 and an 8s timeout, and describes the return type as a CheckResult union. This is good, though it could mention rate limits or error 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?

The description is just two sentences, front-loading the core purpose and then providing key details (queries, timeout, return type). Every sentence adds value with no 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?

For a single-parameter tool with clear schema, the description fully covers purpose, usage, behavioral details, and return type. No output schema exists, but the description explains the return structure (CheckResult union with fields). It is complete for this complexity.

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%, but the description adds context: 'Public FQDN, e.g. example.com. Must be resolvable on the public internet; IPs, ports, paths, and protocol prefixes are rejected.' This reinforces and extends the schema, justifying 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 explicitly states the tool verifies DNSSEC chain-of-trust for a domain, listing relevant record types (DS, DNSKEY, AD flag). It distinguishes from siblings like dossier_dns (raw record types) and dossier_full (complete audit), making purpose clear.

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 says 'Use to confirm the zone is signed and resolvers accept the chain' and directs when to use alternatives (dossier_dns for raw records, dossier_full for complete audit). This provides explicit usage guidance.

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

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

No annotations, so description carries full burden. Discloses parallel execution via Cloudflare DoH or direct HTTPS, 5s per-check timeout, and return format (JSON object with CheckResult discriminated union). No contradictions.

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?

Four sentences, front-loaded with purpose. Every sentence adds unique information (parallel execution, when to use, timeout, return format). 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?

Given tool complexity (10 checks, parallel, timeout) and no output schema, description covers all key aspects: input, execution model, timeout, output structure, and behavioral notes. Fully adequate for agent selection and invocation.

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

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

Only one parameter 'domain' with 100% schema coverage. Description adds value: clarifies it must be a public FQDN, rejects IPs/ports/paths/protocols. Provides example.

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?

Clearly states it aggregates all 10 Domain Dossier checks in parallel and returns all results. Distinguishes from sibling tools by noting individual dossier_* tools are for focused 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?

Explicitly says when to use (comprehensive domain health snapshot) and when to use alternatives (single focused check prefer individual tools). Also mentions paywall call count.

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?

Despite no annotations, the description fully discloses behavior: single GET, 5s timeout, captures before redirect, and details success/error return format.

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 paragraph but well-structured with a core statement, details, and result format. Could be slightly more organized, but it's concise 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?

Despite no output schema, the description fully explains the return structure (CheckResult with fields). Given the single parameter and clear behavior, the description is 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?

Schema coverage is 100% with a description for 'domain'. The description adds further clarification (e.g., public FQDN, restrictions on IPs/ports/paths) which is helpful but not essential.

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 fetches HTTP response headers and performs a security audit. It lists specific headers and distinguishes from sibling dossier_redirects.

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

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

Explicitly says when to use this tool (review security headers) and when to use alternative (redirect tracing with dossier_redirects). Also specifies technical behavior: single GET, timeout, header capture.

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 fully discloses the tool's behavior: it resolves a TXT record, fetches a policy with a 10s timeout, and returns CheckResult or not_applicable. No contradictions.

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 that cover purpose, action, sequence, and edge case with no wasted words. Front-loaded with the core purpose.

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 input, process, output (CheckResult), and the not_applicable case. No output schema exists, but the description provides enough information.

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 describes the 'domain' parameter, but the description adds useful constraints: 'Public FQDN', 'Must be resolvable on the public internet', and rejected inputs (IPs, ports, etc.).

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 ('Fetch and validate a domain's MTA-STS policy') and the resource (MTA-STS policy). It differentiates from sibling tools by specifying the exact DNS record and endpoint used.

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

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

The description provides a clear use case ('confirm inbound SMTP is locked to TLS') and mentions when it's not applicable. However, it does not explicitly contrast with sibling tools like dossier_tls or 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?

No annotations provided, but description fully discloses behavior: queries Cloudflare DoH, follows CNAME aliases, 5s timeout, and output format (CheckResult discriminated union with success/error).

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?

Description is concise (4 sentences), front-loaded with purpose, and every sentence provides useful 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?

For a single-parameter tool with no output schema, the description is complete: explains purpose, behavior, and return format.

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

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

Schema coverage is 100% with detailed parameter description. The description does not add new information about the parameter itself 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 it looks up MX records and returns them sorted by priority, distinguishing it from sibling tools like dns_lookup (raw DNS) and other dossier 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?

Explicitly specifies use cases (verifying inbound-mail routing, precursor to SPF/DMARC) and provides an alternative (dns_lookup with type=MX for raw answer).

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 discloses that the tool follows Location headers with fetch (no auto-redirect), stops at 10 hops, and has a 5-second timeout per hop. Since no annotations are provided, this fully informs the agent of behavioral traits. 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 concise, using a single well-organized paragraph. Every sentence provides necessary information without waste. It front-loads the core action and then adds details and return format.

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 single parameter and no output schema, the description provides a thorough explanation of the tool's behavior, limitations, and return format. It is complete for an agent to understand and use 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 schema covers the domain parameter fully, and the description adds important constraints: must be a public FQDN, and IPs, ports, paths, and protocol prefixes are rejected. This adds value 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 traces the full HTTP redirect chain starting from https://<domain>/, recording each hop's status code and destination URL. It distinguishes itself from sibling tools by focusing on redirect debugging rather than DNS or other 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 explicitly mentions use cases: debug redirect loops, verify HTTP→HTTPS upgrades, audit link shorteners. It also specifies limits (10 hops, 5s per hop). While no alternatives are named, the sibling list and context make the tool's unique purpose 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 provided, but description covers behavioral traits: uses Cloudflare DoH, 5s timeout, fetches TXT records, parses v=spf1, returns success/error structure. Missing potential side effects like rate limits, but read-only nature implied.

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?

Description is informative but slightly verbose; each sentence adds value. Front-loaded with purpose and usage, then technical details. Could be more concise.

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 no output schema, description fully explains return values (CheckResult with status, raw, mechanisms, lookupCount) and error case. Covers timeout, DoH, parsing logic, and sibling context. Complete for a complex 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 coverage is 100% with existing parameter description. Description adds context about what the tool does with the domain but no additional parameter semantics beyond 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?

Description clearly states it retrieves and parses a domain's SPF record, decomposing into mechanisms and qualifiers. It distinguishes from sibling tools like dossier_dmarc and dns_lookup.

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

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

Explicitly says when to use (verify email sender policy, debug delivery failures, check 10-lookup limit) and when to use alternatives (pair with dossier_dmarc, use dns_lookup for raw record).

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 discloses the timeout (5 s), the action (TLS handshake, extract leaf certificate), and the detailed return format for both success and failure. Since annotations are absent, this fulfills the need for 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?

The description is three paragraphs with no extraneous information. It front-loads the main purpose and efficiently covers usage, behavior, and output.

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?

Despite the lack of output schema, the description provides a complete specification of the return value. The tool has low complexity and the description covers all necessary aspects for correct invocation.

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

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

The input schema already fully describes the 'domain' parameter with constraints. The description does not add new parameter-specific information, but it places the parameter in context (port 443). With 100% schema coverage, the baseline is 3, and the description adds minimal extra value.

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 'fetch and inspect' and the resource 'TLS certificate'. It distinguishes from siblings by explicitly noting it is not a full cipher-suite scanner, making its scope clear.

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 use cases: 'verify certificate expiry, issuer, Subject Alternative Names, or detect mismatched or self-signed certs'. It also tells when not to use: 'not a full cipher-suite scanner'. However, it does not name alternative tools from the sibling list.

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

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

Describes resolution method (Cloudflare DoH), timeout (5s), and result type (CheckResult). With no annotations, this adds value. Could mention it's a read-only operation.

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 fluff, front-loaded purpose. 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?

For a simple lookup tool with one param and no output schema, the description covers purpose, usage, method, timeout, and result cases adequately.

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 a clear param description. The description adds resolution context but does not enhance parameter 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?

Clearly states it looks up TLS-RPT policy, distinguishes from sibling tools by specific record type. Verb+resource+scope are 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?

Provides clear when-to-use ('confirm the domain receives reports of SMTP-TLS failures') and mentions the not_applicable case. Lacks explicit exclusions or comparison to 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?

With no annotations, the description fully discloses behavior: concurrent fetches of /, /robots.txt, /sitemap.xml via HTTPS with 5-second timeouts, lightweight HTML parser, and the exact response structure (CheckResult with status, meta, robots, sitemapPresent or error with reason).

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: opens with core purpose, lists components, gives use cases, references siblings, explains implementation details, and closes with return format. All sentences are informative with minimal redundancy, though slightly dense.

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 no output schema, the description fully explains the return format (composite CheckResult with specific fields). With only one parameter and high schema coverage, no essential information is missing; the tool's scope, inputs, and outputs are completely described.

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 the schema already describes the single parameter (domain) in detail, including constraints. The tool description adds context ('Public FQDN, e.g. example.com') but does not significantly extend beyond the schema's own description, so baseline 3 applies.

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

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

The description clearly states the action ('snapshot a domain's public web surface') and specifies the exact resources checked (robots.txt, sitemap.xml, home-page <head> metadata including title, description, OpenGraph, Twitter cards). It also distinguishes from sibling tools by naming dossier_headers and dossier_redirects.

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 lists use cases ('SEO audits, content discovery, or verifying metadata before sharing') and provides alternatives for HTTP headers (dossier_headers) and redirect behavior (dossier_redirects), giving clear when-to-use and when-not-to-use 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?

With no annotations, the description discloses the query method (WHOIS over TCP/43 via whoiser library), 15s timeout, and the not_applicable case for redacted queries. This provides full behavioral context.

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 short, with each sentence adding unique value: purpose, usage, implementation details, and edge case. No unnecessary 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?

Given a single parameter and no output schema, the description covers the return type (CheckResult) and a key edge case. It lacks comparison with siblings but is sufficient for a focused 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 coverage is 100%, so baseline is 3. The description adds meaning by specifying valid format (FQDN), requirements (resolvable, public), and rejected inputs (IPs, ports, etc.), beyond the schema's description.

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 looks up registrar, creation date, expiry date, and registry statuses for a domain, using the verb 'look up' and specifying resource and fields. It distinguishes from siblings by focusing on WHOIS data.

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 recommends use for ownership/expiry audit and notes when not_applicable occurs. However, it does not explicitly say when not to use or list alternatives, though no sibling duplicates this function.

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 details that it queries ipinfo.io with a server-side token (not exposed), returns a JSON object with specific fields, and returns an error string on failure. No annotations exist, so the description carries the full burden; it is quite transparent although it omits potential concerns like rate limiting.

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

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

The description is concise at five sentences, front-loaded with 'Context lookup', and covers purpose, usage, implementation, output format, and error handling without unnecessary 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 simple tool with one parameter, no output schema, and no annotations, the description is fully complete: it explains input constraints, output fields, error behavior, and backend details. There are no gaps in information needed for correct invocation.

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

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

Schema coverage is 100% with a good description of the ip parameter. The description adds crucial clarification that hostnames are not accepted, which goes beyond the schema's description and adds value.

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 that it resolves an IPv4 or IPv6 address to geolocation, ASN, org, city/country. It distinguishes itself from siblings like dns_lookup and dossier_dns by explicitly noting that those are for hostname resolution.

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 tells the agent to use this tool when network/location context for a raw IP is needed, and to prefer dns_lookup or dossier_dns for hostnames. This provides clear when-to-use and when-not-to-use 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?

Despite no annotations, description fully discloses local synchronous execution using ua-parser-js, no external calls, and enumerates return fields with handling of unknown values.

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?

Description is well-structured and front-loaded with the core action, though slightly verbose with examples; still 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?

For a simple single-parameter tool with no output schema, the description covers purpose, behavior, return fields, and constraints comprehensively.

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%; description adds value with a concrete example and clarifies the parameter's role beyond the schema's description.

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 verb 'Parse' and resource 'User-Agent header string', specifies components extracted, and distinguishes from sibling network-based lookups.

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

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

Explicitly describes use case (analyzing server logs or request headers) and what the tool does not do (no network lookups), providing clear context.

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