hyperping

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

Annotations already cover idempotentHint=true and destructiveHint=false, but the description adds key behavioral insights: it stops repeat alerts, but escalation steps still fire on schedule. This goes beyond annotations to explain side effects, which is valuable for 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?

Two sentences with no fluff. The key action is front-loaded, and the caveat about escalations is placed right after. 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 the simple 1-parameter tool with full schema coverage, no output schema, and the behavioral detail provided, nothing essential is missing. It clearly tells when to use and what to expect.

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

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

Schema coverage is 100% with a single 'uuid' parameter described as 'Outage UUID from list_outages.' The description does not add extra parameter semantics beyond that, but since coverage is full, a baseline of 3 is appropriate.

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

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

The description clearly states the action ('mark as handled') and the resource ('ongoing outage'), and immediately distinguishes it from sibling tools like resolve_outage by noting that escalation steps still fire. This is a specific verb+resource with clear differentiation.

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

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

It explicitly explains when to use this tool: when an outage is being handled but not yet resolved. It also contrasts with resolve_outage, as it mentions that resolving or fixing the cause stops escalations, implying resolve_outage is for that. This gives clear context and route.

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

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

The description discloses important behavioral traits beyond the annotations: the update is public and will be sent to subscribers unless notify_subscribers is false. This adds real context about visibility and side effects that the annotations alone do not convey, although it does not cover all possible outcomes like incident reopening.

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 concise sentences with no filler. The core action is front-loaded, and the important public-notification behavior is stated immediately after.

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, combined with a fully documented schema and annotations, provides enough context for an agent to invoke the tool correctly. It clarifies the public nature and subscriber notification default, though it does not describe the response format or any additional side effects beyond what the schema already covers.

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 input schema already documents every parameter. The description adds little beyond the schema—it repeats the status enum and the notify_subscribers effect—but it does not need to compensate for missing schema 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 verb ('Post') and resource ('update on a status page incident') and enumerates the valid status values, so an agent immediately knows what the tool does. It is clearly distinguishable from siblings like edit_status_page_incident_update or resolve_status_page_incident based on the action word and resource 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 implies when to use the tool—when posting a new update to an incident—but does not explicitly state when not to use it or name alternatives such as edit_status_page_incident_update. The notification behavior is mentioned, but exclusions and sibling differentiation are left 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 cover readOnlyHint=false, idempotentHint=true, destructiveHint=false, and the description adds genuine value beyond them: section auto-creation at the end, defaulting to the first section, and the non-destructive guarantee that existing services stay put. This contextualizes the idempotent/non-destructive profile well.

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 compact sentences with zero filler. The core purpose is front-loaded and the placement behavior is stated in one tight follow-up clause. Every sentence earns its place.

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

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

For a mutating tool with no output schema, the essential behavioral context (section handling, non-destructiveness, service types and paused-monitor restriction) is well covered. The only gap is the absence of return-value/response expectations, which is minor for a mutation action.

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 of 3 applies. The description adds no parameter-level meaning beyond the schema; all five parameters (uuid, section, services, show_uptime, show_response_times) are already fully documented in the schema itself.

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 ('Show monitors or components on a status page') and clarifies scope with section placement rules. The phrase 'Services already on the page stay where they are' implicitly distinguishes it from the sibling remove_status_page_services by emphasizing its additive, non-removing nature.

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 usage context through behavior details (section creation, first-section default, paused-monitor refusal) but never explicitly says when to use this versus alternatives or names the sibling remove_status_page_services. No when-not-to-use guidance is provided.

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 (destructiveHint=true, idempotentHint=true), the description discloses concrete side effects: the window is deleted, it leaves status pages, and subscribers are not notified of the cancellation. This adds meaningful behavioral context the annotations alone do not provide.

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 concise sentences, each earning its place: the action and scope, the side effects, and the alternative for a different case. The most important information is front-loaded.

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

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

For a simple one-parameter tool with rich annotations and no output schema, the description fully equips an agent: what the tool does, when it applies, what side effects occur, and which sibling to use instead. Nothing essential 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 parameter uuid is already documented with its format ('mw_...'). The description does not add parameter-specific detail, but it does not need to because the schema fully covers the parameter semantics.

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

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

States a specific verb ('Cancel') and resource ('maintenance window'), and immediately narrows scope to windows that have not started. It also distinguishes itself from complete_maintenance_window by describing the delete-and-leave-status-pages effect.

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

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

Explicitly says when to use it ('a maintenance window that has not started') and when not to, pointing to the sibling tool complete_maintenance_window for an in-progress window. It also warns that subscribers already notified will not be told about the cancellation, setting expectations clearly.

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 operation as non-readOnly, idempotent, and non-destructive. The description adds useful behavioral context beyond these hints: it explains that monitors resume checks/alerts and that status pages transition to completed. It does not cover edge behavior (e.g., repeated calls), but the idempotentHint covers that.

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

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

A single sentence, front-loaded with the action and condition, followed by the consequences. Every clause adds information; there is 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 one-parameter mutation tool with rich annotations, the description gives enough information to call it correctly and set expectations for the result. No output schema is present, but the description explains observable effects sufficiently.

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 uuid parameter already has a clear description including the format 'mw_...'. The tool description adds no meaning beyond the schema, 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?

Description uses a specific action ('End a maintenance window in progress now') and clearly names the resource and the outcome ('checks and alerts resume', 'status pages show it as completed'). It distinguishes from obviously read-oriented siblings, but does not explicitly differentiate from cancel_maintenance_window, so it falls one step short of full sibling differentiation.

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

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

The phrase 'in progress now' gives clear context for when this tool applies, and the absence of 'scheduled' or 'upcoming' suggests it is not for future windows. However, it does not explicitly name when to use cancel_maintenance_window or update_maintenance_window instead, so alternatives are not spelled out.

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

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

Annotations only mark the operation as non-read-only and non-destructive. The description adds meaningful behavioral facts: checks and alerts are suspended during the window, selected status pages announce it, and the window is public once status pages are attached. This is valuable context beyond the annotations and with no contradiction.

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

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

The description is two compact sentences with no filler. It front-loads the core action and effect, then states the important privacy/consent caveat in the second sentence. 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?

With 10 parameters, the schema fully documents field semantics, and the description supplies the behavioral and consent context that schema cannot convey. The description does not mention return values or error cases, but with no output schema this is a minor gap rather than a critical omission.

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 extra meaning by connecting the monitors parameter to 'checks and alerts stop' and the status_pages parameter to 'announce it'/'public', which clarifies the real-world consequences of those parameters beyond their schema definitions.

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 action ('Schedule') on a maintenance-window resource and explains the concrete effect: checks and alerts stop for the named monitors, and passed status pages announce the window. This distinguishes it from maintenance-window lifecycle siblings like update_maintenance_window or cancel_maintenance_window.

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 one important precondition: 'confirm with the user first' if status pages are passed, because the window becomes public. However, it does not explicitly explain when to choose this tool over alternatives such as update_maintenance_window, cancel_maintenance_window, or complete_maintenance_window; that choice is left mostly 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 indicate readOnlyHint=false, implying a write operation. The description adds no further behavioral detail beyond the act of creation – no side effects, duplicate handling, or authorization requirements. Since annotations exist, the description adds minimal value beyond them.

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 17-word sentence, front-loaded with the core action. No filler; every phrase earns its place. This is appropriately sized for a concise summary.

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?

