Server Quality Checklist

Tool Scores

• pathsC
  2.9/5.0
  Behavior3/5

  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 does add useful processing context: prepending is resolved, and results include collapsed paths with prepend counts. However, it does not state whether this is read-only, how results are bounded, what the output format is, or any caveats about the data.

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

  Conciseness4/5

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

  The description is one dense sentence with no filler, and the primary scope ('for a prefix') is front-loaded. It earns its place but is slightly cryptic because of heavy domain jargon and compressed phrasing.

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

  Completeness2/5

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

  Given three parameters, no output schema, no annotations, and a large sibling set, this description is not complete enough for reliable invocation. It omits semantics for start/end, expected return structure, and usage context. The existence of many related tools increases the need for clearer guidance.

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

  Parameters2/5

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

  Schema description coverage is 0%, so the description must compensate. It clarifies that prefix is the core input, but it says nothing about the start and end parameters, leaving their meaning ambiguous. The two optional parameters are completely undocumented in both the schema and the description.

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

  Purpose4/5

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

  The description identifies a specific resource (a prefix) and a concrete output concept (transit structure with immediate upstreams, their share, and top paths with collapsed_path / prepend_count). This is much more informative than a tautology. However, it lacks an explicit verb like 'returns' or 'lists', and it does not clearly distinguish itself from sibling tools such as path_diversity or origin_history.

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

  Usage Guidelines2/5

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

  No when-to-use or when-not-to-use guidance is provided, and no alternative sibling tool is mentioned. The phrase 'for a prefix with prepending resolved' implies a niche use case, but an agent selecting among 18 sibling tools gets no explicit decision rule.

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

• subprefixesC
  2.9/5.0
  Behavior3/5

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

  With no annotations, the description carries the burden of explaining behavior. It does disclose what the tool returns — announced more-specifics and an estimate of unrouted space — and defines the estimate's meaning. However, it does not state whether the operation is read-only, whether filters or limits apply, or what output format to expect.

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

  Conciseness4/5

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

  The description is a single sentence and contains no filler; the em-dash definition of unrouted space adds value. It would be slightly stronger if it began with a verb to make the tool's action explicit.

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

  Completeness2/5

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

  For a tool with three parameters, no output schema, and no annotations, this description is incomplete. It does not explain the start/end range semantics, the output structure, or the caveats of the unrouted-space estimate, leaving an agent without enough context to call the tool confidently.

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

  Parameters2/5

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

  Schema description coverage is 0%, and the description only indirectly maps 'more-specifics inside a block' to the required prefix parameter. The start and end parameters are not explained at all, so agents must guess their meaning, format, and the effect of the null defaults.

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

  Purpose4/5

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

  The description identifies a concrete object — announced more-specifics inside a block — and adds a distinctive second output: an estimate of unrouted space. It lacks an explicit verb like 'returns' or 'lists', so it reads as a noun phrase, but the resource and function are inferable from context.

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

  Usage Guidelines2/5

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

  No guidance is given on when to call this tool versus siblings such as detect, inventory, or relationships. There are no conditional triggers, expected scenarios, or statements about when not to use it, so an agent must infer applicability from the name and domain context.

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

• detectionsB
  3/5.0
  Behavior3/5

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

  No annotations are provided, so the description carries the full burden of behavioral disclosure. It does add genuinely useful context by explaining that the direction field indicates offender versus victim and warns against hand-inverting conclusions. However, it does not describe output shape, pagination, rate limits, or side effects, so transparency is only partial.

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

  Conciseness5/5

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

  The description is compact and front-loaded, with the core scope stated first. The subsequent warning about direction inversion earns its place because it prevents a likely misinterpretation of results.

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

  Completeness2/5

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

  With six parameters, no annotations, no output schema, and no usage alternatives, the description is too thin to fully support correct invocation. The direction clarification is valuable but leaves major gaps around parameter semantics, result interpretation, and when to choose this tool over siblings.

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

  Parameters2/5

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

  Schema description coverage is 0%, and the description does not explain the six input parameters such as asn, prefix, start, end, anomalous_only, or detection_type. It mentions direction values, but direction is not even an input parameter in the schema, so it contributes little to parameter understanding.

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

  Purpose4/5

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

  The description states that the tool returns 'platform findings for an ASN or prefix,' which identifies both the resource and the query subject. It also adds the distinct trait that direction is made explicit, but it does not use a concrete action verb like 'list' or 'get,' and it doesn't differentiate itself from sibling tools beyond the direction emphasis.

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

  Usage Guidelines2/5

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

  There is no guidance on when to use this tool versus siblings such as platform_baseline, origin_history, or events_sample. The scope 'for an ASN or prefix' implies some usage context, but no explicit exclusions or alternative routing are provided.

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

