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

Adds significant context beyond annotations: discloses the API key authentication requirement (auth needs), explains the distributed nature of the probe network (architectural context), and details the return format ('Traceroute hop tables per probe with RTT and IP'). Annotations only cover safety profile (readOnly/destructive), while description explains operational requirements.

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

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

Well-structured with front-loaded purpose sentence followed by context (network), prerequisites (API key), and docstring-style Args/Returns sections. No wasted sentences given the schema description gap. Slightly formal structure but appropriate for the technical complexity.

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?

Complete coverage for a measurement tool: explains what it does, what it needs (auth), parameter semantics, and return format ('hop tables with RTT and IP'). With annotations covering safety hints and the description covering operational details, no significant gaps remain.

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 has 0% description coverage (no property descriptions), but the Args section fully compensates by documenting all three sub-parameters: target semantics ('IP address or hostname'), probes constraints ('default 5, max 25'), and response_format options ('markdown' or 'json'). Carries the full documentation burden effectively.

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?

Excellent specificity: 'Launch a RIPE Atlas traceroute measurement' provides exact verb, service (RIPE Atlas), and operation type (traceroute). The mention of 'global probe network' distinguishes it from local traceroute tools and siblings like `rir_looking_glass` or `peerglass_dns_resolve`.

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

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

Provides explicit prerequisite: 'Requires PEERGLASS_RIPE_ATLAS_KEY environment variable.' The mention of 'thousands of vantage points' implies the distributed use case (when you need geographic diversity). Lacks explicit comparison to local traceroute alternatives, but the API key requirement serves as a clear gate for when-to-use.

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

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

Annotations declare readOnlyHint=true and destructiveHint=false, establishing the safety profile. The description adds valuable behavioral context beyond these booleans: it explains the scoring methodology (0–100 scale), defines catastrophic vulnerability thresholds (1–2 providers), and details the specific output components (transit providers by dependency, single-upstream count), helping the agent understand what constitutes a 'good' vs 'bad' result.

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 uses a structured docstring format (Args/Returns) with zero filler. The vulnerability explanation ('cutting those providers isolates the entire country') earns its place by contextualizing the tool's value proposition. Information is front-loaded with the core action in the first sentence, followed by parameter and return value specifications.

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

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

Given the presence of an output schema (noted in context signals) and good annotations, the description appropriately focuses on domain-specific context rather than repeating structural metadata. It comprehensively covers the complex BGP/infrastructure domain by explaining what the resilience score measures, the risk model (upstream dependency), and the specific data returned, making it sufficient for an agent to use effectively.

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 schema properties lack descriptions), the description fully compensates by documenting both parameters in the Args section: country_code includes the format standard (ISO 3166-1 alpha-2) and concrete examples ('SY', 'BY'), while response_format specifies the enum values ('markdown', 'json') and default behavior.

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

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

The description explicitly states the tool 'Map[s] internet resilience for a country by identifying transit providers that many in-country ASNs depend on, and computing a resilience score.' This provides a specific verb (map/identify/compute), resource (transit providers/ASNs), and distinguishes from siblings like peerglass_country_health by focusing specifically on chokepoint analysis and dependency concentration rather than general health metrics.

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

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

The description provides clear contextual guidance by explaining that 'Countries with 1–2 dominant upstream providers are catastrophically vulnerable,' which signals when this tool is valuable (assessing isolation risk). However, it does not explicitly name sibling alternatives (e.g., 'use peerglass_country_health for general connectivity status instead') to guide selection against the 30+ related tools available.

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 indicate read-only, idempotent, non-destructive behavior. The description adds valuable context about the methodology (BGP withdrawal analysis, neutral vs ISP resolver comparison) and data sources (OONI, Starlink/Viasat/OneWeb) without contradicting the safety annotations. It could enhance further by mentioning data freshness or caching behavior.

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

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

The description uses efficient bullet points for the four weighted components and structured Args/Returns sections. Every sentence conveys distinct information (methodology, weighting, audience, parameters), with no redundant filler despite the rich detail provided.

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

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

Given the tool's complexity (composite aggregation of four distinct measurement types) and the presence of an output schema, the description provides sufficient context by explaining the scoring methodology, target audience, and return value structure without needing to replicate the full output schema 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?

With 0% schema description coverage for the input properties, the description fully compensates by documenting both parameters in the Args section: country_code includes the ISO 3166-1 alpha-2 standard and concrete examples ('UA', 'SY', 'MM'), while response_format specifies the enum values and default behavior ('markdown' default or 'json').

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

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

The description explicitly defines the tool as providing a 'Composite country internet health score' with specific component weightings (40/30/20/10). It clearly identifies target users (journalists, NGO directors, crisis responders) and distinguishes this dashboard view from individual probe tools by listing the four distinct data sources it aggregates.

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

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

The description clearly establishes when to use this tool (for a single 0-100 score and plain-language summary) and implies its scope through the composite methodology. However, it does not explicitly direct users to sibling tools like peerglass_shutdown_detect or peerglass_dns_censorship for component-level detail versus this aggregate view.

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 establish the safety profile (readOnlyHint, idempotentHint), while the description adds valuable behavioral context absent from structured fields: it discloses the external data source (crt.sh), deduplication behavior, and the specific output fields returned (CN, CA, validity, SAN). The openWorldHint annotation is implicitly confirmed by the crt.sh reference.

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

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

The description is well-structured and front-loaded: single-sentence purpose statement followed by use-case bullets and structured Args/Returns sections. Every sentence adds value—no tautology or redundancy with the tool name. Length is appropriate for the parameter complexity.

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

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

Given the presence of an output schema and clear annotations, the description provides adequate completeness: it summarizes the return type (certificate table with CA summary) and covers all input parameters. Minor gap: no mention of rate limits or crt.sh availability constraints, though not strictly required.

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 schema description coverage at 0% (or near-zero), the Args section in the description provides essential semantic meaning for all three parameters: domain includes an example ('cloudflare.com'), limit explains constraints ('default 50, max 500'), and response_format clarifies the enum options. This fully compensates for the schema's lack of descriptions.

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

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

The description opens with a specific verb ('Search') and clearly identifies the resource (TLS certificates via Certificate Transparency logs) and scope ('ever issued for a domain'). It effectively distinguishes from sibling tools like peerglass_tls_inspect by emphasizing historical certificate transparency data versus real-time inspection.

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 'Useful for:' section provides four concrete scenarios (shadow IT discovery, CA auditing, incident forensics, rotation verification) that clearly signal when to invoke the tool. However, it lacks explicit guidance on when NOT to use it or direct comparisons to siblings like peerglass_tls_inspect or peerglass_dns_enumerate.

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 cover safety profile (readOnly, idempotent, non-destructive). The description adds valuable behavioral context: specific resolver sources (Cloudflare, Google, Quad9), detection methods, and return format (per-resolver response table). Does not mention timeout behavior or 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?

Excellent structure with clear sections for purpose, detection list, arguments, and returns. Bullet points enhance scannability. No redundant text; every sentence conveys essential information about tool behavior or parameters.

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?

Comprehensive for a censorship detection tool: covers detection logic, vantage points, parameter semantics, and return value summary. Given the presence of an output schema, the brief return description is sufficient. Minor gap: no mention of execution time expectations for multi-resolver queries.

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 Args section fully compensates by documenting all three parameters (domain, country_code, response_format) with types, optionality, defaults, and examples (e.g., 'twitter.com', 'markdown').

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

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

The description explicitly states the tool 'Probe[s] for DNS censorship by querying a domain from multiple resolver vantage points' and lists specific detection techniques (NXDOMAIN injection, IP poisoning, DPI block) that clearly distinguish it from sibling tools like peerglass_dns_resolve or peerglass_dns_propagation.

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 'Detects' section implies usage by listing specific censorship techniques, but the description lacks explicit when-to-use guidance relative to sibling DNS tools (e.g., 'use this instead of dns_resolve when investigating censorship').

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?

Adds valuable behavioral details beyond annotations: notes parallel execution ('All queries run in parallel for fast results'), lists specific blocklist providers included in the check, and describes the return value format ('Per-list listed/clean status with return codes'). Does not mention rate limits or error behaviors, but covers execution model well.

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

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

