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

No annotations are provided, so the description carries the burden. It discloses the tool is a read-only lookup and lists the output fields, which is helpful. However, it does not mention whether the data is real-time or cached, whether it requires network access, or any rate limits. For a simple lookup tool, the lack of behavioral detail is a moderate gap.

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

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

The description is two sentences, front-loads the main action, and lists the return fields concisely. Every sentence earns its place with no redundancy.

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

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

The tool has a single parameter, a clear output schema, and a simple lookup purpose. The description covers the purpose, the input, and the output fields. It could be more complete by noting whether the data is live or cached, but for a simple ASN lookup, the description is largely sufficient.

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

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

Schema description coverage is 100% for the single parameter 'asn', which is well-documented with an example. The description adds context by explaining what the ASN is used for, but it does not add meaning beyond the schema. Baseline 3 is appropriate.

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

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

The description clearly states the tool's purpose: 'Get information about an Autonomous System' and lists the specific data returned (AS name, announced prefixes, upstream providers, total prefix count). This distinguishes it from sibling tools like bgp_route_lookup or bgp_prefix_origin, which focus on routes or prefix origins rather than AS-level footprint.

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

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

The description provides a use case ('Use this to understand an AS's footprint on the Internet') but does not explicitly state when to use this tool versus alternatives like peeringdb_network, irr_autnum, or bgp_prefix_origin. The use case is implied but not contrasted with siblings.

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

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

With no annotations provided, the description must carry the behavioral disclosure burden. It clearly signals a read-only external search, identifies the required CLOUDFLARE_API_TOKEN credential, and summarizes the returned event fields. It does not mention rate limits or pagination behavior, but these are not critical for safe invocation.

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

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

Three front-loaded sentences with no filler: purpose, event semantics/output, and auth requirement. Every sentence contributes actionable information for selecting and invoking the 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?

Given a rich input schema, an output schema, and the sibling set, the description covers the essential non-obvious facts: API token requirement, the definition of a hijack event, and the output fields. It is slightly light on when to choose this over related BGP tools, but it is otherwise complete enough for correct use.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds meaning by explaining that events include confidence scores, hijacker and victim ASNs, affected prefixes, and duration, which clarifies the intent behind filters like asn, prefix, and min_confidence beyond the raw schema text.

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

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

The description names a specific verb and resource ('Search for BGP origin hijack events') and explains what constitutes a hijack via RPKI, IRR, and historical data. It is clearly scoped, though it does not explicitly contrast itself with close siblings like bgp_leaks or bgp_historical_lookup.

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

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

The description gives useful context: this is for finding unauthorized prefix originations and it requires a Cloudflare Radar API token. However, it does not state when to prefer this tool over related siblings such as bgp_leaks or rpki_validate, leaving the selection logic mostly implicit.

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

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

With no annotations, the description carries the full behavioral burden. It discloses that the tool downloads and parses MRT files, explains RIB vs update result semantics, and quantifies performance differences with file sizes and processing times. It stops short of mentioning failure modes or rate limits, but the core behavior is well covered.

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 organized into focused paragraphs that front-load the main purpose, then elaborate on modes and performance. It is longer than strictly necessary but each section earns its place by covering distinct, useful information without redundancy.

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

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

For a tool with two distinct modes, large downloads, and performance implications, the description covers the critical operational context: data source, mode semantics, file sizes, and processing time. The output schema covers return values, so the lack of return-format detail is not a gap.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds real value beyond the schema by explaining what a 'rib' lookup returns versus an 'update' lookup, and by giving performance-based guidance for choosing data_type. This strengthens the meaning of the timeout and data_type parameters.

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

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

States a specific verb and resource: 'Look up historical BGP routes for a prefix from MRT archive data.' It distinguishes itself from current-route siblings by emphasizing historical MRT/RIPE RIS data, and separates the RIB and update modes clearly.

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 for when to use the tool by framing it as historical MRT-archive lookup and gives explicit mode-selection guidance: 'Prefer update for narrow time windows and rib for full routing state.' It does not explicitly name alternative sibling tools like bgp_route_lookup, but the usage context is unambiguous.

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

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

With no annotations present, the description takes the behavioral burden. It discloses that the tool detects leak events, includes specific result fields (leaking AS, origin/prefix counts, timestamps), and requires a Cloudflare Radar API token. This provides meaningful operational context beyond the tool name, though it stops short of detailing pagination or error behavior.

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

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

The description is three concise, purposeful sentences. The primary action is front-loaded, followed by a clarifying definition and a crucial authentication requirement. Every sentence earns its place, with no redundant or filler content.

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

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

The description covers what the tool does, what the returned events contain, and the required API token. Combined with a fully described schema and an output schema, this is nearly complete for an agent to call the tool correctly. Minor gaps like default date behavior are already handled by schema defaults.

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

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

The input schema already provides 100% description coverage for all four parameters. The tool description does not add new parameter-level meaning, but the schema itself documents filters like 'asn', 'date_start', and 'max_results'. A baseline score of 3 is appropriate because the description neither compensates nor conflicts.

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

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

The description states a specific verb ('Search for') and a precise resource ('BGP route leak events'), then defines what a route leak is: an AS improperly propagating routes between peers. This clearly differentiates it from siblings like bgp_hijacks or bgp_route_lookup by focusing on the policy-violation concept.

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 implies when to use the tool: when searching for BGP route leak events. The explanatory sentence about improper propagation gives context, but it does not explicitly state when not to use it or mention alternative tools for related concepts like hijacks or route 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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It explains the fallback order between two data sources and the meaning of an empty origins list with no error, which is valuable for interpretation. However, it does not explicitly state that the operation is read-only or mention any authentication/rate-limit considerations. The disclosure is good but not exhaustive.

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 two sentences long and front-loads the core purpose. Each sentence adds value: the first states the action and output, the second explains the data source fallback and error handling. There is 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?

For a tool with a single parameter and an output schema, the description covers the essential behavioral aspects (source fallback, error semantics, interpretation of empty results). The return format is presumably documented in the output schema, so the description does not need to repeat it. Nothing critical is missing for an agent to call this tool correctly.

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

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

The input schema already provides a complete description of the only parameter ('prefix' with CIDR notation and an example). The tool description adds no additional parameter-specific details beyond what the schema states. Since schema coverage is 100%, the baseline of 3 applies.

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

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

The description clearly states the tool's function: 'Find which AS(es) originate a given prefix.' It also specifies the output (distinct origin ASN(s) with AS names), which distinguishes it from sibling tools like bgp_route_lookup (which focuses on routes) and rpki_validate (which checks RPKI validity). The purpose is precise and unambiguous.

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

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

The description provides context about internal data sources (Cloudflare Radar first, then RIPEstat) and explains error semantics, but it does not explicitly state when to use this tool versus alternatives. It does not name sibling tools or give conditions like 'use this if you need per-origin RPKI status.' The guidance is implicit rather than explicit, so a score of 3 is appropriate.

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

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

No annotations are provided, so the description carries the full behavioral burden. It discloses the source fallback order, config-dependent sources, the 20-route limit, and the `total` field. It does not mention rate limits or error behavior, but it is substantially transparent for a lookup 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 dense but every sentence earns its place: purpose, return fields, regional filtering, source order, limits, and a workflow tip. It is front-loaded with the core operation and contains no filler.

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

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

With an output schema present, return-value details are already handled. The description covers source selection, fallback behavior, collector workflow, and result limits. Minor operational details like failure modes or authentication setup are absent, but the tool is otherwise complete for a 2-parameter lookup.

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

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

Schema description coverage is 100%, so the schema already documents both `prefix` and `collector`. The description adds useful examples and clarifies 'None queries all collectors', but this is marginal value beyond 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?

The description opens with 'Look up current BGP routes for a prefix' – a specific verb, resource, and scope. It also enumerates returned data (origin AS, AS path, communities, peer information), and the 'current' qualifier helps distinguish it from sibling tools like bgp_historical_lookup.

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

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

Provides a concrete workflow for regional perspective: 'Use ris_collectors first to pick a collector ID' and explains collector examples like RRC06 for Tokyo. It does not explicitly contrast with alternative siblings such as bgp_historical_lookup or mrt_search, so when-not-to-use guidance is missing.

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

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

No annotations are provided, so the description carries the full burden. It usefully discloses the comprehensiveness claim ('all IANA reserved ranges...') and lists the specific special-use categories checked. But it does not disclose behavior like IPv4/IPv6 coverage, whether the check is live or static, or what the output looks like — gap that an output schema only partially fills.

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

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

Three sentences with zero filler: purpose, detailed scope, and real-world significance. The core action is front-loaded in the first sentence, and each subsequent sentence adds distinct value.

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

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

For a single-parameter tool with an output schema present, the description covers the essential ground: what counts as a bogon, which ranges are included, and why the result matters. It is only slightly incomplete in not explicitly addressing edge cases like IPv6 input or invalid formats, which the schema examples partially mitigate.

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

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

Schema description coverage is 100% and the schema already documents the query parameter with format examples ('192.168.1.0/24', '10.0.0.1'). The tool description adds nothing about the parameter beyond what the schema provides, so the baseline of 3 applies.

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

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

The opening sentence states a specific verb and resource: 'Check if an IP address or prefix is a bogon (reserved/non-routable).' It then enumerates the exact RFC ranges tested, making the tool's scope concrete. No sibling tool (rpki_validate, ip_contains, prefix_overlap) covers bogon classification, so it is clearly differentiated.

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

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

Usage context is implied rather than explicit: the third sentence explains that a bogon in the global routing table indicates misconfiguration or hijack, which hints at when an agent would run this. However, it never names alternative tools or states when NOT to use it (e.g., for route validity checking, rpki_validate or bgp_route_lookup might be more appropriate).

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

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

With no annotations, the description carries full behavioral burden and succeeds admirably. It explains return contents (records, DNSSEC enabled, validation passes), the SERVFAIL handling, and the CD-bit re-query strategy, which is materially useful for interpreting results.

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

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

The description is compact and front-loaded: purpose and use case come first, then the important edge-case behavior. Every sentence adds value, especially the SERVFAIL/CD-bit explanation, with no filler.

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

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

Given the moderate complexity, full schema coverage, and presence of an output schema, the description is complete. It covers purpose, usage context, return semantics, and a subtle failure-mode behavior, leaving no critical gap for an agent to invoke it correctly.

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

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

Schema description coverage is 100%, so the schema already documents all three parameters well. The description does not add parameter-level semantics beyond referring to 'requested records,' which is acceptable but not an improvement over the baseline.

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

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

The description states a specific verb and resource: 'Query DNS records for a domain with DNSSEC validation status.' It clearly distinguishes this tool from generic DNS tools like dns_trace or local_dig by uniquely mentioning DNSSEC validation status and fallback 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?

The description gives a direct use case: 'Use this to check DNS configuration and DNSSEC health for any domain.' It does not explicitly list when-not-to-use or name alternative tools, but the intended context is clear.

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

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

With no annotations, the description carries the full behavioral burden and largely meets it: it discloses the actual walk order (zone cuts from root), the skip rule for non-zone labels so they are 'not mistaken for a broken delegation,' and the precise DNSSEC-break criterion (signed zone with no parent DS). It stops short of operational traits such as network dependency, timeout behavior, or failure reporting.

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 front-loaded with the purpose and each paragraph contributes distinct information (skip behavior, record-type independence, DNSSEC break definition). There is minor redundancy — 'from root' appears twice and 'delegation chain' overlaps with 'delegation/chain-of-trust structure' — keeping it just below the zero-waste 5 bar.

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

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

For a single-parameter tool with an output schema, the description covers the input, the trace behavior, and the DNSSEC break semantics well. Remaining gaps (network requirements, timing, failure modes for nonexistent domains) are minor given that return values are already specified by the output schema.

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

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

Schema coverage is 100% and the single 'name' parameter is already documented in the schema. The description adds an incidental interpretation detail — non-zone labels in the input are skipped during the trace — but offers no format guidance (trailing dot, IDN, etc.), so the baseline of 3 is appropriate.

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

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

The first sentence states a specific verb and resource: 'Trace DNS resolution from root to authoritative nameservers.' The body further differentiates from record-query siblings like dns_lookup by stressing that it walks the delegation chain (zone cuts), shows nameservers and DNSSEC signing status, and is 'independent of any particular record type.'

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

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

The description gives clear context for when to invoke it: for delegation/chain-of-trust structure rather than record-type queries, and for diagnosing DNSSEC breaks. It explains the island-of-security condition an agent can look for, but it never names alternatives (e.g., dns_lookup, local_dig) or states explicit when-not-to-use guidance, so it falls short of a 5.

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

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

With no annotations, the description carries the full burden of behavioral disclosure. It explains that both bare IPs and CIDR prefixes are accepted and illustrates the containment relation, which is useful. It does not address edge cases like invalid CIDR, IPv4/IPv6 handling, or strict vs inclusive containment, though the presence of an output schema mitigates the missing return-type detail.

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

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

The description is a single informative sentence followed by two illustrative examples, with no filler or repetition. The core action is front-loaded, and every sentence earns its place.

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

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

For a two-parameter pure predicate with a fully documented schema and an output schema, this description is nearly sufficient. The only material gap is the lack of guidance on special cases or exact containment semantics, but the structured fields cover much of what an agent needs.

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

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

The input schema already provides full descriptions for both parameters with 100% coverage, so the baseline is 3. The description's examples reinforce valid values but do not add semantic information beyond what the schema already states.

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 line states a specific predicate: checking whether an IP address or prefix is contained within a network. The two concrete questions remove ambiguity by showing both an IP-in-network case and a prefix-in-prefix case, which clearly separates this from overlap or general routing tools.

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

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

The 'Answers questions like...' examples give clear context for when the tool is relevant, so usage is not merely implied. However, it does not name alternatives such as prefix_overlap or subnet_split, nor does it state when not to use this tool.

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

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

With no annotations, the description carries the full behavioral disclosure burden. It explains recursion, member attribute reading, nested set following, bounded recursion (6 levels, 20000 ASNs), default source rationale, and partial-result-with-error behavior on lookup failure. This is unusually transparent.

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

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

The description is compact yet complete. It front-loads the core purpose in the first sentence, then adds only high-value details about behavior, constraints, and error handling. No sentence is redundant or wasted.

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

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

For a tool with two parameters and an output schema, the description covers everything an agent needs: purpose, valid input forms, default source, recursion limits, and failure behavior. The output schema handles return-value documentation, so no additional output details are necessary.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds meaningful semantic value beyond the schema: it enforces valid RPSL set naming, explicitly rejects bare ASNs, and explains why the default source is RADB. These are useful validation and rationale details that an agent would not get 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 description opens with a specific verb and resource: 'Expand an AS-SET into its member ASNs.' It further clarifies the recursive resolution behavior and distinguishes this from sibling tools by identifying its purpose (customer cone, peering group membership). This is unambiguous and clearly differentiated.

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

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

The description gives clear usage context: useful for customer cones or peering groups, and it explains that RADB is the default because it mirrors many registries. It also provides important input constraints, such as rejecting bare ASNs and requiring RPSL-style names. It does not explicitly mention alternatives or when not to use it, but the context is strong enough for an agent to decide.

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

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

With no annotations provided, the description carries the full burden and does so well. It discloses one-object-per-registry behavior, the registry/source distinction, error handling when a registry is unreachable, partial result continuation, and the 20-line cap on policies. This is rich behavioral context beyond what the schema alone could convey.

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

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

The description is concise, front-loaded with the main purpose, then organized into return behavior and edge-case handling. Every sentence adds useful information with no filler or redundancy.

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

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

For a read-only lookup tool with an output schema, the description covers input formats, returned content, query semantics, registry/source meaning, and failure behavior. Nothing an agent needs to call or interpret this tool correctly 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?

The input schema already provides 100% coverage of both parameters, including examples and allowed source values. The description reinforces the ASN format variants, but adds little beyond the schema, so the baseline 3 is appropriate.

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

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

The description opens with a specific verb and resource: 'Look up an aut-num object in IRR databases.' It then details the exact returned fields, making the tool's purpose unmistakable and distinct from sibling tools like irr_route_lookup or irr_as_set_expand.

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

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

The description gives clear context for when to use the tool ('useful for understanding an AS's registered routing policy'), though it does not explicitly name alternatives or state when not to use it. This is clear context with no exclusions, but not quite full alternative-routing guidance.

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

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

With no annotations provided, the description fully carries the behavioral transparency burden. It discloses query normalization (ASN and prefix formats), rejection of invalid input, the difference between 'registry' and 'source' fields, a result cap of 200 with an uncapped 'total', and error handling behavior when a registry is unreachable. This is exceptionally transparent for a network tool and covers the key behaviors an agent would need to anticipate.

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-organized: it states the purpose first, then usage context, then input validation, then result semantics, then error handling. Every sentence adds value; there is no fluff or repetition. It is long enough to be informative but structured so an agent can quickly extract the key points.

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

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

For a tool with only 2 parameters and an output schema, the description covers everything an agent needs: accepted inputs, normalization, defaults, error behavior, and the meaning of key output fields. The comparison context with RPKI/BGP is also included, making it clear how this tool fits into a broader analysis workflow. Nothing essential 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?

Schema coverage is 100%, so the schema already documents both parameters. The description adds meaningful behavioral context beyond the schema: it explains normalization rules ('AS13335' or '13335' to 'AS13335', IP to CIDR), the default sources (RADB and RIPE), and the registry/source distinction. These details are not in the schema and help the agent form correct queries and interpret results.

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-resource pair: 'Look up IRR route objects for a prefix or origin ASN.' It clearly scopes the tool's purpose and distinguishes it from sibling tools like rpki_validate and bgp_prefix_origin by stating it queries Internet Routing Registries. The mention of comparing with RPKI and BGP to identify inconsistencies reinforces its distinct role.

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

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

The description explicitly suggests using this tool in conjunction with rpki_validate and bgp_prefix_origin to compare registered, authorized, and announced data, which implies when to use it. It also clarifies the accepted input format (ASN or prefix) and notes that anything else is rejected. However, it does not explicitly state conditions under which an agent should NOT use this tool or prefer an alternative, so it falls short of a 5.

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

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

With no annotations, the description carries the behavioral burden. It discloses that entries are cached, that the scope is the local network/L2 segment, and that no admin privileges are required. This gives an agent useful expectations for a read-only command.

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

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

Three short sentences, each earning its place: what is shown, what it means, and the privilege requirement. No filler or repetition.

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-argument, read-only ARP inspection tool with an output schema, the description covers operation, scope, cache behavior, use case, and privilege requirements. Nothing essential 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?

The input schema has zero parameters, so there are no parameter semantics to document; the rubric baseline of 4 applies. The description's no-arguments framing is implicitly consistent with the empty 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 uses a precise verb ('Show') and concrete resource ('ARP table (IP-to-MAC address mappings)'), then clarifies it displays cached entries for the local network/L2 segment. This cleanly differentiates it from sibling tools like local_routes or local_connections.

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

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

The description gives a clear use case: 'seeing what hosts are on the same L2 segment.' It does not explicitly name alternatives or say when not to use it, but for a uniquely scoped local diagnostic the guidance is sufficient.

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

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

No annotations are provided, so the description carries the full behavioral disclosure burden. It explains the underlying commands (ss on Linux, netstat fallback), reveals that state filtering is done post-processing when netstat lacks native support, mentions the note field, and flags the admin privilege caveat for PIDs. This is rich and honest context beyond the schema.

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 front-loaded with the core purpose, and every additional sentence covers a distinct necessary behavior: command selection by OS, state-filter mechanics, note-field behavior, and privilege requirements. There is no filler or repetition.

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

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

With one optional parameter and an output schema already present, the description covers all non-obvious behavior an agent needs: OS differences, fallback command behavior, filtering approach, note field, and permission caveats. Nothing important is missing for correct invocation or interpretation.

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

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

Schema coverage is 100% and the single optional enum parameter is already well described, so the baseline is 3. The description adds value by explaining how the state filter behaves differently per platform and that the tool filters output itself when the underlying command cannot, recording this in the note field.

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

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

The description states a specific verb and resource: 'Show active network connections and listening ports' and explicitly says it displays TCP/UDP sockets with local/remote addresses and state. It is unambiguous, but it does not explicitly differentiate itself from sibling tools like local_netstat_stats or local_interfaces.

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 first sentence clearly establishes the use case: inspecting active network connections and listening ports. It also provides practical context about platform-specific command behavior and the admin privilege caveat. However, it does not explicitly compare with sibling tools or state when-not-to-use, so it stops short of a 5.

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

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

With no annotations provided, the description carries the full burden and delivers: output truncation at 10,000 characters, no admin privileges required, -q and -g curl flags, only http/https URLs accepted, and deliberate non-blocking of private/loopback/metadata addresses. This is unusually rich behavioral disclosure for a tool definition.

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 longer than average, but every sentence earns its place: purpose, use cases, output limits, permission requirements, curl behavior, URL constraints, and security trade-offs. Information is front-loaded and structured logically from general purpose to operational details.

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 output schema (which explains return values) and the high parameter schema coverage, the description is complete enough for an agent to select and invoke this tool correctly. It covers safety-relevant behavior (private addresses), operational constraints (truncation, disabled by default), and URL restrictions, leaving no critical gap.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds meaningful nuance beyond the schema by explaining URL scheme restrictions, -g globbing behavior for bracket/brace URLs, and the output cap. It does not add much for timeout, head_only, or follow_redirects, but the URL-related behavior is a genuine value-add.

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

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

The description states a specific verb and resource: 'Make an HTTP request from the local machine using curl.' It clearly differentiates this tool from local networking siblings like ping, traceroute, or DNS tools by focusing on HTTP/S inspection through curl, and further lists concrete use cases (connectivity, headers, TLS certs, response codes).

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

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

The description gives clear context about when to use the tool: for testing connectivity, checking HTTP headers, TLS certificates, and response codes from the local network perspective. It does not explicitly name alternative tools or exclusions, so it misses the top bar of explicit when-not/alternatives, but the use-case context 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?

With no annotations provided, the description carries the full behavioral burden and does so well. It discloses that the tool runs the actual dig binary, returns raw output including query time and server, falls back to nslookup when dig is unavailable, does not require admin privileges, and rejects dig options such as '+trace' or '-x' with errors reported in the 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 is front-loaded with the core purpose, then efficiently covers the sibling distinction, use case, fallback behavior, privilege requirement, and a parameter constraint. Every sentence adds useful information and there is no filler.

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

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

Given the presence of an output schema, return values need not be elaborated. The description covers the tool's execution model, expected output characteristics, fallback behavior, privilege needs, and failure handling for invalid parameter values. An agent has enough context to select and invoke this tool correctly.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds meaningful parameter semantics beyond the schema by specifying that record_type must be a bare mnemonic of 1-10 letters/digits and that dig options are rejected and surfaced in the error field, which is not 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 opens with a specific verb and resource: 'Run dig on the local machine for DNS lookups.' It clearly distinguishes itself from the sibling dns_lookup by noting it executes the actual dig binary and returns raw output, making its purpose and differentiation immediately clear.

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

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

The description names the relevant alternative (dns_lookup) and explains the difference in implementation and output, and it states when it is useful: 'seeing exactly what a real resolver returns.' It does not explicitly state when not to use it, but the contrast with dns_lookup provides strong contextual guidance.

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

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

With no annotations provided, the description carries the full disclosure burden. It usefully reveals OS-specific command usage (ifconfig, ip addr, ipconfig), the fact that it requires no admin privileges, and the kinds of data returned. It could additionally note read-only guarantees or edge cases, but for a simple interface-listing tool this is solid.

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

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

Three tight sentences front-load the core purpose, then efficiently cover return values, platform behavior, and privileges. No filler or redundant wording.

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?

This is a simple zero-parameter tool with an output schema available. The description covers what it returns, how it behaves on each OS, and its privilege requirements, so an agent has enough to invoke and interpret the result correctly.

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

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

The tool has zero parameters and the schema coverage is 100%, so there is no parameter meaning for the description to add. The baseline of 4 applies because no parameter documentation is needed.

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

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

The description clearly states the tool's action ('Show network interfaces') and its specific resource ('IP addresses on the local machine'). It also lists return values, making its purpose unmistakable and distinguishing it from remote-network sibling tools.

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

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

The description provides clear context by emphasizing 'local machine' and noting that no admin privileges are required, which helps an agent decide when this local-introspection tool is appropriate. It does not explicitly name alternatives or state when not to use it, but the context is strong 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?

With no annotations provided, the description carries the full burden, and it does well: it discloses per-hop packet loss/latency output, the install prerequisite, the possible admin/sudo requirement for raw ICMP sockets, and what happens if permission is denied. It does not mention runtime behavior or that it performs a fixed count of pings per hop, but the schema covers 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?

Three short sentences, all substantive: purpose, output value, and operational caveats. It is front-loaded and contains no filler or redundant restatement of the tool name.

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 low parameter count, the presence of an output schema, and a moderate complexity level, the description covers the essentials: what the tool does, what it reports, installation requirements, and permission failures. It is slightly light on sibling differentiation, but that is more a usage-guidance gap than a completeness gap.

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

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

Schema description coverage is 100%, with host and count already well documented in the input schema. The description adds no parameter-specific meaning beyond what the schema provides, so the baseline 3 applies.

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

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

The description clearly states a specific verb and resource: 'Run mtr (My Traceroute) combining ping and traceroute,' and explains what it shows. It does not explicitly name or differentiate from sibling tools like local_ping or local_traceroute, but the 'combining ping and traceroute' phrasing locates it among them.

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

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

The description implies when to use it (when you want both ping and traceroute combined) and provides a prerequisite: mtr must be installed. However, it gives no explicit guidance on when to use this rather than local_ping, local_traceroute, or other sibling tools, and no exclusions.

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

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

With no annotations provided, the description carries the burden and does well: it discloses that this is a read-only display operation, what categories of output to expect, and that admin privileges are not required. It does not describe edge cases like empty counters, but the output schema covers return structure.

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

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

The description is compact and front-loaded with the core action and resource. Minor redundancy exists between 'network protocol statistics' and 'other protocol-level statistics', but it remains efficient and each sentence contributes purpose, output detail, or usage context.

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

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

For a zero-parameter tool with an output schema, the description fully covers what the tool does, what data it returns, when to use it, and a key behavioral trait (no admin privileges). No critical calling information 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?

The tool has zero parameters and 100% schema description coverage, so there is no semantic burden on the description. A baseline of 4 is appropriate because no parameter meaning needs to be added.

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

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

The description states a specific verb ('Show') and resource ('network protocol statistics') and enumerates concrete contents: TCP/UDP/ICMP counters, packet counts, error rates, retransmissions. This clearly differentiates it from sibling tools like local_connections, which report active connections, and local_interfaces, which report interface state.

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

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

The description gives clear context ('Useful for diagnosing network health issues'), which implies when an agent should invoke it. It does not explicitly name alternatives or exclusions, but the protocol-statistics scope makes the boundary versus sibling local networking tools reasonably evident.

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

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

With no annotations provided, the description carries the full burden and does so thoroughly. It discloses the scan method, privileges not required, target size limits, timeout rationale, rejected syntaxes, error reporting behavior, the separate installation requirement, and the default-disabled security posture.

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 longer than average, but every sentence delivers decision-relevant information such as constraints, error handling, installation, and enablement. It is organized in short logical blocks and contains no filler, making the length justified.

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 an output schema exists and only two parameters, the description covers everything an agent needs to invoke the tool correctly: what it does, how it behaves, constraints, failure modes, prerequisites, and configuration. Nothing essential 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?

Schema coverage is 100%, so the schema already documents both parameters, but the description adds meaningful semantics beyond it: target restrictions are tied to the 120 s time budget, rejected target syntaxes are enumerated, and the default ports behavior is clarified. This goes beyond simply restating parameter names.

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

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

States a specific action ('Run an nmap TCP connect scan') on a clear resource ('a target') with the scan technique named. It distinguishes itself from scanning variants by explicitly noting it uses -sT, not SYN scans or OS detection, so an agent can tell it apart from similar network 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?

Gives clear context: TCP connect scan needs no admin, host discovery is skipped, and only open ports are reported. It also states exclusions (no SYN scans, no OS detection, no large CIDR blocks) and notes it is disabled by default and must be enabled via config, but it does not name sibling alternatives to choose instead.

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

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

With no annotations provided, the description carries the full burden. It discloses two valuable behaviors: no admin privileges required, and invalid hosts are reported in the result's error field rather than raised. It also states the output statistics (round-trip time, packet loss, latency). This goes beyond a minimal statement and helps the agent set expectations.

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 four sentences, each adding distinct value: purpose, behavior/statistics, privilege requirement, and error handling. It is front-loaded with the core purpose and has no redundant or filler text. Every sentence earns its place.

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

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

The tool is simple and the schema covers parameters; an output schema exists, so return values are presumably documented there. The description covers the key behavioral aspects (no admin, error handling) and enough detail to differentiate from siblings. It does not explicitly mention prerequisites like network connectivity, but that is implied for a ping tool.

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

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

The input schema has 100% description coverage for all three parameters (host, count, timeout). The description adds no additional semantic meaning beyond what the schema already provides, so the baseline of 3 is appropriate.

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

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

The description clearly states the verb 'ping' and the resource 'host from the local machine', and further clarifies it sends ICMP echo requests and reports latency statistics. This differentiates it from siblings like local_traceroute (path tracing) and local_mtr (combined ping+traceroute), so an agent can distinguish it without opening schemas.

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

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

There is no explicit guidance on when to use this tool versus alternatives. It does not mention typical use cases (e.g., basic reachability checks) or when to prefer other local_* tools. The agent is left to infer usage from the tool's name and generic description.

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

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

With no annotations provided, the description carries full disclosure burden and does so well. It reveals outbound queries to three external services, the fallback sequencing, the User-Agent used, and the privilege requirement.

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

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

The description is compact and front-loaded: purpose first, then external behavior, use cases, and privilege note. Every sentence adds useful information with no redundancy.

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

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

For a zero-parameter tool with an output schema present, the description is complete enough. It covers side effects, fallback behavior, use cases, and requirements; return-format details are handled by the output schema.

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

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

The tool has zero parameters, so there is no parameter semantics to document. The description focuses on the operation and return intent, which is sufficient for this no-input tool.

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

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

The description clearly states the tool's action and scope: getting the public IP address of the local machine. This distinguishes it from sibling tools like local_interfaces (local addresses) and other network diagnostic 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?

It provides concrete use cases: verifying NAT, VPN, or proxy configuration, and notes that no admin privileges are required. It does not explicitly name alternatives or exclusions, so it stops short of a 5.

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

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

No annotations are provided, so the description carries the behavioral disclosure burden. It adds valuable context beyond the schema: the tool uses platform-specific commands (netstat -rn, ip route, route print) and explicitly states it does not require admin privileges. This gives agents enough behavioral grounding for a read-only local diagnostic.

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

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

The description is three sentences with no wasted words. It front-loads the core purpose, then adds useful scope and implementation details, with each sentence contributing necessary information for correct invocation.

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 no-argument tool, this is complete: it states what is displayed, which platforms are supported, which underlying commands are used, and the privilege requirement. The presence of an output schema covers the return shape, so no additional output explanation is needed.

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

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

The tool has zero parameters, so parameter semantics are not applicable; the baseline of 4 is appropriate. The description adds no parameter details because there are none to document, and the schema already provides complete coverage.

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

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

The description states a specific verb and resource: 'Show the local routing table' and enumerates the exact content (default gateway, connected networks, static routes). This clearly distinguishes it from sibling tools like local_interfaces, local_arp, or local_netstat_stats.

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 context: use this tool when the local routing table is needed. It does not explicitly name alternatives or exclusions, but the phrase 'local routing table' and the enumerated route types make the intended use unambiguous.

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

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

With zero annotations, the description carries the full burden and handles it well: it discloses probe type (UDP default), privilege requirement (no admin), platform variance (traceroute vs tracert), and crucially the timeout behavior — partial output returned with returncode 124. This exceeds the typical safety/behavior disclosure bar.

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: purpose, output, probe/privelege, platform mapping, timeout behavior. Front-loaded with the core action, and compact at roughly 50 words with no filler.

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

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

For a 2-parameter tool with an output schema (so return values are already specified), the description covers everything needed to invoke it correctly: privilege, platform, probe type, and the partial-output-on-timeout edge case. Nothing operationally relevant 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?

Schema description coverage is 100%, so the schema already documents host and max_hops with ranges and defaults. The description adds no parameter-specific meaning (e.g., how max_hops relates to the time budget), so the baseline 3 applies.

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

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

States a specific verb ('Trace'), a resource ('the network path to a host'), and a clear scope ('from the local machine'), plus the output it produces ('each hop along the route with latency'). This cleanly distinguishes it from siblings like local_ping (reachability, no path) and dns_trace (DNS resolution path, not network path), even without naming alternatives.

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

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

The description implies usage context (diagnosing network path/hops) and adds practical conditions — UDP probes by default and 'no admin required' — but never explicitly says when to choose this over local_mtr or local_ping, nor names alternatives. Usage is inferable but not 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?

With no annotations, the description carries the behavioral burden. It usefully discloses that it runs from the local machine, queries the appropriate whois server, and does not require admin privileges. It does not mention network dependency, possible timeouts, or raw output shape, though the output schema partially covers return behavior.

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

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

The description is compact and front-loaded: the action appears in the first sentence, followed only by useful qualifications. No filler or redundant detail.

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

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

For a one-parameter lookup tool with an output schema, the description is nearly complete: it states the action, query scope, local execution, and privilege requirements. The only gap is lack of explicit routing guidance toward or away from sibling tools, which is a minor omission here.

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

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

Schema coverage is 100% and the query parameter already includes concrete examples and accepted formats. The description restates domain/IP/ASN scope but adds no significant meaning beyond the schema.

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

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

The description uses a specific verb ('Run a whois lookup') and names exactly what it covers: domain registration, IP allocation, and ASN information. The 'from the local machine' scoping helps distinguish it from remote/API-based siblings like peeringdb_network or bgp_asn_info.

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 clearly implies when to use it—when whois data for a domain, IP, or ASN is needed. However, it does not explicitly contrast with related tools such as irr_route_lookup or peeringdb_network, nor does it state when not to use this tool.

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?

There are no annotations, so the description carries the full burden of behavioral disclosure. It states the tool 'Returns URLs, sizes, and timestamps for each MRT file' and explains the nature of RIB dumps and update files, which covers the main behavioral surface. It does not explicitly say 'read-only' or mention potential response size or pagination, but 'Find available' strongly implies a non-mutating discovery 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?

The description is well-structured: it leads with the purpose, then the relationship to bgp_historical_lookup, then the RIB/update explanation. It is slightly redundant with the input schema's parameter descriptions, especially for data_type, but every paragraph contributes useful behavioral or usage context. It is not bloated, though it could be tightened.

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 100% schema coverage, the presence of an output schema, and the absence of nested objects, the description provides sufficient context to call the tool correctly. It explains the tool's role in a larger workflow, what it returns, how to choose between data types, and the temporal cadence of MRT files. Nothing an agent needs to decide whether to use this tool 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?

Schema description coverage is 100%, so the baseline for this dimension is 3. The description reinforces the meaning of data_type and the RIB/update time cadence, but the schema already provides nearly identical detail (e.g., 'Use rib to see full routing state at a point in time'). The description adds some usage framing but does not introduce significant new parameter-level semantics beyond the schema.

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

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

The description starts with a specific verb and resource: 'Find available MRT data files for a given time range and collector.' It further distinguishes itself from the sibling bgp_historical_lookup by explicitly saying this is the discovery step before that lookup, and it clarifies the two file types (RIB dumps vs update files). An agent can clearly tell what this tool does and how it differs from nearby tools.

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

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

The description explicitly says to use this tool 'before calling bgp_historical_lookup' and provides concrete guidance for choosing between RIB dumps and update files: 'Use these to see what the routing table looked like at a specific time' and 'Use these to see route changes during an incident.' This gives clear when-to-use context and differentiates the internal modes.

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

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

With no annotations provided, the description carries the full transparency burden and does well. It discloses internal behavior: one request normally, two if the name search is empty and falls back to a city search, counts sourced from PeeringDB's net_count/ix_count fields, and the error semantics where facilities is empty when error is set.

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

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

The description is compact, front-loaded with the core action and returns, then adds practical behavior details. Each sentence contributes useful information with no filler or repetition of the schema.

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

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

The description covers what the tool does, what it returns, when it is useful, how it behaves internally, and how errors are represented. With an output schema present and only one input parameter, nothing essential is missing for an agent to select and invoke it correctly.

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

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

Schema description coverage is 100%, so the parameter is already well documented. The description adds value by explaining the fallback from name search to city search and by giving concrete examples like 'Equinix' and 'Ashburn', plus the numeric ID exact-lookup path, making the query semantics clearer than 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 description opens with a specific verb and resource: 'Search for data center facilities in PeeringDB.' It further clarifies scope by listing returned fields (name, location, website, networks_count, exchanges_count), which distinguishes facility search from sibling tools like peeringdb_network and peeringdb_ix.

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

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

The description states a clear use case: 'understanding colocation options and where networks can physically interconnect.' It does not explicitly name sibling alternatives or state when not to use the tool, but the facility-focused context is sufficient to guide an agent toward appropriate 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?

With no annotations, the description carries the full behavioral burden, and it does so thoroughly. It discloses the fallback from name to city search, that 'total_members' comes from PeeringDB's net_count and costs no extra requests, the selection rule for include_members (exact match else first, flagged with members_included=true), and that an error field may indicate a partial or empty payload. This is more than sufficient transparency.

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

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

The description is concise yet comprehensive. Every sentence earns its place: purpose, returned fields, optional member behavior, data source and fallback, and error semantics. It is front-loaded with the core purpose and uses no filler or repetition. The structure is easy to parse and directly actionable.

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 output schema exists and the tool has only two parameters, the description covers all necessary context for correct invocation. It explains the tricky aspects (fallback, member selection, error handling) and notes cost implications. An agent has everything needed to call this tool correctly without additional inference.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds meaning beyond the schema: it explains that a numeric query is an exact PeeringDB IX id, that a name search falling back to city search changes the semantics of the query parameter, and that include_members adds one extra request—context not present in the schema. This extra nuance justifies a 4.

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 and resource: 'Search for Internet Exchange Points (IXPs) in PeeringDB.' It then enumerates the returned fields (name, location, website, total_members) and the optional member-list enrichment. This clearly distinguishes the tool from siblings like peeringdb_facility and peeringdb_network, which target different PeeringDB entities.

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 operational guidance: query by name, city, or numeric ID; name searches fall back to city searches; include_members fetches only one exchange (exact match else first result); and members for a specific exchange require querying by numeric ID. It does not explicitly name alternative tools, but the purpose is clear enough that an agent can select it confidently. The lack of explicit sibling exclusions keeps it from a 5.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It explains the underlying two-request data source, the null-network/error semantics, and the risk of partial records when upstream lookup fails. This is substantial transparency beyond what the schema shows.

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 front-loaded with the main purpose, followed by the return contents, then the data-source and edge-case details. Every sentence adds information an agent needs; there is no filler or repetition of schema 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?

For a single-parameter lookup with an output schema, the description covers the main behavior, the key return fields, the external data source, and the important null/error response cases. An agent has enough information to call the tool correctly and interpret ambiguous results.

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

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

There is only one parameter, asn, and the schema already describes it with an example. The description adds no new format, range, or constraint information, so it provides no value beyond the high schema coverage.

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

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

The description opens with a specific verb and resource: 'Look up a network in PeeringDB by ASN.' It clearly distinguishes this tool from siblings like peeringdb_ix and peeringdb_facility by stating it focuses on network records and their IXP peerings, so an agent can select it confidently.

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

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

The description gives clear context: it is 'useful for understanding a network's peering footprint and how to reach it.' It does not explicitly name sibling tools or state when NOT to use it, but for a straightforward lookup tool the usage context is clear enough.

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?

Since no annotations are provided, the description bears full responsibility for disclosing behavior. It does state that it 'returns the relationship' and lists the possible outcomes, but the output schema already conveys that structure. It does not disclose side effects (e.g., whether it is read-only), error handling for invalid prefixes, or edge-case behavior like overlapping but not identical prefixes. The 'Useful for detecting conflicts' phrase is usage context, not behavioral transparency. More is expected given zero annotation coverage.

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

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

The description is three sentences, all substantive. The first sentence states the core action, the second lists the return values, and the third gives a concrete use case. There is no filler, no redundant restatement of the tool name, and the key information is front-loaded. This is an exemplary concise 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?

For a simple two-parameter tool with an output schema, the description covers purpose and use case adequately. However, it lacks guidance on alternatives, edge cases, or what happens with invalid input. Given that there are no annotations, the description is somewhat thin on safety/read-only implications and differentiation from sibling tools. It is complete enough for a straightforward check but misses opportunities to make the agent fully confident in invocation.

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

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

Schema description coverage is 100%, with each parameter fully documented including examples ('10.0.0.0/24', '10.0.0.128/25'). The description adds no semantic information about the parameters—it merely refers to 'two IP prefixes' in the purpose, which is redundant with the schema. Per the rubric, a baseline of 3 is appropriate when the schema covers the parameters fully, and the description does not compensate with additional parameter nuances.

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 and resource: 'Check if two IP prefixes overlap.' It also enumerates the three possible results (disjoint, one contains the other, or equal), which clearly delineates it from sibling tools like ip_contains (which likely tests a single IP against a prefix) and supernet_aggregate (which computes aggregates). An agent can immediately understand the tool's distinct 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 provides a clear application context: 'Useful for detecting conflicts in IP allocation or routing policy.' This gives the agent a reason to select it, but it does not explicitly mention when not to use it or name alternative tools, such as ip_contains for single-IP membership or rpki_validate for routing security checks. It stops short of explicit exclusions, so it earns a 4 rather than a 5.

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

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

With no annotations provided, the description carries the behavioral burden. It transparently states that this is a listing operation and explains collector characteristics like multihop peers and full-feed peer counts, which helps the agent interpret results. It does not cover pagination or data freshness, but those are minor for a list endpoint.

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 core purpose is front-loaded in the first sentence, and the bullet list is structured and scannable. The use-case bullets are genuinely useful rather than filler, though the description is slightly long for a simple list 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?

The description covers purpose, usage context, and selection guidance, while the output schema covers return values and the input schema covers parameter defaults. The only minor gap is that it doesn't explicitly state that calling with no arguments returns all collectors, but the schema's optional parameters already imply this.

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

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

The input schema already documents both parameters (region, active_only) at 100% coverage, so the baseline is 3. The description adds regional domain knowledge that indirectly relates to the region parameter, but it does not explicitly explain the filter semantics or default behavior beyond what the schema already provides.

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 and resource: 'List RIPE RIS route collectors with location, peer counts, and status.' This clearly identifies what the tool does and differentiates it from sibling lookup/validation tools like bgp_route_lookup or mrt_search.

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

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

The description gives explicit context for when to use it ('Use this to understand where BGP data is collected from') and adds practical regional use cases such as 'Need Asian perspective? Use RRC06 (Tokyo)'. It does not explicitly mention when not to use it or name alternatives, but the usage context is clear.

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

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

No annotations are provided, so the description must carry full weight. It clearly states it requires a Cloudflare Radar API token, which is critical. It doesn't disclose rate limits, pagination, or whether changes are per-ASN or global. Since it's a read-only monitoring tool, the safety profile is implied but not stated. It could be more explicit about what it returns (e.g., list of change events).

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

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

The description is concise and front-loaded with the core purpose. It uses a short paragraph and clear sentences. The API token requirement is a necessary addition. No fluff, but it could be more structured with bullet points. Slightly dense but acceptable.

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 (3 optional params, output schema exists), the description covers the essential use case and requirement. However, it lacks details on output format, pagination, or how changes are structured (e.g., timestamps, old/new values). The output schema might cover return values, but the description doesn't highlight any specific field. It's adequate but not rich.

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

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

Schema coverage is 100%, so the baseline is 3. The description itself doesn't add parameter details beyond the schema. The description implies filtering by ASN and date ranges, which aligns with the parameters, but doesn't elaborate on format or semantics beyond what schema provides. It correctly notes the date_start example.

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

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

The description clearly states the tool tracks changes to RPKI ASPA objects over time, mentioning specific actions (added, removed, modified). It also provides use cases. However, it does not differentiate from sibling rpki_aspa_lookup, which likely provides current state; the description implies temporal nature but doesn't explicitly say 'use this for history vs current state'.

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

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

The description mentions 'useful for monitoring provider authorization changes and detecting potential routing policy shifts', which implies when to use it. But it doesn't explicitly state when not to use it or alternatives. With siblings like rpki_aspa_lookup, more explicit guidance would be better. However, the API token requirement is a needed prerequisite.

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

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

With no annotations provided, the description carries the full burden, and it does so well: it discloses the 200-object cap, that 'total' reports the true count, the Cloudflare Radar API token requirement, and that a missing token yields an 'error'. This is substantial behavioral context beyond the schema.

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 tightly organized and front-loads the core purpose, then explains role semantics, then behavioral limits and auth. Every sentence earns its place; there is no redundancy or filler.

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

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

For a 3-parameter lookup tool with an output schema, this is complete: it explains the domain concept, how to use each role, result limits, counting behavior, and authentication requirements. The presence of an output schema covers return-value details.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds real semantic depth by explaining what each role means in terms of AS authorization relationships. It also clarifies how 'asn' interacts with the role, going beyond the schema's brief field 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?

States a specific verb and resource ('Look up RPKI ASPA objects') and expands the acronym with a clear definition. The distinction between customer and provider roles further clarifies exactly what the tool addresses, separating it from other RPKI/route 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?

Gives explicit, actionable usage guidance for both roles: use 'customer' to see authorized providers and 'provider' to see reverse relationships. It does not explicitly name sibling alternatives or exclusion conditions, so it falls just short of a 5.

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

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

With no annotations, the description carries full responsibility for behavior. It discloses the 50-prefix scan cap for ASN queries, the `note` field indicating when the cap applied, the RIPEstat data source, and the `error` field when RIPEstat is unreachable. These are meaningful behavioral traits beyond the schema.

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

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

The description is concise and well-structured: purpose first, then return values and use cases, then important limitations and data source. Every sentence carries useful information without padding.

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

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

For a single-parameter lookup with an output schema, the description covers purpose, query types, return fields, use cases, a cap behavior, and error conditions. Nothing essential is missing for an agent to invoke it correctly.

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

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

Schema coverage is 100% and the query parameter description in the schema already explains prefix CIDR and ASN integer formats. The description mostly reinforces this rather than adding new parameter-specific meaning, so the baseline of 3 applies.

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

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

The description states a specific verb and resource: 'Look up RPKI ROAs for a prefix or ASN.' It also names what is returned (matching ROAs with max-length, trust anchor, ASN), making the tool's scope clear and distinguishable from siblings like rpki_validate or rpki_aspa_lookup.

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

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

The description provides clear use cases: 'understanding what routes an AS is authorized to originate or what ROAs cover a prefix.' It does not explicitly name alternatives or state when not to use, but the context is clear enough.

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

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

With no annotations, the description carries full disclosure burden and meets it well: it reveals the RIPEstat-first strategy, Cloudflare Radar fallback, the case where only status is returned, and that matching ROAs and max-length details are included. This is unusually transparent about source behavior and output 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?

The definition is compact and front-loaded with the core purpose, followed by outcome semantics and fallback behavior. Every sentence adds useful information and none merely restates the title or schema.

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

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

The description covers purpose, input semantics (via schema), return statuses, ROA details, max-length handling, and fallback behavior. With an output schema present, nothing needed to invoke the tool correctly 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?

Schema coverage is 100% and both parameters already have clear descriptions with examples in the schema. The tool description adds no new parameter-level meaning beyond restating prefix + origin ASN, so the baseline 3 is appropriate.

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

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

The description opens with a specific verb and object: 'Validate a BGP route origin against RPKI ROAs.' It then defines the exact input (prefix + origin ASN) and output statuses (VALID/INVALID/NOT_FOUND), which makes the operation distinct from the sibling RPKI lookup tools.

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

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

The description implies when to use the tool (whenever route-origin validation against RPKI is needed) and gives clear context, but it does not explicitly name alternatives or state when not to use it. Given the nearby rpki_roa_lookup and rpki_aspa_lookup tools, explicit sibling routing would have been stronger.

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

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

With no annotations, the description carries the behavioral disclosure burden. It clearly states what is returned (network/broadcast addresses, netmask, host count, classification) and that it works with both IPv4 and IPv6, giving concrete expectations. It does not mention invalid input behavior, but for a read-only info tool this is a reasonable level of transparency.

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

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

The description is three compact sentences with no filler. It front-loads the core purpose and then lists outputs and compatibility in an easily scannable way.

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

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

For a one-parameter lookup tool with an output schema, the description covers purpose, return content, and protocol scope. It lacks explicit sibling differentiation and edge-case behavior, but the tool is simple enough that the description is substantially complete.

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

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

Schema description coverage is 100%, and the schema already documents the prefix parameter with format examples. The description adds useful context about IPv4/IPv6 support but does not add substantial new meaning beyond the schema.

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

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

The description uses a specific verb ('Get') and names the resource ('detailed information about an IP prefix or address'), and it enumerates the key outputs. It does not explicitly distinguish it from sibling tools like subnet_split or ip_contains, but its purpose is unambiguous.

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

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

Usage is implied: an agent would use this tool when it needs detailed information about an IP prefix or address. However, there is no explicit guidance about when not to use it or which sibling tools to prefer for related operations such as splitting subnets or checking containment.

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

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

No annotations are present, so the description carries the behavioral disclosure burden. It adds useful context by stating 'Works with both IPv4 and IPv6' and providing a concrete example, but it does not describe the output format or behavior on invalid inputs. For a simple pure computation this is adequate, though not rich.

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

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

Three short sentences with no wasted words: purpose, example, and protocol support. The key information is front-loaded and every sentence earns its place.

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

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

For a low-complexity pure function with two clearly documented parameters and an output schema, the description covers the essential selection and invocation details. The example plus protocol coverage makes it complete enough for an agent to call correctly.

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

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

Schema coverage is 100%, so parameters are already documented. The description adds value by giving a concrete example that maps prefix and new_prefix_length to an expected result ('4 subnets'), which helps an agent understand the relationship between parameters beyond the schema.

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

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

States a specific verb+resource: 'Split an IP prefix into smaller subnets.' The example (splitting 10.0.0.0/24 into /26s) and the IPv4/IPv6 note make the tool's purpose unambiguous and clearly distinguish it from sibling tools like supernet_aggregate or subnet_info.

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 when to use the tool through its purpose and example, but it does not explicitly contrast it with siblings such as supernet_aggregate or subnet_info. There is no when-to-use vs. when-not-to-use guidance, though the use case is clear enough on its own.

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

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

With no annotations, the description carries the behavioral burden. It discloses the core behavior—returning the smallest covering supernet—and implies the input requirement of contiguity. However, it does not explain behavior on non-contiguous, invalid, or mixed-version prefixes, nor any failure modes beyond the tentative word 'Try.'

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

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

The description is compact and front-loaded: it states the action, output, input condition, and use case in just two sentences. Every sentence contributes meaningful information with no filler or repetition of the tool name.

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

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

For a single-parameter pure computation tool with an output schema available, the description is nearly complete. It explains what the tool does, what input it expects, and what it returns. The main gap is explicit handling of edge cases, but the low complexity and output schema reduce the need for additional 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?

Schema description coverage is 100%, and the parameter description already includes the comma-separated format and an example. The tool description adds the 'contiguous subnets' precondition but does not substantially enhance understanding of the prefixes parameter beyond what the schema already provides.

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

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

The description clearly states the action (aggregate IP prefixes) and the resource (a list of prefixes), with a specific outcome: 'returns the smallest covering supernet.' It does not explicitly contrast itself with siblings like subnet_split, but the core purpose is unambiguous.

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

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

The description provides useful context: it is for 'summarizing route announcements' and expects 'contiguous subnets.' However, it does not explicitly state when to prefer this tool over alternatives such as prefix_overlap or subnet_split, nor does it give when-not-to-use guidance.

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