dotmoose-tools

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so safety is covered. The description adds genuine scope behavior beyond that — a 20-link ceiling, same-origin filtering, and per-link status reporting — but says nothing about redirect handling, blocked/failed link behavior, or how long a run may take.

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 short sentences, zero filler, and the scope constraint leads before the exclusion. Nothing repeats the name or title verbatim.

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 tool with no output schema and full annotation coverage, the description conveys the essentials: what is checked, the boundary of the check, and that statuses are returned per link. Only the target format and failure/redirect semantics are 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 single 'target' parameter has 0% schema description coverage, so the description carries the burden. 'Found on one page' implies target is a page URL, which is useful, but it gives no format guidance (scheme required? path allowed? origin vs full URL) for a 1–1024 char string.

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 ('Check ... links found on one page and report the status of each') plus concrete scope limits: up to 20 links, same-origin only. The explicit 'not a site crawl' line separates it from crawl-style siblings, but it never distinguishes itself from the closest alternative, check_http_status.

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?

One negative exclusion is given ('This is a single page check, not a site crawl'), which implies when to reach for it, but no sibling is named as the alternative and no prerequisite (reachable page, same-origin assumption) is stated. Usage is inferable rather than spelled out.

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 openWorldHint=false, so safety is covered and the description only needs to add generation-specific context. It adds that the record is assembled from parts, but says nothing about the output form (a raw 'v=DMARC1; p=...' string?), whether inputs are validated or normalized, or whether addresses must carry a mailto: prefix.

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 with no filler, and the required parameter (policy) leads the enumeration. The terseness is close to the point of under-specification, but no sentence is wasted.

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 six parameters, zero schema descriptions, and no output schema, an agent needs the description to explain parameter meaning and return shape. One sentence cannot cover that: failureReporting is entirely absent and the produced record's format is never stated, leaving gaps an agent would have to guess at.

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 full burden, and it does not fully discharge it. It names policy, subdomainPolicy, report addresses, and percentage, but never mentions failureReporting (the sixth parameter), never distinguishes rua (aggregate) from ruf (forensic) address lists, and gives no format guidance for the URI arrays.

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+resource ('Assemble a DMARC record') and enumerates the inputs it consumes, which clearly marks it as a generator rather than a validator like check_dmarc. It stops short of explicitly naming the sibling it differs from, but the build-vs-check distinction is readable from the text.

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 only implied: an agent can infer that this is the tool to reach for when it needs to produce a DMARC record rather than inspect one. There is no explicit 'use this instead of check_dmarc when...' statement, no prerequisites, and no guidance on whether the result should then be validated or published.

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, openWorldHint=false, so safety is covered. The description adds one genuinely useful behavioral fact — that lookup terms are counted against the limit of 10 — but says nothing about whether an over-limit result is an error, a warning, or just a count, and nothing about return shape (no output schema exists).

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 tight sentence with the core operation front-loaded and the lookup-count behavior appended. No filler, no repetition 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 7-parameter tool with zero schema descriptions and no output schema, the description is too thin: it omits two parameters outright and gives no indication of what is returned (a record string? a term count? warnings?). Adequate to understand the purpose, insufficient to invoke confidently across the full parameter set.

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 maps to five of seven parameters (ipv4/ipv6 as 'IP ranges', includes, useA/useMx as 'a and mx mechanisms') but leaves allQualifier (an enum with four values and a default) and redirectDomain entirely unexplained, including what the qualifier enum means for the generated record.

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?

A specific verb-plus-resource: 'Assemble an SPF record' from named inputs (IP ranges, includes, a/mx mechanisms), plus a secondary function (counting DNS lookup terms). It implicitly separates itself from the sibling check_spf (build vs. check), but never names the alternative, so sibling differentiation is only inferable.

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 — you call it when you want to construct a record — but there is no explicit when-to-use, when-not-to-use, or pointer to check_spf for validating an existing record. The mention of the lookup limit of 10 hints at the tool's purpose (producing compliant records) without stating a routing rule.

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 establish that this is a safe, read-only, non-destructive, closed-world calculator. The description adds useful behavioral context by naming the exact conversions performed, though it omits assumptions such as month length, rounding, or unit conventions.

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 efficient sentence organized around three calculation modes. Every clause adds useful information 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?

For a calculator with no required parameters, no output schema, and no schema descriptions, the definition explains the three computations adequately. However, it leaves gaps around valid input combinations, precedence when multiple parameters are supplied, and exact return values.

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 maps loosely to all three inputs—link speed, monthly transfer, and file size at a given rate—but does not explicitly name parameters, state optionality, or confirm valid combinations.

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 calculator's three functions: link speed to transfer volume, monthly transfer to average rate, and file transfer time estimation. It is specific about the resource and operations, though it does not explicitly differentiate itself from any sibling tools.

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

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

The three clauses imply when to use each calculation mode, but the description does not explicitly say which parameter combinations are valid, whether parameters are optional, or when not to use the tool. Usage is inferable but not fully 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?

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds value by naming the exact results computed (network address, broadcast/last address, address counts), which matters because there is no output schema. It does not state error behavior for malformed CIDR or whether host bits are accepted.

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 with zero padding; the verb and the returned quantities come first and the input domain is stated immediately after.

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, read-only computation tool with no output schema, naming the computed quantities largely covers what an agent needs before calling. The remaining gaps — accepted CIDR format and failure behavior on invalid input — are minor for a purely deterministic calculator.

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 and schema description coverage is 0% — the schema only constrains length (3–60). The description partially compensates by saying the value is an IPv4 or IPv6 CIDR block, but gives no example format (e.g. '10.0.0.0/24'), no statement about host-bit handling, and no valid-range 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?