Well-structured with front-loaded purpose statement, followed by behavioral details (parallel execution), then explicit Args and Returns sections. Every sentence adds value. Minor deduction because the Args section duplicates information that belongs in schema (though schema coverage is reported as inadequate).

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?

Adequately complete for a read-only lookup tool: combines rich annotations (idempotent, readOnly, openWorld) with description coverage of inputs, outputs, and execution behavior. Given the presence of output schema documentation in the description and the simple single-input nature, no critical gaps exist.

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?

Compensates effectively for 0% schema description coverage at the root level by documenting both nested parameters (ip, response_format) in the Args section, including the default value ('markdown') and valid options for response_format. Provides redundant example for ip that schema also contains, but ensures clarity.

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

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

Excellent specificity: states the exact action ('Check'), resource ('IPv4 address'), and scope ('30 DNS blocklists' including named lists like Spamhaus ZEN, Barracuda, SORBS). The mention of specific blocklists distinguishes it from generic threat intel or DNS resolution tools in the sibling 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?

Provides implicit usage context by specifying the domain (DNS blocklists/RBLs for spam/security), but lacks explicit guidance on when to use this versus siblings like peerglass_threat_intel or peerglass_dns_censorship. No explicit prerequisites or exclusions listed.

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 cover the safety profile (readOnly/idempotent), but the description adds valuable behavioral context not in structured data: the four possible return statuses (SECURE/INSECURE/BOGUS/INDETERMINATE), the specific meaning of BOGUS (signatures exist but fail validation), and the security implications. No contradictions with annotations.

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

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

Well-structured with clear sections: purpose statement, BOGUS status explanation, Args, and Returns. The Args/Returns sections slightly duplicate schema information but provide necessary context given the 0% top-level coverage. The BOGUS explanation sentence earns its place by highlighting security relevance.

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

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

Given the tool's complexity (cryptographic validation), the description adequately covers inputs, outputs, and behavioral traits. It documents return value meanings and signing algorithms. Minor gap: it assumes network access (openWorldHint is true in annotations) but doesn't describe network dependency or potential timeouts in the text.

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% top-level schema description coverage (the 'params' object lacks a description), the description compensates via the Args section detailing the nested DNSSECInput structure, including the domain example ('cloudflare.com') and response_format options ('markdown' or 'json'). This adds necessary semantic meaning beyond the bare schema.

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

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

The description clearly states the specific action ('Validate the DNSSEC chain-of-trust') and resource (DNSSEC records for a domain), distinguishing it from generic DNS resolution siblings like peerglass_dns_resolve by explicitly mentioning DNSKEY, DS, and RRSIG record types.

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 clearly explains what BOGUS status means (misconfiguration/tampering indicator), it lacks explicit guidance on when to use this versus sibling tools like peerglass_dns_resolve or peerglass_dns_censorship. The usage is implied by technical specificity but not explicitly 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 declare readOnlyHint, destructiveHint, and openWorldHint. The description adds valuable behavioral context beyond these annotations: it specifies exactly what gets probed (common DKIM selectors like google/selector1/default), what validations occur (SPF policy strength, DMARC pct coverage), and the risk scoring methodology (LOW/MEDIUM/HIGH/CRITICAL). It does not mention rate limits or timeout behavior, preventing a perfect 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?

The description is excellently structured with bullet points for scannability, followed by clearly labeled Args and Returns sections. Every sentence conveys specific information about functionality, parameters, or output format. No filler text is present.

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

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

Given the tool's moderate complexity (5 distinct protocol checks) and the presence of an output schema (per context signals), the description provides complete contextual coverage. It explains what the tool does, what it returns (audit with risk level/recommendations), and documents parameters adequately without needing to replicate the output schema structure.

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 schema description coverage at 0%, the description compensates effectively via the 'Args' section, documenting both the domain parameter (with example) and response_format (with allowed values and default). It provides sufficient semantic meaning for an agent to construct valid inputs, though it omits validation constraints like maxLength that appear in the schema.

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

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

The description explicitly states it performs a 'Comprehensive email security posture check' and lists specific protocols audited (SPF, DMARC, DKIM, MX, BIMI) along with risk scoring. This clearly distinguishes it from sibling tools like peerglass_dns_resolve or peerglass_dns_dnssec which handle general resolution or DNSSEC rather than email authentication analysis.

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 detailed bullet points imply the tool is used for auditing email authentication configurations, there is no explicit guidance on when to select this over peerglass_dns_resolve for simple MX lookups, or when not to use it. Usage is implied by the specific capabilities listed but lacks explicit 'when-to-use' or alternative comparisons.

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

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

Annotations already declare readOnlyHint, idempotentHint, and openWorldHint. The description adds valuable behavioral context beyond these: it specifies the return format includes 'Per-type record tables with TTL values' and clarifies that SPF/DMARC policies are extracted 'inline' rather than requiring separate calls. It does not mention error behaviors for invalid domains.

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

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

The description is well-structured with clear sections (action, Args, Returns) and front-loaded with the primary verb. Every sentence provides specific value: the record type list, the extraction feature, parameter types, and return structure. The docstring format adds slight verbosity but improves scanability.

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

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

Given the rich annotations (4 hints) and the presence of an output schema, the description provides sufficient context by detailing what data is returned (tables with TTL) and the specific record types covered. It appropriately focuses on functional specifics rather than re-stating safety properties already covered by annotations.

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 schema description coverage reported at 0% (the 'params' wrapper lacks description), the description carries the full burden. It clearly documents both parameters: domain with type and example, and response_format with type, allowed values ('markdown', 'json'), and default value. It does not mention domain length constraints present in the schema.

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

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

The description clearly states the specific action (enumerate), resource (DNS record types), and comprehensive scope (A, AAAA, MX, NS, TXT, SOA, CNAME, CAA, SRV). It also distinguishes this from sibling tools by emphasizing 'all common... in one call' and highlighting the bonus SPF/DMARC extraction feature.

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 this is a comprehensive enumeration tool via 'in one call' and the exhaustive list of record types, suggesting use when complete DNS data is needed. However, it lacks explicit guidance on when to prefer this over siblings like peerglass_dns_resolve or peerglass_dns_email_security, and doesn't advise on selecting between markdown vs JSON formats.

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 declare readOnly/idempotent status, while the description adds crucial behavioral details: it queries specific named resolvers (Cloudflare, Google, etc.), compares answers against a majority consensus, and classifies results as 'stale, diverging, or failing.' This provides clear execution context beyond the safety hints.

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?

Well-structured with clear Purpose → Args → Returns sections. Lists the 10 specific resolvers to establish scope without excess verbosity. Every sentence conveys necessary information about functionality, comparison logic, or output format.

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

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

Given the nested input schema and presence of output schema (Returns: str with table description), the description provides sufficient context. The Args section clarifies the wrapper object structure that the schema's 0% top-level coverage obscures, and annotations cover operational safety aspects.

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 at the top level (only a $ref), the Args section compensates effectively by documenting the nested structure (params containing domain, record_type, response_format), providing examples ('cloudflare.com'), and noting defaults. It does not mention pattern constraints or enum values explicitly, but covers essential semantics.

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

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

Description explicitly states the tool checks 'whether a recent DNS change has propagated globally' using '10 geographically distributed resolvers simultaneously.' It distinguishes from sibling tools like peerglass_dns_resolve by emphasizing propagation status checking and majority consensus logic rather than simple resolution.

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

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

The description implies usage context ('recent DNS change') but does not explicitly state when to use this versus siblings like peerglass_dns_resolve or peerglass_dns_censorship. No 'when-not-to-use' guidance or explicit alternatives 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, idempotentHint, and openWorldHint. The description adds valuable context about the specific RDAP fields returned (holder, country, RIR, covering prefix) and the output format (DNS records table + RDAP details), which goes beyond the annotations.

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

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

The Args/Returns structure is organized and front-loaded with the core purpose, but the inclusion of the non-existent record_type parameter wastes space and creates confusion. The length is otherwise appropriate for the complexity.

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 adequately explains the return value (string with table + RDAP details) which complements the existing output schema. However, the parameter documentation is incomplete/inaccurate due to the phantom parameter, and it lacks guidance on rate limits or auth needs despite openWorldHint being true.

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?

