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

No annotations are provided, so the description carries the full burden. It discloses what the tool reports (coverage and freshness metrics) and implies read-only behavior since it merely reports status. But it doesn't state that this is a read-only operation, doesn't mention any auth requirements or side effects, and doesn't describe the return shape or whether it aggregates data in real-time. It's partially transparent but leaves gaps.

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

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

The description is a single compact sentence that lists the key metrics in a clear, scannable way. It front-loads the core purpose ('Coverage and freshness of the underlying dataset') and then enumerates specifics. Slightly dense with the colon-list, but efficient and 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 zero-parameter, read-only reporting tool, the description covers the essential context: what data it reports. It doesn't explain the return format or any caveats about how metrics are computed, but with no output schema, the agent might need more detail on response structure. Given the tool's simplicity, this is adequate but not 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?

This tool has zero parameters, so the description doesn't need to explain parameter meanings. The description focuses entirely on what the tool returns, which is appropriate. Baseline is 4 for 0-param tools, and the description adds value by detailing the reported metrics.

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 that this tool reports the coverage and freshness of the underlying dataset, and enumerates the specific metrics it returns: vendors mapped, machine-readable feeds, incidents on record, recent incidents, platform breakdown, poll cadence, license, and bulk downloads. This distinguishes it from sibling tools like vendor_status and vendor_incidents, which are vendor-specific rather than dataset-wide. However, it doesn't explicitly name the sibling it is not, so it loses one 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 description implies when to use this tool: when you need dataset-wide coverage and freshness metrics, rather than per-vendor status. But it doesn't explicitly state when not to use it, or name alternatives like vendor_status or vendor_incidents. Usage guidance is present but implied, not 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?

No annotations are present, so the description carries the full burden of behavioral disclosure. It explains what data is returned (status page URL, platform, feed existence, newest poll state) and implies a cached map lookup, but it doesn't state read-only behavior, error/no-match handling, or whether any external calls are made.

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 dense sentences: the first states purpose and output fields, the second gives a usage heuristic. There is no filler, and the most important action ('Resolve', 'Use this first') 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?

With no output schema, the description compensates by listing the key return fields. It covers the tool's purpose and when to use it, though it doesn't mention no-match behavior or result formatting, which would make it fully 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 describes both parameters fully (query examples and limit range/default), giving 100% schema coverage. The description adds 'name, slug or status-page domain' and mentions limit indirectly, but doesn't materially go beyond the schema, 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 uses a specific verb ('Resolve') and names the resource ('entry in the 1,100+ vendor status-page map') plus the exact fields returned. It also distinguishes itself from sibling tools by positioning itself as the first-step lookup for unknown slugs.

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

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

The description explicitly says 'Use this first when unsure of the exact vendor slug,' giving clear when-to-use guidance. It doesn't name alternative tools or provide explicit when-not-to-use conditions, but the 'first' directive implies it precedes the sibling status/incident 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?

With no annotations, the description carries the full behavioral burden. It discloses keyless access, direct polling, conditional availability of RSS/Atom, and the inclusion of normalized history JSON. It does not cover failure/not-found behavior or clarify whether the history JSON is a URL or the data itself.

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 the subject front-loaded; the em-dash enumeration packs useful detail without padding. The closing phrase 'for the vendor' is mildly redundant, but no sentence is wasted.

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

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

For a one-parameter tool with no output schema, it lists the returned endpoint categories and the no-key workflow, covering most practical needs. But the exact response shape is unspecified, and ambiguity remains about whether normalized history JSON is a URL or the content itself.

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 the single vendor parameter, so baseline 3 applies. The description's phrase 'one vendor' is consistent but adds no meaningful semantic detail 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 what the tool returns: machine-readable status-page endpoints (summary JSON, incidents JSON, RSS/Atom) plus normalized history JSON, scoped to one vendor. This distinguishes it from siblings like vendor_incidents and vendor_status by emphasizing raw feed URLs rather than interpreted status 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?

It gives a concrete use case—polling a vendor directly without an API key—which helps an agent recognize when this tool is relevant. However, it does not explicitly contrast it with sibling tools or state when not to use it, leaving the routing somewhat 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?