Despite 20 parameters and no output schema, the description is extremely brief. It covers required fields and a hint about port/dns, but doesn't explain return values, error cases, or how to select among the many optional parameters. Given the tool's complexity, the description leaves 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 each of the 20 parameters is already documented. The description adds a small grouping hint (port for port checks, dns_* for DNS checks) which slightly helps, but doesn't go beyond schema explanations like 'required when protocol is port'. 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 opens with 'Create a new monitor', a specific verb+resource that clearly distinguishes from siblings like update_monitor, pause_monitor, and create_outage. It also notes required name+url, reinforcing the creation action.

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 says 'Requires name+url' and instructs to add 'port' for port checks and 'dns_*' for DNS checks, giving some usage context. But it doesn't explicitly say when to use create_monitor vs update_monitor or other alternatives, and doesn't mention exclusions. The guidance is implied rather than explicit.

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

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

The description discloses key behavioral consequences beyond the annotations: the incident appears in the Incident Management dashboard, it pages on-call responders when an escalation policy is attached, and it is internal only with nothing published on a status page. These are important side effects not captured by readOnlyHint, 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?

Three sentences, each earning its place: the core action, the dashboard/paging effect, and the internal-vs-status-page distinction. The most important information is front-loaded, and there is no redundant wording.

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 create tool with fully documented parameters and clear side-effect disclosure, the description is nearly complete. The only minor gap is that it does not mention what the tool returns on success, but since there is no output schema and the tool's behavior is well covered, this is not a significant deficiency.

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 minimal parameter meaning beyond the schema; the escalation policy behavior is mentioned, but the schema already documents that without one nobody is paged. No parameter needs additional clarification.

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: 'Declare an incident by hand, for a problem no monitor detects.' It clearly distinguishes itself from create_status_page_incident by noting that this tool does not publish to a status page, which separates it from the most similar sibling.

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

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

It explicitly says when to use this tool: for problems no monitor detects, i.e., manual declaration. It also names the alternative create_status_page_incident for status-page publication, giving the agent a clear branch between the two 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 indicate this is a write operation (readOnlyHint=false, destructiveHint=false, openWorldHint=true). The description adds a key behavioral detail: the page is public as soon as it exists, and the need for user confirmation. This goes beyond the annotations and helps the agent understand side effects and required pre-checks.

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 sentences with zero filler. It front-loads the core action, immediately flags the public-visibility consequence, and then notes what is not covered. Every sentence earns its place.

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

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

For a tool with 10 parameters and a nested sections array, the schema covers parameter details thoroughly, and the description covers the critical behavioral context (immediate public access, user confirmation, dashboard-only settings). No output schema exists, but the description doesn't need to explain returns. Slightly missing is explicit error handling or permission requirements, but overall adequate.

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

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

Schema description coverage is 100%, so the schema already documents all parameters. The tool description does not add new parameter-specific semantics beyond what the schema provides (e.g., subdomain pattern, sections structure). Baseline 3 is appropriate since the description adds no extra meaning to parameters.

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

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

The description clearly states a specific verb (create) and resource (status page on hyperping.app subdomain), and specifies it includes sections of monitors and components. This distinguishes it from sibling tools like update_status_page or create_status_page_incident, so an agent knows exactly what it does.

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

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

It explicitly instructs to confirm name, address, and services with the user first because the page becomes public immediately. It also notes that password protection, SSO, custom domain, and logo are set in the dashboard, implicitly excluding those from this tool. It does not explicitly contrast with update_status_page, but the usage context is clear.

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

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

Annotations already signal a mutating, non-idempotent operation, so the bar is lower. The description adds valuable behavioral context: the incident is public and emailed to subscribers unless notify_subscribers is false, which is a significant side effect an agent must know before invoking.

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

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

Two sentences with no wasted words. The primary purpose is front-loaded, the critical side-effect warning comes second, and the alternative tool is named in the same sentence. Every clause earns its place.

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

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

For an 8-parameter tool with no output schema, the description plus the rich schema covers what an agent needs: purpose, side effects, required user confirmation, and a clear alternative. It does not describe return values, but the schema and annotations cover the parameter space adequately.

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

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

Schema description coverage is 100%, so the schema already documents all parameters. The description reinforces the notify_subscribers behavior and the 'first update' concept, but it does not add meaning beyond what the property descriptions already provide, hence the baseline score 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 states a specific verb and resource: 'Publish an incident on status pages, with its first update.' It also differentiates from the sibling create_outage by explicitly noting the internal incident path, so an agent can distinguish the two tools immediately.

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 when-to-use versus when-not-to-use directive: 'To record an incident internally and page on-call instead, use create_outage.' It also instructs the agent to 'confirm the wording with the user first,' which is a concrete usage prerequisite.

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 mark this as destructive (destructiveHint=true) and non-read-only, so the description's job is to add nuance. It does: it states the correction is shown on the page, subscribers are not re-notified, and the original date is preserved. This discloses side effects beyond the annotation flags, which is exactly what behavioral transparency needs.

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, no wasted words. The first sentence states the core purpose and gives a concrete example (typo); the second covers key behavioral consequences. Information is front-loaded and every clause earns its place.

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

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

For a 5-parameter tool with 100% schema coverage and no output schema, the description covers the essential use case and the main side effects. It doesn't mention edge cases like editing after resolution or restrictions on language, but those are not critical for an agent to call the tool correctly. The required parameters (uuid, update_uuid) are obvious from the schema, and the status semantics are already in the schema. Overall, it's sufficiently 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?

Schema description coverage is 100%, so all parameters are already documented. The description only reinforces that the tool edits 'text or stage', which maps to message and status, but adds no new parameter-level detail beyond the schema. Since the baseline for high coverage is 3, this stays at 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 a specific verb ('Correct') and a specific resource ('an update already posted'), with a concrete example ('e.g. a typo'). It distinguishes itself from siblings like add_status_page_incident_update by emphasizing 'already posted', and from resolve_status_page_incident by focusing on updates rather than incident resolution. An agent can immediately tell what this tool does.

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: it's for correcting an existing update, not for creating a new one. The phrase 'already posted' and the typo example implicitly route agents away from add_status_page_incident_update. However, it doesn't explicitly name the alternative or state when NOT to use it, so it falls short of the highest bar. It's still clear enough for most cases.

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 the tool is non-read-only, non-idempotent, and non-destructive. The description adds the key behavioral trait that 'each call moves one step further', which goes beyond the annotations and is critical for predicting side effects. It does not disclose error conditions (e.g., reaching the final step), but given the annotations cover the safety profile, this is acceptable.

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 with no filler. It front-loads the action ('Page the next step') and immediately follows with the behavior ('Each call moves one step further'). Every word earns its place.

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

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

For a simple one-parameter tool with annotations covering mutation and non-idempotence, the description explains the effect (pages next step) and the step-wise nature. Since there is no output schema, the description does not need to explain return values. It lacks details on failure modes or prerequisites, but these are not necessary for basic 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%, with the single parameter uuid clearly documented as 'Outage UUID from list_outages.' The description adds no additional parameter semantics beyond what the schema already provides, so the baseline of 3 applies.

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

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

