API Status Check

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

With no annotations, the description must disclose behavior. It clearly states this tool performs a live probe at call time and returns a status plus response time, which is critical behavior beyond the schema. However, it does not mention potential side effects like latency or rate limiting, leaving minor 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 two sentences long, front-loaded with the core action and result, then immediately provides a practical usage example. Every word adds value with no waste 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 simple, real-time probe tool with one parameter and no output schema, the description is complete: it explains the return values (up/degraded/down, response time), the live nature, and the use case. No important context is missing.

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

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

Schema coverage is 100% and the single parameter 'slug' is already well-described in the schema with an example and reference to search_apis. The description does not add parameter-level details, but the schema fully covers it, so the baseline of 3 is appropriate.

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

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

The description uses the specific verb 'probe' and clearly identifies the resource ('monitored API endpoint') and the action ('return up/degraded/down with the response time'). It explicitly distinguishes itself from sibling tools by contrasting with 'reading the hourly cache,' 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 provides direct usage guidance: 'This is the tool to reach for when a user asks "is X down?"' and explicitly notes it 'makes a real request rather than reading the hourly cache,' which implies when not to use it (when a cached answer is acceptable). This effectively differentiates from sibling tools like list_down_apis.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It explains data retention (30 days), the impact of recently added APIs (few/null data points), and clarifies that null percentages are expected rather than 100%. This adds valuable context beyond the schema, though it stops short of describing return structure or potential errors.

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, front-loaded with the core output (uptime percentages, response-time stats, data points) and followed by a valuable caveat about retention. No words are wasted, and every sentence contributes to understanding the tool's behavior.

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

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

Given the tool's simplicity (2 parameters, no output schema), the description provides sufficient context for basic use. It covers what the tool returns and a key edge case (null percentages for recent APIs). However, it leaves some ambiguity about the exact format of response-time stats and does not explicitly state the default range, which the schema handles. Overall, it is complete for typical usage.

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

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

The input schema already provides 100% coverage of both parameters (slug and range), so the description adds minimal semantic value. It mentions 'one API' and 'time range', which map to the parameters, but does not elaborate on allowed values or defaults beyond what the schema's enum and descriptions already state. 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 that the tool returns uptime percentages, response-time stats, and recorded data points for one API over a time range. This specific verb-resource pairing distinguishes it from siblings like get_api_status (which likely returns current status) and list_apis (which lists APIs), making its purpose unmistakable.

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 the tool is for historical uptime data but does not explicitly mention when to use it over alternatives like get_api_status or list_down_apis. It provides no exclusions or alternative recommendations, though the context of 'history' and 'one API' gives a reasonable hint. This is adequate but lacks explicit 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?

No annotations are provided, so the description carries the full burden. It discloses that statuses are from the most recent hourly monitor run, not a live probe, which is key behavioral context. The verb 'List' also implicitly indicates a read-only 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, front-loaded with the verb 'List', and no filler. The caveat about data freshness adds value without bloating the description.

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

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

For a simple list tool with no output schema, the description conveys purpose, optional filtering, and a critical data freshness caveat. Sibling tools are easily distinguishable, making the description sufficient for tool selection.

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

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

Schema description coverage is 100%, with both parameters already described. The tool description only reiterates the category filter without adding new syntax or behavior 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?

Description states it lists APIs and developer platforms with optional category filtering, using a specific verb and resource. This clearly distinguishes from siblings like get_api_status (specific status) and list_down_apis (only down services).

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 clarifies the data freshness caveat ('not a live probe'), implying when it is appropriate to use. It doesn't explicitly name alternatives, but the context is clear enough for a list tool.

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

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

No annotations are provided, so the description carries the full burden. It states the output (slugs and counts) but does not explicitly confirm it's read-only, nor does it mention ordering, pagination, or error behavior. For a trivial listing tool with no parameters, a 3 is appropriate as the description gives basic transparency but lacks explicit safety or behavioral 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 two sentences with no wasted words. The first sentence states the return value, and the second gives usage direction. Every word contributes to the intended meaning, making it highly efficient.

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 simplicity (zero parameters, no output schema, read-only by nature), the description fully covers the return value and provides a usage context via the sibling tool reference. There is no additional complexity requiring more 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 input schema has zero properties, so there are no parameters to document. According to the rubric, a 0-parameter tool gets a baseline of 4. 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 returns 'Category slugs and how many monitored APIs sit in each', specifying both the resource (categories) and the output (slugs and counts). This distinguishes it from sibling tool list_apis, which lists APIs rather than categories. The verb 'List' is implicit in the name and title, 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 explicitly instructs to 'Use the slugs with list_apis', giving a concrete workflow context and a reason to call this tool. It does not state exclusions or alternative scenarios, but for a simple zero-parameter listing tool, this provides clear usage 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?

No annotations are provided, so the description carries full responsibility. It discloses a key behavior: an empty list can indicate a missing or stale snapshot, not health, and directs users to check monitorLastRun. This adds meaningful context beyond the tool name.

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

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

The description is two sentences long and front-loads the core purpose, followed by a necessary caveat. Every clause earns its place and no 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, parameterless list tool, the description explains the data source (monitor run), the scope (all categories), and the critical caveat about empty lists and stale snapshots. This is complete for the tool's 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 and schema coverage is complete, so there is nothing to compensate for. The baseline for zero-parameter tools is 4, and the description adds no parameter-specific information, which is acceptable.

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?

Clearly states the tool lists everything found down or degraded in the most recent monitor run, across all categories. The verb is implied by the name, and the description distinguishes it from sibling tools by specifying the monitor-run 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 provides context about the most recent monitor run and warns about empty lists when the snapshot is stale, which helps interpret results. However, it does not explicitly direct users to alternatives or state when to use this tool over list_apis or get_api_status.

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

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

With no annotations, the description carries the full burden of behavioral disclosure. It clearly implies a non-destructive search operation, but it does not disclose the return format, whether results are exact or fuzzy matches, or pagination behavior. This leaves some behavioral ambiguity.

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

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

The description is two sentences, front-loaded with the core action and resource, and the second sentence provides practical context without waste. It is compact and informative.

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 search tool with 100% schema coverage and no output schema, the description is sufficient: it states what is searched, the resolution purpose, and the limit parameter is already documented. Sibling tools provide additional context. The main gap is a lack of detail about the result structure, but that is not critical for selection.

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%: both 'query' and 'limit' are described with examples, defaults, and constraints. The description adds that query can match name/slug/category/description, which reinforces the schema but doesn't add new parameter semantics. This is the baseline 3.

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 ('Find') and the resource ('monitored APIs'), and enumerates the searchable fields (name, slug, category, description). It also distinguishes the tool from sibling list tools by explaining that it resolves a product name into the slug used by other tools.

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

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

The description explicitly says 'Use this to resolve a product name the user mentioned into the slug the other tools take,' which gives a concrete use case and implies that alternatives require the slug. However, it doesn't explicitly name sibling tools or state when not to use it, 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.