No annotations are provided, so the description carries the burden. It discloses that histories vary in depth ('weeks to years depending on what the vendor's page exposes') and that data is sourced from the vendor's status page, which implies external variability. However, it does not mention pagination behavior, rate limits, or what happens when a vendor is not found.

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 no wasted words. The first sentence front-loads the core purpose and output fields; the second adds a useful caveat about data availability. 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 list tool with a fully documented schema, the description covers the essential context: what data is returned, ordering, and the variability of history depth. It lacks explicit notes on error cases or pagination, but these are minor given the tool's simplicity and the schema's completeness.

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

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

Schema description coverage is 100%, so the schema already documents all four parameters. The description adds context about the data source and ordering but does not add meaning beyond the schema for individual parameters. 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 returns one vendor's incident history as posted on its status page, with specific fields (title, state, impact, timestamps, update text, URL) and ordering (newest first). This distinguishes it from siblings like vendor_status (current status) and vendor_resolution_times (aggregated metrics).

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

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

The description implies this is for historical incident data from a vendor's status page, which differentiates it from vendor_status (current status) and vendors_down_now (current outages). It does not explicitly name alternatives or state when not to use it, but the scope is clear enough for an agent to select it appropriately.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It adds substantial context: data is computed from the vendor's own posted start and resolve timestamps, maintenance and inferred resolutions are excluded, and the exact metrics are enumerated. It stops short of describing return format, error behavior, or freshness, but the core behavioral profile is well disclosed.

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?

One dense sentence front-loads the purpose, enumerates the metrics, and then adds the important non-uptime caveat. Every element earns its place, and there is no filler or redundant restating of the tool name.

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

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

For a one-parameter tool with no output schema, the description covers the returned metric set, the data source, exclusions, and intended interpretation. An agent can safely invoke it for the right vendor and correctly interpret the returned values, so nothing critical is missing.

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

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

The single 'vendor' parameter is fully documented in the schema (name, slug, or status-page domain), so schema coverage is 100%. The description reinforces that the data is scoped to one vendor's incidents but adds no new parameter-level semantics beyond what the schema already provides.

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

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

The description uses a specific, informative framing: it quantifies how long incidents take to be resolved徒, enumerates the exact metrics (median, p90, count, max), and explicitly distinguishes itself from uptime/SLA tools. This differentiates it from sibling tools like vendor_status, vendor_incidents, and vendors_down_now without needing to inspect their schemas.

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

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

The description establishes the domain clearly: use this when you need one vendor's incident resolution duration metrics computed from posted timestamps. It also gives an explicit when-not signal ('Not an uptime or SLA number'), but it does not name sibling alternatives such as vendor_incidents or vendor_status, so the guidance is clear but not fully explicit about routing.

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

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

With no annotations, the description carries the behavioral disclosure burden. It explains selection criteria (not fully operational), ordering (major, partial, degraded, then maintenance), time scope (newest poll), and aggregation (counts by state). It does not explicitly state read-only behavior, but the query-like wording strongly implies a safe read operation.

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

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

Two sentences with no filler: the first packs selection, ordering, and aggregation; the second states the intended user query. All key details are front-loaded and every sentence earns its place.

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

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

For a read-only tool with four optional parameters and 100% schema coverage, the description gives sufficient invocation context. Since there is no output schema, a brief sketch of the response shape would make it more complete, but the core selection, ordering, aggregation, and use case are all present.

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

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

Schema descriptions cover all 4 parameters, so the baseline is 3. The description reinforces the state vocabulary and the notion that maintenance is included, but it does not add meaning beyond what the input schema already provides.

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

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

The description clearly defines what the tool returns: vendors not fully operational in the newest poll, sorted worst-first, with counts by state. The scope 'across all polled vendors' distinguishes it from single-vendor tools like vendor_status and from incident-detail or feed tools in the sibling list.

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

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

It gives an explicit use case: 'which SaaS vendors have incidents right now'. However, it does not name alternatives or state when not to use this tool, so some routing burden is left to sibling descriptions.

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

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

With no annotations, the description carries the behavioral disclosure burden. It covers the polling cadence, staleness, and the exact fields returned. It omits edge-case behavior such as handling unknown vendors, but for a read-only status lookup the key traits are disclosed.

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 no filler. The result is front-loaded, the status values are compactly enumerated, and the important daily-poll caveat is included without 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 one parameter and no output schema, the description lists the returned fields and possible status values, which is enough for basic invocation. It could clarify behavior for an unknown vendor, but the input schema's 'name, slug or status-page domain' already covers flexible lookup.

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

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

The schema already documents the single parameter at 100% coverage, so the description does not need to repeat it. The description adds no extra parameter semantics beyond what the schema provides.

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

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

The description names the exact resource ('one vendor'), the data source ('newest daily poll'), and the status vocabulary, making the tool's purpose unmistakable. It also implicitly distinguishes itself from plural or incident-focused siblings like vendors_down_now and vendor_incidents.

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 explicitly warns that this is a daily poll, not a live probe, which tells an agent not to use it for real-time checks. It does not name a specific alternative tool, so the routing guidance is clear but not fully explicit.

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