PeppolStatus

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

Annotations already declare readOnlyHint=true, and the description does not contradict that. The description adds meaningful behavioral context beyond the annotation: the stale-key resolution behavior (stale keys resolve to the current provider, returned key is canonical) and the exact fields in the response. This gives the agent a clear picture of the tool's behavior without requiring a call.

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

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

The description is moderately sized and front-loaded with the purpose ('Get an access point'). It is dense but each sentence adds value: the first sentence states the main function, the second enumerates return fields, and the third clarifies an important nuance about stale keys. It could be slightly more structured, but it avoids unnecessary 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 that there is no output schema and only one parameter with full schema coverage, the description carries the full burden of explaining what the tool returns and how it behaves. It covers the response structure (display name, verified flag, member seats, roster size, composition), the canonical-key guarantee, and the stale-key resolution. This is sufficiently complete for a read-only single-entity fetch operation.

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 has full coverage for the 'key' parameter with a clear description and examples. The tool description adds extra semantic meaning by explaining that stale keys are resolved to the canonical current key, and by clarifying that the returned key is always the canonical one. This goes beyond the schema's basic type/format info, enhancing the agent's understanding of what the parameter represents.

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 purpose with a specific verb ('Get') and resource ('access point'). It then lists the specific fields returned, distinguishing it from list_access_points and other sibling tools by focusing on single-entity details. Although there is a get_provider sibling, the description's detail about member seats, roster size, and composition makes the purpose distinct.

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 does not provide explicit guidance on when to use this tool versus alternatives such as list_access_points or get_provider. It mentions the stale-key behavior, which is a usage consideration, but it does not say 'use this when' or point to alternatives. Thus, the usage context is largely implied by the name and sibling context rather than stated.

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

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

The description goes well beyond the readOnlyHint annotation by explaining the data semantics: definitions of joiners (with a data-availability caveat for 2026-08-02 onward), movers, and leavers, as well as the period defaulting to trailing 30 days. This is substantive behavioral context that is not evident from the annotations or 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 well-structured and front-loaded: the first line states the core purpose, then each sentence adds necessary clarification about definitions and defaults. No redundant information is present, and the length is appropriate for the complexity of the subject.

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

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

Despite the absence of an output schema, the description sufficiently describes the return contents: a daily category series, net growth, period totals, and the 'won from / lost to' breakdown. It also covers data definitions and default periods, making the tool's behavior and return value understandable without further documentation.

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

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

Schema coverage is 100%, with descriptions for all three parameters (key, from, to). The description adds context like 'Defaults to the trailing 30 days,' but this is largely already captured in the schema defaults. The description does not introduce new parameter syntax or format details, so a baseline score 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 tool's purpose with a specific verb and resource: "Get an access point's churn." It then elaborates on what churn means (joiner/mover/leaver activity) and distinguishes it from sibling tools like get_access_point and get_country_churn by focusing on the access point's churn-specific data.

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

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

The description provides clear context for when to use the tool (to retrieve churn data for a specific access point) but does not explicitly exclude alternatives or reference sibling tools like get_country_churn. It lacks explicit when-to-use/not-to-use guidance, but the specificity makes the intended usage 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?

Annotations only declare readOnlyHint=true, but the description adds substantial behavioral disclosure: data is cached for a day, small numerators are suppressed with nulls, denominators never suppressed, and region/sector codes are included for geometry joins. This goes far beyond the annotation and provides critical edge-case behavior that an agent must know.

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?

Although long, every sentence and clause contributes unique information. The opening sentence is a clear summary, followed by precise details on output structure, codes, suppression, and caching. There is no fluff, and the density is appropriate for the complexity of the returned object.

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

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

With no output schema, the description carries the full burden of explaining return values. It thoroughly covers all output components (headline, cuts, cross-tabs, trend), data semantics (codes, suppression rules), and operational behavior (caching). This is complete enough for an agent to invoke the tool and interpret results 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 only parameter, country, is fully documented in the schema with an enum and description. The tool description does not add extra parameter semantics beyond what the schema already provides. Since schema coverage is 100%, 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 opens with 'Get a country's adoption aggregates' — a specific verb with a clear resource and scope. It then details the exact contents (headline totals, cuts, cross-tabs, trend) and even distinguishes from sibling tools by its country-level focus. This fully clarifies what the tool does and sets it apart from similar get_* 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 gives clear context about what data is returned and the country scope, so an agent can infer when to use it. However, it does not explicitly mention when not to use it or point to alternatives among the sibling tools (e.g., get_country_churn). It meets the 'clear context, no exclusions' level, but stops short of explicit alternative 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?

The readOnlyHint annotation already indicates a safe read operation, and the description's 'Get' is consistent with that. The description adds little behavioral context beyond what annotations provide, but there is no contradiction.

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 only two sentences, front-loaded with the tool's purpose, and contains no unnecessary words or repetitive information.

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

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

For a simple read-by-id tool with one parameter, a readOnlyHint, and no output schema, this description is complete. It conveys the essential purpose and the key concept without needing extra 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?

The schema fully documents the 'id' parameter as 'The stable anomaly key.' The description adds 'content-derived' to clarify the key's origin, but this is a minor addition given the schema's already high 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 clearly states the tool's action ('Get an anomaly') and resource ('anomaly'), and specifies it retrieves a single anomaly by its stable content-derived key. This distinguishes it from sibling list_anomalies and other get_* 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 usage when you have a known stable key for a specific anomaly, but it does not explicitly mention alternatives like list_anomalies for browsing or searching. The guidance is implied rather than explicit.

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

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

Beyond the readOnlyHint annotation, the description reveals the return structure (daily series, all-time monthly rollup), the data source (hourly churn rollup), and an important edge case ('valid but unknown country returns empty arrays'). Also notes 'keyless-cacheable' behavior. No contradiction with annotations.

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

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

Three sentences cover purpose, output shape, edge case, and caching, with no filler. The most important information is front-loaded.

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

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

No output schema exists, so the description carries the burden of describing returns. It explains the series types and the edge case, but could be more explicit about the exact array fields. Overall adequate for the tool's moderate complexity.

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

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

Schema coverage is 100%, so parameters are already documented. The description adds semantic context for the country code (valid but unknown -> empty arrays) and clarifies that from/to bound the daily series. This provides extra meaning beyond the raw schema.

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

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

The description clearly states the resource and scope: 'Per-country participant churn' and 'New (joiner) vs departed (leaver) participants for one country'. It distinguishes from sibling tools like get_access_point_churn by focusing on country-level data, and specifies the output shape (daily series + monthly rollup).

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 usage context is implied by the name and description (for country-level churn), but there are no explicit alternatives or when-not-to-use conditions. Sibling tool names exist but are not referenced, so the agent must infer when this tool is the right choice.

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

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