• health_checkA
  3.5/5.0
  Behavior3/5

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

  With no annotations, the description must carry full behavioral disclosure. It does state that this is an audit, mentions that it returns remediation guidance, and discloses that sampling bounds per-prefix checks for speed. It does not explicitly say it has no side effects, mention permission requirements beyond 'ASN you control', or describe the response shape.

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

  Conciseness5/5

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

  The description is tight and front-loaded: first the overall purpose and scope, then the specific checks and remediation behavior, then a performance-related sampling caveat. Every sentence earns its place and no wording is redundant.

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

  Completeness3/5

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

  The description is strong for tool selection: it clearly conveys a read-only-style audit, what it covers, and that it is fast due to sampling. However, with no output schema and no annotations, an agent still has to guess about the exact structure of returned findings and how to format the optional `checks` values, so completeness is only partial.

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

  Parameters3/5

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

  Schema description coverage is 0%, so the description bears more responsibility for explaining parameters. It adds useful meaning by clarifying that the target is an ASN the user controls and by listing the major check domains, which likely map to the `checks` parameter. It does not define accepted string values for `checks` or explain the `window` parameteperture in detail.

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

  Purpose4/5

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

  The description clearly states a specific audit purpose: full hygiene and exposure review for a controlled ASN, and it enumerates concrete check categories such as RPKI/IRR coverage, MOAS, ROa max-length, and transit diversity. It stands apart from the sibling tools by scope and comprehensiveness, but it does not explicitly name or contrast a sibling alternative.

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

  Usage Guidelines3/5

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

  The phrase 'for an ASN you control' gives useful context, and calling it the 'single most valuable operator call' implies using it as a first-pass comprehensive audit. However, it never explicitly states when to prefer this over granular tools like path_diversity, visibility, or validate_announcement, nor when not to use it.

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

• platform_baselineA
  3.5/5.0
  Behavior3/5

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

  With no annotations, the description must carry behavioral disclosure. It clearly states that the tool aggregates recent anomalous detections and provides interpretive guidance. However, it does not mention whether the operation is read-only, how results are returned, or how the window/by parameters affect behavior—gaps that are more significant given the absence of annotation support.

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

  Conciseness5/5

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

  The description is compact, front-loaded with the core question, and immediately states the action and the critical usage instruction. Every sentence earns its place, and there is no filler or redundant information.

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

  Completeness3/5

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

  For a simple two-optional-parameter tool with no annotations and no output schema, the description gives enough context for an agent to know when to call it and what it conceptually does. But it leaves parameter semantics and expected return shape undocumented, which creates a moderate gap for correct invocation and result interpretation.

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

  Parameters2/5

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

  Schema description coverage is 0%, so the description must compensate for explaining the 'by' and 'window' parameters. It does not. The word 'recent' hints at the window, but there is no explanation of the enum values, defaults, or how grouping by type/severity changes the output. The schema provides titles and defaults, but the description adds little parameter-level meaning.

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

  Purpose4/5

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

  The description uses a clear verb 'aggregates' and identifies the resource: recent anomalous detections, platform-wide. It also states the intended purpose—distinguishing normal volume from real events—and implicitly differentiates from more specific sibling tools by emphasizing platform-wide aggregation. However, it does not explicitly name a sibling or contrast itself with tools like detections or identify.

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

  Usage Guidelines4/5

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

  The description gives strong usage guidance: 'Call this BEFORE describing anything as anomalous.' It also conveys that this is the right tool for platform-wide anomaly context and warns against misinterpreting spikes. It does not explicitly state 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.