States a specific verb (compute) and a specific resource (IPv4/IPv6 CIDR block) and enumerates the outputs (network address, broadcast/last address, address counts). It is unmistakable what the tool does, though it never mentions the inverse sibling ip_range_to_cidr, so sibling differentiation is left to inference.

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 input scoping ('for an IPv4 or IPv6 CIDR block'), but there is no explicit when-to-use, no exclusion, and no pointer to the related sibling tools such as ip_range_to_cidr or lookup_ip_info. An agent can infer the context but gets no routing 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, openWorldHint, and destructiveHint=false, so the safety profile is covered. The description adds the selector default behavior but doesn't say the lookup is a live DNS query, how a missing record is reported, or whether results are cached — real behavioral context for an open-world read.

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 short sentences, front-loaded with the action and resource, and the second sentence carries only the non-obvious default. No waste.

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?

A simple two-parameter read tool with annotations covering safety and no output schema to paraphrase. The description covers the essentials; only the absent-record behavior and query nature are missing, which is minor at 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 coverage is 0%, so the description must carry parameter meaning. It does add genuinely useful information the schema lacks — the selector defaults to 'default' — but 'domain' and 'selector' are otherwise unexplained (e.g. that a selector follows the DKIM-style selector convention, or the allowed character set). Partially compensates 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 specific verb and resource ('Read the BIMI record') scoped to a domain and selector, which clearly separates it from siblings like check_dkim, check_dmarc, and check_mta_sts. It doesn't explicitly name a sibling, but the resource is unique enough that disambiguation isn't a concern.

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 — an agent checking BIMI configuration would call this — but there is no explicit when-to-use, no prerequisites, and no mention of alternatives or follow-up tools. Adequate but leaves the agent to infer 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?

The annotations provide good safety coverage (readOnlyHint: true, destructiveHint: false). The description enhances this by detailing the specific behaviors: reporting sizes both with and without compression, which is valuable functional 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?

It is a single, concise sentence where every word adds value to the definition, focusing on what the tool does and its specific 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?

Given the simplicity (one input parameter), the excellent purpose clarity, and the safety annotations, the description is fully sufficient 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 schema coverage is 0%, meaning the description must carry the semantic load. Specifying that the 'target' is a URL adds necessary meaning to the string parameter, meeting the minimum viable definition standard.

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 purpose is stated with high specificity: checking whether a URL is served with gzip or Brotli compression. This clearly differentiates it from the various security-focused checks present in the sibling tool list.

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?

While it doesn't explicitly state 'when vs. alternative,' the functional difference between checking compression (performance) and the many other sibling tools (security, structure, metadata) provides clear guidance on its appropriate 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?

Annotations already declare readOnlyHint=true, destructiveHint=false, openWorldHint=true, so the safety profile is covered by structured data. The description is consistent with this but adds almost nothing: it does not mention that this performs a live DNS lookup, what happens on NXDOMAIN or missing selector records, or how failures are reported. The added value is minimal beyond confirming the read semantics.

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?

One short, front-loaded sentence with no filler or redundancy. It is efficient, though its brevity borders on under-specification rather than ideal density.

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?

There is no output schema, so the description should convey what comes back — raw TXT record, parsed key, validity verdict, or error — but it does not. For a diagnostic DNS tool the agent cannot predict the response shape or interpret an empty result, which is a meaningful gap.

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, yet it only restates the two parameter names inline ("domain and selector"). It does not explain what a DKIM selector is or how a wrong selector causes an empty result, leaving the agent dependent on the schema's regex pattern alone.

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?

Specific verb and resource: "Read the DKIM public key record for a domain and selector." It clearly separates itself from check_spf, check_dmarc, and check_bimi by naming the DKIM record type, though it does not explicitly reference any sibling tool for contrast.

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 use this tool, no prerequisites (e.g., domain must be DNS-resolvable), and no mention of related tools like check_dmarc or check_dns_propagation that an agent might need alongside it. The agent must infer the usage context entirely from the name.

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, openWorldHint=true and destructiveHint=false, so the safety profile is covered. The description adds the useful detail that the lookup targets the _dmarc subdomain, but says nothing about behavior when no record exists (error vs. empty) or about lookup latency, leaving a modest gap.

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?

One sentence, front-loaded with the verb and resource, with zero filler. 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?

For a single-parameter read-only lookup with annotations covering the safety profile and no output schema, the definition is nearly sufficient. The only missing piece is any hint of what the returned record data looks like, which would help an agent decide it has the right 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 0% and the single 'domain' parameter is undocumented in the schema. The phrase 'for a domain' implicitly identifies the parameter's meaning, but provides no format constraints (e.g. no scheme, no subdomain handling) beyond what the schema's maxLength already enforces.

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 (Read) and resource (the DMARC record) plus the exact DNS location (_dmarc), so an agent knows precisely what is fetched. It does not name or contrast with siblings like build_dmarc_record or check_spf, which keeps it from 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?

Usage is only implied: the description says what it reads but never says when to call it versus build_dmarc_record or check_dkim/check_spf, nor does it mention prerequisites such as the domain needing to exist. Adequate for a diagnostic tool, but no explicit context or exclusions.

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, openWorldHint=true, and destructiveHint=false, so safety is covered. The description usefully enumerates which resolvers are queried, but says nothing about how results are presented (per-resolver answers vs. a diff), what happens when a record type is absent, or whether resolvers are queried in parallel.

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 with no filler; every clause (record types, resolvers) carries information an agent needs.

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 tool with annotations covering safety and no output schema, the description supplies the essentials: what records, what resolvers. The remaining gap is that it does not characterize the returned comparison, which matters for a 'propagation' 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?

There is one parameter ('domain') with 0% schema description coverage, so the description carries the burden. Saying answers are checked 'for a hostname' gives partial guidance but also muddies the terminology against the parameter name 'domain' (apex vs. subdomain, subdomain format) without resolving it.

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 verb (Check), the exact resource (A, AAAA, MX, NS, and TXT answers), and the scope (three named public resolvers). That combination separates it cleanly from siblings like check_dnssec, check_mx_records, and check_domain_delegation.

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 only implied by the word 'propagation' – an agent can infer this is for verifying that a record change has spread across resolvers. There is no explicit when-to-use, no when-not-to-use, and no pointer to the sibling tools (check_dnssec, trace_cname_chain) that cover adjacent questions.

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, openWorld and non-destructive, so the safety profile is covered. The description adds genuinely useful behavioral detail about what is queried (DS, DNSKEY, AD flag), but says nothing about behavior when DNSSEC is absent/unsigned or about query failures, which is the case an agent most needs framed.

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 that names what is checked and what verdict is derived, 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?