Given 0% schema description coverage per context signals, the description attempts to compensate by documenting parameters with examples (e.g., '8.8.8.8', 'cloudflare.com'). However, it erroneously documents a 'record_type' parameter that does not exist in the input schema, which could confuse the agent about available functionality.

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

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

The description clearly states the tool resolves hostnames or reverse-looks up IPs and specifically distinguishes itself from basic DNS tools by correlating results with RDAP registration data (holder, country, RIR, covering prefix). The specific verb+resource combination is precise.

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

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

The description implies usage through the RDAP correlation feature but provides no explicit guidance on when to use this versus siblings like peerglass_dns_enumerate, peerglass_geo_lookup, or rir_query_ip. It does clarify it handles both forward and reverse lookups.

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

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

Annotations already declare readOnly/idempotent hints. The description adds valuable behavioral context: external dependency on the MaxMind DB file, specific return fields (city, coordinates, EU membership), and data freshness limitations ('when available'). No contradiction with annotations.

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

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

Uses structured docstring format (Args/Returns) that is front-loaded with purpose. While slightly verbose due to boilerplate, every section provides necessary information given the lack of schema descriptions. No 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?

Covers the critical deployment requirement (env var path) that annotations cannot express. Since output schema exists, the return value description is supplementary but helpful for understanding semantic content. Could mention error cases (invalid IP, missing DB file) for completeness.

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

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

With 0% schema description coverage, the description carries full documentation burden. It clearly documents both nested parameters: 'ip' as IPv4/IPv6 and 'response_format' with valid options and default ('markdown'). This compensates perfectly for the sparse schema.

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

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

The opening sentence 'Look up the geographic location of an IP address using MaxMind GeoLite2' provides a specific verb, resource, target, and data source. This clearly distinguishes it from sibling tools like peerglass_dns_resolve (DNS) or rir_query_ip (RIR registration data).

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

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

The description provides critical operational context (requires PEERGLASS_GEOIP_DB environment variable) and output format options, but lacks explicit when-to-use guidance comparing it to similar IP lookup siblings like rir_query_ip or peerglass_passive_dns.

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 cover idempotency and safety (idempotentHint: true, destructiveHint: false). The description adds valuable behavioral context: the specific trigger condition (when withdrawn% exceeds threshold), the alert format (JSON POST), the polling nature (interval_minutes), and the return value semantics (confirmation and count).

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

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

The description is well-structured with the core purpose in the first sentence, followed by clearly labeled Args and Returns sections. Every sentence conveys essential information; no redundancy or fluff.

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

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

Given the moderate complexity (4 parameters, webhook setup) and presence of return value documentation, the description is substantially complete. It could enhance by mentioning the idempotent behavior (already in annotations) or error handling for invalid webhooks, but covers the essential operational contract.

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 at the top level and only titles (no descriptions) for threshold_pct and interval_minutes in the nested schema, the Args section in the description carries the full load. It clearly documents all four parameters including their types, purposes, and default values (20% threshold, 5min interval).

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 the specific action (Register), resource type (country code/ASN/prefix), and mechanism (webhook URL for shutdown monitoring). It distinguishes from siblings like 'peerglass_shutdown_detect' by emphasizing the webhook/alert-based continuous monitoring aspect rather than one-time detection.

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 continuous monitoring use cases through the webhook mechanism and threshold trigger, but provides no explicit guidance on when to choose this over siblings like 'rir_change_monitor' or 'peerglass_shutdown_detect', nor any prerequisites for the webhook URL.

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 cover safety profile (readOnly/idempotent). Description adds crucial behavioral constraint 'last 30 days' not present in annotations, and details specific measurement categories. Could improve by mentioning probe coverage limitations or 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?

Well-structured with clear sections: purpose statement, Args block, Returns line. No filler. Front-loaded with key scope (30 days, country-level) in first sentence. Docstring-style format is efficient.

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

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

Complete for moderate complexity (1 nested param object). With output schema present, description appropriately focuses on behavior and parameter semantics rather than return structure. Addresses all 3 sub-parameters via Args section.

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 description carries full burden. Args section compensates perfectly: documents country_code format (ISO 3166-1 alpha-2 with examples), domain purpose (filter), and response_format options (markdown/json with default).

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 'Fetch' + resource 'OONI censorship measurements' + clear scope 'country over the last 30 days'. Distinguishes from siblings like peerglass_dns_censorship by specifying OONI probe methodology and specific measurement types (Tor, Psiphon, Signal).

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

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

