Uptimepage

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

Annotations already declare readOnlyHint=true, and the description reinforces it with 'Read-only.' The description adds behavioral context by specifying the time window options (1h/24h/7d/30d) and the type of data returned (every declared step, failure step, page). This adds value beyond the schema and annotation without contradicting them. No hidden side effects are mentioned, but the bar is met given 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 sentences, with the first packing all essential facts about the resource, data, and scope, and the second giving a practical use case. There is no redundant or filler language; every phrase contributes.

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 an output schema present, the description need not detail return formats. It explains what the tool returns conceptually, the windows, the monitor type, and a motivating use case. For a two-parameter read-only tool, this is complete.

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

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

The input schema already provides descriptions for both parameters with 100% coverage. The description only restates the window choices and confirms the id must be a flow monitor (already in the schema). No additional parameter semantics are added, 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 noun phrase ('A browser flow monitor's recent runs') and details the contents (steps, outcomes, durations, failure step, page). It clearly specifies the resource (flow monitor runs) and the action (get). It also distinguishes from siblings by focusing on recent runs with failure details, and even offers a concrete use case ('why a login check failed').

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 a clear context for when to use the tool: 'Use this to answer why a login check failed.' It implies this is the diagnostic tool for inspecting individual runs and step outcomes. However, it does not name alternative tools or specify exclusions, so it falls short of full alternative guidance.

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

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

In addition to the read-only annotation, the description discloses the exact output semantics: per-step earliest/latest mean duration, ratio, and pass/fail run counts. It also notes the window values (1h/24h/7d/30d), making the tool's behavior more transparent 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 two sentences, front-loading the core purpose and then the use case. Though the first sentence is dense, every clause adds value and there is 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?

Given a 2-parameter read-only tool with an output schema, the description is quite complete: it explains the kind of analysis, the exact metrics returned, and the intended diagnostic use. It does not cover edge cases like empty data, but the output schema likely addresses return structure, and the tool is simple enough that this is sufficient.

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 100% of parameters, with descriptions for both 'id' and 'window'. The description largely repeats the window values and adds no new parameter semantics beyond what the schema already provides, so 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 what the tool does: it reports the duration of each step in a browser flow monitor over a window, including trend metrics like earliest/latest mean, ratio, and pass/fail counts. This explicitly focuses on 'browser flow monitor' steps, distinguishing it from general monitor or run-level tools.

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

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

The description gives an explicit use case: 'Use this to spot a step drifting toward failure while the monitor still reports up.' This clearly indicates when to employ the tool, though it does not explicitly name alternative tools or conditions 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 description discloses that the tool returns a full operator-update timeline and includes an error sample, which are behavioral details not covered by the readOnlyHint annotation. Since the annotation already declares read-only safety, the description adds useful context without redundancy. 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?

The description is remarkably concise: one sentence lists the returned fields, and a second word 'Read-only' conveys safety. Every word adds value, and the sentence structure is front-loaded with the primary object. No filler or repetition.

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

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

For a simple single-parameter tool with an output schema (indicated by context signals), the description fully captures what the tool returns and its read-only nature. The schema covers the id parameter, and the description enumerates the key result components, making it 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?

Schema description coverage is 100%: the id parameter is described and sourced from list_incidents or get_org_health. The tool description adds no additional parameter meaning, so the baseline of 3 for high coverage 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 clearly identifies the tool as retrieving a single incident with specific fields ('affected monitor, severity, open/resolved times, error sample, and the full operator-update timeline'). This distinguishes it from sibling tools like list_incidents (which lists incidents) and get_incident_metrics (which focuses on metrics), making the 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 usage context is implied: use when you need details of one incident. The schema comment adds that the id comes from list_incidents or get_org_health, which hints at workflow. However, there is no explicit 'use this instead of X' or clear exclusion of alternatives, so the guidance is not as strong as the calibration example that names an alternative 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?

The annotations already declare readOnlyHint=true, and the description repeats 'Read-only'. The description adds useful context about the default 30-day window and the metric categories, but it does not disclose other behavioral aspects like response structure or pagination. Since an output schema exists, the bar is lower, and this provides modest added value.

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, front-loaded sentence that packs essential details (window default, metrics list, read-only) without redundancy or filler. Every phrase 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 simple aggregate tool with one optional parameter and an output schema, the description sufficiently covers purpose, scope, and key behavior. It does not need to explain return values since an output schema exists, and the sibling context clarifies 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 single parameter (window_days) is fully described in the schema with trailing window and default value. The description only echoes the default without adding new syntax or semantic detail. With 100% schema coverage, 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 a specific action ('get incident metrics') and resource plus the exact metrics included (MTTA/MTTR, counts by severity/state, resolution source, noisiest monitors). This differentiates it from sibling tools like get_incident (single incident) and list_incidents (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 context is clear: this tool provides aggregated incident metrics over a trailing window, implying use for summary/trend analysis. It does not explicitly name alternatives or exclusions, but the sibling list makes the differentiation evident, warranting a 4 rather than 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 that credentials are withheld and that the return shape matches update_monitor's input. It clearly states the tool is read-only and lists the kinds of data included (state, last error, uptime), providing additional transparency.

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

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

The description is lengthy but well-structured with em dashes to enumerate configuration, alerting, and status details. It is front-loaded with the main purpose and stays organized, though the trailing 'Read-only.' is redundant with the annotation. Slightly verbose but effective.

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 output content (configuration, regions, alerting, state, last error, uptime), credential handling, and usage context. With an output schema present, it does not need to detail return types, but it provides ample context for when and why to use the tool, making it nearly 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 only parameter `id` is fully documented in the schema with a description referencing list_monitors. The description does not add further parameter details, but with 100% schema coverage, 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 clearly states it retrieves one monitor's full configuration, current state, and uptime data. It distinguishes itself from sibling tools like list_monitors and get_monitor_history by emphasizing the full configuration and updatable fields.

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?

Explicitly instructs to read this before judging whether a response passed or before changing a monitor. It also notes that every field update_monitor can change is readable here, providing clear when-to-use context and a companion relationship with update_monitor.

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 is reinforced by the description's 'Read-only' statement. The description adds valuable behavioral context beyond the annotation by enumerating exactly what data is returned (uptime, latency, region split, failures, incident windows), which helps 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 two sentences, front-loaded with the core purpose and data list, followed by a targeted usage tip for `region`. Every word contributes, 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 an output schema present and a read-only annotation, the description sufficiently covers the tool's behavior and usage for a straightforward 3-parameter history fetch. It lists return components and parameter rationale, leaving no significant gaps.

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

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

Schema coverage is 100%, but description adds semantic value beyond the schema: it reiterates window enum values and explains the diagnostic purpose of `region` (telling partial from total outage), which enriches the parameter's meaning.

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 function: retrieving one monitor's history over a specified window, listing specific data types (uptime, latency series, per-region split, failures, incident windows). This distinguishes it from sibling tools like get_monitor, which likely provides current status.

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 (historical data) and gives explicit guidance on using the `region` parameter to differentiate partial from total outages. It does not explicitly name alternatives or state exclusions, but the context is sufficient.

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 this is a safe read operation. The description adds value by explaining the output content (per-state totals and worst failing monitors) and the 'current' snapshot nature, which goes beyond the annotation. The explicit 'Read-only' statement is 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 two short sentences, front-loaded with the key summary and immediately followed by the use case. Every word earns its place, and the redundant 'Read-only' is minimal and harmless.

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 no-parameter tool with an output schema present, the description is complete: it states what the tool does, what data it returns, and when to use it. There are no significant gaps given the tool's simplicity.

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 nothing to explain. The empty schema is fully covered, and the description correctly omits unnecessary parameter details. Baseline 4 is appropriate for a no-parameter tool.

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

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

The description clearly identifies the tool as providing an org health summary with per-state monitor totals and the worst currently-failing monitors. This is specific and distinguishes it from sibling tools like list_monitors and get_incident, and the 'one-shot answer' phrase further clarifies its 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 explicitly states the use case: 'The one-shot answer to what is broken right now?'. It does not mention alternative tools or exclusions, but the positioning as a summary tool is clear enough to guide 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 is reinforced by 'Read-only'. The description adds meaningful context beyond the annotation by specifying the resources included (monitors, status pages, members, components, key policy values) and the 'against plan limits' aspect, which clarifies what data the tool reports. No contradictions.

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 that immediately convey the core purpose and key details. No filler, no redundant phrasing, and the information is front-loaded. 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?

For a zero-parameter, read-only tool with an output schema present, the description fully covers what the tool does and what domain it addresses. The output schema handles return-value explanations. No critical information 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 tool has zero parameters, so the schema description coverage is trivially 100%. The description adds no parameter information, but none is needed. The baseline for 0 parameters is 4, and nothing in the description detracts from that.

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 org resource usage against plan limits, listing specific resource types (monitors, status pages, members, components, key policy values). This is a specific and unambiguous purpose that distinguishes it from siblings like get_org_health or list_monitors.

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

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

No explicit guidance on when to use this tool versus alternatives. While 'Read-only' hints at safety, it doesn't explain the intended use case or contrast it with similar tools like get_org_health or list_status_pages. The context is implied but not stated.

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

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

Annotations already declare readOnlyHint=true, and the description redundantly says 'Read-only.' It adds a small behavioral nuance by noting the inclusion of 'linked monitor's current state,' implying a live/snapshot view, and clarifies the nested structure of the response. No side effects or additional behavioral traits beyond the read-only annotation 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?

The description is a single, front-loaded sentence that immediately identifies the resource ('One status page') and then lists the return fields in a compact, readable enumeration. No filler or repetition beyond the redundant 'Read-only' phrase, which is minor.

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 presence of an output schema, a single well-documented parameter, and a read-only annotation, the description provides sufficient context for an AI agent to understand the tool's purpose and output. It does not need to explain return values because the output schema covers that, and the parameter description already provides the prerequisite.

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 covers 100% of the parameter, and the `slug` description already explains where it comes from (`list_status_pages`) and what it identifies. The main description adds no further parameter-level detail, so the schema carries the full semantic weight, establishing a baseline of 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 tool fetches a single status page and enumerates exactly what it returns: name, public URL, enabled status, components, and linked monitor states. It distinguishes itself from sibling tools like `list_status_pages` by specifying 'One status page' and detailing the nested component/monitor data.

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

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

The description implies usage when you need detailed information about one specific status page. The parameter description also references `list_status_pages` as the source of the slug, giving a contextual prerequisite. However, it does not explicitly state when to avoid this tool or mention alternatives beyond the implied list-then-get pattern.

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 reaffirms 'Read-only' without contradicting it. The description adds behavioral detail beyond the annotation: default state (currently-open), default time window (last 30 days), and the interplay between state and window. It doesn't mention pagination or cursor behavior, but those are covered in the schema, so the burden on the description is lower.

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 action and output fields, then defaults and filters, then a one-word safety confirmation. No filler or redundant explanation – 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?

Given a 5-parameter list tool with output schema, the description covers the main usage modes (open vs. all, time window, monitor filter) and returned fields. It doesn't mention pagination or the fact that the cursor carries the whole query, but those are explicitly handled in the schema descriptions. Slightly more detail on when to use list vs. get_incident would round it out.

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 adds value by explaining the query semantics: how state='all' combines with from/to, the default window, and that monitor_id narrows results. This is beyond what individual parameter descriptions state (e.g., it clarifies the overall filtering model). It doesn't detail the cursor behavior, but the schema does.

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 resource ('the org's incidents') and details what is returned (incident id, affected monitor, severity, times, update phase). This clearly distinguishes it from sibling tools like get_incident (which fetches a single incident) and get_incident_metrics (which computes 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?

It provides clear context on when to use the tool: defaults to open incidents, use state='all' with a from/to window for resolved history, and monitor_id to narrow. It doesn't explicitly say when to prefer a sibling (e.g., 'use get_incident for a single incident'), but the scope is well implied. Missing explicit 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, and the description reinforces this by stating 'Read-only.' It adds behavioral context beyond the annotation by mentioning cursor pagination and the fact that each item includes its current state and last-checked time. No contradictions.

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 front-load the verb and resource, then add essential detail. Every sentence earns its place with no filler.

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

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

For a simple list tool with an output schema and fully described optional parameters, the description is complete. It covers the core behavior (listing with filters and pagination) and discloses the item content. No significant gaps.

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

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

Schema description coverage is 100%, so the baseline is 3. The description echoes the filters (state/type/tag) and cursor pagination, but it does not add new meaning beyond what the parameter descriptions already provide. It groups filters but does not deepen the understanding of each 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 identifies the action ('List') and the resource ('monitors'), and adds specific detail about optional filters and pagination. This distinguishes it from sibling tools like get_monitor (singular) and list_incidents by resource and 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 implies when to use the tool (to list monitors with optional filters and pagination) but provides no explicit guidance on alternatives or exclusions. It does not mention that get_monitor should be used for a single monitor, nor does it contrast with other list tools.

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

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

Beyond the readOnlyHint annotation, the description adds valuable behavioral context: it explains that sensitive settings (webhook URLs, bot tokens) are deliberately withheld and why, and that channels are created elsewhere. This gives the agent a clear picture of what to expect and what not to expect.

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

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

Three sentences, front-loaded with the core listing purpose, followed by relevant behavior notes. Every sentence serves a purpose with no redundancy or fluff.

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

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

With no parameters and an output schema present, the description still adds essential context: what fields are returned, what is intentionally omitted, and the read-only nature. This is fully sufficient for an agent to select and invoke the tool correctly.

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

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

There are zero parameters, so the baseline is 4 per the rubric. The description doesn't need to explain parameter semantics, and it does not add any parameter-related info, which is appropriate given the empty 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 uses a specific verb+resource ('list notification channels') and enumerates the precise output fields (id, operator-set name, kind, enabled status), making the tool's function unmistakable. It distinguishes from sibling list tools by focusing on notification channels rather than other resources.

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

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

The description provides explicit when-not guidance: 'Channels are created in the Uptimepage app, not here' and explicitly labels the tool as 'Read-only,' telling the agent this is not for management. It implies when to use (when you need to list channels) and excludes creation/modification, fulfilling the explicit usage guidance criterion.

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 reinforces this with 'Read-only'. It adds behavioral context by listing the fields returned, which goes beyond the annotation. No information about pagination or ordering is disclosed, but for a simple parameterless list tool this is sufficient.

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 resource definition and followed by usage guidance. No unnecessary words or repetition; it 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?

The tool has no parameters and an output schema exists, so the description need not explain return values. It covers purpose, field list, usage context, and connectivity to a sibling tool, making it complete for this simple tool.

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

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

The tool has zero parameters, so the baseline is 4. The description adds meaningful value by noting that the output can be used to pass a valid `region` to get_monitor_history, linking the semantics of this tool's data to another tool's 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 tool lists the fleet's probe regions and enumerates the fields (id, display name, city, country, continent). It distinguishes the resource type from other list_* siblings, so purpose is 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 explains when to use the tool: to name where a check runs from and to obtain a valid `region` parameter for get_monitor_history. This provides actionable guidance and connects to a specific sibling tool, making usage context 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 adds behavioral details beyond the readOnlyHint annotation by disclosing cursor-based pagination and the specific fields returned. While 'read-only' repeats the annotation, the pagination behavior is valuable and not present in the 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 three short sentences, front-loaded with the action and resource. Every phrase contributes to the tool's understanding, with no filler or redundant clauses beyond the optional 'Read-only' which is also in annotations.

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 operation with a single optional cursor parameter and an existing output schema, the description sufficiently conveys purpose, pagination, and output fields. It lacks explicit default page size or contrast with get_status_page, but these are not critical given the schema and 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?

The input schema already provides a complete description of the cursor parameter (opaque cursor from next_cursor), achieving 100% schema coverage. The description merely mentions cursor-paginated, which aligns with the schema but adds no new syntax or semantics beyond what the schema documents.

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

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

The description states a specific verb 'List', identifies the resource 'status pages', specifies scope 'org's', and enumerates the fields returned (slug, name, public URL, enabled). This clearly distinguishes it from sibling tools that list incidents, monitors, regions, etc., and from get_status_page which retrieves a single page.

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 clearly communicates the tool's function for listing all status pages and notes cursor-based pagination, which implies its use case for enumerating status pages. It does not explicitly contrast with get_status_page or provide exclusionary guidance, but the purpose is self-evident among siblings.

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

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

Annotations already declare readOnlyHint=true, and the description redundantly states 'Read-only.' However, it adds behavioral details beyond annotations: it lists tags sorted by usage ('most-used first') and includes per-tag monitor counts, plus the scope covers 'every tag in use across the org's monitors.' This enriches the agent's understanding of output formatting and data scope.

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

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

Two sentences, front-loaded with the essential output description, immediately followed by a usage hint and read-only note. 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?

Given the tool has no parameters and an output schema exists, the description is fully sufficient. It explains the ordering, counting, and how to use the results with list_monitors. No gaps for a simple read-only 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?

The tool has zero parameters, so the schema fully covers parameter semantics. The description adds no parameter-specific detail, but none is needed. Baseline for 0 parameters is 4.

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 tags in use across the org's monitors, ordered by usage frequency, and includes monitor counts. It also distinguishes itself by explaining how the output feeds into list_monitors, which is its primary use case.

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

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

The description provides explicit guidance: pass a returned tag as the `tag` filter to list_monitors. It implies the tool is a precursor to filtering monitors, but does not explicitly state exclusions or alternatives beyond that. The context is clear and actionable.

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