With no output schema, a single obvious parameter, and annotations covering the safety profile, the description gives enough to call the tool correctly and interpret its purpose. A note on unsigned-domain results would make it 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?

One required parameter with 0% schema description coverage; the description only implies the parameter via 'for a domain'. The domain argument is self-evident in form, so the gap is minor, but no format guidance (apex name vs. hostname, IDN, trailing dot) 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?

Names the specific records (DS, DNSKEY) and the exact signal evaluated (AD flag from a validating resolver), so the agent knows this is a DNSSEC validation check rather than a generic DNS lookup. It is distinguishable from siblings like check_dns_propagation or check_domain_delegation by the resources named, though no sibling is named explicitly.

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: use it when you need to know whether a domain is DNSSEC-signed and validating. There is no explicit when-to-use/when-not, and no pointer to alternatives such as check_domain_delegation for delegation-only questions.

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, openWorldHint=true, and destructiveHint=false, so safety is covered. The description usefully adds the output shape (delegation NS plus glue A/AAAA records), but says nothing about failure behavior for unregistered or invalid domains, rate limits, or depth of resolution.

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 that packs the resource, the action, and the returned records 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 simple read-only lookup with annotations covering safety, the description gives the essential output shape. However, it leaves gaps around input format, error cases, and usage context, so an agent could still be unsure how to call it correctly or interpret an empty result.

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 in either schema or tool description. The phrase 'for a domain' adds no format guidance (e.g., apex vs. subdomain, IDN handling), so the description does not compensate for the schema 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?

Names a specific verb+resource ('List the delegation nameservers for a domain') and specifies the exact outputs (A and AAAA glue addresses). It is clearly distinct from sibling tools like check_dnssec or check_dns_propagation, though it does not explicitly name those 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 states what the tool returns but gives no guidance on when to use it, when not to, or which sibling tool to prefer for related DNS checks. Usage is only implied by the tool name and output description.

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, openWorldHint=true, so the safety profile is covered. The description adds what information is reported, but says nothing about network fetching behaviour, redirect handling, timeouts, or what happens when a site declares no favicon.

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 with zero filler; the verb and the reported outputs are packed into it 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?

With no output schema, the description does state the return fields (URL, type, size), and read-only/open-world semantics come from annotations. The remaining gap is the expected format of 'target' and the no-favicon-found case.

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% — 'target' carries only a min/max length constraint with no type meaning. The description's phrase 'a site' is the only hint that target is a domain or URL, which is thin compensation for a parameter that 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?

States a specific verb ('Locate ... and report') and resource (favicon) plus the returned fields (URL, type, size). It is clearly distinguishable from most siblings, though the nearest neighbour, check_page_metadata, could plausibly surface favicon data and is never mentioned.

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 when-to-use or when-not-to-use guidance appears. The description never says to prefer this over check_page_metadata or check_website_security, nor does it state prerequisites such as requiring a reachable HTTP endpoint rather than just a domain.

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 openWorldHint, so the safety profile is covered. The description adds real behavioral detail beyond that: the tool performs two dependent lookups (PTR, then forward resolution of the returned name) and compares them, which explains latency and failure modes implicitly.

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?

One sentence, front-loaded with the verb and resource, no filler. Every clause carries information about the check's mechanics.

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 exists, so the description should sketch what comes back (the PTR name, whether forward match succeeded, mismatch cases). It tells the agent what is checked but not what the result looks like, leaving a real gap for a simple but result-oriented 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 0% for the single 'ip' parameter, so the description must carry meaning; it does clarify that the input is an IP address, but adds no format guidance (v4/v6, CIDR not allowed) beyond the parameter's name. Minimal compensation 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 specific operation: fetch the PTR record for an IP and verify the returned name resolves back to the same address, which is exactly what forward-confirmed reverse DNS means. This is clearly distinct from lookup_ip_info or check_dns_propagation among the 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 nature of the check implies when it's useful (mail-server/PTR validation), but the description never says when to pick this over lookup_ip_info or other DNS checks, nor any prerequisites. Usage is inferable rather than 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=true, openWorldHint=true and destructiveHint=false, so the safety profile is covered. The description adds that per-hop status codes and response headers are returned, which is useful, but it says nothing about redirect limits, timeouts, or failure handling for an open-world network call.

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?

One sentence, zero waste, and the output content is front-loaded so an agent immediately knows what it gets back.

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 no output schema, the description carries the return-value burden and does so adequately by naming hops, status codes and headers. It is only slightly incomplete on redirect-depth limits and error behavior.

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 single 'target' parameter is undocumented in the schema. The description only implies it is 'a URL' to fetch, adding minimal meaning beyond the name — no format, scheme, or length guidance 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 specific verb (fetch) and resource (URL redirect chain) and clarifies the return content: each redirect hop with status codes and headers. This distinguishes it reasonably from the sibling check_http_status, though it never names that sibling explicitly.

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 only implied — an agent can infer this is the tool for tracing redirects rather than a single status check, but there is no explicit when-to-use guidance, no mention of how it differs from check_http_status, and no prerequisites or limits noted.

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, openWorldHint=true and destructiveHint=false, so the safety profile is covered. The description adds the meaningful behavior that redirects are followed, but says nothing about timeouts, auth requirements, or whether the body is fetched for an outbound network call.

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?

One sentence with zero waste; the action and its key behavioral detail (redirect following) are 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?

