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?

The description goes well beyond the readOnlyHint annotation by explaining suppression rules for low counts, the non-suppression of denominators, caching behavior, and the specifics of region/sector codes. This proactive disclosure of data quirks and limitations is excellent and fully consistent with 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 dense but efficient, using four sentences to cover purpose, content, coding, suppression, and caching. Every sentence carries meaningful detail without repetition. It is slightly longer than strictly necessary, but the complexity of the returned object justifies the length.

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 fully compensates by explaining the return structure (headline totals, cuts, trend), including edge cases (suppression of small cells), and operational details (caching). It provides enough information for an agent to understand what will be returned and how to interpret it, making it highly complete for a one-parameter read 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 schema fully documents the single 'country' parameter with an enum and description (100% coverage), establishing a baseline of 3. The description adds valuable semantic context by explaining country-dependent behavior (FR-only size class, different region code standards for BE vs FR), which enriches understanding beyond the schema alone.

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

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

The description begins with 'Get a country's adoption aggregates', clearly specifying the verb and resource. It details the contents of the returned object (headline totals, cuts, trend) and is unambiguous among siblings, none of which handle adoption. This distinctly establishes the tool's purpose.

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

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

While it does not explicitly name alternatives or exclusions, the description provides clear context: it is for a single country's adoption aggregates. Since no sibling tool covers adoption, the intended use case is evident. The absence of explicit when-not-to-use guidance prevents a 5, but the context is strong.

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

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

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?

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?

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?

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?

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 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, so the safety profile is clear. The description adds valuable behavioral details: data comes from daily snapshots of the rollup, history accrues from the feature ship date, and it is keyless-cacheable. This goes beyond the annotation and helps set expectations about data availability and caching.

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 concise: a short title followed by two sentences that convey the core purpose, data source, and a noteworthy caching property. 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?

The tool has no output schema, so the description helps by indicating the return is a daily time series. With annotations covering safety, schema covering parameters, and the description providing context about data provenance and history start, the description is fairly complete for a read-only history tool. It could detail the output structure more, but the use case is sufficiently clear.

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

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

Schema description coverage is 100%, so the schema already documents all five parameters. The description adds minimal extra meaning beyond the schema, only briefly reinforcing that the dimension is a 'facet' and that the result is a time series. Since the baseline for high schema coverage is 3, this 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 provides a daily time series over a participant facet dimension, with examples like adoption curves and QoQ trends. It distinguishes this from sibling tools like get_participant_stats (current stats) and get_participant_history (likely a different history), though it does not explicitly name alternatives.

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

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

The description provides clear usage context: use this to obtain daily time series data for a specific facet dimension, with history starting from the feature ship date. It does not explicitly state when not to use it or mention alternatives, but the context is sufficient for appropriate selection.

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

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

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?

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?

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?

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?

The description adds behavioral context beyond the readOnlyHint annotation by noting 'newest-first, cursor-paginated' behavior. However, it doesn't disclose other aspects like whether output is limited to defaults or if filters are exclusive, so it's modest value-added.

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 and front-loaded: 'List anomalies' followed by one sentence of behavioral detail. It contains no filler or repetition, earning full marks for efficiency.

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 8 parameters, no output schema, and a minimal description, the tool is usable but not complete. The description tells it's a feed but doesn't explain return structure or default behavior (e.g., all anomalies when no filters). Adequate but with gaps given the lack of 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?

Input schema covers all 8 parameters with descriptions (100% coverage), so the description doesn't need to add parameter details. The tool description contributes no extra parameter semantics beyond what's in the schema, keeping this at 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 anomalies, with additional details about ordering and pagination ('newest-first, cursor-paginated'). This makes the purpose specific, though it doesn't explicitly distinguish from sibling tools like get_anomaly beyond the plural resource name.

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 guidance is provided about when to use this tool versus alternatives. It doesn't mention, for example, using get_anomaly for a single anomaly or how list_anomalies differs from list_incidents or list_events.

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 safety is covered. The description adds meaningful behavior: newest-first ordering, cursor-paginated, anomalies embedded, cursor vs prev_cursor directionality, and the meta block on the first page. This is substantial 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?

Three sentences, front-loaded with the core action, each sentence adds distinct value (scope/ordering, cursor behavior, first-page metadata). 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?

The description covers the key aspects needed to use the tool: pagination, filtering capability, event embedding, and response metadata. The absence of an output schema is partially compensated by mentioning the meta block and embedded anomalies. It doesn't exhaustively document event fields, but that may be beyond the description's role.

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 9 parameters have schema descriptions (100% coverage), so baseline is 3. The description adds specific semantics for cursor and prev_cursor (walks older vs newer edge), and mentions the meta block which relates to the response, not parameters directly. This elevates it above 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 opens with 'List global change events' – a specific verb and resource. It distinguishes from sibling tools like list_participant_events by emphasizing 'global' and 'Every typed change event', and the pagination scope is 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 implies global scope and explains cursor mechanics for live polling, but it does not explicitly name alternatives or state when not to use this tool. The usage context is clear, but no exclusions 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 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?

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?

Beyond the readOnlyHint annotation, the description discloses key behaviours: keyset pagination, default sort order, sort being ignored under certain filter combinations, meta.filter_count degrading to null on timeout, and privacy-discovered participants lacking name/card fields. These are rich, non-obvious traits.

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

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

The description is front-loaded with the purpose, then organized into focused sentences covering pagination, filters, q semantics, meta behavior, and privacy. Every sentence adds specific value without redundancy, making it dense yet readable.

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 12 parameters and no output schema, the description covers the major operational and behavioral aspects: filters, pagination, sort caveats, metadata, and privacy. It does not enumerate the default participant object fields, but the privacy note implies the expected shape, and the tool is a list endpoint where the entity is known.

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% parameter coverage, so the baseline is 3. The description adds extra semantics: the smart q behavior (ID index vs trigram name-contains), the sort interaction with doctype/transport_profile, and the meaning of meta.filter_count. This goes 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 'List participants', a specific verb and resource. It clearly indicates this tool lists the participant set, but it does not explicitly distinguish itself from sibling tools like get_participant or 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: a keyset-paginated list with many filters and a default sort order. It implies use for listing participants, but does not explicitly state when to use it over alternatives or exclude cases like fetching a single participant.

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?

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.