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 are sparse (only readOnly=false, idempotent=false, destructive=false), so the description carries the burden of behavioral disclosure. It excellently covers the trial-run-before-save behavior, the conditional approval prompt, the creation on token scope when no prompt is possible, refusal behaviors (credential in URL, too many regions, browser flows), and credential reference requirements. It does not explicitly mention rate limits or whether the operation is idempotent, but the annotations already signal idempotent=false, and the trial-run behavior is thoroughly described.

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 dense paragraph that front-loads the primary purpose and then layers important caveats. Every sentence earns its place, but the length is substantial and could be lightly structured (e.g., bullet points) to aid scanning. Still, there is no fluff; the density is justified by the number of important behavioral caveats.

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 complexity of this tool (11 parameters, 7 check types, multiple behavioral constraints), the description plus the rich schema covers everything an agent needs: creation semantics, approval flow, alert binding, region policy, credential handling, and exclusions. The output schema exists and the parameter schema is 91% covered, so the description need not enumerate return values or every parameter. The combination is complete enough 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 description coverage is 91%, so the schema already documents most parameters well. The description adds semantic value on top of the schema by clarifying the channel_ids consequence ('paging nobody'), the regions default-selected behavior, the credential-reference rule, and the browser-flow exclusion. It doesn't need to repeat every parameter because the schema covers them; the marginal additions are meaningful.

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 ('Create') and the resource ('a monitor'), enumerates the supported check types (http, tcp, ping, dns, tls_cert, domain_expiry, heartbeat), and differentiates from siblings like update_monitor and create_monitors. It also specifies a key behavioral scope — the trial run before saving and approval-based creation — which sharply distinguishes this from a naive 'create' tool.

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 on when to use the tool and how to behave in specific scenarios: pass channel_ids from list_notification_channels, warn when the org has no channels, leave regions unset unless the user named locations, use list_variables for credential references, refuse URLs with embedded credentials, and direct browser flows to the app. This is exemplary usage guidance.

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

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

The description goes well beyond the annotations by disclosing the trial-run behavior, the single batched confirmation, and the partial-failure semantics: failing items are reported while the rest are still created. It also states 'Not read-only,' which aligns with the readOnlyHint=false annotation and reinforces the mutation risk.

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 five sentences with no filler: batch confirmation, trial run, partial-failure behavior, when-to-use guidance, and parity with create_monitor are all packed in efficiently. The most decision-relevant facts are 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 creation tool with complex nested schema, the description covers invocation behavior, failure modes, confirmation flow, safety, and relationship to the sibling tool. The presence of an output schema and detailed parameter schemas means return-value and field-level details do not need to be repeated in the description.

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 schema already documents the monitors array and every per-monitor field with rich detail. The description adds the cross-tool pointer 'Same per-monitor fields and same limits as create_monitor' and the batch trial-run behavior, but it does not need to explain individual parameters further.

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 and resource: 'Create several monitors at once,' which clearly states the batch capability. It explicitly distinguishes itself from create_monitor by naming the sibling and saying 'Prefer this over repeated create_monitor calls,' leaving no ambiguity about which tool to choose.

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 usage condition: 'whenever the user names more than one thing to watch,' and directly names the alternative (create_monitor) and the trade-off ('it costs them one prompt instead of many'). It also notes that per-monitor fields and limits are the same as create_monitor, so the agent knows what carries over.

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?

Annotations already declare readOnlyHint=true, and "Read-only" merely restates that with no added value. The description does disclose the shape of the response (error sample, full timeline), which gives the agent context about cost/size, but it says nothing about pagination, freshness of the timeline, or auth requirements.

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

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

One sentence, front-loaded with the resource and the concrete fields returned, closed by a two-word safety note. No filler, nothing repeated.

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-id read tool with a fully documented parameter, an output schema, and read-only annotations, the description covers everything an agent needs: what it fetches and roughly what comes back. 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?

Schema description coverage is 100% and the single id parameter is already documented with its source (list_incidents or get_org_health) directly in the schema. The description adds no id-format or sourcing detail of its own, 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?