A simple single-parameter read tool with annotations covering safety, so not much is needed. However, with no output schema, 'final status' is ambiguous – it does not say whether this returns an HTTP status code, a status string, or the final URL – and network-failure behavior is unstated.

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 0% description coverage for the single 'target' parameter, so the description must compensate. It does clarify that target is a URL to fetch, but omits format constraints such as allowed schemes or whether a bare domain is accepted.

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: fetch a URL and return the final status after redirects. The 'final status after following redirects' clause implicitly distinguishes this from chain-style siblings like check_http_chain, but it never names that alternative explicitly.

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 only implied – the agent can infer this is for a quick single-URL status check, and the redirect-following note hints it differs from a full-chain tool. No explicit when-to-use, when-not-to-use, or named alternative is 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, openWorldHint=true and destructiveHint=false, so safety is covered. The description adds that hostnames are resolved to their public addresses and that only 'reviewed' providers are queried, which is useful context, but it says nothing about how many providers are consulted, latency, rate limits, or what a result looks like.

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 sentence with the key scoping detail (hostname resolution) front-loaded and no filler. Every clause carries information about what is checked or how the target is interpreted.

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 tool with no output schema, the description covers input interpretation but not outcomes: it doesn't say whether the result lists per-provider verdicts, a boolean, or the specific blacklists consulted, which an agent needs to reason about follow-up steps.

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 has 0% schema description coverage, so the description must compensate. It does: 'target' accepts an IP address or a hostname (resolved to its public addresses), which the bare string schema does not convey. Only minor gaps remain, such as whether IPv6 literals are accepted.

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 (check) and resource (IP/hostname against DNS blacklist providers), and the scope clause distinguishes it from generic lookups like lookup_ip_info. It doesn't name a sibling alternative explicitly, but the operation is 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?

Usage is implied: use this to determine whether an IP or a hostname's resolved addresses appear on blacklists. There is no explicit when-to-use versus when-not, no statement of prerequisites (e.g. reverse DNS on the IP), and no pointer 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?

Annotations already declare readOnlyHint=true, openWorldHint=true, and destructiveHint=false, so the safety profile is covered. The description adds only the dual-stack comparison behavior; it says nothing about lookup timing, retries, DNS resolution vs. direct connect, or failure reporting. With annotations carrying the safety burden, the added context is modest but real.

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?

One short, front-loaded sentence with no filler. It is efficient, but there is too little content for the sentence to be structural — nothing follows the core statement.

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 exists, so the description should hint at what a result looks like (e.g., per-family reachability, latency, or pass/fail) and what target forms are valid. Neither is covered, leaving an agent guessing about input format and result shape for an otherwise simple 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 0%, so the description must compensate for the single 'target' parameter, and it does not. It never states whether target accepts a hostname, a full URL with scheme/path, or an IP literal, nor whether the same target is resolved to both A and AAAA records (which is the core semantic of the comparison).

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 ('Check whether a site answers over IPv6') and adds the IPv4 comparison, which no sibling tool covers (siblings are DNS/TLS/DMARC/performance checks). It is clearly distinguishable from the list, though 'site' leaves ambiguity about whether the resource is a hostname, URL, or literal address.

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 indication of when to use this versus related checks like check_dns_propagation, check_http_status, or looking_glass_ping. There are no exclusions, no prerequisites, and no note about whether the target should be a domain, URL, or IP.

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, openWorldHint=true, and destructiveHint=false, so the safety profile is covered. The description adds the useful fact that two distinct retrievals happen (a DNS TXT lookup plus an HTTPS fetch of the policy file), but says nothing about failure modes — e.g. what happens when no record exists or the policy file is unreachable/invalid.

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 naming both resources read; no filler, no 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 one-parameter read-only tool with full annotation coverage, the definition is minimally adequate. However, with no output schema, the description could reasonably hint at what comes back (policy mode, MX list, record presence) and at the fact that policy retrieval requires an HTTPS request, which an agent budgeting latency or sandbox permissions would want to know.

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%, but there is only one parameter and the description's 'for a domain' makes its meaning unambiguous. No added detail on format (bare domain vs. URL) beyond the schema's 253-char string constraint.

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 verb is specific ('Read') and the resources are named precisely: the MTA-STS DNS record and the published policy file. That distinguishes it from the many DNS/security-check siblings (check_dmarc, check_spf, check_tls_rpt), though it never names or contrasts with them.

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 when-to-use guidance, no prerequisites, and no mention of alternatives such as running a broader security audit or checking the related TLS-RPT/DMARC records first. The agent must infer the trigger condition from the tool name alone.

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, openWorldHint=true, and destructiveHint=false, so the safety profile is covered. The description adds genuinely useful output context (per-server A/AAAA resolution), but says nothing about failure behavior for nonexistent domains, missing MX, or whether priority values are returned.

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 with zero filler; the resource leads and the enrichment detail follows.

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 read-only lookup with annotations covering safety, the description explains both what is queried and what is returned. Minor gaps remain around MX priority and error/no-record handling, but nothing essential for invoking it 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?

Only one parameter with 0% schema description coverage, but the description's phrase 'for a domain' identifies it, and the schema property is named 'domain'. It adds no format constraints beyond the min/max length already in the schema, so a 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?

States a specific verb (List) and resource (MX records for a domain), and adds that each server's A/AAAA addresses are resolved. An agent can tell this apart from sibling checks like check_spf or check_dmarc, though it never names an explicit alternative.

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 indication of when to use this versus check_dns_propagation, check_domain_delegation, or other DNS-related siblings, and no prerequisites or exclusions are given. Usage must be inferred entirely from the tool name.

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, openWorldHint=true, so the safety and network-access profile is covered. The description adds real value by disclosing the contents of the response (the exact metadata categories), but says nothing about failure modes for unreachable pages, redirect handling, or whether the fetch is a single request.

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?