The description states a specific verb ('Page') and resource ('outage's escalation policy'), and clarifies the behavior (moves one step further). This clearly distinguishes it from sibling tools like acknowledge_outage and resolve_outage, which serve different purposes. The phrase 'now instead of waiting for it' further clarifies the action.

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

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

The description provides clear context for when to use this tool: to trigger escalation immediately rather than wait for automatic policy timing. It does not explicitly mention alternatives or exclusions (e.g., 'use acknowledge if you only need to acknowledge'), but the context is sufficient for an agent to identify the appropriate scenario. Lacks explicit 'when not to use' guidance, so not 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?

Annotations already declare readOnlyHint=true, covering safety. The description adds value beyond annotations by disclosing what the response reveals: step sequence, linked schedules, and contact channels. It does not contradict the read-only hint and provides meaningful behavioral context for a simple getter.

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 with no filler. The core operation is front-loaded, and the second sentence earns its place by summarizing the useful response contents.

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, read-only getter with no output schema, the description is complete: it states the scope, the lookup key, and the returned content. An agent has everything needed 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 single uuid parameter is already fully documented with its format. The description adds no additional parameter semantics beyond confirming UUID-based lookup, which matches the baseline for high schema coverage.

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 'One policy by UUID,' identifying the specific verb-resource pairing and scope. It distinguishes this from list_escalation_policies and other get_* tools by emphasizing a single policy lookup and enumerating the returned details.

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 'One policy by UUID' clearly indicates the appropriate context: use this when you have a specific escalation policy UUID. It does not explicitly name the alternative for listing policies, but the context is clear enough for an agent to select this over list_escalation_policies.

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

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

Annotations already declare readOnlyHint=true, so the safety profile is covered. The description adds useful context about the response contents (channel-specific config, webhook URL, routing), but does not address error behavior, authentication requirements, or rate limits. This is acceptable but not particularly rich.

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, efficient sentence that leads with the core action and resource, then adds the most valuable detail about what is included in the response. Every word earns its place; there is no redundancy.

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

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

For a simple one-parameter read-only lookup, the description is largely sufficient: it names the resource, the identifier, and the key contents of the result. The absence of an output schema is partially mitigated by the mention of channel-specific config, though a more explicit list of returned fields or not-found behavior would make it fully complete.

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

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

Schema description coverage is 100% and the single parameter 'uuid' is already well documented in the schema. The description adds no new parameter-level detail beyond what the schema provides, so the baseline score 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 ('get'), a precise resource ('integration'), and the lookup key ('by UUID'). It also distinguishes this from list-style siblings by emphasizing 'One integration', making the tool's scope immediately clear.

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 implies this tool is for fetching a single integration when the UUID is known, but it does not explicitly mention alternatives such as list_integrations for browsing all integrations. Usage context is clear, yet no exclusions or alternative routing are provided.

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 openWorldHint=false, so the safety profile is covered. The description adds useful context about what the response contains, but it does not disclose not-found behavior, error cases, or any additional operational details. 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 a single, tightly scoped sentence with no filler. The core distinction—one maintenance window, including updates and subscriber notification state—is front-loaded and immediately actionable.

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, read-only retrieval tool with no output schema, the description adequately conveys the response content. The schema covers the only parameter, and annotations cover the side-effect profile, so an agent has the essentials needed 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?

The single uuid parameter is fully documented by the schema with format context ('Maintenance window UUID (format "mw_...")'). With 100% schema description coverage, the description is not required to add parameter semantics, and it does not.

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 (maintenance window), the singular scope (one window), and the return contents (updates and subscriber notification state). This distinguishes it from list_maintenance_windows and update_maintenance_window based on the text alone.

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 only implied through the word 'one' and the tool name, suggesting a single-window fetch rather than listing all windows. There is no explicit statement about when to prefer this tool over list_maintenance_windows or when it should not be used.

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's 'Fetch' is consistent with that. The description adds no further transparency about error handling, authentication, or response format, but the low bar set by annotations is met. No contradiction.

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

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

A single, front-loaded sentence with no wasted words. It directly states the action, target, and key qualifier, making it an efficient and well-structured description.

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

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

For a simple single-parameter fetch tool with read-only annotations and no output schema, the description provides all necessary information to call it correctly. Nothing critical is missing.

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

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

Schema coverage is 100% since the only parameter uuid is fully described with its format. The description merely repeats 'by its UUID' without adding additional meaning beyond the schema, so it meets the baseline for high coverage.

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 (Fetch) and a specific resource (single monitor), and qualifies it by UUID, clearly distinguishing it from list_monitors or search_monitors_by_name. An agent can immediately know what this tool does without ambiguity.

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 a specific monitor UUID is known, but does not explicitly contrast with list or search tools. There is no mention of alternatives or conditions, so the guidance is implicit rather than explicit.

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

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

Annotations already declare readOnlyHint=true, covering the safety profile. The description adds useful context about the kind of output (anomaly types), but does not disclose additional behavioral details such as response format, time range, or pagination.

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, focused sentence that front-loads the core purpose and adds illustrative examples. There is no redundant or filler content.

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 one-parameter read-only tool with no output schema, the description adequately conveys what the tool returns and its scope. It could mention response structure or time range, but the current level is sufficient 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%, and the single uuid parameter is already documented with its format. The description does not add further parameter-level meaning beyond what the schema provides, so the baseline score of 3 is appropriate.

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

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

The description clearly states that the tool returns anomaly-detection output for a single monitor, with concrete examples like flapping and latency spikes. It is distinguishable from list-style siblings by the 'single monitor' scope, though it does not name a specific alternative 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 implies the tool should be used when anomaly-detection results for one monitor are needed, and the 'single monitor' phrasing provides some scope guidance. However, it does not explicitly state when to prefer this over sibling get_monitor_* tools or mention exclusions.

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

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

Annotations already declare readOnlyHint=true, so the safety profile is covered. The description adds useful behavioral context by stating the logs are 'recent' and 'paginated,' which goes beyond the annotations. It stops short of describing the exact content or ordering of the logs, but for a read-only list endpoint this is adequate.

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 with zero filler. The main subject is front-loaded, the pagination trait is stated second, and the diagnostic use case closes the description. Every word earns its place.

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

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

For a simple read-only list operation with full parameter schema coverage, the description competently conveys what is returned, how it is returned (paginated), and when to use it. The absence of an output schema is not a major gap since 'HTTP probe logs' sufficiently describes the payload.

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

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

Schema description coverage is 100%, so all four parameters are fully documented in the schema. The description's 'paginated' hint relates to page/limit but adds no new semantic detail beyond what the schema already states, 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 clearly identifies the resource ('HTTP probe logs for a monitor') and mentions pagination, which distinguishes it from sibling monitor getters like get_monitor_uptime or get_monitor_outages. Although it lacks an explicit verb, the title and tool name supply 'get', making the purpose unambiguous.

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

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

The phrase 'Useful to diagnose recent check failures' provides clear context for when to use this tool. It does not explicitly name alternatives or state when not to use it, but the diagnostic purpose is specific enough to guide selection among the many monitor-related getters.

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 signal read-only behavior, and the description adds useful non-obvious behavioral context: the tool is batch-oriented, returning per-monitor breakdowns, and looping is expensive and rate-limit-prone. This goes beyond the annotation's safety profile, though it does not describe response shape in detail.

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 focused sentences with no fluff: the first states what the tool computes, and the second delivers the only critical invocation nuance. The most important usage warning is front-loaded and direct.

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 read-only aggregation tool, the description plus fully documented schema parameters cover what an agent needs: metric, unit, date-window defaults, batching behavior, and rate-limit caution. No output schema exists, but 'MTTA per monitor, in seconds' provides adequate expectations for the return value.

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

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

Schema description coverage is 100%, so the schema already documents all three parameters thoroughly, including defaults and batching semantics. The description repeats the batching point but adds no new parameter-level meaning beyond what the schema already provides, matching the 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 a specific metric (MTTA), the resource (monitors), and the unit (seconds), so an agent immediately knows what the tool computes. It does not explicitly distinguish itself from the near-named sibling get_monitor_mttr, but the phrase 'mean time to acknowledge' makes the purpose specific enough to avoid serious confusion.

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: it applies to a date window and is already per-monitor, and it instructs the agent to pass all monitors at once rather than loop. It does not explicitly mention when to choose this tool over get_monitor_mttr or other metrics, so it stops short of full when/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 provide readOnlyHint=true, so safety is known. The description adds valuable behavioral context: the tool aggregates multiple monitors in a single query, returns a per-monitor breakdown, and implies rate-limit consequences for improper use. This goes beyond annotations. It does not detail the response format, but the per-monitor breakdown is mentioned.

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

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

The description is two sentences with no filler. The first sentence front-loads the purpose and units. The second sentence packs the critical usage instruction (batching) and its rationale, including a concrete consequence (rate limit). Every phrase earns its place; it is efficient and well-structured.

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

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

For a read-only tool with zero required parameters, full schema coverage, and no output schema, the description covers the essential: what it returns, how to invoke it (batch), and the omit behavior. It lacks a detailed response structure, but given the simplicity and annotations, it is reasonably complete. A small gap remains in describing the exact output format, but it is not critical for correct invocation.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds significant semantics for monitor_uuids: instructing to pass every monitor in a single call, noting the cost equivalence of N monitors to one, and warning about rate limits. It also clarifies the omission behavior. For from/to, it relies on schema defaults, but the additional monitor_uuids guidance raises the score.

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

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

The description clearly states the tool returns 'Mean time to resolve (MTTR) per monitor over a date window, in seconds.' It specifies the resource (monitors), the metric (MTTR), the aggregation (per monitor), and the unit (seconds), distinguishing it from sibling tools like get_monitor_mtta and other monitor metrics. No ambiguity.

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 guidance: 'pass all monitors at once in monitor_uuids rather than calling this once per monitor' and warns about rate limiting and cost when looping. It also explains the omission behavior ('Omit to cover the whole project'). It does not explicitly contrast with alternative tools for other metrics, but the core usage pattern is clear.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds the pagination behavior (paginated list) but does not disclose return format or any edge cases. Since annotations carry the safety burden, this is acceptable but minimal.

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

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

Two sentences with no filler. The core purpose is stated first, and the relationship to list_outages is conveyed in a compact second sentence. Everything earns its place.

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

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

For a read-only, scoped list tool with full schema coverage and annotations declaring safety, the description is sufficient. An agent has all it needs to call it correctly: the scoping, the pagination hint, and the read-only nature are all covered.

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% – every parameter (page, status, monitor_uuid) has a clear description in the schema. The tool description adds no parameter-specific meaning beyond what the schema already provides, 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 states a specific verb ('list') and resource ('outages scoped to one monitor'), and explicitly differentiates from the sibling list_outages by calling it a convenience wrapper. An agent can immediately understand what this tool does and how it differs.

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 context: it is a scoped wrapper around list_outages, so it should be used when you have a monitor_uuid and want that monitor's outages. However, it does not explicitly state when to prefer list_outages instead, leaving the alternative comparison implicit rather than explicit.

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

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

Annotations already mark this as read-only and non-open-world, so the safety profile is covered. The description adds useful behavioral context: the tool returns a per-monitor breakdown and is designed for batched multi-monitor queries rather than per-monitor loops.

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 concise sentences. The core purpose is front-loaded, and the batching instruction follows without redundancy or filler.

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

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

For a read-only trend query with no required parameters and a rich schema, the description is nearly sufficient. It doesn't detail the exact return shape beyond 'per-monitor breakdown,' but given the simple tool type and strong schema, that is a minor gap.

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 mentions monitor_uuids batching, but the input schema already documents that behavior in more detail, so the description adds little 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?

States a specific verb and resource: 'Response time latency trend over a date window.' It also clarifies the output shape ('Returns a per-monitor breakdown'), which distinguishes it from sibling metric tools like get_monitor_uptime or get_monitor_mttr.

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 clear invocation guidance: pass all monitors at once in monitor_uuids rather than calling once per monitor. It doesn't explicitly name alternative tools or say when not to use it, but the date-window and response-time context makes the intended use clear.

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

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

Annotations already declare readOnlyHint=true, so no safety disclosure is needed from the description. The description adds aggregation and grouping behavior, but does not mention rate limits, return shape, or SLA calculation details. This is acceptable given the annotations, but the description itself adds only modest behavioral context.

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

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

One 13-word sentence that front-loads the core purpose and packs the optional grouping into a compact clause. No filler or repetition of schema details.

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 schema covers all four optional parameters with defaults, enum values, and batching/rate-limit guidance, and annotations cover the read-only safety profile. The description states the output metric and grouping options, which is sufficient given the simple return value. The main omission is explicit sibling routing, but that is already scored under usage_guidelines.

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's 'date window' and 'per day/hour/week/month' loosely map to from/to and resolution, but add no meaning beyond the schema's own descriptions and defaults. It does not mention monitor_uuids, which the schema documents thoroughly.

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 metric (uptime percentage) over a date window, and the title adds 'SLA stats.' This clearly distinguishes it from sibling monitor tools like get_monitor_response_time or get_monitor_outages. The optional grouping by day/hour/week/month further clarifies 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 gives no guidance on when to choose this tool over alternatives such as get_monitor_response_time or get_monitor_mttr. The only usage hint (batching monitors in one call) lives in the monitor_uuids parameter schema, not in the tool description. An agent must infer selection from the title and metric name.

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 provide readOnlyHint=true, and the description complements this by disclosing what the response contains: full rotation detail and linked escalation policies. It adds meaningful behavioral context without contradicting 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?

One short sentence that front-loads the core operation ('One schedule by UUID') before describing response contents. 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?

For a simple read-only getter with one fully documented parameter, the description provides sufficient behavioral context (what is returned) without an output schema. 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?

The schema fully documents the single required uuid parameter, including the expected 'sch_...' format. The description only restates that lookup is by UUID and adds no new parameter-level meaning. Baseline 3 applies because coverage is 100%.

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 retrieves a single schedule by UUID and specifies the included content (full rotation detail, linked escalation policies). This distinguishes it from list_on_call_schedules and other get_* siblings without requiring schema inspection.

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 'One schedule by UUID' makes the use case apparent: call when you have a specific schedule UUID and need its full details. It does not explicitly name list_on_call_schedules as the alternative for listing all, but the context is clear enough.

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 establishes that this is a safe read operation, lowering the burden on the description. The description adds useful context by revealing the response includes acknowledgements, description, and root cause, but it does not mention behavior on not-found cases or other edge conditions. This is adequate but not rich.

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

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

The description is a single compact sentence that front-loads the core action and identifier before listing the returned fields. Every word earns its place and there is no redundant phrasing or filler.

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

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

For a one-parameter, read-only fetch tool, the description is nearly complete: it names the operation, the identifier, and the main returned content. The lack of an output schema is partially mitigated by the listed fields, though it could mention not-found behavior or confirm the full object shape.

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 documents the only parameter, uuid, at 100% coverage with the description 'Outage UUID.' The tool description merely repeats 'by UUID' without adding format, source, or additional semantic detail, so it does not meaningfully exceed 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 uses a specific verb ('Fetch') with a precisely bounded object ('a single outage') and identifier ('by UUID'), making the tool's scope unmistakable. It also lists the detail fields returned (acknowledgements, description, root cause), which clearly differentiates it from list_outages and get_outage_timeline.

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 conveys that this tool is for retrieving one specific outage when a UUID is known, which implicitly distinguishes it from list-style siblings. However, it does not explicitly name alternatives or state when not to use the tool, so it stops short of full 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?

The annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is established. The description adds useful scope about the kind of events included, but it does not disclose ordering, time range, whether the timeline is paginated, or how entries are represented in the response.

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 states the artifact and then enumerates the lifecycle phases. Every word contributes; there is no filler, restatement of the tool name, or repetition of schema details.

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, read-only tool, the description is nearly complete: it tells the agent what will be returned and the schema covers the input. A minor gap is the absence of output-shape details, such as whether the timeline is ordered chronologically or returned as an array of events, but this does not prevent 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?

The input schema has 100% coverage and already documents the uuid parameter, including its accepted formats ('outage_...' or 'INC-123'). The description adds no additional parameter-level meaning, so the baseline score of 3 applies.

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

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

The description names a concrete resource—an outage timeline—and lists the specific event categories returned: detection, cross-region verification, alert dispatches, acknowledgement, and resolution. This clearly distinguishes it from related tools like get_outage, which would return current outage state rather than an activity timeline.

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 'Full activity timeline for an outage' implies that an agent should use this when it needs lifecycle history rather than current outage status, so context is present. However, there is no explicit when-not-to-use guidance or mention of alternatives such as get_outage or list_outages; the agent must infer the correct choice.

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 openWorldHint=false, so the agent knows this is a safe, read-only operation. The description adds value by disclosing the structure of the response: it includes settings (languages, subscriptions, access) and the services with their UUIDs. This goes beyond the annotations and helps set expectations for the output. It doesn't contradict any 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 a single, focused sentence that front-loads the core purpose ('One status page') and then lists the key elements returned. There is no fluff or redundant information. Every word contributes to understanding the tool's function.

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 that there is no output schema, the description must convey what the agent can expect in the response. It does so by naming the categories: settings (languages, subscriptions, access) and services with UUIDs, section by section. This gives a good high-level picture of the return structure. It could be more detailed (e.g., exact format), but it is sufficient for an agent to understand the tool's purpose and outcome.

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

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

The schema already fully describes the single parameter 'uuid' with format 'sp_...' (coverage 100%). The description does not add any additional meaning to the parameter itself; it only describes what the tool returns. Since the schema covers the parameter semantics completely, the baseline of 3 is appropriate.

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

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

The description clearly states that this tool retrieves a single status page with its settings (languages, subscriptions, access) and the services it shows, section by section, with UUIDs. It uses the specific 'get' verb and distinguishes it from list_status_pages by emphasizing 'one' status page. The scope and return content are explicit.

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 about what the tool returns (detailed settings and services for a single page), implying it should be used when you need the full details of a specific status page rather than a list. It does not explicitly name alternatives or state when not to use it, but the context is clear enough for an agent to infer appropriate 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, so the read-only safety profile is covered. The description adds useful behavioral context beyond annotations by disclosing the response composition and update ordering (newest first, with UUIDs).

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

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

The description is a single compact sentence that front-loads the resource and includes the key return details without 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?

For a low-complexity single-parameter read tool with no output schema, the description adequately conveys what the response contains: the incident, its updates in order with UUIDs, status pages, and affected components. Nothing essential 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 coverage is 100% and the uuid parameter is already documented with its format ('inci_...'). The description mentions UUIDs of updates but does not add further meaning to the input parameter itself, 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 states a specific verb and resource: retrieving one status page incident. It also specifies what is included—every update newest-first with UUIDs, status pages, and affected components—which clearly distinguishes it from list_status_page_incidents and create/update/resolve incident siblings.

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 singular phrasing 'One status page incident' combined with the required uuid parameter makes the get-by-id use case clear. It does not explicitly contrast with list_status_page_incidents or other incident tools, so it stops short of a 5.

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

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

Annotations already declare readOnlyHint=true, so the description's job is to add detail. It precisely specifies the returned content: counts and a list of down monitors with timestamps. No additional behavioral traits (e.g., pagination) are disclosed, but given the simplicity and read-only nature, this is adequate.

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

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

A single sentence with zero waste. The key outputs (counts and list) are front-loaded, and every word adds value.

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 no-parameter, read-only tool with no output schema, the description fully specifies what the agent will receive. There are no missing details that would prevent correct invocation or interpretation of the result.

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

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

There are zero parameters, so schema coverage is 100%. Per the baseline rule for 0 params, a score of 4 is appropriate. The description doesn't need to explain parameters that don't exist.

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: it provides counts of up/down/paused monitors and a list of currently down monitors with timestamps. This clearly distinguishes it from sibling get_* tools that focus on individual monitors or outages.

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 for a high-level status overview. It doesn't explicitly name alternatives, but the tool is unique among siblings, so no exclusions are needed. The clear purpose makes when-to-use evident.

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

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

Annotations already declare readOnlyHint=true, so the description doesn't need to restate safety. It adds minimal context about scope (all policies in project) but doesn't mention pagination, ordering, or other response details. With no output schema, more could be added, but the description is not misleading.

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 extremely concise—two short sentences with no fluff. It front-loads the purpose and adds a brief use case. Every word earns its place.

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

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

For a simple list tool with zero parameters and read-only annotations, the description is mostly sufficient. However, it doesn't mention pagination or result size, which could matter for listing many policies. Given the tool's simplicity, this is a minor gap.

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

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

There are no parameters, and the schema requires none. The description adds a use case but doesn't need to explain parameters. The baseline of 4 for zero-parameter tools applies.

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

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

The description clearly states the tool lists all escalation policies in the project and suggests a use case (finding where monitors route alerts). It is distinguishable from the sibling get_escalation_policy, though it doesn't explicitly contrast them.

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 (listing policies) and hints at a use case, but it doesn't explicitly state when not to use it or when to prefer the sibling get_escalation_policy over it.

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

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

The annotations already declare readOnlyHint=true, so the description need not repeat that. It adds a list of integration examples, which gives some context about what may be returned. However, it does not disclose pagination, response format, or any other behavioral details beyond the read-only nature 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 a single, concise sentence that front-loads the core function. It avoids unnecessary words and effectively communicates the scope without 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?

The description covers the essential purpose but omits details like output structure or pagination behavior. Given that there is no output schema and annotations only cover read-only safety, an agent might need more information about what the response looks like. However, for a simple list-all tool, the description is adequate but not thorough.

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 baseline is 4. The description clarifies that the tool returns 'all' integrations, implying no filtering parameters are needed. Since the schema is empty, the description adds sufficient semantic clarity about the absence of parameters.

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

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

The description clearly states the resource (notification integrations) and the action (listing all of them), and enumerates common types. It also implicitly differentiates from the sibling get_integration, which retrieves a single integration. This is a specific and unambiguous purpose.

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 no guidance on when to use this tool versus alternatives such as get_integration or list_monitors. It only states what the tool does, leaving the agent to infer usage context. There are no explicit when-to-use or when-not-to-use instructions.

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 openWorldHint=false, so the safety profile is covered. The description adds useful behavioral context: pagination (20 per page) and the inclusion of related objects and a status field. However, it lists status values (upcoming, inprogress, completed) that are inconsistent with the schema's timeline enum (upcoming, ongoing, past), which could mislead an agent about valid status values. This partial transparency earns a 3.

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 fragment sentence, which is concise but not well-structured. It lacks a clear subject-verb-object structure and mixes response content details with pagination. The most important element (that it lists maintenance windows) is implied by the title rather than stated. It is not front-loaded with the primary action, though it is short.

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

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

For a read-only list operation with optional parameters, the description covers the returned content (monitors, status pages, updates, status) and pagination, but it does not mention that the timeline parameter is optional or that omitting it returns all windows. The schema does cover this, but the description could have reinforced it. Since there is no output schema, the description should more explicitly describe the response shape, which it partially does. Overall, it is adequate but not fully complete.

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

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

The input schema provides 100% coverage with clear descriptions for both page (zero-indexed, 20 per page) and timeline (enum, omit for all, newest first). The tool description does not add meaning beyond the schema; it merely repeats the pagination detail. Since the schema already does the heavy lifting, a 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 title explicitly says 'List maintenance windows', and the description clarifies the scope by mentioning pagination and the included data (monitors, status pages, updates, status). It clearly refers to a plural resource, distinguishing it from get_maintenance_window. However, the description itself is a fragment without an explicit verb, so it relies on the title for the action.

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 no guidance on when to use this tool versus alternatives like get_maintenance_window (for a single window) or create/update/cancel/complete_maintenance_window. It does not mention any selection criteria or exclusions. The agent must infer usage from the tool name and schema.

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

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

Annotations already declare readOnlyHint=true, so the read-only nature is covered. The description adds that the tool is paginated and supports a status filter, which are behavioral details beyond the annotation. However, it does not disclose what fields the returned list contains or whether pagination metadata (e.g., total count) is included. Given the annotation already covers safety, a 3 is appropriate – the description adds some context but not rich 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 a single sentence with no filler. It front-loads the core purpose ('Paginated monitors') and immediately states the optional filter. Every word earns its place – it is concise and well-structured.

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 list tool with no output schema, the description covers the essentials: pagination, optional filter, and the resource being listed. It does not mention return format or sorting, but given the tool's simplicity and the read-only annotation, this is adequate. The presence of sibling tools like get_monitor implies the list likely returns summaries, and the description is sufficient for an agent to invoke 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 all three parameters (page, limit, status) are already documented in the input schema. The description mentions 'paginated' and 'status filter', but these are redundant with the schema's parameter descriptions. It adds no new semantic meaning beyond what the schema already provides, so the baseline of 3 applies.

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

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

The description clearly states the action ('list monitors') and the scope ('in the project'), plus the optional status filter. It distinguishes from get_monitor (singular) by plural 'monitors', but does not explicitly differentiate from search_monitors_by_name. Still, the verb 'list' with pagination implies a bulk listing operation, making the purpose clear enough.

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 no guidance on when to use this tool versus alternatives like search_monitors_by_name or get_monitor. It does not mention exclusions or conditions. An agent would have to infer that this is the tool for enumerating all monitors with filters, but no explicit when-to-use or when-not-to-use guidance is given.

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

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

readOnlyHint=true already signals that this is a safe read operation, and openWorldHint=false supports the exhaustive 'all schedules' claim. The description adds that entries typically include rotation config and current on-call, which is useful. However, it does not clarify response format, ordering, pagination, or what 'typically' excludes, so the added behavioral detail is moderate.

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 with no wasted words. The first sentence front-loads the scope, and the second adds the actionable detail about what each entry contains. It does not duplicate the title or the schema.

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

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

With no parameters, no output schema, and read-only annotations, the description provides the key facts an agent needs: it returns all schedules, and entries carry rotation config and current on-call information. It is complete enough for safe tool selection, though a more precise entry shape would remove the slight ambiguity of 'typically.'

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

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

There are zero parameters, so schema description coverage is vacuously 100% and there are no parameter semantics to clarify. The description correctly does not invent or repeat parameter information. This matches the baseline for a zero-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 indicates this tool returns all on-call schedules in the project and characterizes the entries, so it is not a tautology. The plural 'All' helps distinguish it from the singular sibling get_on_call_schedule, though that sibling is not explicitly named. A small gap is that the description does not itself state the verb 'list' or 'returns.'

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 guidance is implied: use this when you want all on-call schedules rather than a single one. There is no explicit statement of when to prefer get_on_call_schedule or any other alternative. The wording gives clear context but no exclusions or alternative 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?

Annotations already declare readOnlyHint=true, so the safety profile is covered. The description adds behavioral context about pagination and filter availability, but it does not disclose return shape, ordering, or default filter behavior beyond what the schema already states.

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 core purpose and then list filters with no wasted words. Every sentence earns its place.

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

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

For a read-only, paginated list tool with 100% schema coverage and zero required parameters, the description is nearly sufficient. The main missing element is what fields each outage entry contains, but the lack of an output schema is mitigated by the tool's straightforward listing nature.

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 even though the description adds little beyond listing the filter dimensions. The schema already documents page, type, search, and status semantics.

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 verb ('list') and resource ('outages in the project'), and mentions pagination and filter dimensions. This clearly distinguishes it from single-outage tools like get_outage and monitor-scoped tools like get_monitor_outages.

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

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

The description establishes a clear project-wide listing context and specifies the available filters, which implies when this tool is appropriate. It does not explicitly name alternatives or exclusions, but the scope is clear enough to guide selection 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?

The readOnlyHint annotation already tells the agent this is a safe read operation, so the description's main behavioral addition is the 'up/down transitions' scope and the default 30-day window. It does not disclose response structure, pagination behavior, or any limits beyond the schema defaults. This is acceptable for a simple read-only list tool but not richly transparent.

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 compact sentences with no filler. It front-loads the core purpose and then adds the default behavior. Every sentence earns its place.

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

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

For a list tool with four documented optional parameters and a read-only annotation, the description is mostly adequate. However, there is no output schema and the description does not mention pagination, result ordering, or what fields each alert notification contains. Sibling differentiation guidance is also missing, leaving some context gaps for an agent choosing among related tools.

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 parameters are already fully documented in the schema. The description adds minimal parameter-level meaning beyond clarifying the alert domain. This matches the baseline of 3 for tools where the schema handles 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 clearly states the tool returns alert notifications (up/down transitions) over a date range. This distinguishes it from sibling tools like list_outages or get_monitor_outages by emphasizing notifications rather than raw outage records. The title and description together make the resource and action unambiguous.

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

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

The description gives useful context by defining the resource and the default date range, so an agent can infer when it might apply. However, it does not explicitly state when to use this tool versus alternatives such as get_monitor_outages or list_outages, nor does it mention exclusions. Usage is implied rather than explicitly guided.

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 read-only, so the description adds useful behavioral context beyond them: newest-first ordering and what each incident entry contains. No hidden side effects are implied.

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 with no filler. The core scope is front-loaded and the sibling pointer is placed efficiently at the end.

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

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

For a read-only list tool with three optional parameters and no output schema, this description is complete: it covers ordering, return contents, and the relevant alternative. The schema handles filter semantics.

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 does not need to restate the parameters. It also does not add extra meaning beyond what the schema already provides.

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

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

Description identifies the resource (incidents published on status pages), the ordering (newest first), and the result shape (current stage, latest update). It also explicitly distinguishes this tool from list_outages.

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

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

Explicitly states when not to use it: 'For downtime detected on monitors, use list_outages.' This gives clear routing guidance between 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, so the read-only nature is known. The description adds pagination behavior (20 per page) and the fields returned, which is useful context beyond the annotations. No contradiction; it augments the safety profile with pagination details.

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

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

The description is a single, compact sentence that front-loads the core purpose (listing status pages) and immediately states key details (20 per page, fields). Every word earns its place with no redundancy.

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

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

For a simple list tool with two optional parameters and no output schema, the description covers the essential behavior: what is returned, pagination, and scope. It could mention the search behavior (substring on name/hostname) but that is already in the schema, so the description is sufficiently 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?

Schema description coverage is 100%, so both parameters (page, search) are fully documented. The description adds no new parameter details beyond what the schema provides; it only restates the pagination size which is already in the schema. Baseline 3 is appropriate.

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

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

The description clearly states a specific verb (list) and resource (status pages), and mentions the key attributes (UUID, name, public URL, password protection). This distinguishes it from get_status_page which returns a single status page, and from other 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 gives context (project, 20 per page) but does not explicitly mention when to prefer this over alternatives like get_status_page or list_status_page_incidents. The use case is implied for enumeration, but no exclusions or alternative routing are provided.

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 return-content context ('names and emails') and the scoping 'on the project' beyond the readOnlyHint annotation. It does not mention pagination or exact ID fields, but for a zero-parameter read-only list this is acceptable detail.

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 carry all the necessary information, with the core result stated first and the use case immediately after. There is no filler or repeated schema content.

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, read-only, parameterless list tool without an output schema, the description tells the agent what the call returns and why to call it. No additional context is needed to invoke it correctly.

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

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

There are no parameters, so the input schema is trivially complete and there is nothing for the description to explain. The baseline of 4 for a parameterless tool 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 title supplies the verb-resource pair ('List team members') and the description specifies the exact resource: users on the project, including names and emails. This clearly distinguishes it from sibling list tools such as list_monitors or list_on_call_schedules, which target different resources.

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

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

The description provides a concrete use case: resolve user IDs from schedules/policies. It does not name exclusion criteria or alternative tools, but the intended context is clear and no sibling tool covers project users.

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 record idempotentHint=true, destructiveHint=false, and readOnlyHint=false. The description adds behavioral context by explicitly stating the operational effect ('no checks run and no alerts fire') and the underlying equivalence to update_monitor with paused=true, which goes beyond the structured fields.

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 entire description is one front-loaded sentence that immediately states the action, adds two concrete behavioral consequences, and gives the equivalent API. Every clause 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 single-parameter, idempotent mutation with rich annotations and no output schema, the description covers what the action does, what it stops, and how it relates to the update_monitor sibling. Nothing essential is missing for an agent to invoke 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% and the only parameter, uuid, is already described as 'UUID of the monitor to pause.' The tool description does not add parameter-specific detail, so the schema carries the semantic weight; 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 states a specific action ('Pause a monitor') and clarifies the exact behavioral scope by saying no checks run and no alerts fire. It also situates itself relative to update_monitor with paused=true, which makes the tool's identity 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 provides a clear usage context: use this tool when the goal is to pause a monitor so checks and alerts stop. It references update_monitor as the equivalent general alternative, but it does not explicitly mention when-not-to-use or the resume_monitor sibling.

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 signal destructive and idempotent behavior, and the description adds concrete detail by stating that display-name and description settings are lost. It also expands the removal scope ('wherever they appear, groups included'), giving useful behavioral context beyond the annotation flags.

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 with no filler; the action and scope come first, and the consequence (lost settings) is stated second. Every sentence earns its place.

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

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

For a two-parameter removal tool with full schema coverage and appropriate annotations, the description covers the purpose, scope, and irreversible side effects. It could mention that paused monitors are refused or that no result schema exists, but those are either already in the schema or not essential for correct invocation.

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

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

Schema coverage is 100%, so the schema fully documents both uuid and services, including UUID formats, valid source lists, and the paused-monitor restriction. The description does not add parameter-specific semantics beyond what the schema already provides, 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 uses a specific verb and resource: 'Take monitors or components off a status page', and clarifies scope with 'wherever they appear, groups included'. This clearly differentiates it from sibling tools like add_status_page_services and update_status_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?

It gives clear context for when to use the tool: removing monitors or components from a status page, including from groups. It does not explicitly name an alternative or state when not to use it, but the action is specific enough that an agent can select it correctly.

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 useful behavioral context beyond the annotations: it discloses that the tool sends recovery notifications to the channels that were paged, and that monitor-detected outages auto-resolve. This complements the idempotentHint and destructiveHint annotations without contradicting them.

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

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

Two sentences with no filler. The primary action and key side effect are front-loaded, and the caveat about monitor-detected outages is stated succinctly.

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 resolution tool, the description covers the action, the applicable incident types, the notification side effect, and an important auto-resolution edge case. With supportive annotations and a simple schema, 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%, and the uuid parameter is already documented as 'Outage UUID from list_outages.' 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 uses a specific verb ('Resolve') and identifies exactly what is resolved: incidents declared by hand or server incidents. It also distinguishes itself by noting the recovery notification behavior and the self-resolving nature of monitor-detected outages, which separates it from sibling actions like acknowledge_outage or escalate_outage.

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 indicates when this tool applies (hand-declared or server incidents) and provides an implicit when-not by stating monitor-detected outages resolve themselves. It does not explicitly name alternative tools, but the usage context is clear enough for an agent to decide appropriately.

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

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

Annotations already cover non-read-only, non-destructive, and idempotent behavior. The description adds useful behavioral context by disclosing that it refuses already-resolved incidents and that it writes a final 'resolved' update. This goes beyond what the annotations alone express, though it does not detail side effects such as subscriber notifications.

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 tightly worded sentences communicate the core action, the relationship to the sibling tool, and an important refusal behavior. 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?

For a tool with fully documented parameters, clear siblings, and safety-related annotations, the description is complete enough to guide correct invocation. The refusal condition and the 'final resolved update' behavior cover the key operational context, and no output schema is present to require return-value documentation.

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 documents all four parameters with meaningful descriptions, including defaults for language and notify_subscribers. The tool description adds no parameter-level detail, so the baseline of 3 is appropriate.

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

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

The description uses a specific verb and resource ('Close a status page incident with a final resolved update') and clearly differentiates this from add_status_page_incident_update by framing it as the same operation with status 'resolved'. An agent can tell exactly what this tool does and how it differs from nearby siblings.

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 names add_status_page_incident_update as the equivalent operation with status 'resolved', which tells an agent when to choose this tool. It also provides a clear when-not condition: it refuses an incident that is already resolved.

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 idempotentHint=true, destructiveHint=false, and readOnlyHint=false, covering the safety profile. The description adds the equivalence to update_monitor with paused=false, but does not disclose additional behavioral details such as failure conditions or side effects beyond what annotations provide.

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 with no redundant wording. The core action is front-loaded, and the clarifying alternative is stated efficiently.

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 one-parameter tool with annotations covering idempotency and safety, the description is adequately complete. It explains the action and the relationship to update_monitor, though it does not describe return values or error behavior, which are not critical for this simple operation.

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

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

Schema description coverage is 100%, with the uuid parameter already documented as 'UUID of the monitor to resume.' The description adds the paused=false equivalence, which slightly clarifies intent, but it does not significantly extend the parameter 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 states the action ('Resume a paused monitor') with a specific verb and resource. It also distinguishes itself from update_monitor by explicitly noting the equivalence with paused=false, making the tool's purpose unambiguous.

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

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

The description provides clear context for when to use the tool: to resume a paused monitor. It names the alternative update_monitor and explains the relationship, though it does not explicitly state when not to use this tool or enumerate exclusions.

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 and openWorldHint annotations already cover the safety profile. The description adds the case-insensitive substring matching behavior, but it largely duplicates the query parameter description and does not disclose result limits, pagination, or response shape.

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

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

A single sentence that front-loads the operation and scope with no wasted words. The description is appropriately sized and easy to parse at a glance.

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, read-only search tool, the description combined with the schema and annotations provides everything an agent needs to invoke it correctly. The expected result—a list of matching monitors—is implied and no complex behavior requires further explanation.

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

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

Schema description coverage is 100%, with the single required query parameter fully described as a case-insensitive substring matched against monitor names or URLs. The tool description adds no additional parameter-level meaning, so the baseline score of 3 applies.

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

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

The description states a specific verb ('search'), a clear resource ('monitors'), and a precise scope ('names and URLs'). It clearly differentiates from siblings like list_monitors (full listing) and get_monitor (exact retrieval), even without naming them.

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 its use case—finding monitors by partial name or URL—but does not explicitly state when to prefer it over list_monitors or get_monitor. With many sibling tools available, an explicit routing note would strengthen this dimension.

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 communicate that this is a mutating, destructive operation (readOnlyHint=false, destructiveHint=true), so the description's job is to add context. It does: 'The pages show the change; subscribers are not notified' discloses a real behavioral consequence not derivable from annotations or schema. This is exactly the kind of side-effect information that helps an agent set expectations correctly. It stops short of describing effects on existing scheduled windows or whether changes are immediately visible vs. staged.

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

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

Two sentences with zero filler. The first sentence front-loads the verb and enumerates all operation categories compactly; the second adds the single most decision-relevant side effect. Every clause earns its place.

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

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

For an 11-parameter destructive mutation with no output schema, the description reasonably covers the full action space and one key side effect. However, it omits partial-update semantics (only uuid is required, so calling with just uuid presumably touches nothing), validation relationships (e.g., end_date after start_date), and any notion of idempotency. The openWorldHint=true annotation signals unknown extra behaviors that the description does not attempt to bound. Adequate, but with clear gaps for such a complex 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 description coverage is 100% and every parameter already has rich documentation with formats and examples (e.g., ISO 8601 dates, 'mw_...' UUID format, per-language behavior). The description adds a light action-to-parameter mapping ('rename it' → name/title, 'post a public update' → message/language, 'change monitors or status pages' → add/remove arrays), but the schema carries the heavy lifting. 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 opens with concrete action verbs ('Reschedule', 'rename', 'change', 'post') applied to a specific resource (maintenance window) and enumerates exactly what can be modified: schedule, name, monitors, status pages, and public updates. This clearly differentiates it from siblings like create_maintenance_window, cancel_maintenance_window, and complete_maintenance_window by naming the operations only update 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?

The action list ('reschedule', 'rename', 'change monitors or status pages', 'post a public update') gives clear context for what the tool is for, but it never explicitly states when NOT to use it or names alternatives. An agent must infer that early termination is handled by cancel_maintenance_window or that a brand-new window belongs to create_maintenance_window. Usage guidance is implied rather than stated.

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

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

Annotations declare readOnlyHint=false, destructiveHint=true, and idempotentHint=true, so the description doesn't need to repeat those. The description adds value by clarifying that unspecified fields are preserved, which is a specific behavioral guarantee beyond the annotations. It does not contradict any 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?

Two sentences with no wasted words. The action is stated first, followed by the critical usage rule. It is front-loaded and immediately actionable.

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 21 parameters are fully described in the schema, annotations cover idempotency and destructiveness, and the description explains the partial-update behavior, the tool is adequately specified. It does not mention return values or error handling, but no output schema exists and the operation is straightforward. Minor gaps like return format are not critical for a patch 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 description coverage is 100%, so each parameter already has a descriptive text. The tool description does not add any parameter-specific meaning beyond the generic 'pass only fields you want to change', which is about usage rather than individual parameter semantics. 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 ('Patch a monitor') and the resource (monitor). It distinguishes itself from siblings like create_monitor, pause_monitor, and resume_monitor by implying modification of an existing monitor. The partial-update semantics ('Pass only fields you want to change; others are preserved') adds precision beyond a generic 'update'.

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

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

It explicitly instructs the agent to pass only fields to change, which is the core usage rule. It does not mention alternatives or when-not-to-use (e.g., 'use create_monitor for new monitors' or 'use pause_monitor to toggle pause'), but the partial-update guidance is clear and sufficient for selecting this tool over create_monitor. It lacks explicit exclusions but is not misleading.

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 context beyond the annotations: it discloses partial-update semantics ('Only the fields passed change') and flags that the page is public, requiring user confirmation. Annotations already state idempotent and destructive hints, and the description does not contradict them.

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 action and target, followed by necessary caveats. Every phrase earns its place: the field list, the partial-update rule, and the public-confirmation warning.

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 12 parameters but a rich schema and informative annotations, the description covers the essential behavioral context: what can change, how partial updates behave, and the public nature requiring confirmation. It does not explain return values, but there is no output schema and the mutation's purpose is sufficiently clear.

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 75%, leaving font, theme, and hide_from_search_engines undocumented by the schema. The description names some parameter categories like name, description, website, and subscription button, and adds the partial-update rule, but it does not compensate fully for the undocumented parameters. It is adequate but not exceptional.

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 begins with a specific verb ('Change') and resource ('status page'), then enumerates the distinct settings it affects: name, description, website, look, or subscription button. This clearly separates it from related tools like update_status_page_incident or update_monitor by focusing on status page settings.

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 important usage context: only the fields passed are changed, so callers can do partial updates without specifying all fields. It also instructs the agent to confirm with the user first because the page is public. It does not explicitly mention alternatives, but the tool's resource and scope are clear enough.

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 destructiveHint=true, readOnlyHint=false, idempotentHint=true, and openWorldHint=true. The description adds valuable behavioral detail beyond those: immediate publication to status pages and the absence of subscriber notifications. It also implies reversibility via remove_* parameters, which is not stated in annotations but is consistent with idempotency.

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 concise sentences: the first states the core purpose, the second covers immediate effect and lack of notification, the third points to the alternative for notifying. Every sentence contributes, and the most critical info is front-loaded. No redundancy or fluff.

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

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

Despite having 8 parameters and no output schema, the description combined with the fully-documented schema and annotations gives an agent everything needed to call the tool correctly. It explains the primary use case, the behavioral nuance, and points to the sibling for notifications. No critical gap remains.

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

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

Schema description coverage is 100%, with each parameter fully documented (enums, formats, constraints, references). The description's mention of 'title, type, status pages or affected services' maps directly to schema properties but adds no new semantic information. Per the baseline for full coverage, this is 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 states a specific verb ('Change') and resource ('status page incident'), and enumerates the mutable fields (title, type, status pages, affected services). This clearly distinguishes it from siblings like create_status_page_incident, resolve_status_page_incident, and edit_status_page_incident_update, so an agent can select it without confusion.

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 usage context: changes take effect immediately but subscribers are not notified. It then names the alternative action ('post an update') for when notification is desired. This provides a clear when-to-use vs when-not-to-use distinction, covering the primary decision point.

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