The description names the resource (a single incident) and enumerates the concrete payload an agent gets back - affected monitor, severity, open/resolved times, error sample, operator-update timeline - which is far more specific than the sibling list_incidents. It never explicitly contrasts itself with that sibling, so it lands just short of a 5.

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: the singular framing and the id parameter make it clear this is the detail fetch you run for one incident, presumably after list_incidents. There is no explicit when-to-use statement, no mention of prerequisites, and no naming of alternatives such as get_incident_metrics.

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, it discloses that credentials are withheld, that the response shape matches what update_monitor accepts, and that it includes state, last error, and uptime. This gives the agent reliable expectations about side effects, redaction, and response semantics.

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

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

The description is dense and front-loaded with the core purpose, and every clause contributes information about config, alerts, state, or usage. It loses a point because the main sentence is a long, nested enumeration that is harder to parse than a structured list or shorter sentences.

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 and the annotations cover read-only behavior, the description still adds everything an agent needs: when to call it, what configuration is returned, how it relates to update_monitor, and what is intentionally omitted (credentials). Nothing required for correct invocation is missing.

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

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

The single parameter id is fully described in the input schema as coming from list_monitors, giving 100% schema coverage. The description adds context about the returned configuration but does not add new meaning to the parameter itself, so the schema-heavy baseline 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 states a precise verb and resource: retrieving one monitor's full configuration, and enumerates exactly what that includes. It differentiates from siblings like get_monitor_history by emphasizing current state, alerts, and uptime rather than historical 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 gives explicit context for when to call it: 'Read this before judging whether a response should have passed, or before changing a monitor.' It does not name the alternative tools to use instead for other monitoring queries, so it stops short of full when-not 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 matches with 'Read-only'. It adds useful behavioral context: returns failure error text, incident windows, per-region breakdowns, and supports distinguishing partial from total outages.

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 tight sentences with no wasted words; the resource and window are front-loaded, and each clause adds useful information. 'Read-only' is brief and reinforces the annotation.

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 readOnly annotation covering safety, the description sufficiently explains what data is returned, how windows work, and when to pass region. Nothing critical is missing 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 description coverage is 100%, so the baseline is 3. The description adds meaning beyond the schema by explaining the region parameter's diagnostic purpose (partial vs total outage) and the overall window scope.

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: one monitor's history over a time window. The enumerated payload (uptime, latency series, per-region split, failures, incident windows) clearly distinguishes it from sibling tools like get_monitor or get_incident.

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?

Implies use for historical monitor analysis over 1h/24h/7d/30d windows, and the region guidance explains how to narrow the view. However, it does not explicitly name sibling alternatives or state when not to use this 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 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 read-only hint is confirmed by the description, and the pooled-caps caveat adds meaningful behavioral context beyond the annotation. It explains why counts can exceed a single org's limits, which prevents misinterpretation of the results.

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 tightly scoped sentences: what the tool reports, the pooled-cap caveat, and the read-only safety note. No filler or redundant detail; each sentence earns its place.

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

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

For a zero-parameter, read-only tool with an output schema, the description provides all the context needed to invoke it correctly and interpret its results. The pooling caveat is especially valuable for understanding abnormal-seeming counts.

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 by definition. The description adds value by describing what the output covers, which compensates for the absence of any parameter documentation.

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 a specific resource (org usage against plan limits) and enumerates the metrics returned (monitors, status pages, members, components, key policy values). This clearly distinguishes the tool from sibling tools like get_org_health and 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 purpose implies when to use the tool: when an agent needs org binding and resource usage against plan limits. However, it does not explicitly contrast this with alternatives such as get_org_health or provide exclusions, leaving some 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?

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 discloses critical behavioral traits: the two flags (awaiting_verification, not_delivering) that indicate a channel may not work, the auto_bind_tags rule for pages, the withholding of settings for security, and that channels are created in the app. This far exceeds the annotation's 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?

The description is a single paragraph but every sentence adds a specific behavioral or field detail. No fluff or redundancy; it is dense yet efficient.

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

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

The description covers all relevant output aspects: field enumeration, unusual status flags, security redaction, and creation context. For a zero-parameter read-only tool, this is fully complete.

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

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

With zero parameters, the schema is trivially complete, so the description has no obligation to explain params. It instead adds helpful field semantics (e.g., 'auto_bind_tags' behavior), which is a bonus beyond the baseline.

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

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

The description clearly states the tool lists the org's notification channels and enumerates key fields (id, name, kind, enabled), distinguishing it from any sibling resource. The verb 'list' and resource are explicit, 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?