• visibilityA
  3.5/5.0
  Behavior4/5

  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 discloses what the tool reports—peer/collector reach, upstreams, and sibling ratio—and explains how to interpret those results. It does not fully describe return formatting or side-effect profile, but the core behavior is substantively covered.

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

  Conciseness4/5

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

  The description is three sentences with a front-loaded clarifying question, a compact list of output areas, and a concrete interpretive example. It is efficient and every sentence contributes meaning, though the conversational tone adds a bit of style over strict operational precision.

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

  Completeness2/5

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

  Given three parameters, no output schema, and 0% schema description coverage, the description leaves operational gaps. An agent still does not know how to use window or compare_to effectively, or what the exact response shape looks like. The conceptual value is strong, but calling the tool correctly requires more parameter-level guidance.

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

  Parameters2/5

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

  Schema description coverage is 0%, so the description must compensate. It implicitly maps 'this prefix' to the required prefix parameter and 'sibling prefixes' to compare_to, but the window parameter is entirely unexplained. The description does not clarify accepted formats, defaults, or how compare_to should be supplied.

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

  Purpose4/5

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

  The description clearly identifies the tool as a prefix visibility analysis tool, covering peer/collector reach, upstreams, and a comparative ratio against sibling prefixes. It distinguishes the tool from siblings by emphasizing ratio-based filtering detection, though it does not explicitly name an alternative.

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

  Usage Guidelines4/5

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

  The description provides clear context: absolute peer counts are meaningless and the ratio against sibling prefixes is the useful signal. This implies when to use the tool, especially for detecting filtered prefixes, though it does not give explicit exclusions or name alternative tools.

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