One front-loaded sentence with no filler; the verb and the enumerated output come first. The comma-separated field list is dense but every item is informative, so nothing is wasted.

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 no output schema, the description correctly carries the burden of describing return values and does so thoroughly. What is missing for a network-fetching tool is the input contract (target format) and any error/empty-result behavior, which leaves it only adequate rather than 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 0% and the single required parameter 'target' is completely undocumented in the schema. The phrase 'found on a page' weakly implies target is a page URL rather than a domain or IP, but the description gives no format detail (scheme required? path allowed? maxLength 1024 rationale?) 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 specific verb ('Return') and enumerates exactly what is extracted from the page: title, meta description, canonical URL, headings, hreflang, JSON-LD types. That is concrete and lets an agent distinguish it from audit_page_links or validate_sitemap by output content, though it never explicitly names those siblings or contrasts itself with them.

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 reach for this tool versus the ~40 sibling checks (audit_page_links, check_favicon, measure_web_performance, validate_sitemap). No prerequisites, no statement that it fetches over the network, and no indication of when it is inappropriate.

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, openWorldHint=true, destructiveHint=false, so the description need not restate safety. Beyond that it adds almost nothing: no indication of well-known (/.well-known/security.txt) versus root fallback, redirect handling, or what happens when the file is absent — the most common outcome.

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?

One front-loaded sentence with no filler or repetition. It is efficient, though the brevity here reflects under-specification rather than discipline.

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 and annotations cover the safety profile, but the description still leaves the two things an agent most needs: the accepted format of 'target' and the expected parsed result / missing-file behavior. No output schema exists to fill that gap.

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 'target' has 0% schema description coverage, so the description carries the burden — but 'for a site' only vaguely hints at meaning. It does not say whether target is a bare domain, a URL, or an IP, nor whether a scheme/path is tolerated.

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?

Specific verb pair (fetch and parse) plus a named, unambiguous resource (security.txt for a site). The resource is distinct from all siblings (test_robots_txt, validate_sitemap, check_website_security), so an agent can tell it apart, though no sibling is explicitly named.

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 statement of when to use this versus check_website_security, test_robots_txt, or any other sibling, and no prerequisites or exclusions. Usage must be inferred from the tool name alone.

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/openWorld/non-destructive, and the description adds real context on top: a live outbound connection to port 25 and explicit reassurance that no message is delivered. It does not mention firewall blocking or timeouts, so it stops short of 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?

Two sentences, front-loaded with the action and followed by the output list and scope caveat. No filler or 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?