No explicit when-to-use or alternative guidance is provided. The unique resource (notification channels) makes it the obvious choice among siblings, but the description does not contrast it with other list tools or state 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?

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?

Beyond the annotations, the description discloses two important behaviors: the tool may show a confirmation prompt when the client supports it, and otherwise it operates using the token's scope. It also confirms the non-read-only and idempotent nature, giving an agent a clear model of side effects and repeatability.

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 compact sentences front-load the core purpose and then add only high-value behavioral notes. Every sentence earns its place, with no redundant 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?

For a one-parameter tool with an output schema and full parameter documentation, the description covers purpose, effect, confirmation behavior, auth scope, and idempotency. Nothing essential to invoking 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?

The sole id parameter is fully documented in the schema, including its provenance from list_monitors, so schema description coverage is 100%. The tool description adds no additional parameter-level meaning, so the baseline of 3 applies.

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

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

The description opens with a specific verb and resource: 'Pause a monitor', and immediately clarifies the effect with 'stop its checks until resumed.' This makes the tool's purpose unambiguous and distinguishes it from siblings like resume_monitor and run_check_now by defining the state transition it performs.

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 explicit when-to-use or when-not-to-use guidance, and no alternative tools are named. The intended use is implied by the purpose, but the description does not mention resume_monitor as the counterpart or run_check_now as an alternative for immediate checks.

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, destructiveHint=false), the description adds valuable side-effect context: 'Status-page subscribers may be notified' and 'Asks for confirmation where the client can show a prompt; otherwise runs on the token's scope.' This enriches the behavioral profile without contradicting annotations.

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

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

Three sentences, each carrying weight: the core effect, the notification side effect, and the confirmation/scope behavior. Front-loaded with the main action, no fluff or repetition.

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

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

With an output schema present and annotations covering safety/idempotency, the description covers the essential operational details: effect, optional fields, side effect, confirmation, and scope. It could mention an existing-incident prerequisite, but that is implied by the required 'id' parameter and is minor.

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

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

The input schema already describes all three parameters with 100% coverage. The description adds only that public_title and public_description can be 'seeded', which loosely maps to the schema's 'public' fields. Since schema covers semantics, the baseline 3 is appropriate; description adds marginal value.

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: 'Publish an incident so it appears on every status page carrying the affected monitor.' It also mentions optional seeding of public title/description, which distinguishes it from siblings like unpublish_incident or post_incident_update without needing to inspect their schemas.

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

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

The description gives clear context for when to use the tool: to make an incident appear on status pages. It does not explicitly name alternatives or exclusions, but the phrasing 'Publish' and the mention of status pages versus updates makes the intended use apparent. Lacks explicit 'use X instead' 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 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?

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?

Annotations already flag destructive and non-read-only behavior, and the description adds substantial behavioral detail: channel_ids/tags replace entire sets, an empty channel list silences the monitor, Terraform-managed monitors are refused, and the tool shows old/new values before executing or falls back to running on the token's scope. This goes well beyond the annotation flags and matches destructiveHint.

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

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

The description is dense and well-structured: primary purpose and editable fields first, exclusions second, runtime behavior last. The trailing 'Not read-only' is mildly redundant with the annotations, but every other sentence earns its place and no significant content is missing.

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 9-parameter mutation tool with a full input schema, output schema, and annotations, the description covers the invocation-critical gaps: destructive replacement semantics, Terraform refusal, auth scope, and prompt behavior. An agent can use this tool correctly without opening the schema for most decisions.

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, but the description adds one genuinely schema-absent fact: channel_ids requires the channels:read scope. It also translates parameter names into readable concepts (e.g., 'reminder interval' for renotify_interval_secs), though most details are already present in the schema.

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

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

The description opens by explicitly stating the tool's function—'Change how loudly a monitor is watched'—and enumerates the specific mutable settings (check interval, alert confirmations, tags, channel_ids, region quorum, etc.). It further distinguishes itself from siblings by listing what it refuses to change (name, address, assertions, owner), making its scope unmistakable.

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

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

The description gives clear negative guidance: it cannot change what the check watches and refuses Terraform-managed monitors, so an agent knows when this tool is not appropriate. It does not explicitly name an alternative tool or instruct calling get_monitor first, though the schema's parameter descriptions partially cover that need.

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.