• locateA
  3.6/5.0
  Behavior3/5

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

  With no annotations, the description carries the full burden. It discloses the data source (PeeringDB), the routing-only approach, and the top-prefix derivation for ASNs. It does not mention failure modes, empty-result behavior, or explicitly state that the operation is read-only, but the core behavior is reasonably transparent.

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

  Conciseness5/5

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

  The description is two dense, front-loaded sentences with no filler. It opens with the core mechanism, then adds a rationale and input instructions. Every sentence earns its place.

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

  Completeness4/5

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

  For a tool with no output schema and no annotations, the description defines the conceptual output ('cities common to all upstreams' PeeringDB presence') and the input handling. It omits output format and edge-case behavior, but for a simple analytic lookup it is nearly complete.

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

  Parameters3/5

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

  Schema description coverage is 0%, so the description must compensate. It explains the role of both parameters: a prefix directly, and an ASN via its top prefix. However, it does not clarify expected formats, mutual exclusivity, or what happens when both/neither parameter is provided, leaving clear gaps.

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

  Purpose4/5

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

  The description clearly states the operation: 'Finds cities common to all upstreams' PeeringDB presence' and labels it 'routing-only geolocation'. It is specific about the resource and method, but it does not explicitly differentiate from sibling tools such as identify or origin_history, so it misses the top score.

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

  Usage Guidelines3/5

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

  It gives input guidance ('Give a prefix (or an ASN, whose top prefix is used to derive upstreams)') and a context cue ('far more reliable than GeoIP for leased/anycast space'). However, it does not state when to prefer locate over sibling tools or when not to use it, leaving the usage conditions partly implied.

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

• inventoryA
  3.7/5.0
  Behavior4/5

  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 states a non-obvious behavior: persistence is server-computed and must not be derived from first_seen. It also enumerates the classification values, giving the agent a concrete picture of what the tool will return.

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

  Conciseness5/5

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

  The description is tight and front-loaded: the purpose appears in the first sentence, the key output detail is bolded, and the warning sentence prevents a likely misuse. No filler.

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

  Completeness3/5

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

  A basic call with only the required asn is feasible, and the return shape is described. However, the optional parameters are undocumented and there is no output schema, so an agent cannot confidently craft richer queries or interpret edge cases.

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

  Parameters2/5

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

  Schema description coverage is only 20%, and the description adds no parameter guidance. start/end, classify, and min_prefix_len are left to name-guessing; the agent cannot tell what date range means, how classify affects output, or how min_prefix_len filters.

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

  Purpose4/5

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

  The description opens with a concrete question ('What does this ASN announce...') and then states a specific deliverable: each prefix plus a server-computed persistence classification. It distinguishes the tool from first_seen-based inference, but it does not explicitly differentiate from sibling tools like timeline or origin_history.

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

  Usage Guidelines4/5

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

  The instruction 'Do not infer persistence from first_seen — use this' gives a clear directive on when to rely on this tool. It identifies the use case for persistence classification, though it does not name sibling tools or specify when not to use inventory.

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

• timelineA
  3.9/5.0
  Behavior4/5

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

  With no annotations, the description must carry behavioral disclosure. It adds important traits: the daily rollup limitation, why hour/peer/event_type grouping are unavailable, and what configuration produces the handder chart. It does not disclose return format, safety profile, or rate limits, but for a read-only counting endpoint the key behavioral pitfalls are addressed.

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

  Conciseness5/5

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

  The description is three succinct sentences with no filler. The primary function is front-loaded and each sentence adds either usage, capability, or a limitation. It is compact and scannable.

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

  Completeness3/5

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

  For a tool with 5 parameters, no annotations, and no output schema, the description is moderately complete. It covers the main target format, a key group_by use case, and the daily rollup limitation, but it omits start/end handling, other group_by values, week granularity, and what the response shape looks like. An agent might still need to infer several details before invoking it confidently.

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

  Parameters3/5

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

  Schema description coverage is 0%, so the description must compensate. It does explain the 'target' format and gives meaning to 'group_by=origin' + daily granularity. However, it does not explain start/end semantics, the difference between group_by none vs collector, or what 'week' granularity means, leaving several parameters underdocumented.

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

  Purpose4/5

  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: 'Counts over time for target', with concrete target examples (asn:13335, prefix:1.1.1.0/24). It distinguishes itself from bulk event downloads by saying it replaces them, but it does not explicitly name any sibling tool, so it misses some differentiation.

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

  Usage Guidelines4/5

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

  It provides usage context by noting it replaces bulk event downloads and that 'group_by=origin' at daily granularity is the handover chart. It also explicitly lists unavailable options (hour granularity, peer/event_type grouping) and explains the underlying daily rollup, which helps prevent incorrect usage. However, it does not name alternative sibling tools for unsupported queries.

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

• origin_historyA
  4/5.0
  Behavior4/5

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

  With no annotations provided, the description carries the behavioral burden. It discloses day-level origin sets, MOAS days, and transition classifications, and defines those categories. It omits output shape and edge cases, but for a read-style lookup this is solid behavioral coverage.

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

  Conciseness5/5

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

  Three sentences with no wasted words. The core purpose is front-loaded, outputs are listed compactly, and the intended use case is stated in the closing sentence. Every clause adds information.

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

  Completeness3/5

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

  Without an output schema or annotations, the description needs to cover both behavior and inputs. It covers behavior well, but leaves the optional date parameters unexplained and gives no hint about output formatting. Still, the core decision-relevant information is present.

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

  Parameters2/5

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

  Schema description coverage is 0%, so the description must explain parameters. It clearly covers 'prefix' and implies a temporal dimension, but it never mentions the 'start' and 'end' parameters, their formats, defaults, or how they bound the day-by-day results. This is a meaningful gap.

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

  Purpose5/5

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

  The description opens with a specific action and resource: 'Day-by-day origins for a prefix', and lists concrete outputs (origin set, MOAS days, classified transitions). It also frames the tool as 'THE persistence check', which clearly separates its intent from siblings like timeline or compare_windows.

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

  Usage Guidelines4/5

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

  The description explicitly tells the agent when to use this tool: when checking persistence and when avoiding mistaking a transient blip for a migration. It does not name alternatives or provide explicit when-not-to-use conditions, so it loses one point.

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

• reachabilityA
  4/5.0
  Behavior4/5

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

  With no annotations, the description carries the full burden. It discloses that the tool reads raw events, warns about cost, and defines the outage-window threshold as >=5% of peers routeless. It also explains that multi-prefix events resolve in one call. This is meaningful 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.

  Conciseness5/5

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

  Four short sentences, front-loaded with the core answer and return shape. Each sentence adds a distinct fact: what is counted, what is returned, multi-prefix behavior, and a cost warning. No filler or redundancy.

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

  Completeness3/5

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

  The description explains the output type and threshold, which is useful given no output schema. However, it leaves important invocation details underspecified, especially start/end format and defaults, and does not describe the structure of the event-driven series well enough for an agent to interpret the result confidently.

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

  Parameters2/5

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

  Schema description coverage is 0%, so the description must compensate. It explains that prefixes are multiple and implies start/end define a time window via 'keep the window tight,' but it does not explain their optionality, value format, defaults, or how they interact with the returned series. Parameter semantics remain under-specified.

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

  Purpose5/5

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

  The description clearly states the tool computes how many observing peers had no route and when, and that it returns an event-driven series plus server-computed outage windows. It also highlights multi-prefix support, which distinguishes it from sibling tools focused on paths, visibility, or timeline analysis.

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

  Usage Guidelines4/5

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

  The description gives explicit practical guidance: use multiple prefixes in a single call for multi-prefix events, and keep the time window tight because the tool reads raw events. It does not name alternatives or explicitly say when not to use it, so it misses the top tier, but the context is clear.

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

• events_sampleA
  4.1/5.0
  Behavior4/5

  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 reveals important behavioral traits: the event count is capped at 500, windows over ~24h are rejected, and it is a narrow-window sample rather than a comprehensive query. It does not describe error behavior or ordering, but for a read-only sampling tool the key constraints are surfaced clearly.

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

  Conciseness5/5

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

  Three terse sentences, each carrying a distinct piece of information: what it is, its hard limits, and when to use it. The text is front-loaded with the essential purpose and avoids explaining what the schema already covers. Every clause earns its place.

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

  Completeness2/5

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

  The tool has 8 parameters, no output schema, no annotations, and only 13% schema description coverage. The description does not clarify the required 'prefix' semantics, any of the optional filter parameters, or the structure of the returned raw events. While the usage guidance is strong, an agent is left to guess important call details, so the overall description is not complete enough.

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

  Parameters2/5

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

  Schema description coverage is only 13% (just start), and the description only adds meaning for the window and cap, implicitly linking start/end/limit. It says nothing about the required 'prefix' parameter or the optional filters (peer_asn, origin_as, event_type, collector_id), leaving the agent without semantic guidance for the majority of parameters. The description fails to compensate for the low schema coverage.

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

  Purpose5/5

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

  The description clearly identifies the tool as providing 'Bounded raw events for a NARROW window' and frames it as a 'last resort' after other tools, which makes its resource and scope explicit. It distinguishes itself from siblings by positioning itself against timeline, reachability, and origin_history, which tells an agent what this tool is not for.

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

  Usage Guidelines5/5

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

  It explicitly states when to use this tool: 'Use only after timeline/reachability/origin_history have localised what you need to see at the message level.' It names the alternatives and gives concrete constraints (capp at 500 events, rejects windows over ~24h) that help an agent decide if this tool fits the task. This is strong, actionable guidance.

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

• validate_announcementA
  4.1/5.0
  Behavior4/5

  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, and it delivers: it enumerates the distinct checks performed (ROA/max-length, IRR route objects, current announcers, registration changes) and states the three-valued verdict (clear | warn | blocked). It even explains the causal rationale for the registration check (freshly transferred space keeps the old holder's ROAs), which is genuinely informative. Minor gaps: it does not explicitly state that the tool is non-mutating (though 'pre-flight' strongly implies it) nor the exact 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.

  Conciseness4/5

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

  The description is front-loaded with the core question, then proceeds through the checks and finishes with the return verdict. It is dense but every clause earns its place — including the em-dash rationale for the holder check, which adds causal context rather than padding. The single run-on sentence is slightly less scannable than it could be, but there is zero wasted verbiage.

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

  Completeness4/5

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

  For a tool with no annotations and no output schema, the description is notably complete: it covers the purpose, all four checks performed, the verdict values, and even the domain-specific reasoning behind the holder check. Remaining gaps are the exact return structure beyond the verdict names and explicit parameter value formats, neither of which is fatal given how much the description already conveys.

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

  Parameters3/5

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

  Schema description coverage is 0%, so the description must compensate. It successfully gives functional meaning to all three parameters: `prefix` and `origin_asn` appear inline in the core question, and `check_holder` maps to the explained registration-change check. However, it does not specify value formats or constraints (e.g., CIDR notation for prefix, ASN integer range, type expectations), which is a meaningful gap given the schema itself provides no parameter titles or descriptions.

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

  Purpose5/5

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

  The description opens with a specific, answerable question ('will announcing `prefix` from `origin_asn` validate?') that names the exact verb, resource, and inputs. It then enumerates precisely what is checked (covering ROA and max-length, IRR route objects, current announcers, registration changes), which makes the tool's scope unmistakable and distinguishes it from the diverse sibling set (identify, timeline, reachability, etc.), none of which obviously overlap with validation.

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

  Usage Guidelines4/5

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

  The description frames the tool as a 'pre-flight' check, which clearly signals it is meant to be run before announcing a prefix, giving strong contextual guidance on when to use it. However, it names no explicit alternatives or when-not-to-use exclusions. Among the siblings (detections, origin_history, reachability) there is no obvious competitor for this task, so it stands apart without needing explicit routing.

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

• compare_windowsA
  4.3/5.0
  Behavior3/5

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

  No annotations are present, so the description carries the full behavioral burden. It discloses an important limitation—upstream/paths comparison is unavailable via the rollup—and explains how dimension choice changes behavior, but it does not state return format, whether the operation is read-only, or any other side effects. For a comparison tool this is acceptable but 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.

  Conciseness5/5

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

  Three compact sentences front-load the core comparison and immediately explain window shape and dimension semantics. The final parenthetical routes readers to the correct sibling without extra words.

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

  Completeness3/5

  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, when to use it, and a key exclusion, and there is no output schema to describe returns. Still, it omits the shape of the comparison result and details of `target`/`from`/`to` formats, which an agent would need for robust invocation.

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

  Parameters4/5

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

  Schema description coverage is 0%, but the description compensates by explaining that each window is {from, to} and by giving meaning to all three enum values for `dimension`. It does not explain the `target` parameter or the format/type of `from` and `to`, leaving a small gap.

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

  Purpose5/5

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

  States a specific operation: compare baseline (window_a) vs event (window_b) for a target, and enumerates what each dimension does. It distinguishes itself from sibling `paths` by explicitly saying upstream/paths comparison is not available via the rollup and to use `paths` instead. This is enough to know exactly what the tool does and what it is not.

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

  Usage Guidelines5/5

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

  Provides clear usage semantics: `dimension=volume` compares totals, while `origin`/`collector` compare per-group breakdowns to surface new origins or shifted collector mix. It explicitly names an alternative (`paths`) for the unsupported upstream/paths comparison, so an agent knows 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.

• path_diversityA
  4.3/5.0
  Behavior5/5

  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 reveals that data comes strictly from observed AS paths (no inference), that shares are per-upstream coverage and can sum past 1.0, that `is_tier1` marks Tier-1 core, that `diverse=false` indicates single-threaded or thinly observed behavior with a `reason` field, and that the view is control-plane rather than data-plane. It also states the default window and what widening it does.

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

  Conciseness4/5

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

  The description is dense but well-structured: a one-sentence lead, then layered detail on semantics, usage, and caveats. Backticks and line breaks make fields and concepts scannable. Some concepts like observed-vs-inferred and control-plane vs data-plane are repeated across paragraphs, but the length is largely justified by the tool's complexity.

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

  Completeness4/5

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

  Despite no output schema, the description documents key return concepts (`share`, `total_vantage_points`, `is_tier1`, `diverse`, `reason`) and explains how to interpret them. It also covers the default time window, the optional `prefix` parameter, and the tool's limitations. It does not specify date string formats or include an example, but for a read-only analysis tool this is nearly complete.

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

  Parameters3/5

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

  The input schema provides only names and types with no descriptions. The description adds meaningful context for `prefix` (a CIDR the ASN originates, useful for MOAS or specific route redundancy) and implies the role of `start`/`end` via the default 14-day window. However, it does not clarify the expected format for `start`/`end` or explicitly define `asn` beyond the general origin-network context, so compensation is only partial.

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

  Purpose5/5

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

  The description states a specific, concrete function: computing the observed propagation/path-diversity tree of an origin's announcements as they fan out through upstreams to collectors. It clearly identifies the resource (origin ASN, upstreams, collectors) and distinguishes itself from a data-plane traceroute, which helps separate it from sibling path-oriented tools.

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

  Usage Guidelines4/5

  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: to see which upstreams actually carry a network's routes and how lopsided that distribution is. It also explains when to pass the `prefix` parameter (for MOAS prefixes or checking a specific route's redundancy) and notes the default 14-day window. However, it does not explicitly compare against any sibling tools or state when not to use it beyond the traceroute caveat.

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

• identifyA
  4.4/5.0
  Behavior4/5

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

  With no annotations provided, the description carries the responsibility for behavioral disclosure. It discloses that the tool aggregates multiple datasources in one call, allows filtering via `include`, and notes the current API limitation that whois is unavailable. It does not describe output structure or potential errors, but for a read-only identity lookup the disclosed information is substantial.

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

  Conciseness5/5

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

  The description is compact, front-loads the core purpose, and uses every sentence meaningfully. The first sentence establishes what the tool does, the second gives usage context, and the third provides precise parameter guidance with a limitation note. No filler or redundancy.

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

  Completeness4/5

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

  Given no annotations, no output schema, and three optional-looking parameters, the description covers the main requirements: what the tool does, what inputs to give, and what `include` values are valid. Minor gaps include lack of prefix format details and ambiguity about whether both `asn` and `prefix` can be provided together, but the description is still largely sufficient for an agent to invoke it.

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

  Parameters4/5

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

  Schema description coverage is 0%, so the description must compensate. It effectively explains that `asn` and `prefix` are the two identification keys, and provides the valid values for `include` (rdap, rpki, irr, peeringdb), which the schema does not enumerate. It could go further by specifying prefix format or clarifying mutual exclusivity, but it adds real semantic value.

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

  Purpose5/5

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

  The description opens with a clear question 'Who is this ASN or prefix?' and specifies the exact data sources: Registry, RPKI, IRR, and PeeringDB. It clearly differentiates this as an aggregated identity lookup, and the framing as 'the right first step' separates it from investigation-specific tools like reachability or detections.

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

  Usage Guidelines4/5

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

  The description explicitly says to provide either `asn` or `prefix` and explains the `include` options, giving concrete invocation guidance. It positions the tool as the 'right first step in almost any investigation,' which communicates when to prefer it, though it does not enumerate when not to use it or name direct alternatives.

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

• translate_communitiesA
  4.7/5.0
  Behavior5/5

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

  With no annotations available, the description carries the full behavioral burden and does so thoroughly. It discloses that results may have known=false, instructs not to guess meanings, distinguishes inferred conventions from authoritative definitions, and explains the owner AS resolution and matched_by field. This is far beyond a minimal description.

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

  Conciseness5/5

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

  The description is dense but every sentence adds meaningful detail: examples, output semantics, convention inference, and wildcard matching. It is front-loaded with the core purpose and uses clear paragraph breaks to separate conceptual overview from result-field nuances.

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

  Completeness5/5

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

  Despite having no output schema and no annotations, the description fully covers what the tool does, what inputs look like, what fields come back, and how to interpret ambiguous or inferred results. There is no major gap an agent would need to guess about before invoking the tool.

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

  Parameters4/5

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

  The schema only defines an array of strings with no description coverage, so the description must compensate. It provides concrete examples of valid inputs and explains what each community string represents. It could add more detail about input constraints like accepted formats or limits, but for a single-parameter list-of-strings tool the examples and context are sufficient.

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

  Purpose5/5

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

  The description uses a specific verb ('translate') and resource ('raw BGP community strings'), with concrete examples such as '3356:2065' and '1299:2731'. It clearly distinguishes the tool's function from the broader set of network-analysis sibling tools, and the stated output meaning goes well beyond a restatement of the name.

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

  Usage Guidelines4/5

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

  The description makes the intended use clear: when you have raw BGP community strings and need their meanings. It does not explicitly name alternatives or exclusions, but the tool is specific enough that no obvious sibling competes with it, and the context provided is sufficient for an agent to recognize when to use it.

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

• relationshipsA
  4.9/5.0
  Behavior5/5

  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 the inference methodology, CAIDA agreement, the fact that peering is not inferred, the meaning of other_connections, and the dependence on the requested date window. This is unusually transparent about limitations.

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

  Conciseness5/5

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

  Three dense paragraphs, each earning its place: the first defines the result, the second explains inference caveats, and the third distinguishes topology from usage and names the alternative tool. The key definition is front-loaded.

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

  Completeness5/5

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

  Even with no output schema and no annotations, the description covers what is returned, what is excluded, temporal semantics, and where to go for complementary data. An agent has enough context to decide whether to call it and what the results mean.

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

  Parameters4/5

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

  Schema description coverage is 0%, so the description must compensate. It does convey that asn identifies the ASN whose hierarchy is returned and that start/end define the requested date window. It does not specify date formats or defaults, but the parameter names and the window concept cover most of the meaning.

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

  Purpose5/5

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

  The description clearly defines the tool's output as an ASN's transit hierarchy: upstreams, downstreams, and unknown-neighbor adjacencies. It also explicitly states what the tool is not, since peering is not inferred, which distinguishes it from related topology tools like path_diversity.

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

  Usage Guidelines5/5

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

  It explicitly frames this tool as the transit TOPOLOGY answer and directs agents to path_diversity for observed USAGE. It also warns against presenting other_connections as confirmed peers, giving both a positive selection cue and an important exclusion.

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