Uptimepage

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

Adds behavioral context beyond annotations: it mentions confirmation prompts and token scope execution ('Asks for confirmation where the client can show a prompt; otherwise runs on the token's scope') and explicitly states it is not read-only, aligning with readOnlyHint=false. 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 compact yet complete, with each sentence serving a purpose: state the action, scope, alternatives, execution behavior, and read-only status. It is front-loaded with the primary purpose and avoids 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 the presence of an output schema and annotations, the description covers all necessary context: purpose, usage boundaries, mutation behavior, and authorization. Nothing critical is missing for an agent to correctly invoke the tool.

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

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

Schema coverage is 100%, and the schema already describes both id and note clearly. The description does not add parameter-specific meaning; it only reinforces that the note is internal via 'Internal/operational only' but doesn't elaborate on the parameters themselves.

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: 'Acknowledge an incident: take ownership and halt escalation.' It identifies the specific resource and distinguishes it from sibling tools by explicitly saying it is internal/operational only and does not post to the public status page, pointing to post_incident_update for customer-facing updates.

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?

Provides explicit when-not-to-use guidance ('does NOT post anything to the public status page') and names the alternative tool ('Use post_incident_update for customer-facing updates'). Also clarifies it's not read-only, helping agents decide between mutation and read 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?

Annotations already establish readOnly=false and idempotentHint=true, and the description reinforces 'Not read-only' while adding useful nuance: duplicate monitors are reported rather than duplicated. It also discloses the privacy-relevant behavior that detail_link_enabled exposes the monitor's operator-side name and address, which is not apparent from the schema alone. This is strong behavioral disclosure for a mutating 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?

Three sentences deliver the core action, idempotency behavior, and a critical privacy warning without padding. The final 'Not read-only' is slightly redundant with the readOnlyHint=false annotation but costs little. Overall, compact and 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?

For a batch-add mutation with an output schema and safety annotations, the description covers the important operational consequences: batch/prompt behavior, deduplication, and the detail-link privacy caveat. An agent has enough information to select and call the tool correctly. The only minor gap is explicit sibling routing, which is more of a usage-guideline concern.

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 description only needs to add rationale. It adds meaningful context for public_name (reader-friendly, not operator-facing), public_group (filing related components), and detail_link_enabled (privacy tradeoff). It does not comment on every parameter like public_description, but the added value over the schema is clear.

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

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

The description opens with a concrete verb-object pair ('Add monitors to a status page as public components'), making the operation unambiguous. It clearly differentiates itself from siblings like create_status_page or update_status_page_component by focusing on adding monitors to an existing page. The scope is specific and actionable.

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 it: when adding monitors to a status page in a batch operation, with duplicate handling explained. However, it never explicitly names alternatives such as update_status_page_component, nor states conditions that would make another tool preferable. This is adequate but not explicit routing 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 declare the safety profile (readOnlyHint=false, idempotentHint=true, destructiveHint=true), but the description goes substantially beyond them: it specifies what is left behind (listed under past as a record), what stops (holding paging), what does not happen (subscribers are not notified of cancellation), and the confirmation/prompt behavior. That is rich behavioral context that the annotations cannot convey.

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?

Front-loads the core action, follows with consequences, the alternative route, confirmation semantics, and an annotation echo, with zero filler. Every clause carries distinct 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?

Covers action, side effects, record retention, notification behavior, confirmation, auth scope, and the sibling alternative. An output schema exists so return values need not be described. Nothing an agent needs to invoke this correctly 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?

Only one parameter and schema coverage is 100%, so the schema fully documents the id (including its source from list_maintenance). The description adds no parameter detail beyond the schema, so the baseline of 3 is correct.

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

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

States a specific verb (cancel) and resource (maintenance window), and disambiguates from the semantically adjacent sibling update_maintenance by naming it with a concrete alternative behavior. An agent can tell this apart from update_maintenance and get_maintenance without opening any schema.

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 names the alternative tool and the condition that selects it: 'To stop a running window early and keep it as completed work, use update_maintenance with end_now instead.' This is a textbook when-to-use-this-vs-that directive.

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?

Goes well beyond annotations: explains that checks still run and incidents still open, that an open incident at window end pages then, that subscribers are notified at schedule and end, and the time constraints (RFC 3339, future, ≤30 days). Annotations only give readOnly=false, idempotent=false, destructive=false, so the description carries meaningful behavioral context.

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

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

Front-loads purpose and effect, then alternatives, then constraints. Dense but every sentence adds value. Slightly long yet not wasteful.

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?

Output schema exists, so return value explanation is unnecessary. The description covers scope, side effects, notifications, and timing constraints, making it complete for a mutation 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%, so parameter meanings are documented in the schema. The description adds the suppress_alerts default and time constraints, but these largely duplicate schema descriptions. 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?

States a specific verb (schedule) and resource (maintenance window), plus the effect on monitors and status pages. Explicitly distinguishes from pause_monitor, naming the sibling and giving the selection condition.

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?

Explicit when-to-use ('planned work') and when-not via the alternative ('Prefer this over pause_monitor for planned work'). Also states the paging-hold default condition, giving the agent clear routing 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 indicate readOnlyHint=false, and the description reinforces this with 'Not read-only.' More importantly, it discloses that the page is created unpublished unless enabled, that the slug is first-come across the platform and moving it later breaks links, and that the slug should be confirmed with the user. These are critical behavioral details that go beyond the annotations and significantly inform 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?

Three sentences, each carrying essential information. The core purpose is front-loaded, followed by the default state, slug warning, and a pointer to the sibling tool. No wasted words and the structure is logical.

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 creation tool with an output schema, the description covers the key aspects: what it does, default behavior, important caveats about the slug, and the next step for adding monitors. The output schema handles return values, and the annotations cover idempotency and read-only status. Nothing an agent needs to call this correctly 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 schema covers 100% of parameters with descriptions, so baseline is 3. The description adds valuable context for slug (public address, first-come, breaking links) and enabled (curation before publication), which enhances understanding beyond the schema. Name doesn't get extra treatment, but the schema already describes it adequately. Overall, it adds meaning beyond the schema.

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

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

The description states a specific verb and resource: 'Create a status page.' It also distinguishes itself from siblings by noting that monitors are added via add_status_page_components, so an agent knows exactly what this tool does and what it doesn't.

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

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

It clearly instructs to use add_status_page_components for adding monitors, which is a key follow-up step. It also advises confirming the slug with the user before creating. It doesn't explicitly mention alternatives like update_status_page, but the create/update distinction is implicit in the tool name and the guidance provided is sufficient for correct usage.

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 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?

readOnlyHint=true already declares the safety profile, and "Read-only." merely restates it, earning no extra credit. The field-level detail about monitors covered and paging hold is genuinely useful behavioral context beyond the annotation, but the description says nothing about lookup failure behavior for a bad id.

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?

A single front-loaded sentence: the resource first, then the fields it carries, ending with a two-word read-only flag. Every clause conveys information and nothing is padded.

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?

An output schema exists, so return values elsewhere need not be explained, and the single required parameter is fully covered by the schema. The definition is adequate for a simple by-id read, though it omits error/missing-id behavior and any hint of when to prefer this over the 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?

Only one parameter exists and schema description coverage is 100%, with the schema even documenting that the id originates from list_maintenance. The description adds no format, constraint, or sourcing detail beyond what the schema already provides, 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 names the exact resource returned ("One maintenance window") and enumerates its meaningful fields (title, description, start/end, phase, covered monitors, paging hold), so the agent instantly knows what comes back. It implies a single-item fetch versus list_maintenance, but never names that sibling explicitly, which keeps it out of the top band.

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?

There is no statement of when to call this versus list_maintenance, update_maintenance, or cancel_maintenance. The only routing clue (the id comes from `list_maintenance`) lives in the input schema, not in the description, so the description itself offers no guidance.

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

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

The readOnlyHint annotation already indicates 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?

Annotations already declare readOnlyHint=true, so the trailing 'Read-only' adds nothing. However, the description contributes a genuinely non-obvious behavioral fact: caps are pooled across every org the account owns, so counts can exceed what this org holds. That caveat prevents a wrong interpretation of the numbers.

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, zero filler, and the identity-plus-metrics content is front-loaded ahead of the pooling caveat. Every clause carries 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?

With an output schema present, return-value structure needn't be restated, and with zero parameters there is no input contract to cover. The description supplies the data semantics (pooling) and safety profile needed to use the result correctly, leaving nothing material 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 takes zero parameters, so the baseline of 4 applies. There is no parameter semantics to add beyond the schema, and the description correctly spends no space on inputs.

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

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

States a specific resource pair — the org a connector is bound to plus the account's resource usage against plan limits — and enumerates the exact metrics returned (monitors, status pages, members, components, policy values). That level of specificity clearly separates it from the nearest sibling, get_org_health, without opening either schema.

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?

Usage is implied by the content (call it when you need org binding or plan-limit consumption), but the description never states when to prefer it over get_org_health or list_monitors. No exclusions or alternatives are named, so the agent must infer the trigger condition.

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?

Annotations already declare readOnlyHint=true, and the description restates 'Read-only', which earns no extra credit. It does add value beyond annotations by disclosing pagination behavior ('Cursor-paginated') and result ordering ('latest start first', 'ended or cancelled'), which an agent needs to interpret multi-page output correctly.

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?

There is no preamble or filler; the core purpose is front-loaded in the first clause and the rest is dense with useful detail. It is slightly run-on with stacked parentheticals, which costs a point but not readability.

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?

An output schema exists, so return values need not be explained, yet the description still enumerates them — harmless but partly redundant. Combined with the pagination note, default, and ordering rules, an agent has enough to call this correctly; only guidance on alternatives 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 description coverage is 100%, so the schema already documents cursor semantics (carries the whole query, send alone) and each status constant. The description mostly echoes the enum meanings and repeats the default ('the default is all'), adding little beyond what structured fields provide; baseline 3 applies.

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

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

The description opens with a specific verb+resource ('List maintenance windows') and enumerates the fields returned (title, start/end, phase, covered monitors, paging hold), so the agent knows exactly what this returns. It does not explicitly contrast itself with siblings like get_maintenance (single window) or cancel_maintenance, so it falls short of full 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?

It explains how the status filter narrows results ('narrows to active, upcoming or past') and what the default is, which implies usage context. However, no alternative tools are named and there are no when-not-to-use conditions or prerequisites (e.g., 'use get_maintenance for a single window'), leaving routing to inference.

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

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

The readOnlyHint annotation already declares the safety profile, and 'Read-only' merely restates it. It adds moderate value by noting cursor pagination and that each item carries state and last-checked time, but the output schema already covers the return shape, so the added context is thin.

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 tight sentences with zero filler, front-loading the operation and filters before pagination and read-only status. Every clause 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 an output schema present, return values need not be explained, and the readOnlyHint carries the safety profile. The description covers filters, pagination, and item contents adequately, though it omits default behavior when all filters are omitted.

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

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

Schema description coverage is 100%, so all four parameters (tag, type, state, cursor) are fully documented in the schema itself. The description only names the filters, adding no syntax, enum values, or format detail beyond what the schema provides — 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?

States a specific verb (List) and resource (monitors) plus the available filters and pagination model. Distinguishes from get_monitor by plurality and listing semantics, though it never explicitly names the singular sibling.

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?

Usage is only implied: an agent infers this is the bulk-listing tool versus get_monitor for one monitor. There is no explicit when-to-use, when-not, or alternative routing, and no note on default scope when filters are omitted.

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 assert readOnlyHint=true, but the description adds substantial behavioral context: the meaning of awaiting_verification and not_delivering (a channel can read as ready yet be broken), how auto_bind_tags extends coverage to tagged monitors, and that channel settings are withheld because they contain webhook URLs and bot tokens. This is real disclosure 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?

Front-loaded with the resource and its fields, then layers the two health flags, the auto_bind_tags rule, and the security caveat. Dense but every clause carries information; only mildly longer than strictly necessary.

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 an output schema exists, the description need not explain return values, yet it usefully annotates the non-obvious flags (awaiting_verification, not_delivering, auto_bind_tags) that a raw schema would not interpret. Combined with the creation-boundary note and withheld-settings warning, nothing an agent needs 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?

Zero input parameters, so the baseline is 4; there is nothing for the description to add or compensate for on the input side. It correctly spends no words pretending there are parameters.

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

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

States a specific verb+resource ('The org's notification channels') and enumerates the fields returned (id, name, kind, enabled), so the agent knows exactly what it will get. No sibling tool covers notification channels, making it trivially distinguishable from the rest of the catalog.

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?

Clarifies the boundary that channels are created in the Uptimepage app, not via this tool, implicitly steering the agent away from looking for a create sibling. However, it does not state explicit when-to-use/when-not conditions or name an alternative read path, so it falls short of a full 5.

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

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

Annotations already declare readOnlyHint, and the description reinforces it with 'Read-only.' It adds valuable behavioral detail about `max_regions` appearing only when the plan limit is lower than catalog count, which is beyond annotation coverage.

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, each earning its place: the catalog contents, the max_regions behavior, and usage guidance. The most critical usage warning is placed last but clearly marked, and the text is front-loaded with the resource 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?

With an output schema present, the description doesn't need to detail return values. It covers the fields, the edge case of max_regions, and proper usage, making it fully complete for an agent to call correctly without ambiguity.

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

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

The tool has zero parameters, so the description carries no parameter burden. The description focuses on output and usage, which is appropriate for a parameterless tool; a 4 reflects the baseline for 0-param tools.

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

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

The description clearly states the tool lists probe regions and specifies the exact fields returned: id, display name, city, country, continent, and default status. It also explains its role in supplying valid `region` values for other tools, distinguishing it from sibling list 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 directs when to use it: to pass a valid `region` to get_monitor_history and to read where a check runs. It also gives a clear exclusion: not to use it as a menu to fill create_monitor.regions unless the user named specific places.

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.

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

Beyond the readOnlyHint annotation, the description discloses that values are never returned and that secret values are never even read. It also explains the security context around credential pasting being refused. This gives the agent an accurate mental model of the tool's safety and behavior.

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

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

The description is compact and front-loaded with the core purpose. Each sentence contributes meaningful context: the resource, the privacy behavior, the usage pattern, and the mutation boundary. There is no redundant filler.

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

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

The tool has no parameters and an output schema, so the description only needs to convey what is listed and any important behavioral caveats. It does both thoroughly, including the critical guarantee that secret values are never read or returned. Nothing an agent needs to safely call this tool 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 input schema has no parameters, so there are no parameter semantics to document. The baseline for a zero-parameter tool is 4, and the description appropriately signals that the tool simply lists all variables without requiring input.

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

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

The description clearly states the tool lists the org's reusable variables with their keys and secret status. It is distinct from every sibling list_* tool because no other sibling targets variables, and it names the exact resource being operated on.

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

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

The description explains why and how variables are used: they go into a monitor's header or body as {{ key }} and are resolved at check time to build authenticated checks. It also explicitly says variables are created and edited in the app, not here, which prevents an agent from attempting mutations. It does not name sibling alternatives, but none are direct alternatives for this resource.

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=false, idempotentHint=true, destructiveHint=true, so the closing 'Not read-only; idempotent' is largely a restatement. The genuinely additive content is the confirmation behavior ('Asks for confirmation where the client can show a prompt; otherwise runs on the token's scope'), which tells the agent about interactive and auth-fallback behavior not captured in 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 tight sentences, each carrying distinct information: the core action, the sibling alternative for planned work, and the confirmation/scope behavior. The core action is front-loaded and nothing is padded.

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?

An output schema exists, so return values need no explanation. For a single-param mutation the description covers the effect, the alternative tool, the confirmation prompt, and the token-scope fallback — enough for an agent to call it 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 is a single parameter with 100% schema description coverage, and the schema already tells the agent the id comes from list_monitors. The description adds no format or sourcing detail beyond that, so the baseline 3 applies.

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

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

States a specific verb+resource ('Pause a monitor') and immediately clarifies the scope of the effect ('stop its checks until resumed'), which an agent can distinguish from sibling operations like resume_monitor or create_monitor without opening a schema.

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 routes the agent: 'For planned work, create_maintenance holds paging instead while the checks keep running' names the alternative and the condition that selects it. It also implies the resume_monitor counterpart ('until resumed').

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 annotations (readOnlyHint false), it discloses a confirmation-prompt behavior and that the action otherwise runs on the token's scope. It also states 'Not read-only.' No contradiction with annotations; it adds useful behavioral context for a mutation.

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, each earning its place: purpose, audience, and behavioral caveat. No filler or repetition; front-loaded with the core operation.

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 output schema, 100% param coverage, and annotations, the description covers purpose, audience, confirmation behavior, and token scope. It is slightly vague about when confirmation is possible, but overall enough for an agent to call it 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?

Schema description coverage is 100%, so the schema already documents id, phase, and message fully. The description only mentions phase + message at a high level and does not add semantics beyond the schema; baseline 3 applies.

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

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

The description opens with a specific action and resource: posting a public, customer-facing update to an incident's status-page timeline. It also clarifies the content (phase + message) and differentiates from siblings like publish_incident or update_status_page by emphasizing the status-page timeline and subscriber visibility.

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 for use: this is what subscribers and status-page visitors see, so an agent can infer it is the tool for public incident timeline communication. It does not explicitly name alternatives or when-not-to-use conditions, but the context is strong enough for 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?

Beyond annotations (readOnlyHint=false, idempotentHint=true), the description discloses that subscribers may be notified, that confirmation may be requested, and that the status_page_ids list replaces existing pages—behavioral details not captured in annotations. 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?

Four sentences, front-loaded with the main action. Each sentence adds necessary context (monitor vs no monitor, replacement behavior, notification, confirmation, idempotency). Slightly long but 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?

Covers all critical aspects: the publishing behavior, the conditional use of status_page_ids, replacement semantics, notification side effects, confirmation behavior, and idempotency. The output schema exists, so return values are covered. No missing information for correct invocation.

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 detailed descriptions for all parameters, including the replacement semantics for status_page_ids. The tool description adds only a general 'optionally seeding' phrase, which adds little beyond the schema. 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 verb 'publish' and the resource 'incident', and explains the effect (appears on status pages). It differentiates from siblings like unpublish_incident and post_incident_update by focusing on the publishing action and 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?

Provides explicit guidance on when to set status_page_ids (incidents with no monitor) and when not to (monitor incidents). Mentions starting from get_incident's status_page_ids. While it doesn't name alternative tools, it gives clear when/when-not conditions for parameter usage.

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 meaningful behavioral detail beyond the annotations: it states the operation is not read-only, confirms the internal-only status page behavior, and explains the confirmation/authorization behavior ('Asks for confirmation where the client can show a prompt; otherwise runs on the token's scope'). This is valuable context that annotations alone do not provide, and it does not contradict the destructiveHint or idempotentHint.

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 concise sentences with no filler. It front-loads the core purpose, then adds behavioral caveats and a scope clarification. Every sentence contributes useful information for tool selection and invocation.

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 output schema exists, the 100% schema coverage, and the annotations describing read-only, idempotency, and destructiveness, the description adds the remaining essential context: internal scope, public status page exclusion, and confirmation behavior. An agent has enough information to select and invoke this tool correctly.

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

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

Schema description coverage is 100%, so the baseline is 3. The description repeats the internal-only nature of the note, which is already documented in the schema, and does not add new parameter-level meaning beyond what the schema provides. The required 'id' parameter is also already described adequately 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 states a specific verb and resource ('Resolve an incident') and clarifies the exact meaning with 'mark the operational state resolved.' It also distinguishes itself from sibling tools by explicitly noting 'Internal only — does not post to the public status page,' which differentiates it from publish_incident and related public-facing 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 provides clear context for when to use the tool: resolving an incident internally without public status page impact. It does not explicitly name alternative tools, but the 'Internal only' and 'does not post to the public status page' exclusions effectively guide tool selection among siblings like publish_incident and post_incident_update.

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 mark the tool as not read-only and idempotent, and the description restates those facts. It also adds meaningful behavioral context beyond annotations: the confirmation prompt behavior and the fallback to the token's scope when a prompt cannot be shown.

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

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

The description is short, front-loaded with the primary action, and uses only three sentences. The 'Not read-only; idempotent' sentence partially duplicates annotations, but it is brief and does not bloat 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 single-parameter tool with an output schema and annotations covering safety/idempotency, the description gives enough context to call it correctly. It explains the effect, the confirmation behavior, and token scope, and the output schema covers return values.

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

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

Schema description coverage is 100%, and the schema already explains that `id` is the monitor id from `list_monitors`. The tool description does not add extra parameter semantics, 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 states a specific verb and resource: 'Resume a paused monitor (restart its checks).' This clearly separates it from pause_monitor and run_check_now, making the tool's purpose immediately obvious.

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 'Resume a paused monitor' implies when to use it, but it does not explicitly name alternatives or state when not to use it. It gives some contextual guidance about confirmation and token scope, but no direct comparison to sibling tools.

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

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

The description goes well beyond annotations by disclosing confirmation-prompt behavior, token-scope fallback, potential alert firing on a down result, and the heartbeat limitation. The explicit 'Not read-only' reinforces the readOnlyHint=false annotation without contradicting it.

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?

All four sentences carry meaningful information: the core action, confirmation behavior, alert side effect, and heartbeat exception. Nothing is redundant or 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 single-parameter tool with an output schema, the description covers the essential behavioral and safety context: side effects, confirmation, scope, and a major exception. No critical information needed to call it correctly 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 description coverage is 100%: the single `id` parameter is already documented as 'The monitor id (from `list_monitors`).' The description adds no further parameter-specific meaning, 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 states a specific verb and resource: 'Run a check on a monitor immediately and record the result.' This clearly distinguishes run_check_now from read-oriented or state-changing siblings like get_monitor, pause_monitor, and resume_monitor.

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 and explicitly notes that heartbeat monitors cannot be probed, which is a valuable exclusion. It does not explicitly name an alternative tool for reading monitor status, but the intended use is still inferable.

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?

Far exceeds the annotations (readOnlyHint=false, idempotentHint=true, destructiveHint=true) by disclosing the ~30-second incident-open latency, that channels are paged unless a maintenance window holds it, the status-page presentation per state, that up closes the incident, that the note becomes the incident cause, and the confirmation/token-scope behavior. This is exactly the mutation side-effect detail an agent needs before calling.

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?

Front-loads the core action and legal values in the first sentence, then layers consequences. Dense and mostly waste-free, though the note guidance ('make it a reason a responder can act on') partially duplicates the schema's own note 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?

An output schema exists so return values need no explanation, and the description covers the remaining risk surface for a mutating tool: incident lifecycle, paging, maintenance suppression, paused-plan edge case, refusal conditions, and confirmation/auth behavior. Nothing material 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?

With 67% schema coverage the schema already documents id, state and note, but the description adds intent-level guidance the schema lacks: why the state matters (outage vs degraded on status pages), that the note must be actionable for a responder, and the monitor-kind constraint on id. It adds real semantic value over the structured fields.

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

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

States the exact verb and resource (set the state of a manual monitor) plus the three legal values, and immediately scopes it to manual monitors with no probe, distinguishing it from every update_monitor/pause_monitor sibling. An agent knows precisely what this does without opening the schema.

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?

Gives a strong when-to-use rationale ('a service only people can judge, such as a SIP trunk, a carrier link or a partner's back office') and an explicit when-not ('Refused for any other kind of monitor'), plus the paused/no-longer-covered caveat. It stops short of naming sibling alternatives such as pause_monitor or update_monitor for adjacent operations.

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 annotations, the description adds genuinely useful behavioral context: the operator timeline is untouched, and it 'asks for confirmation where the client can show a prompt; otherwise runs on the token's scope,' covering both interactive and non-interactive paths. The final sentence ('Not read-only; idempotent') restates the annotations rather than adding value, but the other disclosures lift this above baseline. No contradiction with readOnlyHint=false, idempotentHint=true, or destructiveHint=true.

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 core action is front-loaded in the first sentence, with behavioral caveats following in short, separate sentences. The only waste is the final 'Not read-only; idempotent,' which duplicates the annotations — a minor redundancy in an otherwise tight definition.

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 tool with a full output schema and safety annotations, the description covers the essential added context: the reversible nature of the action, the unaffected operator timeline, and the confirmation/token-scope behavior. No critical call-blocking 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 schema already documents the single id parameter at 100% coverage, including a provenance hint ('from list_incidents or get_org_health'), so the schema carries the full load. The description adds no parameter-specific meaning, which per the baseline rule for high schema coverage warrants a 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 uses a specific verb and resource — 'Hide a published incident from the public status pages again' — clearly identifying what the tool does. The 'again' phrasing and the unpublish/publish pairing with sibling publish_incident make the action unambiguous, though it doesn't explicitly name the sibling it inverts.

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?

Usage context is implied: call this when an incident is currently published and you want to remove it from public status pages, and 'again' signals it reverses a prior publish action. However, it doesn't explicitly name alternatives such as publish_incident or state conditions for when not to use it, leaving the routing decision to inference.

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

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

Adds real behavioral context beyond the annotations: monitor_ids is a wholesale replacement, end_now terminates a live window and marks it completed, and the tool previews old/new values before running when the client can prompt (otherwise it acts on the token's scope). The closing 'Not read-only' is largely redundant with readOnlyHint=false, but the confirmation and set-replacement semantics earn their keep.

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?

Front-loads the operation and the field list, then adds the state restrictions. Dense but every sentence carries information; only the trailing 'Not read-only.' is filler given the 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?

With an output schema and rich annotations, the description supplies the pieces they lack: refusal conditions, set-replacement warning, and the confirmation/preview flow. An agent could invoke this correctly from the description plus schema.

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

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

Schema description coverage is 100% and the schema already documents id, end_now, ends_at, description, monitor_ids, and suppress_alerts. The description restates the monitor_ids replacement behavior and end_now semantics, adding little the schema doesn't already say.

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?

Names a specific verb+resource ('Edit an upcoming or running maintenance window') and immediately scopes it by state (upcoming/running) and lists the editable fields, which cleanly separates it from get_maintenance, create_maintenance, and cancel_maintenance.

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?

States the eligibility condition (upcoming or running only) and the exclusion ('a completed or cancelled window is history and is refused'), which implicitly routes the agent elsewhere. It doesn't name cancel_maintenance or create_maintenance explicitly, so the routing is inferred rather than spelled out.

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 meaningful behavioral details beyond the annotations, such as 'An omitted field is left alone' and 'Changing the slug moves the public URL and breaks existing links.' The 'Not read-only; idempotent' phrase largely restates the annotations, but the additional side-effect warning is valuable.

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

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

The description is compact and front-loaded with the core actions, followed by important behavioral caveats. Every sentence contributes useful information, and there is no padding or unnecessary elaboration.

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 rich schema, annotations, and output schema, the description covers all essential calling context: what can be updated, how omitted fields behave, and the destructive consequence of changing the slug. No critical information for invoking the tool correctly 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 description coverage is 100%, so the schema already documents the meaning and role of each parameter. The description reinforces that omitted fields are left unchanged and that new_slug is destructive, but it does not add substantial meaning beyond the schema.

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

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

The description clearly identifies the resource (a status page) and the specific actions available: rename, change slug, publish, and unpublish. It is more specific than the generic title, though it does not explicitly name sibling tools like update_status_page_component to draw the contrast.

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 through the listed operations, but there is no explicit guidance about when to choose this tool over related siblings such as create_status_page or update_status_page_component. An agent can infer the use case, but the description does not state exclusions or alternatives.

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 reinforces the annotation-backed non-read-only/idempotent behavior and adds useful partial-update context with 'An omitted field is left alone.' It does not cover auth requirements or the effect of explicitly passing null, but the non-destructive and idempotent profile is already covered by 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 short and front-loaded, with the core purpose in the first sentence and the partial-update caveat immediately after. The 'Not read-only; idempotent' sentence is somewhat redundant with the annotations but is brief enough not to hurt clarity.

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 operation and the most important behavioral nuance, and the output schema reduces the need to explain return values. Still, it leaves the null-vs-omitted semantics ambiguous and provides no orientation relative to closely related sibling tools, so it is adequate but not fully complete for a six-parameter update 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 description compensates for low schema coverage by semantically naming the optional fields ('public name, description, group or position') and explaining that omitted fields are left alone. However, it does not clarify the difference between omitting a field and passing null, even though the schema allows null for these optional parameters; an agent could not confidently know whether null clears a field.

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

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

States a specific verb ('Change') and resource ('how one monitor is presented on a status page') and enumerates the affected fields: public name, description, group, or position. This clearly distinguishes it from sibling tools like update_status_page, which would update page-level settings rather than a single monitor's presentation.

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 adjusting the curation/presentation of an existing monitor on a status page, and it communicates partial-update behavior. However, it never explicitly names alternatives such as add_status_page_components or update_status_page, nor does it state when one should be preferred over the other.

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