Provides clear context about what data is returned (blocked websites, circumvention tools) and the 30-day time window, helping agents understand when OONI data is appropriate. Lacks explicit 'when-not' guidance or named sibling alternatives (e.g., vs peerglass_dns_censorship).

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 indicate read-only, idempotent, non-destructive behavior. The description adds valuable context about the data source ('RIPE NCC's Passive DNS system, which aggregates DNS queries from recursive resolvers') and return format specifics ('first/last seen timestamps and observation counts') that clarify what 'historical' means in practice.

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

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

Description is well-structured with distinct sections (main purpose, useful for, data source, args, returns) and no wasted text. Every sentence provides unique value—whether describing the external data source, enumerating use cases, or documenting parameters.

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

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

Given the tool has an output schema and annotations covering safety hints, the description provides comprehensive coverage: it explains the external data source, return value structure ('Historical DNS records table with rrtype, value, and first/last seen dates'), and fully documents all parameters despite zero schema coverage. Complete for a historical lookup 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?

With 0% schema description coverage (per context signals), the description fully compensates by documenting all three nested parameters under 'Args': resource (IP or domain), limit (default 100, max 500), and response_format (markdown/json options). This provides complete semantic meaning absent from the structured schema.

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

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

Description explicitly states the tool 'Query RIPE Stat Passive DNS for historical DNS records' specifying the verb (Query), data source (RIPE Stat), resource type (historical DNS records), and targets (IP or domain). This clearly distinguishes it from active DNS resolution siblings like peerglass_dns_resolve.

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 'Useful for:' section provides four specific scenarios (tracing infrastructure changes, finding previously-used domains, investigating C2 infrastructure, threat hunting) giving clear context for when to use the tool. However, it does not explicitly name alternatives (e.g., peerglass_dns_resolve for current DNS) or exclusion criteria.

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

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

Annotations indicate readOnly/idempotent/non-destructive operations. Description adds valuable behavioral context beyond annotations: specifies the six satellite providers monitored, explains the ground-shutdown scenario where satellite remains available, and documents return format ('Per-provider active status and announced prefix count'). No contradictions with annotations.

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

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

Well-structured with clear sections: purpose statement, usage context, Args, and Returns. Front-loaded with specific providers and use case. Args/Returns sections necessary given poor schema coverage. Slightly verbose but information-dense 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?

Comprehensive for a read-only monitoring tool: annotations cover safety profile (read-only, non-destructive), description covers target providers, use case, and return value semantics. Given output schema exists (per context signals), description appropriately focuses on input parameters and behavioral context rather than output structure details. Could mention rate limits or caching behavior for perfect completeness.

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

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

With 0% schema description coverage, the Args section effectively compensates by documenting both parameters: clarifies country_code expects 'ISO 3166-1 alpha-2 code' and notes it is 'used for context', and specifies response_format accepts 'markdown' (default) or 'json'. Could improve by noting country_code is required, but covers essential semantics well.

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

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

Description states specific action ('Check whether satellite internet providers... are actively announcing BGP prefixes') and lists exact providers monitored (Starlink, Viasat, OneWeb, SES, Inmarsat, HughesNet). Clearly distinguishes from sibling rir_check_bgp_status by specifying satellite-specific providers and BGP prefix announcement monitoring.

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

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

Explicitly identifies use case context ('During ground-based internet shutdowns, satellite services often remain the only available connectivity option for journalists and aid workers'), helping agents understand when this tool is valuable versus general connectivity checks. Does not explicitly name alternative tools, but contextualizes the specific humanitarian/emergency scenario where this tool applies.

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?

Excellent disclosure beyond annotations. While annotations declare readOnly/idempotent hints, the description explains the critical stateful behavior (baseline storage between calls), the exact severity classification thresholds (5%, 20%, 80%), and the return value composition. No contradictions with annotations.

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

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

Well-structured with clear sections. The severity level bullet points efficiently communicate complex thresholds. Every sentence serves a purpose—explaining mechanism, state management, or parameter formats. No redundant or filler text.

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

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

Very complete for a detection tool with stateful behavior. Explains the baseline mechanism, severity levels, and return format. Minor gap: could mention `peerglass_shutdown_timeline` as a complementary tool for users needing historical data rather than current detection.

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?

Despite the schema having minimal coverage (country_code only partially described), the description fully compensates by documenting both parameters with concrete examples ('SY', 'IR', 'MM') and clarifying the response_format default and options ('markdown' vs 'json') that the schema lacks.

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 specific action (detect internet shutdowns), the resource (country-level), and the mechanism (BGP prefix comparison against baseline). It distinguishes this from generic monitoring tools by specifying the BGP/withdrawal methodology.

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

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

Provides critical usage context about the stateful nature (first call establishes baseline, subsequent calls measure) and explains the severity classification thresholds. However, it does not explicitly mention sibling tools like `peerglass_shutdown_timeline` as an alternative for historical analysis vs. current detection.

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 declare readOnlyHint=true and idempotentHint=true, so the description focuses on adding the evidence integrity context (SHA-256 hash) and return value structure (timeline, downtime hours). It successfully adds behavioral traits not covered by annotations, such as the evidentiary nature of the output and its suitability for legal proceedings.

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 follows a clear logical structure: purpose statement, evidence use case, then organized Args and Returns blocks. Every sentence conveys distinct information (scope, integrity feature, use cases, parameter types, return contents). The Args/Returns headers add slight verbosity but are appropriate for technical clarity.

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

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

Given the tool's specific forensic purpose and the presence of good annotations covering safety (read-only, idempotent), the description adequately covers the evidentiary context (SHA-256 hash) and documents the return value contents (timeline, hours, hash) without requiring a separate output schema. The forensic use cases complete the contextual picture.

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% top-level schema coverage (the params object lacks a description) and a nested object structure, the Args section in the description performs essential work documenting all four nested fields (resource, start_date, end_date, response_format) with clear examples and format specifications (e.g., ISO dates, markdown/json options), effectively compensating for the wrapper object structure.

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

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

The description clearly states the tool retrieves a 'timestamped BGP withdrawal/restoration timeline' using specific verbs and identifies the resource. It distinguishes itself from generic monitoring tools via the explicit mention of SHA-256 integrity hashes for legal/forensic use, implicitly differentiating it from sibling tools like peerglass_shutdown_detect.

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

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

The description provides implied usage guidance by specifying the tool is 'useful for UN reports, press, legal proceedings,' indicating forensic/evidence contexts. However, it lacks explicit comparisons to siblings (e.g., peerglass_shutdown_detect) or statements about when not to use this tool versus real-time detection alternatives.

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

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

Despite annotations declaring readOnlyHint/openWorldHint, the description adds critical behavioral context: GreyNoise requires GREYNOISE_API_KEY while Shodan does not, data source limitations (Community vs InternetDB), and output structure details (aggregated risk score 0-100 with specific levels). No contradictions with annotations.

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

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

Excellent structure with hierarchical organization: high-level summary, numbered data sources with bullet points, and standard Args/Returns sections. Every sentence delivers value—source capabilities, authentication requirements, or output format details—without redundancy.

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

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

Given the tool's complexity (dual external APIs, aggregated scoring logic) and 0% schema coverage, the description is remarkably complete. It covers input semantics, authentication prerequisites, data source behaviors, and return value structure, leaving no critical gaps for invocation.

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

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

With schema description coverage at 0%, the Args section fully compensates by documenting both the 'ip' parameter (with IPv4 example) and 'response_format' (with valid values and default). This provides complete semantic meaning missing from the raw schema.

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

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

The description opens with 'Passive threat intelligence for an IP address from two sources'—a specific verb-resource combination that clearly distinguishes it from sibling tools like peerglass_geo_lookup or peerglass_dns_resolve. The explicit naming of Shodan and GreyNoise further differentiates its unique function.

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

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

The description implies usage through detailed capability listing (risk scores, CVEs, GreyNoise classification), allowing an agent to infer this is for security assessment rather than general network debugging. However, it lacks explicit 'when to use vs alternatives' guidance comparing it to siblings like peerglass_atlas_trace or peerglass_passive_dns.

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 correctly declare the tool as readOnlyHint=true and idempotentHint=true. The description adds valuable context about what gets inspected (certificate chain length, HSTS header presence) and the return format, but omits behavioral details like connection timeouts, handling of non-TLS hosts, or rate limits that would be expected for an openWorldHint=true network tool.

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

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

The description is well-structured with clear visual sections (summary, use cases, Args, Returns). The first sentence is front-loaded with the complete value proposition. While dense, every section earns its place; the colon-separated list of return values is efficient, and the bullet points are scannable.

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

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

Given the tool is read-only with provided safety annotations, the description achieves completeness by covering the input contract (with examples), the output contract (described in Returns), and operational use cases. It appropriately omits error-schema details since it describes the successful return value, making it sufficient for agent invocation planning.

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?

Despite the schema's 0% description coverage (only response_format has a schema description), the Args section compensates effectively by providing runtime semantics: hostname includes a realistic example ('cloudflare.com'), port clarifies 'TCP' context and default 443, and response_format enumerates allowed values. This bridges the gap left by the schema.

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

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

The description opens with a precise action verb ('Connect') and resource ('hostname:port over TLS'), then enumerates specific outputs (subject, issuer, SANs, cipher suite, etc.). This clearly distinguishes it from sibling DNS tools (peerglass_dns_*) and network routing tools (rir_*) by focusing specifically on TLS certificate metadata.

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 'Useful for:' section provides four concrete scenarios (verifying expiry, detecting self-signed certs, checking TLS configuration, auditing HSTS) that establish clear context for when to invoke the tool. While it lacks explicit 'when not to use' exclusions or named sibling alternatives, the specificity of the use cases effectively guides selection.

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

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

Annotations cover safety profile (readOnly, idempotent, non-destructive). Description adds value by disclosing the inference methodology (BGP-path-based algorithm), classification taxonomy (upstream/downstream/settlement-free), and external data source (CAIDA AS-Rank API).

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?

Docstring format (Args/Returns) is slightly verbose but efficiently structured. Classification bullets front-load key value propositions. Every section earns its place, particularly parameter documentation which fills schema gaps.

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?

Comprehensive for a data-fetch tool: covers source API, inference methodology, classification categories, parameter details, and return format. Well-supported by annotations covering safety; no significant gaps despite zero schema description coverage.

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 has 0% description coverage but description fully compensates via Args section: documents 'asn' with format examples ('AS13335' or '13335'), and 'response_format' with allowed values and default. Explains semantics beyond raw schema types.

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 'Fetch' + resource 'AS relationship data' + explicit scope (CAIDA AS-Rank API). Explicitly distinguishes from sibling/alternative RIPE Stat asn-neighbours tool by contrasting accuracy levels and classification methods.

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

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

Provides clear comparative context: explains that unlike RIPE Stat (which gives left/right/uncertain), this uses BGP-path-based inference for higher accuracy, implicitly guiding selection when accurate classification is needed. Lacks explicit 'when not to use' constraints.

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 establish read-only/idempotent safety; the description adds critical behavioral context not present in annotations: 6-hour caching policy, LACNIC RDAP limitation, and RDAP entity database sources. Could be improved by mentioning rate limits or authentication requirements, but coverage of data source limitations and caching is valuable.

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?

Well-structured with clear sections (overview, use cases, tips, args, returns). The use cases and tips earn their space by preventing misuse. The JSON return schema is somewhat verbose given that an output schema exists, but it ensures the LLM understands the structured string output. Front-loaded with the core action in the first 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?

Comprehensive for a complex aggregation tool spanning multiple external RIR databases. Documents return structure (including error field), notes the LACNIC limitation, explains partial matching behavior, and provides the JSON output schema. Complete enough that an agent can predict both success and failure modes.

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 schema description coverage at 0% (per context signals), the Args section compensates effectively by documenting both parameters with concrete examples ('GOOGL-ARIN', 'Cloudflare') and default values ('markdown'). The distinction between handles and partial name matching is clarified, adding necessary semantic context for successful 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?

The description opens with a precise action ('Find all IP blocks and ASNs') and scope ('registered to an organization across all RIRs'). The 'across all RIRs' and 'organization-wide' framing clearly distinguishes this from siblings like rir_query_ip or rir_query_asn which handle single resources.

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

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

Provides four specific use cases (M&A due diligence, security research, ICANN policy, incident response) that establish when to select this tool. Includes practical tips for query precision (org handles vs names) and caching behavior. Lacks explicit 'when not to use' contrast with single-resource lookup siblings, though the use cases imply the scope.

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 cover safety profile (readOnly, idempotent, non-destructive). Description adds valuable behavioral context about TTL caching mechanism and rate limit respect. Includes detailed return value schema. Could mention if calling this affects cache state (e.g., does it trigger cleanup?), but otherwise comprehensive.

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

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

Well-structured with purpose front-loaded, followed by value proposition, then detailed returns. The embedded JSON schema in the Returns section is slightly verbose but functionally useful given the context. No wasted sentences.

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

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

Given zero parameters and rich annotations (readOnly, idempotent hints), the description is complete. It explains the 'why' (rate limiting), the 'what' (cache stats), and the 'how' (JSON structure). For a simple diagnostic tool, this coverage is sufficient.

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

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

Tool has zero input parameters, establishing a baseline score of 4 per evaluation rules. No parameter semantics are needed or provided, which is appropriate for a parameterless statistics retrieval function.

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

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

Description opens with specific verb 'View' and clear resource 'in-memory TTL cache'. The second paragraph distinguishes this from sibling RIR query tools by explaining it monitors the cache that 'prevents repeated queries to RIRs', clearly differentiating it from active query tools like rir_query_ip or rir_check_rpki.

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

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

Provides clear context on when the cache matters ('respecting rate limits and reducing latency for repeated lookups'), implying this tool is useful for debugging cache behavior or rate limit issues. Lacks explicit 'when not to use' or named alternatives, but the value proposition is clearly stated.

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

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

Annotations declare idempotentHint=false and readOnlyHint=true; the description explains exactly why—baseline capture creates server-side state that changes between invocations. It adds critical behavioral context: baseline persistence in memory (not database), automatic baseline updates on change detection, and loss of state on server restart. No contradictions with annotations.

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

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

Appropriately structured with clear sections (How it works, Tracked fields, Severity, Args, Returns). The length is justified by the tool's complexity (8 tracked fields, 4 severity levels, stateful behavior). The embedded JSON return schema is valuable for parsing. Minor redundancy exists between the Args section and the schema descriptions.

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 high complexity (stateful diffing across RDAP and BGP data) and presence of output schema, the description is remarkably complete. It documents all 8 tracked fields, explains the severity taxonomy, provides the output JSON schema, and warns about session-scoped baseline persistence.

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?

While the input schema has high description coverage (despite the context signal indicating 0%), the description adds crucial temporal semantics in the 'How it works' section—explaining that the same resource parameter triggers baseline capture on first call and diffing on subsequent calls. This stateful behavior is not apparent from the schema 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?

The opening sentence 'Monitor a prefix or ASN for registration and BGP routing changes between calls' provides a specific verb and resource. It distinguishes itself from siblings by explicitly naming rir_check_rpki and rir_detect_transfers as follow-up tools for specific severity findings, clarifying its role as a monitoring/diffing tool rather than a deep inspection tool.

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

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

Explicitly documents the stateful 'first call vs subsequent calls' behavior and when to use reset_baseline ('after reviewing detected changes'). The severity section provides clear action guidance (e.g., 'verify with rir_check_rpki' for origin ASN changes), functioning as explicit when-to-use-alternatives 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?

Adds valuable operational context beyond annotations: specifies the 5-minute cache duration ('BGP tables change frequently'), identifies the external data source (RIPE Stat route collectors), and explains the 'potential hijack' interpretation of multiple announcing ASNs. Annotations already cover safety profile (readOnly, idempotent), so this adds temporal and sourcing 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?

Well-structured with clear delineation between prefix and ASN return behaviors. The BGP 'GPS' analogy adds educational value without excessive verbosity. The embedded JSON return schema in the Returns section is functional but slightly lengthy; however, it serves as necessary documentation given the complexity of BGP visibility data.

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?

Comprehensive coverage for a complex networking tool: explains RIPE Stat data source, documents both input modes (prefix/ASN) with their respective output structures, includes the JSON output schema, notes caching behavior, and provides sibling tool integration guidance. Complete despite the technical 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?

With schema description coverage reported at 0% (top-level 'params' lacks description), the Args section compensates effectively by documenting the 'resource' format (prefix or ASN examples) and 'response_format' options (markdown vs json). Provides concrete examples ('1.1.1.0/24', 'AS15169') not explicitly shown in the schema reference.

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

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

The description explicitly states the tool 'Check[s] whether a prefix or ASN is currently visible in the global BGP routing table' using RIPE Stat. It clearly distinguishes the resource types (prefix vs ASN) and differentiates from siblings by referencing rir_get_announced_prefixes for ASN details and rir_check_rpki for security assessments.

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

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

Explicitly guides tool selection by stating 'use rir_get_announced_prefixes for details' when querying ASNs, and recommends combining with 'rir_check_rpki for complete routing security assessment.' It clearly delineates different return behaviors for prefixes (visibility check) versus ASNs (prefix listing).

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 declare readOnlyHint=true and idempotentHint=true. The description adds valuable domain context: it explains what IRR is, warns about consequences of missing objects (route filtering), and describes the return value structure ('Route objects per IRR source, consistency status'). No contradictions with annotations.

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

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

The description is well-structured and front-loaded with the core purpose. The IRR explanation paragraph provides necessary domain context. The Args/Returns sections use a standard docstring format that efficiently documents inputs and outputs without verbosity, though they duplicate some schema 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?

Given the tool's medium complexity (external registry lookup), the description is comprehensive: it covers domain concepts, input requirements, output summary, and safety profile (via annotations). It adequately prepares an agent to select and invoke the tool without overwhelming detail.

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 schema description coverage reported at 0%, the Args section compensates effectively by documenting all three parameters (prefix, asn, response_format) with types and examples. It adds the 'Expected origin' semantic to the ASN parameter, clarifying its validation purpose.

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 immediately states the specific action ('Check IRRExplorer') and resource ('route objects'), explaining that it verifies consistency 'with the claimed origin ASN.' It distinguishes from siblings by specifying IRR (vs RPKI) and explaining what IRR objects are for, ensuring clear differentiation from tools like rir_check_rpki.

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

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

The description explains the operational context ('Inconsistent or missing route objects can cause route filtering and reachability issues') and implies when to use it (troubleshooting reachability). It references RPKI ('even when RPKI is valid'), implicitly distinguishing from rir_check_rpki, though it could explicitly name the sibling alternative.

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

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

While annotations declare read-only/idempotent hints, the description adds critical context: 15-minute cache duration with rationale ('ROAs can change, but not frequently'), external dependency (Cloudflare's validator), and detailed semantic meaning of each validity state (e.g., 'Possible hijack' for INVALID). No contradictions with annotations.

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

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

Well-structured with clear visual hierarchy: summary, RPKI background, validity states with emoji indicators, usage note, caching note, Args, and Returns. Slightly verbose due to embedded RPKI primer and JSON return schema, but justified given the specialized domain and lack of formal output schema in structured fields.

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?

Comprehensive for a validation tool: documents input semantics, provides full JSON output schema in description (including covering_roas structure), explains cryptographic meaning of results, and notes caching behavior. Given the complexity of RPKI validation and rich output structure, the description provides sufficient context for correct invocation and result interpretation.

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

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

Context signals indicate 0% schema description coverage (the top-level 'params' object lacks description). The description compensates effectively with an 'Args' section documenting both nested fields (prefix, asn) with format examples (CIDR notation, ASN formats). This compensates for the schema coverage gap and clarifies the expected string formats.

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?

Opens with specific action ('Validate a prefix + ASN pair against the global RPKI') and identifies the external validator (Cloudflare). Explicitly distinguishes from sibling tool 'rir_check_bgp_status' by recommending combination for 'full routing security assessment', clearly delineating this tool's specific scope.

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

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

Provides explicit pairing guidance ('Combine with rir_check_bgp_status') and explains the four validity states (VALID, INVALID, NOT-FOUND, UNKNOWN) with contextual meaning to guide interpretation. Lacks explicit 'when NOT to use' exclusions, but the validity state descriptions effectively guide appropriate usage contexts.

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 declare read-only/idempotent safety, while the description adds substantial detection methodology context: specific heuristics (distinct origin AS detection, valley-free violation checking), data provenance (RIPE Stat), and return value structure (confidence scores, suspect ASNs). No contradictions with annotations.

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

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

Excellent docstring structure with clear sections (Args/Returns), front-loaded purpose statement, and zero waste. Bullet points efficiently enumerate detection criteria without verbosity.

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?

Comprehensive for a detection tool: covers input parameters, detection algorithms, and output format (including data types). Given the complexity of BGP analysis and presence of output schema hints in the Returns section, only minor gaps exist (no mention of RIPE Stat data freshness or rate limits).

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 on leaf parameters, the description effectively compensates by documenting both the 'prefix' parameter (with CIDR format example '1.1.1.0/24') and 'response_format' (enumerating valid values and default), adding crucial semantic context missing from the structured schema.

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

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

Description specifies the exact action ('Detect'), resource ('BGP route leaks or hijacks'), data source ('RIPE Stat BGP-state data'), and distinguishes from sibling tools like rir_check_bgp_status or rir_prefix_history by focusing specifically on leak/hijack detection via origin ASN and AS-path analysis.

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

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

Provides implied usage context by listing specific anomalies it checks for (multiple origin ASNs, AS-path loops), suggesting use when investigating hijacks or valley-free violations. However, lacks explicit when-to-use guidance or named alternatives from the extensive sibling list.

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

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

The description adds substantial value beyond the annotations by explaining the detection methodology (comparing consecutive WHOIS object versions), specific heuristics (checking 'org' or 'mnt-by' fields, RIR suffix differences), and operational constraints (12-hour cache). It clarifies the 'openWorld' nature by explaining it queries historical data across different RIRs.

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?

While well-structured with clear sections (intro, transfer types, methodology, args, returns), the description is verbose. The inclusion of a full JSON schema in the Returns section is redundant given the context signal indicates an output schema exists, and the emoji-style list, while clear, adds length. The core information is front-loaded.

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

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

For a complex analytical tool involving WHOIS parsing, historical comparison, and cross-RIR logic, the description is comprehensive. It covers detection algorithms, data sources (WHOIS), caching behavior, return structure with field explanations, and the distinction between different transfer types, providing sufficient context for invocation.

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

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

With schema description coverage at 0%, the description compensates effectively via the Args section, documenting the nested 'resource' parameter (with syntactic examples like '8.8.8.0/24' and 'AS15169') and 'response_format' options. It adds semantic meaning by explaining that the resource is what gets scanned for transfers.

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

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

The description opens with a precise action (Detect) and scope (past ownership or cross-RIR transfers for an IP prefix or ASN). It distinguishes from generic history tools by specifying it identifies organizational changes and cross-RIR moves, not merely retrieving registration records.

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

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

The description provides clear contextual guidance by defining what constitutes an ownership transfer vs. a cross-RIR transfer and listing the specific detection types (Org Change, Cross-RIR, Intra-RIR). However, it lacks explicit sibling comparisons or when-not-to-use guidance (e.g., it doesn't state to use rir_prefix_history for simple historical lookups without transfer analysis).

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

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

Beyond annotations (readOnly/idempotent), description details algorithm ('IANA RDAP Bootstrap... Falls back to querying all 5'), data extraction logic ('entity roles: abuse, technical, noc'), and caching behavior ('cached for 1 hour'). No contradictions with annotations.

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

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

Well-structured docstring format with Purpose → Mechanism → Usage → Caching → Args → Returns. Every sentence earns its place; technical details (bootstrap logic, fallback, caching) are essential for an external-query tool. No fluff.

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

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

Given complex external dependencies (5 RIRs, bootstrap protocol) and rich output, description provides complete picture: input spec, detailed JSON output schema, error-handling strategy (fallback), and caching policy. Fully sufficient for invocation.

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

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

With claimed 0% schema coverage, the Args section compensates by documenting the single parameter with type (str) and format example ('185.220.101.1'). Would benefit from mentioning IPv6 format specifics, but adequately covers the input semantics.

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

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

Description opens with specific verb 'Find' and resource 'abuse contact for any IP address', plus distinguishes method 'using IANA bootstrap routing'. Explicitly differentiates from sibling RIR tools by focusing specifically on abuse contact extraction.

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

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

Explicitly states 'Use this tool as the first step in any network abuse reporting workflow' followed by concrete scenarios (spam, DDoS, port scanning). Clear value proposition for when to select this over other network 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?

Adds valuable behavioral context beyond annotations: cites RIPE Stat as data source, discloses 5-minute cache, explains min_peers_seeing filters 'unstable/flapping routes' (semantic meaning beyond schema), and documents the complete return structure including peer visibility and timestamps.

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?

Well-structured with clear visual hierarchy: one-line summary → scope elaboration → bulleted use cases → Args/Returns documentation. Front-loaded with the core action. Slightly verbose but every section earns its place by providing distinct value (use cases vs technical specs).

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

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

Given the tool's moderate complexity and existing safety annotations (readOnly, non-destructive), the description is complete: covers data source, freshness/caching, input semantics, and detailed output schema with JSON structure. No gaps remain for agent invocation.

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

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

While input schema describes the two parameters (asn, min_peers_seeing), the description adds critical semantic context: explains min_peers_seeing controls route stability ('Higher = more stable routes only') and provides ASN format examples ('AS13335' or '15169'). Also documents the return structure not present in input 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?

Opens with specific verb 'Retrieve' + resource 'IP prefixes' + scope 'currently being announced by an ASN in BGP'. Clearly distinguishes from siblings like rir_prefix_history (historical) and rir_check_bgp_status (status check) by emphasizing 'complete routing footprint' and 'currently'.

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

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

Provides four concrete use cases (IP footprint, hijack detection, M&A diligence, threat intel) and explains the min_peers_seeing filter purpose. Lacks explicit 'when not to use' guidance or named alternatives, though 'currently' implies distinction from historical 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 cover safety (readOnly, idempotent, non-destructive). Description adds significant value: authoritative data source (NRO Extended Delegation Stats files), 24-hour cache policy, and domain-specific context (exhaustion dates by RIR). No contradictions with annotations.

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

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

Front-loaded with clear purpose statement. Well-structured with logical sections (summary, data source, why it matters, args, returns). Slightly verbose due to embedded JSON schema in Returns section, but every section earns its place for this complex domain tool.

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?

Exceptionally complete for a complex multi-RIR statistics tool. Covers data source authority, historical exhaustion context, all filter parameters, pagination logic, and includes full output JSON schema. Returns section explicitly documents the response structure expected.

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?

Despite 0% schema description coverage at root level (single 'params' object), the Args section comprehensively documents all 7 inner parameters including constraints (rir_filter requires include_blocks), valid enums (RIR names), and dependencies. Fully compensates for schema structure.

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

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

Description opens with specific verb+resource: 'Fetch global IPv4, IPv6, and ASN allocation statistics from all 5 RIRs.' It clearly distinguishes from sibling 'rir_query_ip' and 'rir_query_asn' (specific resource lookups) by emphasizing global statistics, allocation counts, and exhaustion dashboard functionality.

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

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

Provides rich context in 'Why this matters' section explaining IPv4 exhaustion timeline and use cases (tracking adoption/exhaustion states). Caching behavior (24 hours) is disclosed. Lacks explicit sibling comparison (e.g., 'for specific IP details use rir_query_ip'), but the global/dashboard scope is clearly differentiated.

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 declare readOnly/idempotent/openWorld; description adds critical behavioral context: data source (PeeringDB), cache duration ('12 hours'), and domain explanation (what IXPs are and their role). No contradictions with annotations.

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

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

Well-structured with clear Args/Returns sections, but includes verbose 'Notable IXPs worldwide' list (7 bullets) with casual editorializing ('your local exchange!'). Educational paragraph on IXPs is useful context but combined with examples makes the description longer than necessary.

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?

Comprehensive coverage: explains domain concepts (IXP ecosystem), documents parameters (compensating for schema coverage), specifies cache behavior, and provides complete JSON output schema with field definitions. With readOnly/destructive annotations present and output detailed, nothing material 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?

Context signals indicate 0% schema coverage (top-level param lacks description). Description compensates effectively via Args section documenting both nested parameters ('query' accepting country codes or name fragments, 'response_format' options) and noting the markdown default. Also provides JSON output schema adding return value semantics.

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

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

Description opens with specific verb ('Search'), resource ('PeeringDB for Internet Exchange Points'), and filter criteria ('by country code or name'). Clearly distinguishes from sibling RIR tools which focus on BGP, ASN relationships, or DNS rather than IXPs.

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

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

Provides explicit guidance on search syntax (2-letter ISO codes vs. partial name matches) with concrete examples ('MU', 'AMS-IX', 'Nairobi'). Lacks explicit 'when not to use' or sibling alternatives (e.g., doesn't contrast with rir_peering_info), but usage patterns are clearly implied through examples.

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 cover safety profile (readOnly, non-destructive, idempotent). Description adds valuable behavioral context: geographic distribution of collectors, specific return data format (AS paths with region and BGP community values), and data source (RIPE RIS). No contradictions with annotations.

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

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

Well-structured with clear Args/Returns sections. Front-loads the critical sibling distinction before diving into parameters. Efficient use of space though docstring format is slightly more verbose than pure prose. No wasted 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?

Comprehensive coverage for a network diagnostic tool: explains data source (RIPE RIS), geographic scope (worldwide collectors), output format (markdown/json), and return value structure (AS paths with metadata). Adequate for tool complexity despite no output schema being provided in the description section.

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 has 0% parameter description coverage (only titles/types). Description fully compensates by documenting all three parameters with clear semantics: prefix includes CIDR example, vantage_points explains 'max entries' semantics with default/max values, response_format lists allowed values. Exceptional compensation for sparse 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?

Excellent specificity: describes exact action (show BGP routing table entries/AS paths), specific resource (RIPE RIS collectors), and explicitly distinguishes from siblings ('Unlike BGP visibility...'). Clear value proposition.

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

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

Provides clear conceptual guidance contrasting with BGP visibility tools (existence vs. AS paths). Explains the 'how' vs 'whether' distinction effectively. Does not explicitly name the alternative sibling tool (rir_check_bgp_status) to use instead, but the conceptual differentiation is strong.

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

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

Despite annotations declaring readOnly/idempotent, the description adds crucial behavioral context not present in structured fields: parallel asyncio execution model, 5-minute caching behavior with explicit stale data warning ('includes live BGP data'), and detailed synthesis logic explaining how emoji health signals (✅/⚠️/🚨) are derived from underlying check 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?

Well-structured with clear visual hierarchy (headers, bullet points, emoji) and front-loaded purpose. Every section earns its place: parallel execution details explain performance, health signal legend explains output semantics, and Args/Returns sections clarify interface. Minor deductions for length, though justified by tool complexity.

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?

Excellent completeness for a multi-modal tool. Includes output JSON schema in Returns section, explains the four parallel sub-operations (RDAP/BGP/RPKI/PeeringDB) and their specific outputs, documents caching duration, and provides use-case guidance. No gaps remain given the presence of output schema 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?

While the input schema technically has nested descriptions (resulting in 0% top-level coverage per context signals), the description compensates with an explicit Args block documenting both the 'resource' parameter (with format examples: '1.1.1.1', 'AS13335') and 'response_format' (explaining markdown vs JSON semantics). It could slightly improve by noting constraints like 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?

The description opens with a specific verb ('Run') and resource ('health check on any IP address, prefix, or ASN'). It clearly distinguishes from sibling tools (e.g., rir_check_bgp_status, rir_query_ip) by emphasizing it is a 'comprehensive parallel' check that combines RDAP, BGP, RPKI, and PeeringDB simultaneously, positioning it as the consolidated first-response option versus individual deep-dive 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?

Provides explicit usage guidance under 'This is your first-response tool for:' with four concrete scenarios including 'Is this IP address legitimate?' and 'NOC incident triage'. This clearly signals when to use this consolidated tool versus more specific sibling tools, effectively serving as a routing guide for the agent.

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

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

Beyond the safety annotations (readOnly/idempotent), the description adds critical behavioral context: the 6-hour cache duration, parallel querying of PeeringDB and RIPE Stat, and the 'up to 30 adjacent ASNs' result limit. It does not mention authentication requirements or rate limits, preventing a perfect 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?

The description is densely packed but well-structured with clear sections (Data sources, Information returned, Use cases, Args, Returns). Every sentence earns its place by providing specific technical details. It is slightly verbose but appropriately so for the complexity of the data returned.

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

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

Given the tool's complexity (multiple data sources, nested output objects), the description is complete. It documents the return value's JSON schema explicitly, explains all output fields in the 'Information returned' section, and notes caching behavior. The output schema presence means return values don't need exhaustive prose explanation.

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 at the top level (the 'params' object lacks a description), the Args section fully compensates by documenting both parameters with clear types, examples ('AS13335', '13335'), and allowed values ('markdown' or 'json'). This effectively bridges 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?

The description opens with a precise verb ('Fetch') and enumerates specific resources (peering policy, IXP presence, NOC contacts, BGP neighbours) scoped to an ASN. It clearly differentiates from siblings like `rir_query_asn` or `rir_as_relationships` by specifying the exact PeeringDB and RIPE Stat data sources used.

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

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

The 'Use cases' section provides four concrete scenarios (e.g., 'Does Cloudflare have an Open peering policy?') that clearly establish when to invoke this tool. However, it lacks explicit guidance on when NOT to use it or which sibling tools (like `rir_query_asn`) should be preferred for simpler lookups.

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?

Adds critical behavioral context beyond annotations: explicitly notes RIPE NCC has best coverage while other RIRs are partial (data quality limitation), identifies the specific upstream APIs used (RIPE Stat's historical-whois and allocation-history), and discloses the 12-hour caching behavior. Annotations only cover safety/readonly aspects, while description explains data provenance and limitations.

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?

Well-structured with clear visual hierarchy: purpose statement, bullet list of returned event types, implementation details, coverage caveats, use cases, and Args/Returns sections. Front-loaded with the core action. The JSON schema in Returns is verbose but necessary as no separate output schema is provided in the structured fields.

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?

Exceptionally complete for a complex data retrieval tool: covers API sources, RIR coverage limitations, caching policy, specific use cases, input parameter details, and provides a full output schema structure. Given the existence of output schema documentation in the description and the tool's complexity (RDAP/RIR history), no critical gaps remain.

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 Args section explicitly documents the nested params (resource, response_format) with clear type annotations and value examples ('8.8.8.0/24', 'AS15169'), effectively compensating for the schema's structure where top-level coverage may appear limited. While the schema has some descriptions, the description provides a consolidated, readable view of the required resource parameter and optional format toggle.

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

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

The description opens with a precise action statement: 'Fetch the complete registration history for an IP prefix or ASN.' It specifies the exact resource (registration history), the data scope (complete, chronological timeline), and distinguishes itself from current-state siblings like rir_prefix_overview through its focus on historical changes (ever recorded, initial registration, changes).

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

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

Provides specific use cases ('Has this IP block ever changed hands?', 'Due diligence, incident response, fraud investigation') that clearly signal when to use this tool versus current-state alternatives. Lacks explicit 'do not use for X, use Y instead' sibling comparisons, but the historical focus is distinct enough to guide selection.

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

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

Annotations declare read-only/idempotent status, but description adds critical behavioral context: makes '3 RIPE Stat API calls simultaneously,' has '1 hour' cache duration, and explains the tree traversal logic (parent/child relationships) that annotations don't cover.

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?

Well-structured with clear 'Args:' and 'Returns:' sections. The real estate analogy, while adding length, efficiently conveys complex IP hierarchy concepts. Every sentence earns its place by explaining scope (3 layers), behavior (parallel calls), or output format.

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

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

Comprehensive for a complex tool: explains hierarchical concepts, documents the JSON return schema inline, specifies caching behavior, and identifies integration points with sibling tools. Complete given the rich output schema and multi-API-call implementation.

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 schema description coverage at 0% (top-level 'params' lacks description), the description compensates by documenting both nested parameters under 'Args:' with examples ('1.1.1.0/24') and valid values ('markdown' or 'json'), effectively clarifying the wrapped schema structure.

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

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

Description explicitly states it 'fetches a rich hierarchical overview' distinguishing it from simple lookups. The real estate analogy and explicit mention of 'less-specific' vs 'more-specific' clearly differentiate this from siblings like rir_query_ip or rir_check_bgp_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?

Explicitly recommends combining with 'rir_check_rpki to validate the announcing ASN,' providing clear sibling tool coordination. Mentions 1-hour caching implying refresh behavior. Could be improved by contrasting with rir_query_ip for non-hierarchical lookups.

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 indicate read-only/idempotent/safe operation, while the description adds valuable behavioral context beyond these: it discloses the 1-hour caching policy, explains the simultaneous querying of all 5 RIRs (vs single source), and provides a complete JSON output schema showing the exact structure of normalized results and per-RIR responses.

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?

Well-structured and front-loaded: one-line summary followed by domain context, input format examples, caching note, Args block, and Returns block. The inclusion of the JSON output schema is justified for an agent needing to parse structured responses. Minor verbosity in the ASN explanation is acceptable for clarity.

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

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

Given the tool's complexity (multi-source aggregation across 5 RIRs) and rich output schema, the description is comprehensive. It covers function, input semantics, output structure with schema, caching behavior, and provides concrete examples. The presence of output schema documentation in the description satisfies completeness despite the lack of a formal outputSchema field.

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 at the top level (the 'params' property lacks a description field), the description compensates effectively via the Args section documenting both nested parameters (asn and response_format), including valid format examples and enum values ('markdown' or 'json'). It clarifies the nested ASNQueryInput structure that the schema references via $ref.

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

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

The description opens with the specific action 'Query all 5 global RIRs simultaneously for an Autonomous System Number' - clear verb, resource, and scope. It distinguishes from sibling rir_query_ip by explicitly focusing on ASN (Autonomous System Number) rather than IP addresses, and explains what an ASN is with concrete examples (AS15169 = Google).

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

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

The description provides implicit guidance through examples of accepted input formats ('AS15169', '15169', or named sets like 'AS-GOOGLE'), but lacks explicit when-to-use guidance compared to siblings. It does not clarify when to use this versus rir_query_ip or rir_as_relationships, nor does it mention prerequisites or rate limits.

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?

Excellent disclosure beyond the annotations: it reveals the parallel request pattern to all 5 RIRs (AFRINIC, APNIC, ARIN, LACNIC, RIPE NCC), the normalization of responses into a unified schema, and the 1-hour caching behavior for rate limit compliance. This provides crucial context for a distributed query operation.

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

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

Well-structured with clear sections pivoted from general description to Args to Returns. The information is front-loaded with the core purpose in the first sentence. The JSON schema block in Returns is verbose but appropriately detailed for a complex return structure.

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?

Comprehensive coverage appropriate for a multi-API tool: includes input/output schemas, behavioral details (parallelism, normalization), performance constraints (caching, rate limits), and the complete JSON response structure. Nothing critical is missing given the output schema is 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?

The Args section documents parameters with examples (e.g., '1.1.1.1' and '2001:4860:4860::8888'), but largely duplicates the well-described input schema. It does add explicit mention of the default value ('markdown') for response_format, which complements the schema.

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

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

The description clearly states the tool 'Query[s] all 5 global RIRs simultaneously for an IP address using RDAP,' which is a specific verb-resource combination that distinguishes it from siblings like rir_query_asn or rir_get_abuse_contact.

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

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

It explains that exactly one RIR will be authoritative while others return 'not found,' setting correct expectations for the parallel query pattern. It also documents the 1-hour cache to respect rate limits, providing operational context. It could explicitly mention when to use single-RIR alternatives, but the scope is clearly defined.

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

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

Beyond the annotations (readOnlyHint=true, idempotentHint=true), the description adds valuable domain context: defining what a stable route means (no withdrawal/re-announcement cycles), explaining causes of flapping (hardware, misconfiguration, DDoS), and outlining consequences (CPU load, convergence delays). It mentions the RIPE Stat data source. It could be improved by noting any rate limits or caching behavior.

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

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

The structure is efficient and well-organized: one sentence for purpose, two sentences for domain context (stability definition and flapping implications), then structured Args/Returns sections. Every sentence earns its place—no tautological filler. The Returns section concisely maps the output schema to user-meaningful metrics (stability score, uptime %, timeline).

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

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

Given the presence of an output schema and the tool's moderate complexity (single prefix analysis), the description is complete. It covers the operational domain (BGP routing), input requirements (CIDR format, time windows), and output interpretation (score 0-100, event timeline). No gaps remain that would impede correct invocation.

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

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

With 0% schema description coverage for the nested parameters (prefix, hours, response_format have no schema descriptions), the description fully compensates. It provides critical semantics: example format ('1.1.1.0/24'), constraint explanations ('default 24, max 168 = 7 days'), and valid option values ('markdown' or 'json'), effectively documenting all three parameters that the schema leaves 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?

The description opens with a specific verb ('Analyse') and clear resource ('BGP route stability for a prefix'), including the data source ('RIPE Stat routing-history data'). It distinguishes from siblings like 'rir_check_bgp_status' or 'rir_prefix_history' by specifically focusing on stability/flapping analysis over time windows, and defines what constitutes a stable route versus flapping behavior.

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?

Clear context is provided for when to use the tool: investigating route flapping that 'can indicate hardware failure, misconfiguration, or DDoS.' It explains the operational impact (router CPU load, convergence delays). However, it lacks explicit guidance on when to prefer this over siblings like 'rir_prefix_history' or 'rir_check_bgp_status', though the focus on stability metrics implicitly suggests the use case.

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 declare readOnlyHint=true and destructiveHint=false (safety profile), while the description adds valuable implementation context: it specifies the '/help' endpoint is queried, clarifies the operation is 'lightweight', and details the exact return format (Markdown table with specific columns: RIR name, region, status, conformance extensions).

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?

Every sentence earns its place: the opening defines the action, the second explains the technical mechanism (/help endpoint, lightweight nature), the third provides usage guidance, and the fourth documents return values. No redundancy with structured metadata.

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 zero-parameter health check tool, the description is complete. It covers the operational mechanism, usage context, failure scenarios (diagnosing RIR failures), and return value structure (Markdown table format), compensating for the lack of a formal output schema in the structured data.

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 zero parameters, the baseline score is 4 per scoring rules. The description reinforces this by explicitly stating 'no IP/ASN needed', which explains why the schema is empty and distinguishes it from parameter-heavy siblings like rir_query_asn or rir_audit_org.

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

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

The description opens with a specific action ('Check') targeting a specific resource ('5 RIR RDAP servers') with clear scope ('real-time health', 'simultaneously'). It distinguishes from siblings like rir_query_ip or rir_query_asn by emphasizing it requires 'no IP/ASN needed' and queries '/help' endpoints rather than specific resources.

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

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

Explicitly states when to use: 'before bulk queries to verify connectivity' and 'to diagnose why a specific RIR's responses are failing.' This provides clear temporal guidance (pre-flight check) and diagnostic context that separates it from data-retrieval siblings in the rir_* namespace.

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