Beyond the readOnlyHint annotation, the description adds meaningful context: unknown countries return empty lists, company_coverage semantics and empty providers_by_company for unenriched markets, and keyless-cacheability. This enriches the agent's understanding of edge cases and output interpretation.

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 and then provides necessary detail in a compact set of sentences. It includes some technical specifics (issue #467) that may be unnecessary but does not waste words overall.

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 a single parameter and no output schema, the description fully covers the return fields, ranking logic, and edge cases. It provides enough information for an agent to know what the tool returns and how to interpret it, making it contextually 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?

The input schema already provides 100% coverage for the single parameter (code) with a clear description. The tool description does not add syntax details but does clarify the country context and behavior for unknown codes, which is marginal value. 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 it lists access points serving a country with two ranking metrics, giving a specific verb and resource. It distinguishes itself through country-scoped ranking but does not explicitly name sibling alternatives like list_providers.

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 intended use is implied: when you need country-level provider rankings. However, there is no explicit statement of when to use this tool over alternatives or exclusions, so guidance is only 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?

Annotations declare readOnlyHint=true, and the description complements this by detailing the returned data components and the optional point-in-time behavior. It adds clarity about what 'state' means without repeating the annotation.

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

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

Two short sentences; the first states the core purpose, the second adds essential detail 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 simple get tool, the description lists the specific fields returned, covers the optional parameter behavior, and benefits from a readOnly annotation. No output schema exists, but the field list suffices; no critical behavioral gaps remain.

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

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

Both parameters are fully described in the schema (100% coverage). The description adds the functional note that `at` yields point-in-time state, which slightly reinforces the schema but adds no new semantic information beyond it.

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

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

The description uses the specific verb 'Get' with resource 'host', and enumerates the exact state fields returned (role, verdict, network attribution, TLS cert, provider), which distinguishes it from sibling tools like get_host_uptime and list_hosts.

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

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

The description implies this is for retrieving current host state but does not explicitly mention alternatives or when-not-to-use. It provides helpful context (e.g., `?at=` for point-in-time) but no exclusionary 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?

The readOnlyHint annotation already signals a safe read, and the description adds useful behavioral detail: it returns results across ALL roles, includes confidence tiers, first-seen timestamps, and structured evidence, and `?at=` provides point-in-time state. This gives the agent a clear picture of what the result actually contains, beyond the annotation's safe-read signal.

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 first sentence is a strong front-loaded purpose string, and the parameter details are compact. However, the trailing 'Market tier.' fragment is unexplained and contributes no usable meaning, and the description mixes prose about output with a stray field label, making the structure slightly uneven.

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

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

With no output schema present, the description does a good job of describing the major return components: vendor, version per role, hosting, confidence tier, first-seen timestamp, and evidence. It is missing some detail around what 'market tier' means and does not describe error behavior, but it supplies enough context for an agent to select and invoke the tool correctly.

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

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

The schema already fully describes both parameters with 100% coverage: hostname is the fully-qualified hostname and at is an optional ISO 8601 instant. The description adds essentially no parameter meaning beyond restating the at behavior already in the schema, so the baseline score 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 tool returns a host's software fingerprint, including per-role vendor, version, hosting, and evidence. This is distinguishable from broader host tools like get_host and from historical tools like list_host_software_history, although it does not explicitly name those sibling 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 use case is implied: you call this when you want the current or point-in-time software fingerprint of a single host. However, it does not explicitly say when to prefer this over siblings such as list_host_software_history or get_software_stats, so the agent has to infer the boundary.

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

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

Beyond the readOnlyHint annotation, the description discloses key behavioral traits: it returns a per-location rollup including __all__, supports date-range windowing with half-open semantics, and is cursor-paginated. These details are not present in the annotation and add meaningful context for the agent.

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 succinct sentences. The first sentence delivers the primary purpose immediately, and the second elaborates on key details without redundancy. Every phrase earns its place, 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 tool's complexity (7 parameters, aggregate levels, pagination) and lack of an output schema, the description covers the main functional aspects: aggregate ladder, per-location rollup, windowing, and cursor pagination. It does not describe the exact return fields of an uptime aggregate, but the schema and annotations largely compensate.

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 comprehensive descriptions for all 7 parameters with 100% coverage, achieving the baseline. The description adds minimal parameter-specific meaning, mostly rephrasing concepts like resolution and windowing already documented 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 'Get a host's uptime aggregates,' a specific verb and resource combination that clearly states the tool's function. It further differentiates from siblings by detailing the aggregate ladder, per-location rollup, and optional windowing, which distinguishes it from other host/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?

The description implies usage for retrieving uptime aggregates at various resolutions and locations, with windowing and pagination. It provides clear context for when to use the tool but does not explicitly mention exclusions or alternatives, such as using get_host for basic host details or list_hosts for enumeration.

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

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

The annotations provide readOnlyHint=true, and the description adds meaningful behavioral context beyond that: it explains the tool returns counts of participants checked, failures, and violation rates, and that results are 'Ordered by violation count, busiest first.' This gives a clear picture of output structure without contradicting the read-only annotation.

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

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

The description is compact and front-loaded with the essential purpose ('Peppol ID quality summary'), followed by a concise but informative breakdown of what the summary contains and how it is ordered. Every sentence adds value with no fluff 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 simple, parameterless, read-only tool, the description fully covers what the agent needs to know: the aggregation level (per-scheme), the metrics provided (participants checked, failures, violation rate), and ordering. Given the lack of an output schema, the description sufficiently explains the return content without missing critical 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?

The input schema declares zero parameters, so there are no parameter semantics to describe. The description thus correctly focuses on output semantics. Baseline of 4 is appropriate for a no-parameter 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 identifies the tool as a 'Peppol ID quality summary' with specific details about per-scheme (ICD) aggregation of structural identifier checks. It distinguishes itself from siblings like list_id_quality_malformed and get_id_quality_hosting by focusing on summary statistics rather than listing individual malformed IDs or host-specific data.

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

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

The description implies usage when a summary-level per-scheme quality view is needed, mentioning 'summary' and 'resulting violation rate.' However, it does not explicitly state when to prefer this tool over alternatives such as list_id_quality_malformed or get_id_quality_hosting, nor does it provide clear exclusion criteria.

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

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

Annotations include readOnlyHint=true, and the description does not contradict this. It adds behavioral context by explaining that results are ranked by malformed-id count and that totals cover the filtered set, going beyond the basic read-only annotation.

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

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

The description is two sentences: a concise headline followed by a detailed summary. Every word adds value, with no redundancy or fluff.

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

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

For a read-only rollup with no output schema, the description adequately explains what is returned (Access Points, SMPs, ranking, totals) and how filtering works. It lacks explicit return structure but is sufficient for a tool of this complexity.

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

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

The input schema covers all 4 parameters with descriptions, so baseline is 3. The description mentions the scheme, reason, and q filters, confirming their role, but does not add new semantic 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 clearly states this tool provides a hosting rollup for malformed identifiers, listing which Access Points and SMPs serve them. It distinguishes itself from sibling list tools by being an aggregated view, with a specific scope and resource.

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 as a companion to the malformed list tool ('honouring the same filters as the malformed list'), but does not explicitly state when to choose this over get_id_quality or list_id_quality_malformed. Context is clear, but exclusions and direct alternatives are not provided.

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

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

Annotations already declare readOnlyHint=true, and the description adds the last-24h temporal scope and the included data categories. However, it does not disclose return format, pagination, or whether counts reflect live or cached data.

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 very brief and front-loaded, but the first sentence 'Get the network summary' largely restates the tool name. The second sentence carries the substantive value and is concise.

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

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

For a zero-parameter read-only summary tool, the description conveys the main output categories and time window. It lacks precise output shape or field details, but the simplicity of the tool makes this adequate.

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% (empty properties), so the baseline 4 applies. The description adds no parameter details, but none are 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 retrieves a network summary and enumerates its contents: host verdict counts, open incidents, and anomalies in the last 24 hours. This distinguishes it from sibling detail-oriented tools like list_incidents and list_anomalies.

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 use for a high-level aggregate network overview, but it does not explicitly state when to prefer this tool over sibling list/get tools or when not to use it. No alternatives are named.

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

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

Annotations already declare readOnlyHint=true, and the description adds meaningful behavioral context by enumerating the exact fields returned and by noting edge cases ('Discovered participants carry no card; unmatched participants carry company: null'). This goes beyond the basic operation and helps set expectations for response shape, even though it doesn't discuss error handling or auth.

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

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

Two sentences: the first states the core purpose immediately; the second enumerates included components and edge cases. Every sentence earns its place with 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?

With a single parameter, a readOnly annotation, and no output schema, the description covers the main aspects well: what is returned and a couple of edge cases. The phrase 'unmatched participants' is slightly ambiguous (whether it means participant not found or company not matched), so a perfect 5 would require clearer error/not-found semantics.

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%—the 'id' parameter is fully documented as a canonical 'scheme::value' Peppol identifier with an example. The description adds no additional meaning to the parameter, 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 opens with a specific verb+resource: 'Get a participant's current state', then enumerates exactly what that includes (directory presence, SML registration, SMP, business card, endpoints, etc.). This clearly distinguishes from siblings like get_participant_history (current vs history) and list_participants (single vs list).

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

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

The phrase 'current state' provides clear context for when to use this tool—when you need a snapshot of a participant's current data rather than history or statistics. The list of components also hints at use cases. However, it does not explicitly name alternatives or exclusions such as 'for historical data use get_participant_history'.

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

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

Beyond the readOnlyHint annotation, the description thoroughly discloses complex behavior: the two-lane merging logic (SMP vs AP), the exact verdict definitions (available/degraded/unreachable/no_data), how degraded counts as available for uptime, the monthly target semantics (not contractual), and temporal attribution (pre_epoch). This goes far beyond what the annotation provides and avoids any contradiction.

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 lengthy but well-structured: a one-line purpose, then a detailed but organized explanation of semantics and return content. Each sentence contributes substantively (merge logic, verdict definitions, return fields, historical scope). It is appropriately detailed for a tool with complex behavior, though slightly verbose in the middle section.

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

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

Given the tool's complexity and the absence of an output schema, the description fully specifies the return contents (per-lane UptimeBuckets, combined lane, headline uptime ranges, service-level target, host-change markers, incidents), historical coverage, and edge cases like pre_epoch attribution. An agent has enough information to understand exactly what it will receive and how the data is derived.

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 id, to, from, and resolution with clear meanings. The description adds minimal new semantic value—only the note about pre_epoch attribution, which is contextual but not tied to a specific parameter. The baseline of 3 is appropriate since the schema carries the parameter documentation load.

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: 'Get a participant's measured availability' and elaborates on the probe-measured reachability of one Peppol ID over time. The description clearly defines what the tool does and the return structure, making it distinct from siblings like get_participant_stats or get_participant_history, even without naming 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 explains the tool's scope and semantics but provides no explicit guidance on when to use it versus alternative participant-related tools (e.g., get_participant_stats, get_participant_history). Usage context is implied from the function name and detailed output, but no when-to-use or when-not-to-use directives are given.

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

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

Annotations declare readOnlyHint=true, and the description's 'List' is consistent. It adds behavioral context beyond the annotation: newest-first ordering, cursor pagination, and the specific fact families included, which is useful for the agent.

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

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

Two concise sentences: the first front-loads the core action, the second adds scope, ordering, and pagination details. No unnecessary words 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?

Given readOnlyHint and full schema coverage, the description explains scope, ordering, and pagination. However, it does not describe the return structure (no output schema exists), which is a minor gap but not critical for a listing tool.

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

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

Schema coverage is 100%, with each parameter already described in detail. The description only adds behavioral context (cursor-paginated) rather than further parameter semantics, so it does not exceed the baseline for well-documented schemas.

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 'List' and identifies the resource as 'participant's temporal history' with explicit scope (directory/card/registration/SMP fact families), ordering, and pagination. This clearly distinguishes it from siblings like get_participant_stats_history and list_participant_events.

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 on what data is covered (temporal rows across specified fact families) and mentions cursor-paginated, implying when to use it. However, it does not explicitly state alternatives or when not to use this tool, 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?

Beyond the readOnlyHint annotation, the description discloses meaningful behavioral details: derivation from business-card RegistrationDate or first-seen, the handling of unknown/seed tail (reported only in coverage, never bucketed), and keyless-cacheability. It adds significant context without contradicting annotations.

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

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

The description is compact and well-structured, with the title line followed by a brief explanation. The reference to 'issue #222' is somewhat extraneous, but the rest is informative and to the point.

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

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

Given the tool has one optional parameter and no output schema, the description provides solid context: what the curve represents, the join date derivation logic, coverage categories, and the unknown tail behavior. It is sufficiently complete for an agent to select and invoke correctly, though it stops short of specifying the exact response shape.

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

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

Schema coverage is 100% for the single 'bucket' parameter, including its enum, default, and description. The tool description does not add additional parameter context beyond the schema, which is sufficient.

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 identifies the tool as returning a 'Network joiners curve' with joiner counts bucketed by derived join date. It distinguishes from sibling tools by calling it 'The real onboarding curve' and specifying whole-network coverage split, making it distinct from related participant/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?

The description implies usage for onboarding/joiner analysis with a coverage split, but it does not explicitly state when to use this over siblings or provide exclusions. The context suggests it's the go-to for joiners curves, but no direct alternatives are named.

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

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

Beyond the readOnlyHint annotation, the description adds significant behavioral context: 'Keyless-cacheable' indicates no auth and cacheability, 'hourly rollup' implies data freshness and potential lag, and 'estimated total' warns of approximation. This goes well beyond the annotation.

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

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

The description is extremely tight and front-loaded: a short title followed by one dense sentence covering output dimensions, data source, freshness, and usage safety. Every word adds value, with no redundancy.

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

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

For a zero-parameter tool with no output schema, the description covers the response contents (facet counts, estimated total), the data source (hourly rollup), and the access context (keyless-cacheable). It gives a complete picture of what to expect and how to use it.

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 the schema coverage is effectively complete. The description adds no parameter details but doesn't need to; instead, it explains the scope of the fixed output. This aligns with the baseline of 4 for no-parameter tools.

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 explains the tool provides global participant facet counts across multiple dimensions (country/scheme/smp/ap/doctype/transport_profile) plus an estimated total. It effectively distinguishes the current snapshot nature from historical tools by mentioning 'hourly rollup', though it lacks an explicit verb like 'retrieve' or 'list' and doesn't directly compare against siblings.

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

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

The description gives a concrete usage context: 'safe for the marketing site to hit directly' implying it is cacheable and requires no authentication. However, it doesn't explicitly state when to prefer this over sibling tools like get_participant_stats_history, nor does it provide exclusions or alternative guidance.

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

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

Annotations already declare readOnlyHint=true. The description adds useful behavioral context: 'Keyless-cacheable' indicates caching behavior, and 'History accrues from the day the feature shipped' clarifies data availability. This goes beyond the annotation without contradicting it, though it omits details like rate limits or consequences of no data.

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

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

The description is extremely concise: three short sentences with no wasted words. The title is front-loaded, and the subsequent sentences efficiently convey the core concept and key behavioral traits.

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 5 parameters and no output schema, the description covers the core concept (daily time series per facet) and adds caching and data start date. However, it lacks details on return format, how multiple keys combine (logical OR vs AND), or behavior for dates with no data. Given the complexity, there are clear gaps.

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 does not add explicit parameter-level meaning beyond the schema's own descriptions. However, the high-level context (e.g., 'facet dimension' aligns with the dimension parameter) provides some supporting semantics, but no additional depth.

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 identifies the tool as providing a daily time series over a participant facet dimension, mentioning adoption curves and QoQ trends. It distinguishes from siblings like get_participant_stats and get_participant_history by specifying the time-series nature per facet, but doesn't explicitly compare or contrast with similar 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?

No explicit guidance on when to use this tool versus alternatives. The description implies it's for single-facet daily history, but it does not state exclusions or recommend other tools for different use cases (e.g., get_participant_history for per-participant history).

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

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

The annotation readOnlyHint=true already indicates a safe read operation. The description adds that the provider is 'navigable to its seats and each seat's observed hosts,' providing context about the returned structure. However, it does not mention rate limits, pagination, or other behavioral details, so it only modestly extends the annotation.

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

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

The description is two short sentences, front-loaded with the core purpose and a clarifying second sentence. It is concise with zero redundancy or unnecessary 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 simple single-parameter read-only tool with no output schema, the description provides sufficient context: it identifies the resource and hints at the navigable structure. It could be more explicit about the response being a single provider object, but the get verb and slug parameter 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 covers 100% of parameter descriptions, with 'slug' described as 'The curated provider slug.' The tool description repeats the 'curated provider' wording but adds no new semantics. Baseline 3 is appropriate given 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 clearly states the tool gets a 'curated provider' and elaborates that it is navigable to seats and observed hosts. This distinguishes it from siblings like list_providers and get_provider_sla, though it does not explicitly name them. The verb 'Get' and the specific resource make the purpose clear.

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

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

The description does not provide any guidance on when to use this tool versus alternatives such as list_providers or get_provider_sla. It implies usage through the slug parameter and 'navigable' wording, but there are no explicit when-to-use or when-not-to-use instructions.

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

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

Beyond the readOnlyHint annotation, the description reveals ordering (worst uptime first, providers with no checks last), data freshness (materialized hourly by batch runner), and pagination (next_cursor always null). These are non-obvious behavioral details that help 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 three sentences with no redundancy. The first sentence states the core purpose, the second describes the data returned and ordering, and the third covers materialization and pagination. Every sentence carries meaningful information.

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

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

Given this is a simple list endpoint with one optional parameter, no output schema, and a readOnly annotation, the description covers all essential aspects: what data is included, the ordering, freshness, and pagination behavior. It is sufficiently complete for an agent to invoke and interpret results correctly.

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

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

The schema provides 100% coverage for the single `period` parameter, fully explaining the 30d/90d options and default. The description does not add further parameter-specific semantics, so the baseline score 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 opens with 'List provider SLA scorecards,' using a specific verb and resource, then elaborates on the exact contents (checks-weighted uptime, incident count, downtime minutes, worst host). This clearly distinguishes it from sibling tools like get_provider_sla_by_key, which would target a single provider.

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 for viewing all providers' SLA scorecards over a trailing period and notes the hourly materialization, which is useful context. However, it does not explicitly mention alternatives or when to prefer get_provider_sla_by_key for a specific provider, so the guidance is only implied.

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

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

The readOnlyHint annotation covers the safety profile, and the description adds behavioral detail: empty items when no SLA data exists and the structure of one scorecard per trailing period. This goes beyond the annotation, though it does not cover error responses or authentication specifics.

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

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

The description is compact and clearly structured, opening with the core verb and resource. The following sentences add distinct value: output periods, parameter source, and empty-items behavior. 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 single-parameter read-only tool, the description provides sufficient information to select and invoke it: purpose, key semantics, output structure, and no-data behavior. No output schema exists, but the description covers essential return semantics clearly.

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 enhances the parameter meaning by noting the key is the provider's natural key as reported by GET /v1/providers, adding a source reference beyond the schema's 'provider natural key'.

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 gets a provider's SLA scorecards, with specifics about trailing periods (30d and 90d). The 'by_key' designation and natural key reference make the resource and scope unambiguous, even without explicit sibling differentiation.

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 for when to use the tool: when retrieving SLA scorecards for a specific provider by natural key. It explains the output includes one scorecard per trailing period, but does not explicitly mention alternatives or 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.

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

With readOnlyHint=true already noting the read-only safety, the description adds valuable context: the tool requires no API key, returns a public subset, and the response shape matches a known list item. This goes beyond the annotation to disclose access requirements and data scope.

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

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

Two focused sentences, front-loaded with the core purpose, then concise clarifying details. Every word earns its place with 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 simple single-parameter read-only tool, the description is complete: it specifies the return shape, access requirements, and scope. No output schema exists, but the description sufficiently covers what the agent needs to select and invoke this tool.

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

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

Schema coverage is 100% and the parameter description 'The curated provider slug' is already in the schema. The tool description adds no further meaning about the slug, so it meets the baseline but does not elevate it.

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

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

The description clearly states the tool fetches a public provider profile, using the specific verb 'Get' and resource 'public provider'. It distinguishes from siblings like get_provider and list_public_providers by emphasizing it is the 'FREE, crawlable public subset' and 'same shape as a GET /v1/providers/public item'.

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 clear context: this is the public, no-API-key subset for a single curated provider, which implies use when unauthenticated public data is needed. However, it does not explicitly mention alternatives (e.g., use get_provider for full data) or state when not to use it, so it falls short of full alternative 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?

The readOnlyHint annotation already declares the tool as read-only. The description adds useful context about the provider mapping fallback (verified vs. cert-CN unverified) and that hosts are 'observed operating,' but it does not disclose additional behavioral aspects like error handling, authentication, or rate limits. This is a moderate addition over the annotation.

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

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

The description is concise, with just two sentences. The first sentence 'Get a seat' front-loads the action, and the second sentence provides essential context. No filler or redundant information is present.

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

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

For a simple read-only tool with one required parameter and no output schema, the description adequately describes the return value (provider and hosts). It is reasonably complete, though it could mention error cases or response structure explicitly. The absence of an output schema places more responsibility on the description, which it largely fulfills.

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

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

The schema provides 100% coverage for seatId with a clear description and example. The tool description does not add parameter-specific details, but it does explain what a seat is, indirectly aiding comprehension of the identifier. This meets the baseline for 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 states 'Get a seat' and then defines what a seat is: 'A Peppol certificate seat: its embedded provider (verified mapping or unverified cert-CN fallback) and the hosts it was observed operating.' This clearly identifies the resource and its unique characteristics, distinguishing it from siblings like get_provider or get_host.

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 no guidance on when to use this tool versus alternatives. It does not mention specific scenarios, exclusions, or when to prefer a different sibling tool, leaving the agent without explicit usage direction.

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 readOnlyHint=true, safety is already disclosed. The description adds behavioral context by specifying the trailing periods (30d and 90d) and that an empty items array is returned when the seat has no SLA data. This goes beyond annotations and provides meaningful return-behavior 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 extremely concise: three short sentences, front-loaded with the main purpose, and 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 simple one-parameter tool with no output schema, the description covers the purpose, parameter provenance, and return behavior (trailing periods, empty items). However, it does not describe the inner structure of a scorecard (e.g., fields like score or status), which would be helpful given the absence of an output schema. This minor gap prevents a 5.

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

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

The schema already fully documents seatId with a precise example. The description adds extra semantic value by explaining that seatId is the seat identifier as reported by `GET /v1/aps/{key}` on `seats[].seat_id`, which helps agents extract the value from another endpoint's response. This goes beyond the schema's basic type/description.

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

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

The description starts with 'Get a seat's SLA scorecards', a specific verb+resource that clearly distinguishes from sibling tools like get_seat or get_provider_sla. It further clarifies the scope by stating it returns one scorecard per trailing period (30d and 90d), leaving no ambiguity about what the tool does.

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 on when to use the tool (for a seat's SLA scorecards) and explains how to obtain the seatId via a specific endpoint, which is useful guidance. However, it does not explicitly mention alternatives or exclusion criteria (e.g., 'use get_provider_sla for provider-level SLA'), 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?

Annotations already provide readOnlyHint=true, and the description aligns by describing a read-only status snapshot. It adds transparency by disclosing the per-zone layout and the specific status fields, which goes beyond the annotation. However, it does not address potential errors or pagination, but this is reasonable for a zero-parameter read-only 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 exactly two sentences: the first gives the purpose, the second lists the content. It is front-loaded and every phrase earns its place, providing substantial information without fluff 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 no output schema and no parameters, the description compensates by itemizing the returned fields and the per-zone structure. It does not detail the exact JSON format or error behaviors, but for a simple read-only status helper, it provides a sufficiently complete picture for an agent to understand what to expect.

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-specific information to add. Per the rubric, a zero-parameter tool receives a baseline score of 4, as the description cannot contribute additional parameter semantics beyond what is inherently absent from the schema.

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

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

The description clearly states 'Get SML/SMK zone status' with a specific verb and resource, then elaborates the exact components returned (quorum verdict, canary breakdown, etc.). It distinguishes itself from sibling tools that target access points, hosts, or participants, making the tool's purpose unambiguous.

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

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

The description implies usage when the agent needs this specific status data, but it does not explicitly state when to use this tool over alternatives or mention any exclusions. There is no reference to sibling tools or conditions, so the agent must infer applicability from the resource name and contents.

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

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

Despite readOnlyHint already declaring the safety profile, the description adds substantial behavioral context: k=5 anonymisation, tail folding into 'other', two-denominator coverage, no bare coverage scalar, live computation, edge caching, keyless cacheability, and no operator naming. These details materially affect how the returned data must be interpreted.

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 purposeful: it opens with the subject, then explains the exact metrics, denominator treatment, computation method, and caching characteristics. Every clause supplies a meaning or caveat; only the issue number is mildly unnecessary.

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

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

With no output schema, the description carries the full burden of explaining the return meaning. It covers the metric set, k-anonymisation, denominator nuance, temporal characteristics, and caching. An agent has enough context to select and invoke the tool correctly.

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

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

The tool has zero parameters and schema coverage is 100%, so the description bears no burden for explaining inputs. The 0-parameter baseline applies: there is nothing meaningful to add 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 description clearly identifies the resource: a current 'Software landscape' of free host software, listing vendor share, version distribution, ASN hosting share, and coverage metrics. It does not use an explicit verb like 'returns' or 'lists', and it does not explicitly distinguish itself from get_software_stats_history, so it loses the top point.

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 text implies this is the current snapshotted landscape ('Computed live ... edge-cached'), which suggests use for current software stats rather than historical ones. However, it never names get_software_stats_history or gives explicit when-to-use/when-not-to-use guidance, so the usage context is only implied.

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

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

Beyond the readOnlyHint annotation, the description adds useful behavioral detail: it is computed in 'one windowed pass', grouped by UTC day, host-weighted, k-anonymised, and keyless-cacheable. These details help an agent understand performance, privacy, and response shape semantics.

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

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

The description is compact, front-loaded with the resource, and every sentence adds value. The heading 'Software landscape history' plus the explanatory sentence and cacheability note are sufficient without 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 read-only, two-optional-parameter time-series tool without an output schema, the description conveys the time granularity, the metrics, and the date defaults. It doesn't describe row counts, edge cases, or the exact JSON return shape, but an agent has enough context to invoke and interpret 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?

The input schema already fully documents both optional date parameters with defaults and formats. The description adds nothing new about parameter meaning, so the baseline score 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 the resource — 'software landscape history' — and the exact output semantics (per UTC day, host-weighted identified/total targets, k-anonymised vendor shares). It is clear enough to distinguish from the non-temporal get_software_stats sibling, though it never explicitly names that alternative.

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

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

The use case is implied by 'over time' and the tool name, but there is no explicit guidance about when to choose this over get_software_stats or other history tools. An agent can infer it is for historical trends, yet the description doesn't state boundary conditions such as 'current snapshot -> get_software_stats'.

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 readOnlyHint already supplied by annotations, the description adds valuable behavioral context: it is a 'public' rollup, so no authentication is implied, and it precisely defines the data scope. It discloses exactly what data is included and excluded, going well beyond the annotation's read-only hint.

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: a short title line followed by one dense sentence enumerating the contents and exclusions. Every phrase adds information, with no redundant 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?

The description fully covers what to expect from the tool (three data components) and what not to expect (host lists, registry, per-host uptime). Since there is no output schema, this enumeration is essential and fully sufficient for a no-parameter read-only 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 tool has zero parameters, so the description cannot add parameter-specific semantics. Per the rubric, a baseline of 4 is appropriate for no-parameter tools.

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

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

The description clearly states the tool retrieves the public dashboard summary and enumerates three specific data components: network-wide host rollup, hourly fleet-average p50 latency trend, and top-10 providers by market share. It also distinguishes itself from siblings by explicitly stating what is not exposed (no host list, full registry, or arbitrary per-host uptime), making its purpose unambiguous.

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

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

The description provides explicit usage context: it is a 'free marketing-dashboard rollup' for public summary data. It also gives a clear when-not by excluding host lists and per-host uptime, implying users should seek other tools for those details. This is sufficient guidance for selecting this tool over the many sibling get/list tools.

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

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

The description adds valuable behavioral information beyond the readOnlyHint annotation by stating 'Bounded to 500 rows (never paginated; next_cursor null)'. It also clarifies that the output consists of participant IDs, providing context about the return format. This enriches the agent's understanding without contradicting annotations.

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

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

The description is two sentences long, with the first sentence stating the core purpose and the second providing drill-down and limitation details. It is front-loaded, contains no filler, 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 read-only tool with 4 parameters and no output schema, the description covers the purpose, the drill-down logic, and the row limit/pagination behavior. It states that the result is participant IDs, giving return-value context. The absence of explicit parameter explanations is acceptable because the schema fully covers them, leaving only minor gaps.

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?

All parameters are fully described in the schema with 100% coverage, including inclusive date ranges, provider key, and category enum. The description references 'over the period' and 'Provider' but adds no additional parameter-level meaning, so it relies on the schema which already carries the burden.

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 'List participants' and clearly identifies the resource as 'behind a churn category' for a Provider over a period. It distinguishes itself from sibling tools like list_participants by focusing on the churn drill-down context, making the purpose unambiguous.

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

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

The phrase 'The drill-down' implies that this tool is used to expand a churn category count, but it does not explicitly state when to use this tool versus alternatives. No exclusions or alternative suggestions are provided, so usage guidance is only implied rather than explicit.

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

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

The description goes beyond the readOnlyHint annotation by disclosing the ordering (busiest first), the provider resolution precedence, and the lack of pagination. These are behavioral traits not conveyed by the annotation alone, providing valuable context for the agent.

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 information-dense, with every sentence serving a purpose. It is front-loaded with the core action and then provides essential details about the directory structure, ordering, and pagination behavior in a clear, structured manner.

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 lack of an output schema, the description sufficiently covers the return content (member seats, roster size), ordering, provider resolution, and pagination. It could be slightly more explicit about the exact output format, but the current level is adequate for a list tool.

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

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

With zero parameters, schema coverage is trivially 100%, and the description adds meaning by explaining what the tool returns and how results are ordered. The baseline for 0 params is 4, and the description adequately compensates for any missing parameter context.

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

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

The description clearly states the tool list all access points, defining them as a directory of every Provider in serving role with member seats and roster size, busiest first. This specific verb+resource combination distinguishes it from sibling tools like get_access_point.

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 context implies this is the canonical directory for all access points, suitable when a comprehensive listing is needed rather than a single lookup. However, it does not explicitly mention alternatives or when not to use it, such as when one specific access point is required (get_access_point).

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 readOnlyHint: true already in the annotations, the description adds valuable behavioral detail beyond the annotation: results are sorted newest-first and paginated via cursor. This is precisely what an agent needs to consume the feed correctly. It doesn't cover response shape or filter semantics, but those are secondary for a read-only 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?

Two sentences with zero filler. The 'newest-first, cursor-paginated' behavior is front-loaded right after the short verb+resource statement, giving the agent the most decision-relevant information first without any wasted words.

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

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

The description is adequate for a straightforward read-only listing where all parameters are self-documented, but it is thin in a few areas: no output schema exists, the description does not clarify whether the fully documented anomaly items (or a feed of metadata) are returned, and the combination semantics of multiple filters (e.g., host vs detector; AND or OR?) is left unexplained.

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 of 3 applies. All eight parameters are individually documented in the schema (host, seat, grade, limit, since, cursor, detector, acknowledged), and the description itself adds no parameter-level context that isn't already in the structured input.

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 ('List') and resource ('anomalies') and adds defining traits: the newest-first, cursor-paginated anomaly feed. This clearly distinguishes it from get_anomaly (single-item fetch), but it does not explicitly differentiate it from the similarly named sibling list_software_anomalies.

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

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

No explicit when-to-use guidance is provided. The description does not explain when to choose this over list_software_anomalies, get_anomaly, or other list tools, nor does it state the default feed scope or how filters should be combined. The usage context is only implied by the 'feed' phrasing.

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?

Given `readOnlyHint: true` already declares the safety profile, the description adds meaningful behavioral detail: cursor direction semantics, embedded triggered anomalies, and the meta block with facets and timeline chart. The description is consistent with the read-only annotation and enriches it with concrete pagination and payload context.

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

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

The description is four dense sentences with no filler. The core purpose is front-loaded, followed by pagination semantics, embedded anomalies, and meta information — each sentence adds necessary information.

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

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

The description is surprisingly complete for a 10-parameter list tool without an output schema: it covers ordering, pagination, anomaly embedding, and page metadata. It does not enumerate the exact event payload fields, but the 'typed change event' framing plus the schema's type enum lowers the cost of that omission. Still, an output schema or a more explicit event-shape summary would raise completeness further.

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 each parameter is already documented and the baseline is 3. The description adds value beyond the schema by explaining the different directions of `cursor` vs `prev_cursor`, the 'live polling' use case, and the meta block generated for the first page.

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, 'List global change events,' and key ordering behavior, 'newest-first.' It is clear and distinct from incident/anomaly-related siblings, although it doesn't explicitly name an alternative sibling for comparison.

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 conveys usage context through pagination direction: `cursor` walks older events, `prev_cursor` walks newer events and is 'for live polling.' However, it provides no explicit when-to-use vs when-not-to-use guidance or alternative tool names, so comparative selection is left to the agent's inference.

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

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

Annotations only declare readOnlyHint=true, and the description adds meaningful behavior: newest-first ordering and cursor-based pagination. This goes beyond the annotation and the schema to disclose how results are returned, though it does not mention details like auth or rate limits.

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

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

The description is two short sentences, front-loaded with the primary purpose and immediately followed by key behavioral details. Every word 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?

With five parameters all fully documented in the schema, the description provides the essential runtime behavior (ordering, pagination) not covered by the schema. Since there is no output schema, a brief note on return shape could improve completeness, but the current level is sufficient for a list operation.

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

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

The schema provides 100% parameter description coverage, so the description does not need to explain parameters. It adds no additional semantic meaning beyond what the schema already offers for the five parameters, matching 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 clearly states 'List a host's incidents', specifying the verb, resource, and scope ('for one host'). This distinguishes it from sibling tools like list_incidents (likely all incidents) and list_hosts (hosts themselves). The added 'newest-first, cursor-paginated' details further clarify 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 clear context that this tool is for retrieving incidents for a single specific host, which implies when to use it. However, it does not explicitly name alternatives or state when not to use it (e.g., for cross-host incident queries), so it lacks exclusions.

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

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

Annotations already declare readOnlyHint: true, so the safety profile is covered. The description adds valuable behavioral context by specifying exactly what is returned: current verdict, latest latency, 24h uptime, ordering (worst-first), and the network-wide rollup, which goes beyond the annotation.

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

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

The description is extremely concise: two sentences that front-load the core purpose ('List monitored hosts') and then add essential output details. Every sentence is informative with no wasted words.

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

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

For a simple list tool with no parameters and no output schema, the description provides comprehensive information about the return value: the fields, ordering, and inclusion of a rollup. It fully explains what the agent can expect, making it complete for its complexity.

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

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

The tool has zero parameters, so the schema provides no parameter semantics. The description correctly omits any parameter details. Baseline for 0 parameters is 4, and there is nothing to 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 clearly states the tool's purpose: 'List monitored hosts' with a specific verb and resource. It further distinguishes itself from siblings like get_host and get_network_summary by detailing the unique output: verdict, latency, uptime, worst-first ordering, and a network-wide rollup.

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 for obtaining a broad overview of all monitored hosts, including metrics and a rollup. It does not explicitly name alternatives or exclusions (e.g., 'for a single host, use get_host'), but the context is clear enough for an agent to select this tool when a comprehensive list is needed.

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

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

Beyond the readOnlyHint annotation, the description discloses aggregation behavior, exact row granularity, omitted fields, and stable pagination order. This is rich behavioral context that helps the agent anticipate what the response will and will not contain.

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

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

The description is well-structured and front-loaded, with essential semantics about output shape and pagination following the main action. It is slightly padded by repeating 'Market' at both the start and end, which prevents a perfect conciseness score.

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 paginated list with no output schema, the description defines the output row shape, pagination basis, optional filtering, and what is intentionally omitted. This is sufficient for an agent to select the tool and understand its behavior without needing 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?

All three parameters are already documented in the schema with 100% coverage, so the description need not re-explain them. It adds some nuance around the stable (hostname, role) ordering that underlies the cursor, but mainly restates the vendor filter and pagination already captured by the schema.

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

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

The description opens with a concrete verb and resource ('List all hosts' software') and defines the exact row shape: one row per (hostname, role) with vendor/version/hosting axes folded in. This clearly distinguishes it from singular get_host_software and history siblings.

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

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

The description gives clear usage context: a lean, cursor-paginated aggregate list with optional vendor filtering. It also implies an alternative path by noting the evidence blob is omitted and stays on the per-host resource, though it does not explicitly name the sibling 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?

Annotations already declare readOnlyHint=true, and the description adds useful behavior beyond that: the rows are closed/superseded, sorted newest-first, cursor-paginated, and each row represents one axis transition with evidence. This gives an agent meaningful context about what the call actually returns.

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

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

The description is short and front-loaded, with the core purpose in the first sentence and useful behavioral details following. The only structural weakness is the abrupt 'Market tier.' fragment, which is underspecified but does not bloat the overall description.

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 the essentials: one host, superseded rows, ordering, pagination, and row evidence. However, there is no output schema, and terms like 'axis transition' and 'Market tier' are vague enough that an agent may struggle to interpret the returned row contents.

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 each parameter already has a clear description: limit, cursor, and hostname. The tool description mostly reinforces the pagination and one-host scope but does not add materially new parameter-level 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 starts with a specific verb and resource: 'List a host's software-fingerprint history,' and then clarifies that it returns closed/superseded rows for one host. This distinguishes it from current-state tools like get_host_software, though it leaves 'axis transition' undefined.

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: when you need superseded software-fingerprint rows for a single host, newest-first. It does not explicitly name alternatives or state when not to use it, so the routing guidance is only implied rather than fully stated.

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

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

Annotations indicate readOnlyHint=true, and the description adds behavioral context by mentioning keyset-pagination on (scheme, value) and the presence of meta.facets on the first page. This goes beyond the annotation without over-explaining.

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-loaded with the purpose, and every clause adds value. It avoids repetition of schema details and focuses on non-obvious behavior.

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 there is no output schema, the description explains the pagination approach and the meta.facets structure, which is useful. It doesn't detail the exact fields of each malformed identifier, but the phrase 'individual identifiers' gives a reasonable hint. Overall, it's complete enough for a list/filter tool with well-documented 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 description coverage is 100%, so all parameters already have descriptions. The tool description does not add additional parameter semantics, but it implicitly relates cursor and limit to the pagination strategy, which is marginal value. 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 lists malformed participant identifiers, defines what those are ('identifiers that failed their scheme's structural rule'), and distinguishes it by introducing the pagination and facets. The verb 'list' and resource are specific, differentiating it from sibling tools like get_id_quality.

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 for use: it's for viewing malformed identifiers, with keyset pagination and facet counts for analysis. It does not explicitly state when not to use or name alternatives, but the context is strong enough that an agent can infer appropriate use cases.

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

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

The readOnly annotation already signals safety, and the description adds useful behavioral details: global scope, newest-first ordering, and cursor pagination. This goes beyond the annotation and helps the agent understand the tool's operational behavior without needing to inspect schema details.

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

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

The description is extremely concise, front-loading the purpose ('List incidents') and adding only essential qualifiers in a compact form. Every word earns its place, making it easy to parse quickly.

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 read-only annotation, complete schema, and simple list operation, the description provides adequate context for invocation: it names the global feed, ordering, and pagination. It does not describe the return structure, but since there is no output schema, this is a minor gap; overall, the tool is well contextualized.

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 covers all parameters thoroughly (100% coverage), so the description adds little parameter semantics. The description's 'newest-first' and 'cursor-paginated' align with the limit and cursor parameters, but these are also inferred from the schema, so no extra value beyond 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 clearly states the tool lists incidents, with specific qualifiers: global feed, newest-first, cursor-paginated. This distinguishes it from sibling list_host_incidents by emphasizing the global scope, making the purpose unambiguous.

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

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

The description provides clear context: it is the global incident feed, so the agent knows to use this for all incidents. It does not explicitly exclude alternatives or mention host-specific listing, but the 'global' qualifier alone implies the appropriate use case.

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

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

Annotations already provide readOnlyHint=true, and the description adds useful behavioral details: events are 'newest-first' and 'cursor-paginated'. This goes beyond the annotation by specifying ordering and pagination style.

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: the first states the purpose, the second provides key behavioral details. No filler or redundant information.

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

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

For a simple read-only list tool with well-described parameters and annotations, the description provides adequate context (ordering, pagination, scope). It could mention the response shape but 'change events' is sufficient for a list tool.

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

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

Schema descriptions cover 100% of parameters (id, limit, cursor) with clear meaning. The description adds little beyond referencing pagination (cursor-paginated), which is already implied by the schema's cursor parameter.

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 ('List') and the specific resource ('a participant's change events'), which distinguishes it from sibling tools like get_participant_history or list_events. The additional phrase 'typed change events' further narrows the scope.

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

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

The description implies usage for participant change events but does not explicitly state when to use this tool versus alternatives such as list_events or get_participant. No exclusion or alternative guidance is provided.

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

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

The description goes far beyond the readOnlyHint annotation. It discloses pagination style (keyset), default sort, filter interactions (e.g., host alone forces identifier ordering, discovered participants lack name/card fields), and meta behavior (filter_count may return null on timeout). This adds critical behavioral context the annotation alone cannot provide.

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 and comprehensive, but every sentence earns its place. It is front-loaded and well-structured. However, it could be slightly tighter (e.g., grouping some filter notes) to improve readability without losing 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?

Given 19 parameters, no output schema, and only a readOnlyHint annotation, this description is remarkably complete. It covers pagination, sorting, all filter behaviors, special cases, meta details, and privacy constraints. There are no obvious gaps for an agent to use 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?

With 100% schema coverage, the baseline is 3, but the description adds substantial value. For example, it explains the smart search logic for q, the special ordering constraints when host/doctype/transport_profile are used alone, and the role of each filter. This vastly exceeds the schema's parameter descriptions.

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

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

The description opens with 'List participants' and immediately clarifies the scope—'The participant set, keyset-paginated'—and enumerates sorting, filtering, and edge cases. This clearly distinguishes it from sibling tools like get_participant (single entity) or list_participant_events (events for a participant).

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 thoroughly explains the tool's behavior but never explicitly states when to use it versus alternatives (e.g., when to prefer get_participant or list_participant_events). Usage is implied through the feature set, but there is no 'when not to use' or direct comparison to 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?

The readOnlyHint annotation already signals a safe read operation, and the description adds valuable context about the specific content returned (per-Seat counts, expiries, identity shifts). It does not discuss pagination limits or error cases, but for a read-only aggregate tool this is acceptable.

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 one well-formed sentence with a clear subject and a structured list of outputs. It packs substantial detail without redundancy, though the list is slightly long; still, each item earns its place.

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

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

With no output schema, the description carries the responsibility of explaining the return payload, and it does so thoroughly by listing all components (cert counts, expiry thresholds, organisations, identity shift). Given the tool's single-parameter simplicity and read-only nature, the description is sufficiently 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?

The single parameter 'slug' is fully described in the schema as 'The curated provider slug', which makes the schema coverage 100%. The tool description adds no additional parameter-level detail, so it relies on the schema as 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 uses a specific verb ('Get') and a specific resource ('provider's certificate posture'), and enumerates the exact data returned. It clearly distinguishes this tool from siblings like get_provider or get_network_summary by focusing solely on certificate-related metrics.

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

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

The phrase 'whole-fleet certificate posture in one call' implies this is the go-to tool for a consolidated cert summary, and the detailed output list makes its use case obvious. It does not explicitly mention when not to use it or point to alternatives, 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?

Beyond the readOnlyHint annotation, it discloses that results are not paginated ('next_cursor' is always null) and are ordered busiest first. These are non-obvious behavioral details that help the agent correctly process the response.

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: a clear title and a dense, efficient second sentence covering contents, ordering, and pagination. Every word earns its place.

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

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

Despite lacking an output schema, the description covers key aspects: data returned, ordering, and pagination behavior. This is sufficient for an agent to understand what the tool does and what to expect.

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 the schema provides no semantic information. The description compensates by detailing what the returned list contains, meeting the baseline expectation for a no-parameter 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 it lists providers from the OpenPeppol member registry with specific attributes (role flags, country, hostnames, participant counts), distinguishing it from sibling list tools. The verb 'List' and resource 'providers' are explicit.

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

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

The description provides clear context on what the tool returns, implying it is for obtaining a comprehensive provider registry view. It does not explicitly contrast with alternatives, but the detailed content makes selection obvious.

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

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

Beyond the readOnlyHint annotation, the description discloses several behavioral traits: results are 'busiest first', 'Not paginated' with next_cursor always null, limit clamping to [1,500], and the 'as_of' freshness stamp. It also reveals access requirements ('no API key').

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 efficient; the opening phrase identifies the tool, followed by a structured list of returned fields and two key behavioral notes. No wasted words.

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

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

With one optional parameter and no output schema, the description provides a thorough enumeration of the returned fields, ordering, pagination, and authentication requirement, making it sufficient for an agent to invoke 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 fully describes the single limit parameter (default, min, max), so schema coverage is 100%. The description restates the clamp behavior but adds no new parameter-level semantics beyond what the schema already states, warranting the baseline score.

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 'List public provider profiles', a specific verb+resource. It distinguishes from sibling list_providers by emphasizing 'FREE, crawlable public subset' and 'Reachable with no API key', making clear this is the unauthenticated public variant.

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 clear context that this is for public, crawlable data without an API key, implying use when no auth is desired. However, it does not explicitly name sibling alternatives like list_providers or state when not to use this tool, so it stops short of full exclusion guidance.

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

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

Annotations only declare readOnlyHint=true, so the description carries full responsibility for behavioral disclosure. It reveals crucial non-obvious traits: pagination is always disabled ('next_cursor is always null'), participant_count may be null for hostnames outside the top-N facet (not zero), and provider resolution uses a specific precedence mapping identical to /v1/aps. This is rich context beyond what annotations provide.

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 appropriately sized given the tool's complexity. It front-loads the core purpose in the first two words and then each sentence adds unique value: inclusion criteria, count semantics, provider resolution, and pagination behavior. No sentence is wasted, and the structure flows logically from definition to edge cases.

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

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

Despite having no output schema, the description thoroughly explains what the tool returns (hostname, seats, provider, participant_count) and how those fields are derived. It also covers edge cases like null counts and non-pagination. Given the two optional parameters and read-only nature, the description is complete and leaves no significant questions about behavior.

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

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

Schema coverage is 100% and both parameters (q and limit) are already fully described in the input schema (case-insensitive substring filter, cap on rows, defaults). The description adds no additional parameter semantics; it focuses on result interpretation and ordering rather than parameter behavior. Thus the baseline score 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 opens with a clear verb and resource: 'List SMPs'. It then specifies exactly what is listed: 'every current SMP hostname with the seat(s) and provider that sign its metadata, busiest first.' This distinguishes it from sibling list tools like list_hosts and list_providers by focusing on the SMP-specific directory.

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 for when to use this tool: when you need the SMP directory or need to see which hostnames currently home participants or carry signing certificates. It does not explicitly name alternatives or exclusions, but the scope is well-defined, which effectively tells the agent when this tool 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?

The readOnlyHint annotation already declares the tool is a safe read, so the description only needs to add context. It satisfies this by explaining which detectors are included, that both are graded 'notice', and that the output 'has the same shape as the general /v1/anomalies feed'. It reveals encoding/scoping behavior beyond the schema without contradicting the annotation.

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

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

The description is compact: one summary sentence, one scoping sentence with spec reference, and one sentence clarifying carve-out and feed shape. Every sentence earns its place, useful information is front-loaded, 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?

For a read-only list tool with no required parameters and 100% schema coverage, this description is nearly complete. It also covers output shape by pointing to the general feed and the knowledge gap about which detectors/feed are relevant. It leaves some interpretation of 'market carve-out' in jargon, and relies on the reader knowing the general feed's response shape, but these are minor in practice.

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 all 8 parameters with 100% coverage, so the description is not required to add parameter-level detail. It does add limited context, such as 'both graded notice' informing expectations around the grade filter, but it does not meaningfully enrich the schema beyond that. Baseline 3 is appropriate while the structured schema carries the load.

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 clear verb and resource: 'List software anomalies', then narrows the scope precisely to the software-fingerprinting anomaly feed: version downgrades and vendor swaps. It distinguishes itself from sibling list_anomalies by explaining this is a market carve-out for detectors the general network-anomaly feed excludes.

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 tells the agent when this tool is the right one: software-specific anomalies from the fingerprinting feed. It also explains that the general /v1/anomalies feed is for network anomalies and excludes these detectors, which effectively gives a when-not-to-use signal. It could be stronger by naming list_anomalies as the alternative explicitly, but the carve-out language is sufficient guidance.

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