With no output schema, the description usefully enumerates what is reported. It leaves out failure modes (port 25 blocked, no MX, TLS handshake failure), which would matter for an open-world network probe, but the essentials are present.

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% for the single `domain` parameter. The description implies the domain is used to locate mail servers (MX resolution), which is a genuine addition beyond the bare string schema, but it doesn't clarify whether bare domains vs. email addresses are accepted.

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 concrete action (connect to the domain's mail servers on port 25) and the exact outputs (banner, EHLO response, STARTTLS support). This clearly separates it from mail-sending operations and from policy-record checks like check_mta_sts, though it never names a sibling explicitly.

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 mail is sent and no recipient is tested" bounds the scope usefully, implying this is a non-intrusive capability probe. However, it never says when to pick this over check_tls_configuration or check_mta_sts, nor any prerequisite such as the domain needing MX records.

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/openWorldHint/destructiveHint=false, so safety is covered. The description adds genuinely useful behavior beyond that: the lookup count is computed recursively over the entire include chain rather than just top-level mechanisms, and the 10-lookup threshold is the yardstick — that is real signal for 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?

A single sentence with zero filler; the computed metric and threshold are front-loaded so the agent knows the output's shape of interest immediately.

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?

There is no output schema, so the description should say what comes back (the raw record? the numeric count? a pass/fail verdict?). It covers the core computation but leaves the response shape and error behavior undefined, which is a meaningful gap for an agent that needs to act on the result.

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 carries the parameter burden, and it only says 'for a domain' — which restates the obvious. It doesn't clarify whether a mail subdomain, apex, or URL is acceptable, nor what happens with invalid input. The single parameter with a 253-char constraint is otherwise self-evident, keeping this at a minimum-viable 3.

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 ('Read the SPF record for a domain') and goes further to say exactly what is computed: the DNS lookup count across the full include chain against the limit of 10. This cleanly separates it from the sibling build_spf_record, which constructs rather than inspects.

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 framing ('count the DNS lookup terms ... against the limit of 10') strongly implies diagnostic use when troubleshooting SPF lookup-limit failures, but no alternative is named and no when-not condition is given. An agent can infer the use case but must guess whether to reach for check_spf vs build_spf_record when auditing an existing 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?

Annotations already cover the safety profile (readOnlyHint=true, openWorldHint=true, destructiveHint=false), so the bar is lower. The description adds genuinely useful context beyond them: it opens a network connection to port 443 and reports TLS version, cipher, expiry and SANs, which matters since no output schema exists. It omits failure modes (timeouts, refused connections, self-signed certs), which keeps it short of 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?

A single sentence with the action and the returned data front-loaded, and no filler. Every clause 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 no output schema, the description does an adequate job naming the returned fields, but it leaves the 'target' value format undefined and gives no tie-breaker against check_tls_configuration. For a one-parameter network tool that is minimum viable rather than 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 description coverage is 0% for the single 'target' parameter. The description refers to an unspecified 'host', which loosely maps to 'target', but it does not say whether an IP, hostname, or URL is accepted, nor that the port is fixed at 443 and cannot be supplied. Partial compensation, not full.

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-and-resource pair: connect to a host on port 443 and return TLS version, cipher, and certificate details. That is concrete enough to distinguish it from most siblings, but it never contrasts with the closely named check_tls_configuration, so the boundary between the two is left ambiguous.

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 fixed 'port 443' wording implies HTTPS/TLS-on-web usage and implicitly excludes SMTP STARTTLS (check_smtp_starttls) or config-policy inspection (check_tls_configuration), but the description never states when to prefer this tool over those. Usage must be inferred rather than read.

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 establish readOnlyHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds that the tool actively probes a host for accepted protocol versions, which is useful beyond the annotations, but says nothing about how the probe behaves (port, timeouts, failure modes, rate limits).

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

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

One front-loaded sentence with the concrete action first and no filler. The trailing 'and summarize its TLS configuration' is somewhat vague and partly redundant with the first clause, but overall it is tight.

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 network-probing read tool with safety already covered by annotations and no output schema, the key missing pieces are target format and return-shape expectations. 'Summarize its TLS configuration' hints at the output but leaves the agent guessing what fields come back and how failures are reported.

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 has 0% schema description coverage, so the description must compensate. Saying 'a host' loosely implies target is a hostname, but it doesn't clarify accepted formats (hostname vs IP vs URL), whether a port can be specified, or how the target is resolved — leaving real ambiguity for a zero-coverage 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 verb (observe) and resource (TLS protocol versions accepted by a host) and adds that it summarizes the TLS configuration. That distinguishes it in spirit from check_tls_certificate, but it never names or contrasts with that close sibling, leaving the boundary to inference.

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 when-to-use guidance, no prerequisites, and no mention of when to prefer check_tls_certificate or check_smtp_starttls instead. The agent must infer usage entirely from the name.

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 declare readOnlyHint=true, openWorldHint=true, and destructiveHint=false, so safety behavior is covered. The description adds useful context by naming the DNS location '_smtp._tls', but it does not explain failure behavior, return format, or what happens when no record exists.

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 definition is a single front-loaded sentence with no redundant or filler text. Every phrase contributes to identifying the operation and its DNS target.

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 one-parameter check tool with rich safety annotations, the description is adequate to identify the operation. However, with no output schema, it does not explain what the TLS-RPT result contains or how absence/errors are represented.

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 parameter, so the description must carry the explanatory burden. It only says 'for a domain' and adds little beyond the parameter name, leaving format expectations such as bare domain versus URL unstated.

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 ('Read'), a specific resource ('TLS-RPT record'), and the DNS location ('_smtp._tls') for a domain. This is enough for an agent to distinguish it from sibling checks such as check_mta_sts, check_dmarc, and check_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 implies the tool is used to retrieve a domain's TLS-RPT record, but it gives no explicit when-to-use guidance or comparisons to related alternatives. No exclusions or prerequisites are provided.

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 openWorldHint=true, so the safety profile and external-network nature are covered. The description contributes by framing the operation as observing what a site 'exposes in its public responses', implying passive, non-invasive inspection, but it says nothing about timeouts, redirect handling, or what an unreachable or TLS-broken target yields.

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?

One sentence, front-loaded with the verb and the core scope, with the checked surfaces listed after. No filler, though the brevity leaves room that could have been spent on the target format rather than padding.

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 read tool with annotations covering the safety profile, the description is adequate at the level of 'what it inspects'. It falls short on the parameter's expected form and, with no output schema present, gives no hint of the shape of the findings returned.

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 a single required parameter 'target' with 0% schema description coverage, and the description never states whether it expects a bare hostname, a full URL with scheme, a URL including path, or a host:port pair. That format ambiguity is the one thing an agent most needs and the description does not supply it.

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 a specific verb ('Review') and a precisely scoped resource: the security controls exposed in a site's public responses, enumerated as security headers, cookie attributes, and CORS policy. That enumeration clearly separates it from siblings like check_tls_configuration, check_security_txt, and check_http_chain, though it never names those siblings explicitly.

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 only implied by the phrase 'public responses' – an agent can infer this is a passive header/cookie/CORS inspection. There is no statement of when to prefer it over adjacent checks (TLS configuration, security.txt, HTTP chain) and no stated preconditions such as the site being reachable or requiring a live host.

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 behavioral context by explaining the logic of the estimation (e.g., that daily copies are increments while weekly/monthly are full backups). This helps the agent understand the underlying mathematical assumption of the tool, complementing the readOnlyHint annotation.

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 tool uses a single, highly dense, and logically structured sentence. There is no extraneous information, making it maximally concise while conveying all necessary 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 complexity of defining a specific retention strategy, the description provides all necessary high-level context about the model's assumptions, allowing the agent to use the tool correctly for its intended estimation purpose.

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?

With 0% schema description coverage, the description is vital. It provides the essential semantic meaning to the input parameters by linking them to the G-F-S model (daily copies are increments, monthly copies are full), making the tool usable even without detailed schema documentation.

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 tool's purpose is highly specific: to estimate backup storage. It clearly defines the functional context by naming the 'grandfather-father-son retention plan,' which distinguishes it from generic storage calculation tools.

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

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

While the description clarifies the specific model it utilizes, it lacks explicit usage guidelines. It doesn't state when to use this tool relative to other estimation tools, nor does it provide instructions on potential edge cases or limitations of the G-F-S plan model.

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 openWorldHint=false, so safety is covered. The description adds a genuinely useful behavioral fact: the model assumes a constant monthly growth rate, which tells the agent results are idealized projections. It does not state the return shape, and with no output schema that gap remains.

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 sentence with zero waste, front-loading the operation, the model assumption, and the horizon. Nothing to trim and nothing buried.

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 three-parameter arithmetic projection with no output schema, the description covers the core intent but says nothing about what the response contains (per-month series vs. final figure) or whether growth is simple or compounded. Those omissions matter for correctly consuming the result.

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%, but the parameter names (currentGb, monthlyGrowthPercent, months) are self-describing and carry units. The description echoes the concepts implicitly ('storage size', 'monthly growth rate', 'up to 120 months') without adding format or interpretation detail beyond what the names and numeric bounds already convey.

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 ('Project storage size') plus the projection model and horizon, so an agent knows it is a forecast calculator rather than a lookup. It does not explicitly distinguish itself from the closest sibling, estimate_backup_retention, which also projects forward.

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 no when-to-use guidance, no prerequisites, and never names an alternative. An agent must infer from the name alone when this beats estimate_backup_retention or a manual calculation.

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 openWorldHint=false, so the safety profile is covered. The description adds real behavioral content beyond that: the result is an exact, minimal-cover set of CIDR blocks (not an approximation, not a single block), which is a meaningful output guarantee. It omits error behavior for invalid or inverted ranges.

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?

One front-loaded sentence with no filler; every clause ('IPv4 or IPv6', 'smallest set', 'covers it exactly') carries 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?

There is no output schema and no parameter descriptions, so the description is the only prose the agent gets. It conveys input domain and the output concept, but leaves open the return encoding (ordered list? string form?), handling of single addresses, and failure modes — gaps that matter for a converter with zero structured documentation.

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 the parameter load. It does clarify that start/end denote an address range and that IPv4 and IPv6 are both supported, but it never specifies the expected string format (bare address vs. CIDR notation vs. hostname) or behavior when start > end.

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 (convert) and resource (IPv4/IPv6 address range to CIDR blocks) with a precise qualifier ('smallest set ... covers it exactly'). It is distinguishable from siblings like calculate_subnet, though it never names an alternative explicitly.

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 transformation described — the agent knows to call it with a range when it needs CIDR form — but there is no explicit when-to-use/when-not, no mention of prerequisites, and no routing against the closest sibling (calculate_subnet).

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, openWorldHint and destructiveHint=false, so safety is covered. The description adds genuinely useful context the annotations don't: the measurement originates from the DotMoose network in Canada, is capped at 20 hops, and sends three probes per hop — details that shape how the agent interprets 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?

A single, front-loaded sentence with no padding. The vantage point and hop/probe limits are stated efficiently, though a short clause naming traceroute as the alternative would have been worth the extra 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 no output schema, the description should say more about what comes back (hop list, latencies, loss) than it does. It also omits the family parameter and any differentiation from looking_glass_traceroute, so it is adequate but leaves real gaps for a network-diagnostic 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 0%, so the description carries the full burden. It clarifies that 'target' is a public host or IP address, but it never mentions the 'family' parameter (IPv4 vs IPv6), leaving one of two parameters entirely undefined in both schema and 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?

States a specific verb ('sample the route') and resource (path from the DotMoose network in Canada to a public host/IP), which an agent can grasp immediately. However, it never distinguishes itself from the sibling looking_glass_traceroute, which sounds functionally identical, so the agent cannot tell the two apart from the description alone.

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 use this versus looking_glass_ping or looking_glass_traceroute, no prerequisites, and no exclusions. The agent must infer that 'path' is the route-tracing variant of the three looking-glass 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=true, openWorldHint=true and destructiveHint=false, so safety is covered. The description adds useful behavior (exactly four probes, originating in Canada), but says nothing about latency/timeouts, failure reporting, or output shape for a network probe whose result interpretation matters.

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?

One sentence, front-loaded with the action, with no filler. The only criticism is coverage, not verbosity, so structure and economy score full marks.

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 two-parameter probe with no output schema, the description covers the target and probe count but omits the IPv4/IPv6 'family' selector and any sense of what the result contains, which is the main gap an agent would hit when interpreting or retrying.

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. It explains 'target' as a public host or IP address, which is helpful, but the 'family' parameter (const 4 or 6, i.e. IPv4/IPv6 selection) is never mentioned, leaving one of two parameters completely undocumented.

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?

A concrete verb (send ICMP echo probes), an exact count (four), and an explicit vantage point (DotMoose network in Canada) plus target scope (public host or IP). It reads clearly against siblings like looking_glass_traceroute/path, though it never names them to draw the boundary explicitly.

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 phrase 'public host or IP address' implicitly excludes private/internal targets and hints at reachability testing, but there is no stated when-to-use versus looking_glass_traceroute or check_dns_propagation, and no prerequisites or limits (rate limits, timeouts) 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, openWorldHint, and destructiveHint=false, so safety is covered. The description adds useful behavioral context—origin network, hop limit, and one probe per hop—but does not disclose latency characteristics, timeout behavior, or output format, leaving it at a moderate level.

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 sentence, front-loaded with the action and source network, containing no redundant or filler 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?

The description omits any explanation of the return value (no output schema exists) and fails to mention the 'family' parameter, making it incomplete for an agent to invoke the tool confidently in all cases.

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. It explains the 'target' parameter as a public host or IP address, but the 'family' parameter (IPv4/IPv6 selector) is not mentioned at all, leaving a significant gap for one of the two parameters.

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 (trace the route) and resource (from the DotMoose network in Canada to a public host or IP), with operational constraints (20 hops, one probe per hop). It does not explicitly differentiate from siblings like looking_glass_ping or looking_glass_path, 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?

The description implies the tool's general use case but gives no explicit guidance on when to choose it over alternatives such as looking_glass_ping or looking_glass_path, nor does it state any exclusions or prerequisites.

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, openWorldHint, and destructiveHint=false, so the safety profile is covered. The description adds a useful disclosure that registrant contact fields are omitted, but it does not mention behavior for unregistered domains, TLD/registry coverage gaps, or rate limiting from upstream RDAP servers.

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 short sentences, front-loaded with the operation and followed by the key output caveat. No wasted text; the only weakness is that it ends without any usage/routing sentence.

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?

There is no output schema, so the description bears some burden of explaining what is returned. It discloses one important exclusion (registrant contacts) but does not describe what the summary actually contains (status, events, nameservers, registrar), leaving the agent to guess at the result shape.

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 single 'domain' parameter is documented nowhere beyond its type and length bounds. The description does not clarify accepted format (bare domain vs URL, IDN/punycode handling, subdomain behavior), which it should compensate for given the low 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?

States a specific verb and resource ('Return the public RDAP registration summary for a domain'), which clearly identifies the operation. It implicitly separates itself from sibling checks like check_domain_delegation or check_dnssec by naming RDAP registration data, but it does not explicitly distinguish itself from those 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?

There is no when-to-use guidance and no named alternative. The agent must infer from the RDAP phrasing whether this differs from check_domain_delegation or lookup_ip_info, and nothing states when this tool is the wrong choice.

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 (readOnlyHint, openWorldHint, destructiveHint=false), so the bar is lower. The description adds one real behavioral nuance: RDAP/ASN is returned 'for each public address', implying multi-address results and that private addresses yield no such data. It says nothing about failure modes for unresolvable hostnames or rate limits, keeping this at a moderate score.

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 that covers input and output with zero filler. Nothing here repeats structured fields verbatim.

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 exists, so the description carries the return-value burden, and it does so adequately by naming the two returned artifacts. For a read-only one-parameter lookup, only error/timeout behavior is missing, which is a minor gap.

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?

With 0% schema description coverage, the description must define the lone 'target' parameter, and it does: a hostname or a literal IP address. It does not address edge cases like IPv6 literals, CIDR ranges, or URL schemes, but the core accepted input types are unambiguously stated.

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 a specific verb pair (resolve a hostname / take an IP address) plus a concrete resource and the exact data returned (RDAP network data and ASN). It implicitly separates itself from lookup_domain_rdap by being the address-side counterpart, though it never names that sibling explicitly.

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 context is only implied: 'Resolve a hostname, or take an IP address directly' tells the agent it need not pre-resolve DNS itself. There is no explicit when-to-use/when-not guidance and no pointer to alternatives such as lookup_domain_rdap or check_ip_blacklists.

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, openWorldHint and destructiveHint=false, so safety is covered. The description adds real value by disclosing that measurement happens from the DotMoose diagnostic node (server-side vantage point, not the caller's network) and that results are raw timings rather than rendering metrics. It says nothing about rate limits, repeatability/sampling variance, or return shape.

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 short sentences with the operation stated first and the scope caveat immediately after. The final two sentences are both load-bearing (vantage point and non-benchmark disclaimers), though slightly overlapping in intent.

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?

A one-parameter read-only diagnostic is largely covered by annotations plus the described phase set, but with no output schema the agent gains no idea of the response shape (per-phase timings, units, error behavior for unreachable hosts). That is the main remaining gap for a self-contained definition.

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 'target' parameter has 0% schema description coverage, so the description carries the burden. It only implies the value is a URL ('...for a URL'), without stating accepted forms (scheme requirement, host:port, path handling) despite a 1024-char maxLength.

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 a specific verb (measure) and a specific set of resources (DNS, connect, TLS, TTFB) for a URL, executed from the DotMoose diagnostic node. The negative clause 'not a browser rendering benchmark' scopes it away from perceived-performance tools. It stops short of naming a sibling such as check_http_chain, so differentiation is inferred rather than stated.

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 'network timing sample, not a browser rendering benchmark' line implies the appropriate use case and one exclusion, but no sibling tool is named as an alternative and no trigger conditions ('use this when you need phase-by-phase network latency') are spelled out.

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, openWorldHint=true, and destructiveHint=false, so the safety and network profile is covered. The description adds that a remote fetch occurs, which is consistent with openWorldHint, but does not disclose failure behavior when no robots.txt exists or how redirects/errors are handled.

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 sentence that front-loads the fetch action and the evaluation outcome with no redundant phrasing. Nothing could be removed without losing meaning.

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 no output schema, the description must imply what comes back; it does not say whether the result is a boolean allow/deny, the matching rule, or the raw robots.txt body. For a three-parameter tool with zero schema documentation, this leaves meaningful gaps an agent cannot resolve elsewhere.

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 the load; it implicitly maps all three parameters to concepts ('for a site' = target, 'a user agent' = userAgent, 'a given path' = path). It stops short of specifying accepted target format (hostname vs URL) or the default Googlebot user agent, so a small gap remains.

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 compound action: fetch the robots.txt for a site and evaluate whether a user agent may fetch a path. Verb and resource are unambiguous, and no sibling tool covers robots.txt, so there is no ambiguity in 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?

Usage is implied by the sentence – an agent knows to call it when it needs to check robots.txt permissions – but there is no explicit when-to-use guidance, no prerequisites, and no mention of alternatives such as check_security_txt or validate_sitemap, which agents might plausibly confuse with crawler-policy 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?

Annotations already declare readOnlyHint, openWorldHint, and destructiveHint=false, so the safety profile is covered. The description adds two genuine behavioral facts beyond that: a hard cap of 12 aliases and that loops are detected and reported. It does not mention error behavior (NXDOMAIN, SERVFAIL) or truncation reporting, keeping 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?

One sentence, front-loaded with the action and resource, then the two operational constraints. 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?

For a one-parameter, no-output-schema lookup tool with strong annotations, the description is nearly sufficient: it covers what is resolved, the depth limit, and loop handling. It leaves the parameter's accepted hostname format and the shape of the returned chain implicit, which is a minor but real gap.

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 parameter, so the schema only gives a name and length bounds. The description says 'hostname,' which slightly clarifies that a bare host should be supplied rather than a URL, but leaves format details (trailing dot, IDN, subdomain handling) unspecified.

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?

Specific verb (follow) and resource (CNAME chain for a hostname), with concrete scope details: max 12 aliases and loop reporting. It does not name or distinguish itself from any sibling (e.g., check_dns_propagation or check_domain_delegation), 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?

Usage is only implied by the verb 'follow the CNAME chain' — an agent can infer it is for diagnosing alias resolution. There is no explicit when-to-use, when-not-to-use, or alternative tool named among the many DNS siblings.

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, openWorldHint=true, and destructiveHint=false, so safety and network access are covered. The description adds what the report contains (structure, URL count, fetch errors), which is real value. It does not disclose whether sitemap-index files are followed, how the sitemap is located, or whether redirects/retries occur.

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?

One sentence, front-loaded with the action, with no filler. Every clause (fetch, report structure, URL count, errors) carries distinct 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?

With no output schema, the description does sketch the return values, which is the right instinct. But for a one-parameter tool with an undocumented parameter, an agent still lacks the input format and sitemap-discovery behavior needed to call it confidently.

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 'target' has 0% schema description coverage, so the description must carry the burden. 'For a site' only loosely suggests a domain, leaving it unclear whether a bare domain, a page URL, or a direct sitemap.xml URL is accepted — a materially different invocation.

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?

Specific verb+resource: fetches a site's sitemap and reports structure, URL count and fetch errors. That is well beyond a restatement of the name and is clearly distinct from DNS/TLS siblings like check_dns_propagation or check_tls_configuration. No sibling overlap is explicitly named, so it stops short of 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?

There is no when-to-use guidance, no prerequisites, and no mention of alternatives such as test_robots_txt or audit_page_links, which are the nearest neighbors in the sibling set. Usage is only inferable from the name and the noun 'sitemap'.

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