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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states that a new check is created and advises validation first; it does not disclose what the tool returns, whether creation can produce duplicate checks, or what side effects a successfully created and enabled check has.

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

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

Two tight sentences with the main operation front-loaded. The second sentence earns its place by pointing to the exact tools needed for uncertain config shapes, so there is no filler or redundant restatement of 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?

The schema covers all 12 parameters well, and the description gives a useful pre-creation workflow. However, with no output schema and no annotations, the description leaves return values and post-creation behavior to inference, which is a meaningful gap for a tool with nested config and side effects.

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 each parameter already has a meaningful inline description, so the baseline is 3. The description adds useful sequencing guidance around config discovery and validation, but it adds no new parameter-level semantics 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?

The description states a specific verb and resource: 'Create a new monitoring check.' This clearly distinguishes the tool from the many status-page, integration, and maintenance-window creation siblings in the tool list.

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

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

The description gives explicit workflow guidance: if the config shape is unknown, call get_check_type_samples first and use validate_check to dry-run before creating. It does not explicitly contrast with update_check, but the create-versus-update distinction is strongly implied by the sibling tools.

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

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

With no annotations, the description must carry the full behavioral burden. It discloses the title templating behavior (internal title never exposed), which is a valuable transparency point. However, it does not mention side effects (e.g., whether it sends notifications, modifies other resources), permission requirements, or reversibility. For a write operation, this is a moderate disclosure but incomplete.

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 main action and adds a key caveat about title templating. It is concise without being terse, and the dash-separated clause adds necessary context without excess verbosity.

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

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

The tool has no output schema and no annotations, and the description does not cover error conditions, return values, or prerequisites beyond 'EXISTING'. It also does not clarify the relationship to sibling tools (e.g., create_status_page_incident). For a mutation with two required parameters, the description is adequate but lacks depth that an agent might need for robust invocation.

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

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

Schema description coverage is 100%, so the schema already explains all four parameters. The description adds no additional semantics for the parameters; it only mentions title templating, which is a behavioral trait rather than a parameter detail. The baseline 3 is appropriate because 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 states a specific verb ('Publish') and resource ('an EXISTING internal incident onto a status page'), and adds a clarifying detail about title templating that distinguishes it from simply creating a status page incident. It clearly differentiates from siblings like create_status_page_incident and delete_incident_publication.

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 does not provide any guidance on when to use this tool versus alternatives. It doesn't mention when to choose this over creating a status page incident manually, nor any prerequisites beyond the incident existing. The phrase 'EXISTING' implies a condition, but there is no explicit routing to or away from sibling tools.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions that Slack is rejected, but does not state what happens on success (e.g., whether it returns the created integration), any validation side effects, permission requirements, or whether changes are immediately visible. For a mutation tool with zero annotation coverage, this is a significant transparency gap.

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

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

The description is two sentences with no wasted words. It front-loads the core action and then adds the critical Slack exclusion. Every sentence earns its place, and it stays under the ideal length without sacrificing key information.

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

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

Given the tool's complexity (5 parameters, a nested settings object, and no output schema), the description does not explain the return value on success or any prerequisites like permissions. The schema covers parameter specifics well, but the absence of behavioral and return-value context means an agent may be uncertain about what to expect after calling it. Adequate but not 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 the schema already documents all parameters with type-specific details (e.g., settings format, allowed types). The description adds contextual purpose ('attached to checks for incident notifications') but does not meaningfully augment parameter meaning beyond the schema. The baseline of 3 applies because the schema does the heavy lifting.

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

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

The description states a specific verb and resource: 'Create a new integration' and clarifies the types (webhook, email, msteams) and purpose (attached to checks for incident notifications). It also distinguishes itself from other integration-related tools by explicitly excluding Slack and pointing to the dashboard OAuth flow. This leaves no ambiguity about what the tool does and how it differs from list_integrations or incident_notifications_list.

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

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

The description gives a clear when-to-use signal for creating webhook/email/msteams integrations and an explicit exclusion with an alternative for Slack ('install it via the dashboard OAuth flow instead'). It doesn't cover other exclusions like duplicate names or update flows, but the primary choice between this tool and the dashboard is clearly 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?

With no annotations, the description must carry behavioral disclosure. It adds one useful behavioral fact: the underlying service does the operation in two steps but the tool handles it atomically. However, it does not mention side effects, permission needs, or failure behavior for this mutating operation.

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

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

Two sentences with no redundancy. The primary purpose is front-loaded, and the compound behavior (checkUids handling) is explained in the second sentence without wasting words.

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

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

The description covers the creation intent and the notable check-attachment behavior for an 8-parameter tool. The main gap is the lack of any statement about what the tool returns (e.g., the created window object or UID), which matters since no output schema is provided.

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 each parameter is documented with formats, examples, constraints, and recurrence semantics. The description adds no parameter-level meaning beyond that, 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 and resource: "Schedule a new maintenance window." The note about attaching checks in the same call also differentiates it from sibling set_maintenance_window_checks, making the operation 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?

It clearly situates the tool for creating a new window and implies the alternative of attaching checks later via the two-step service mention. It does not explicitly enumerate when to use update/delete/set-maintenance-checks instead, leaving a small gap in 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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states that it creates a resource; it does not mention potential conflicts (e.g., only one default page), required permissions, or side effects on the organization's status pages. This is insufficient for a create operation.

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

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

The description is concise and front-loaded, with two sentences. The first states the purpose and the second defines the concept. It avoids fluff but could benefit from a mention of alternatives, though it is appropriately sized.

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

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

Given the tool has 13 parameters and no output schema, the description is quite minimal. It does not explain the expected outcome (e.g., a new status page object) or any constraints like the uniqueness of slug or default page. However, the schema covers parameter details, so the description is adequate but not comprehensive for an operation with many parameters.

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% description coverage, so the schema already documents all 13 parameters thoroughly. The tool description adds no additional parameter context, which is acceptable given the 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 clearly states the action (create) and the resource (status page), and provides a one-sentence definition of what a status page is. It does not explicitly contrast with sibling tools like create_status_page_section, but the scope 'for the organization' and the resource type distinguish it adequately.

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 the many sibling tools (e.g., create_status_page_section, update_status_page). It states what it does but does not mention alternatives or conditions, leaving the agent to infer usage from the 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?

With no annotations, the description carries the behavioral burden: it clearly states the incident is published and that title/body are customer-visible, which is important safety context. It does not disclose other behavioral traits such as whether notifications are triggered, whether creation is immediate/reversible, or what response is returned.

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 first states the action, the second delivers the critical customer-visibility constraint. The warning is front-loaded where it will be noticed.

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 combination of full schema coverage and the customer-visibility warning is enough to invoke the tool correctly. However, with no output schema and no annotations, the description leaves the return value and post-creation effects unstated, and it does not address how this tool relates to incident publication/update siblings.

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 covers all 6 parameters, so the baseline is 3. The description adds meaningful parameter-level value by warning that both title and body are shown to customers and must not contain internal data—this is not fully stated in the bodyMarkdown schema description.

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 identifies the specific action ('Publish a hand-written incident') and resource ('status page'), and the customer-facing warning helps distinguish it from internal incident tools. It does not explicitly name sibling tools like create_incident_publication or update_status_page_incident, so it stops 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 'hand-written incident' implies this is for manually authored incidents, and the customer-exposure warning implies not to use it for internal or automated content. However, there is no explicit when-to-use/when-not-to-use guidance or mention of alternatives such as create_incident_publication.

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 two important behavioral traits beyond the schema: (1) updates are append-only with no edit or delete, and (2) the body is customer-facing, so probe output or internal names must never be included. This is valuable context for an agent deciding whether to call this tool and how to phrase the body. However, it doesn't mention that certain 'kind' values advance the publication's state, which is a behavioral side effect an agent should know. The schema does mention this, but the description could have reinforced it.

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

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

Three sentences with zero waste. The core action is front-loaded, the critical constraint (append-only) is stated immediately, and the customer-facing warning is a single concise 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?

For a tool with no annotations and no output schema, the description covers the essential behavioral context: what the tool does, its append-only nature, and the content restrictions. It doesn't explain the state-advancing side effect of certain 'kind' values, but the schema already documents that. The description is complete enough for an agent to call the tool correctly without opening the schema.

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

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

Schema description coverage is 100%, so the schema already documents all five parameters. The description adds the customer-facing warning for bodyMarkdown and the append-only constraint, which gives extra meaning to the bodyMarkdown parameter. However, it doesn't add detail about pageIdentifier or publicationUid beyond what the schema provides. Baseline 3 is appropriate because the schema carries the heavy lifting.

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 ('Append'), a specific resource ('narrative update to a published incident'), and a critical scope constraint ('APPEND-ONLY — no edit or delete'). This clearly distinguishes it from sibling tools like update_status_page_incident and create_status_page_incident, which operate on different resources or with different semantics.

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 when to use this tool: when you need to add a narrative update to an existing published incident. It does not explicitly name alternatives or exclusions, but the append-only constraint and the customer-facing warning provide strong context. The sibling list includes create_status_page_incident and update_status_page_incident, and the description's emphasis on append-only helps an agent avoid confusing this with an update tool.

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

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

With no annotations, the description carries the burden of behavioral disclosure. It does disclose a meaningful behavior: a check group is rendered as one aggregated component that never lists its members, and the resource is publicly displayed. However, it omits other behavioral traits such as whether duplicate pins are prevented, whether the section must already exist, or any permission requirements.

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

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

A single sentence that front-loads the action ('Pin a check — or a whole check group... to a status-page section') and uses the parenthetical to add a useful behavioral distinction without filler. 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 create tool with 7 fully documented parameters but no output schema, the description conveys the core action, public visibility, and aggregation behavior. It doesn't mention preconditions like section existence, but the schema and sibling tools (create_status_page_section, update_status_page_resource) fill most of that 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 schema already documents all 7 parameters and the mutual exclusivity of checkUid/checkGroupUid. The description adds slight nuance ('never lists its members') but largely mirrors what the schema already states, 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 ('Pin') and names the exact resource and target: a check or check group attached to a status-page section as a publicly-displayed resource. It clearly differentiates from sibling tools like create_status_page_section, list_status_page_resources, and update_status_page_resource.

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

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

The description gives clear context for when to use the tool: when an existing check or group should appear publicly on a status-page section. It does not explicitly name exclusions or alternatives, but the action and target are specific enough that an agent can infer when this tool applies versus section creation or resource list/update 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?

With no annotations, the description carries the full burden of disclosing behavioral traits. It only states the action 'Create a new section' without describing what happens after creation—whether an ID is returned, what validation occurs, or any side effects. For a write operation, this is a significant gap.

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 with zero filler. It front-loads the core action and is appropriately sized for a simple create operation. While it lacks depth, it is not verbose or redundant.

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 4 parameters (3 required), no output schema, and no annotations, the description is too sparse. It doesn't mention what the tool returns, any prerequisites (e.g., needing an existing status page), or when to use it over siblings. An agent would lack essential context for correct invocation beyond the raw schema.

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

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

Schema description coverage is 100%, meaning every parameter has a description in the schema itself. The tool description adds no parameter-specific meaning beyond what the schema already provides. Per the baseline, a 3 is appropriate since the schema does the heavy lifting.

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 ('Create') and resource ('a new section within a status page'), making the core purpose clear. It is specific enough to distinguish from tools like create_status_page, but it doesn't explicitly contrast with sibling create tools such as create_status_page_resource, which also operate on status page sub-entities. The term 'section' narrows it adequately, so a 4 is warranted.

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. It doesn't mention conditions, prerequisites, or alternatives like update_status_page_section or create_status_page_resource. An agent has no context to decide when this is the right tool among many sibling create/update operations.

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

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

With no annotations, the description carries the full transparency burden. It discloses the non-destructive nature ('soft-delete'), the immediate effect, and that historical results are retained. It does not mention authorization, reversibility, or nonexistent identifiers, but for a single-parameter delete operation it is 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?

Two short sentences with no filler. The action and key behavioral consequence are front-loaded, and every clause adds information.

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

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

For a one-parameter tool with no output schema, this description gives the caller all necessary behavioral context: what the tool deletes, how to identify the check, what happens immediately, and what persists afterward. 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?

The schema already documents the identifier parameter with complete coverage and examples, so the description adds little beyond restating 'by UID or slug'. Baseline 3 applies because the schema handles the heavy lifting.

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 ('soft-delete') with a clear resource ('monitoring check') and identifiers ('by UID or slug'), distinguishing it from sibling delete tools for status pages and maintenance windows. It also adds what happens when deleted, so there is 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 implies when to use it (delete/stop a check) and clarifies a key effect ('stops running immediately'), but it does not explicitly contrast this with alternatives such as update_check or explain when not to use it. The usage context is clear enough, but the guidance is not 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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It explicitly states that the publication row is retained for audit, the incident disappears from the public page, and the same incident can be republished later—critical transparency for a delete-named operation.

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

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

Two concise sentences front-load the main action and immediately follow with the most important behavioral caveats. There is no filler or redundant restating of the tool name.

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 two-parameter operation with no output schema, the description is complete. It explains what the tool does, what happens to the public page, what is retained, and whether the action is reversible, giving an agent everything 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?

Schema description coverage is 100%, so both parameters are already documented in the schema. The description adds context about 'publication row' and audit behavior, but it does not significantly extend the meaning of the parameter names beyond what the schema 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?

The description uses a specific verb ('Unpublish') and resource ('an incident from a status page'), making the operation immediately clear. It also differentiates this tool from sibling delete tools by emphasizing the audit-preserving, reversible nature of 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 clearly conveys when this tool should be used: to remove an incident from a public status page while retaining the audit trail. It does not explicitly name alternatives or exclusions, but the context and behavior make the intended usage obvious.

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

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

With no annotations, the description carries the behavioral burden. It does disclose the key trait that this is a soft delete rather than a permanent deletion, which is valuable, but it does not explain consequences such as reversibility, idempotency, or effects on associated 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?

A single, front-loaded sentence conveys the operation, target, input, and deletion mode with no wasted words. Every element 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 one-parameter tool with no output schema, the description is nearly complete: it identifies the required input and the soft-delete behavior. It leaves minor gaps around return value and error conditions, but those are not essential for invoking the tool correctly.

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

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

Schema coverage is 100% and the single uid parameter is already described as 'Maintenance window UID.' The description's 'by UID' reinforces the parameter's role without adding new format or constraint details, 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 action ('Delete'), the resource ('maintenance window'), and the key input ('by UID'), and adds the important qualifier 'soft delete.' This clearly distinguishes it from sibling tools such as create_maintenance_window, update_maintenance_window, and get_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?

No guidance is provided about when to use this tool versus alternatives, such as update_maintenance_window for modifications or set_maintenance_window_checks for changing associations. 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?

The description explicitly says 'soft-delete' rather than simply 'delete', which signals non-destructive or reversible behavior—valuable context since no annotations are provided. It does not elaborate on restoration or side effects, but the key behavioral trait is disclosed.

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

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

A single, front-loaded sentence conveys the action, target, and identifier method with no filler or redundancy. Every word contributes to the tool's meaning.

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 no output schema, the description covers the essential information: what the tool does, what it operates on, and how to identify the target. It could add notes on post-delete visibility or restoration, but nothing critical is missing for invoking it.

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

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

Schema description coverage is 100%, so the schema already documents the identifier parameter fully. The description's 'by UID or slug' adds no meaning beyond the schema's 'Status page UID or URL-friendly slug'.

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

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

The description clearly identifies the action ('soft-delete') and the resource ('status page'), and specifies that the target is addressed by UID or slug. This makes it immediately distinguishable from sibling tools like delete_status_page_section and delete_status_page_resource.

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 resource type and 'by UID or slug' imply when the tool should be used, but there is no explicit guidance on when to choose this over sibling delete tools or when a soft-delete is preferable. Usage context is inferred 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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It conveys that the action is destructive by using 'Remove', and it clarifies that the resource is a 'pinned check', which hints that the check itself may not be deleted. However, it does not disclose whether the action is reversible, what permissions are needed, or what side effects occur, leaving significant gaps for a delete operation.

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

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

The description is a single sentence that front-loads the verb and key object, with zero filler words. It is appropriately sized for its simplicity and earns its place by clarifying the 'pinned check' meaning. No structural improvements are needed.

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

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

The tool is simple and the schema covers all parameters, but the description lacks any guidance on when to use it vs alternatives or what behavioral consequences to expect. Given no output schema and no annotations, an agent might not know whether the action is reversible or how it affects the underlying check. The one-liner plus schema is minimally viable but leaves meaningful gaps.

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

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

Schema description coverage is 100%, so the parameters are already fully documented. The description adds only the clarification that a resource is a 'pinned check', which is a slight semantic addition but not essential since the schema already defines resourceUid as a status page resource UID. This stays at the baseline of 3 given the 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 uses a specific verb 'Remove' and clearly identifies the resource type as a 'resource (pinned check)' and the scope as 'a status-page section'. This distinguishes it from sibling tools like delete_status_page_section (removes a section) and delete_check (removes a check directly). The clarification 'pinned check' ensures the agent understands what a status-page resource is.

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 does not explicitly state when to choose this tool over the many sibling tools, such as delete_status_page_section or delete_check. It implies its usage by stating its function, but it offers no exclusions or alternative routing. An agent is left to infer that it should be used when a specific resource within a section needs removal, without guidance on related operations.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It explicitly discloses a destructive side effect: 'Resources in the section are removed too.' This is valuable beyond the basic 'delete' semantics and warns the agent about irreversible cascading behavior. It does not mention permissions or reversibility, but the cascade warning is a strong disclosure for a delete operation.

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

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

Two short sentences with zero waste. The core action is front-loaded, and the critical side effect is stated immediately after. 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 two-parameter delete tool with a fully documented schema, the description is nearly complete. The only missing context is explicit guidance on when to use this versus delete_status_page_resource, but the cascade warning and clear resource scope make the tool callable without that. The absence of an output schema is not a gap because delete operations typically return minimal confirmation.

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 both parameters. The description does not add parameter-specific meaning beyond what the schema provides. Baseline 3 is appropriate because the schema does the heavy lifting and the description adds no extra parameter context.

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 ('Delete'), a specific resource ('a section from a status page'), and adds a critical scope detail: 'Resources in the section are removed too.' This clearly distinguishes it from sibling tools like delete_status_page_resource and delete_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?

The description implies when to use it (when you want to delete a status page section) but does not explicitly state when not to use it or mention alternatives. The sibling list includes delete_status_page_resource, which is a related alternative, but the description does not explicitly contrast them. The cascading deletion warning is a useful usage signal, but it is not framed as a when-to-use guideline.

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

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

With no annotations provided, the description carries the behavioral burden. It is transparent that the call is read-oriented ('Return') and specifies the returned categories, including that it aggregates results across regions and incidents in one call. It could add notes about costs, permissions, or null behavior, but it clearly communicates the primary non-destructive 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?

Two sentences, front-loaded with the action and the resource, with no filler. The usage guidance is included in the second sentence without repeating 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?

There is no output schema, so the description compensates by listing the returned data categories and gives a clear invocation context. It is slightly incomplete in not describing the exact shape/nullability of the returned incident fields, but this is a minor gap for an operator-facing diagnostic call.

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 regardless of description-level parameter detail. The description adds context by tying recentResultsLimit to 'recent raw results across regions', but it does not add meaning beyond what the schema already states.

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 ('Return') and a clear resource ('a single check's current state'), then enumerates exactly what is included: status, raw results, active incident, and most recent resolved incident. It also distinguishes itself from chaining list_results + list_incidents, so an agent can tell it apart from sibling tools without opening schemas.

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

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

It gives an explicit trigger condition ('when a human asks "what's wrong with check X?"') and explicitly names the alternative to avoid (chaining list_results + list_incidents). This is strong when-to-use guidance with a named alternative.

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

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

With no annotations, the description carries the full burden. It clarifies the operation returns 'metadata' rather than full results, and contrasts against diagnose_check's richer content. It doesn't mention error behavior or authentication, but the 'get' semantics and 'metadata' scope make the operation's behavior reasonably 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?

Two sentences, no filler. The core action is front-loaded, and the sibling routing is provided in a compact second sentence that 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 two-parameter get operation with a fully documented schema and a clear alternative, this is nearly complete. No output schema exists, and the term 'metadata' is slightly vague on return shape, but the with-field options in the schema compensate.

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 fully documents both identifier and 'with'. The description adds little parameter-level meaning beyond labeling the identifier as a UID or slug, which is also 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?

States a specific action ('Get a single check's metadata'), identifies the resource scope ('by UID or slug'), and explicitly distinguishes itself from diagnose_check. An agent can immediately tell this from list_checks and diagnose_check without opening schemas.

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

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

Explicitly names the alternative (diagnose_check) and the condition for preferring it ('full triage briefing'). This clearly tells the agent when not to use get_check, which is the core of usage guidance.

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

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

With no annotations, the description carries the burden of explaining behavior. It does so by making clear the tool returns ready-made, complete, valid configs that are meant to be cloned and modified glisserather than partial or abstract schema descriptions. The read-only nature is implied by 'Return,' and no side-effect surprises are hidden.

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 with no filler. The first sentence states the operation immediately, and the second explains the practical value. 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 single-parameter tool with no output schema, the description is complete: it says what is returned, that the returned configs are complete and valid, and why an agent should use this tool. No additional invocation details are needed.

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 fully documents the single 'type' parameter, including examples. The description adds no new parameter-level detail beyond 'given check type,' which keeps this at the baseline 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 names a specific verb and resource: 'Return ready-made sample configs for the given check type.' It also states the value proposition ('learn the config shape'), which clearly differentiates this from siblings like create_check, validate_check, or list_check_types.

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: 'Use this to learn the config shape for a type.' It does not explicitly name alternative tools or exclusions, but the intended scenario is clear enough for an agent to select it 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?

No annotations are provided, so the description carries the full burden for behavioral disclosure. It reveals that with='events' expands the response to include timeline events, but it says nothing about error behavior (e.g., non-existent UID), response format, or side effects (though 'Get' implies read-only, it is not explicitly stated). For a tool with zero annotation coverage, this is a significant transparency gap.

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

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

The description is two sentences long, with the primary purpose stated in the first sentence and the optional parameter behavior in the second. It is front-loaded, free of fluff, and 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 get tool with two parameters and no output schema, the description covers the essential action and the optional 'with' field. It does not explicitly mention the possibility of including 'check' (though the schema does), nor error handling or response details, but these are adequately covered by the schema and the tool's simplicity. The only minor gap is not mentioning the 'check' option, which is available via the schema.

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

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

Schema coverage is 100%, so both parameters are fully documented in the schema. The description adds a redundant explanation of the 'with' parameter (repeating the schema) but does not provide additional semantic depth beyond what the schema already offers. Baseline 3 is appropriate given the 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 clearly specifies the action 'Get', the resource 'incident', and the identifier 'UID'. It distinguishes itself from list_incidents by stating 'single', and the scope is unambiguous. Even without comparing to siblings, an agent understands exactly 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 explicit guidance on when to use the optional 'with' parameter to include events, which is a usage tip. However, it does not mention when to use this tool instead of other incident-related tools like list_incidents or diagnose_check. It lacks exclusions or alternative routing, but the core usage is clear enough for a single-fetch tool.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions 'server-computed status' and 'nextOccurrences', giving some insight into the response, but it does not disclose side effects, error conditions, or permission requirements. For a simple get operation, this is acceptable but not comprehensive.

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, front-loads the primary action and resource, and lists the returned fields efficiently without extraneous 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?

The description adequately explains what the tool returns (title, schedule, recurrence rule, status, nextOccurrences), which is essential given the lack of an output schema. It does not mention error cases or prerequisites beyond the UID origin, but for a simple retrieval tool this is sufficient.

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

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

The schema fully describes the uid parameter with 100% coverage. The description only repeats 'by UID' without adding additional semantic detail such as format, constraints, or examples. Since schema coverage is complete, 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 (Get) and the resource (a single maintenance window) and identifies the key differentiator (by UID). It also lists the specific fields returned, distinguishing it from list_maintenance_windows and other maintenance window 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 implies usage when a specific UID is known and a single window's details are needed. The mention that the UID is 'returned by list_maintenance_windows' provides context on how to obtain the identifier, though it does not explicitly state when not to use this tool (e.g., for listing all windows).

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

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

No annotations are supplied, so the description carries the burden of signaling behavior. The verb 'Get' communicates a read operation and 'single status page' sets the scope, but the description does not explain return shape, error behavior, or the effect of the optional 'with' parameter beyond the schema. It is minimal but 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?

A single front-loaded sentence gives the action, resource, and lookup key with no filler or redundancy. 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 two-parameter read operation with full schema coverage and no output schema, the description and input schema are sufficient to call it correctly. The only small gap is that the behavior of the optional 'with' parameter is not reinforced in the description, but the schema covers it.

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 structured schema already documents both parameters. The description restates that the identifier is a UID or slug but adds no new meaning beyond the schema, and it does not clarify when to use the optional 'with' parameter.

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

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

The description states a specific verb (Get), a specific resource (a single status page), and the lookup key (UID or slug). This clearly differentiates the tool from list_status_pages and the many status-page mutation tools in the sibling set.

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 wording implies the tool is for retrieving one status page when an identifier is already known, as opposed to listing all pages. However, it never names list_status_pages as the alternative or states explicit when-to-use/when-not-to-use conditions, leaving the routing implicit.

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

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

No annotations are provided, so the description carries the behavioral disclosure burden. It conveys that this is a read-only listing operation and that delivery status is included, but it does not discuss pagination behavior, permissions, side effects, or edge cases. This is adequate for a simple list tool 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 front-loaded sentence with no filler. It communicates the subject, scope, and output detail efficiently, and every word contributes to the tool's meaning.

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

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

For a simple list operation with full schema coverage, the description plus input schema provide enough to invoke the tool correctly: the incident uid, optional limit, and optional status filter. It lacks explicit usage alternatives and has no output schema, but the description does state what the result 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 schema already documents uid, limit, and status. The description adds no parameter-level details beyond what the schema provides, 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 uses a specific verb ('List') and a specific resource ('who was notified for a given incident'), and adds the result characteristic 'with delivery status.' This clearly differentiates it from siblings like list_incidents or get_incident, which return incident data rather than notification recipients.

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

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

Usage is implied: the tool is for a given incident, and the uid parameter description further clarifies that the uid comes from list_incidents or get_incident. However, the description does not state when to prefer this over alternative tools or provide explicit 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?

No annotations are provided, so the description carries the burden of behavioral disclosure. 'List all' conveys a read-only retrieval operation, and the domain explanation adds useful context. However, it does not mention pagination, ordering, or whether the response includes associated checks, which are relevant behavioral details for a listing tool with no output schema.

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 states the action and scope, and the second defines the domain concept. Every word earns its place.

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

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

For a zero-parameter list tool, the description is nearly complete: it identifies the resource, scope, and purpose. It lacks explicit return-format or pagination details, but since there is no output schema and invocation is trivial, 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?

The tool has zero parameters and the schema coverage is 100%, so there are no parameter semantics to document. The baseline of 4 applies because the description adds no parameter information, but none is needed for this parameterless 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 uses a specific verb ('List'), names the exact resource ('check groups'), and defines the scope ('for the organization'). It also explains what check groups are and how they relate to checks, which clearly distinguishes this tool from siblings like list_checks and list_check_types.

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: use this tool to list all check groups for the organization. It does not explicitly name alternatives or exclusion criteria, but the explanation that check groups bundle related checks implies when this tool is relevant versus listing individual checks. No misleading guidance is present.

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

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

With no annotations, the description carries the behavioral burden. It communicates that this is a read-only listing operation with optional filtering, which is useful. However, it does not mention pagination behavior, default limits, or whether the response includes last results by default, leaving some behavioral detail to the schema.

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 front-loaded, filters are summarized compactly, and the alternative tool is mentioned in a single closing sentence.

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 required parameters and a well-documented schema, the description covers selection and routing adequately. It lacks an explicit statement about the return shape or pagination, but the schema covers the pagination cursor and the sibling routing covers the main alternative use case.

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 fully documents all six parameters. The description adds a concise summary of the main filter dimensions (name/slug, labels, check group) but does not add meaning beyond the schema for parameters like limit, cursor, or with.

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: 'List monitoring checks for the organization', and enumerates the available filters (name/slug substring, labels, check group). It also distinguishes itself from diagnose_check, making it clear this is a fleet-browsing tool rather than a single-check health 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?

It explicitly states when to use this tool ('browsing or filtering a fleet of checks') and names an alternative for a different use case ('To investigate a single check's current health, use diagnose_check instead'). This gives the agent actionable 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?

With no annotations, the description carries the behavioral burden. It communicates the read-only nature through the verb 'list' and adds useful context that the set is server-specific ('supported by this server'). It does not describe the response shape, but for a simple enumeration tool that is largely inferable.

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 first sentence states the operation and gives examples, while the second provides direct usage guidance and the follow-up tool. 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 zero-parameter schema and low complexity, the description is complete: what the tool returns, example values, when to use it, and where to go next. Nothing needed to invoke it correctly is missing.

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

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

The tool has zero parameters, so the schema leaves nothing undocumented and the description does not need to explain parameter behavior. The baseline of 4 applies because there is no parameter surface for the description to compensate for.

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: 'List all monitoring check types supported by this server', with concrete examples. It differentiates itself from siblings like list_checks and get_check_type_samples by focusing on supported types rather than check instances or sample configs.

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 tells the agent when to use this tool: 'Use this first when you don't know what type to use.' It also names the natural next step by routing to get_check_type_samples. It doesn't explicitly state when not to use it, but the guidance is clear enough for a zero-parameter listing tool.

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

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

With no annotations, the description carries the burden of behavioral disclosure. It conveys that this is a read-only listing operation and that results may be past or active incidents. However, it does not mention pagination behavior, result shape, or any operational caveats, which leaves some behavioral transparency gaps.

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

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

Two sentences with no filler. The main purpose is front-loaded, the filter capabilities are summarized compactly, and the sibling alternative is placed in a single actionable sentence.

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 listing tool with 7 optional but fully documented parameters, the description is nearly complete. It explains the org-level scope, filter categories, and alternative routing. It stops short of describing response format or pagination semantics, but those are partially inferable from the schema's cursor/size parameters.

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 already documents all 7 parameters. The description adds only general mapping ('filtered by check, state, or time range' corresponds to checkUid, state, and since/until), which is helpful but not substantial beyond the schema.

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

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

The description states a specific verb and resource: 'List incidents (past or active) for the org' with optional filters by check, state, or time range. It clearly differentiates itself from diagnose_check by explicitly naming the sibling and its intended use case.

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

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

The description gives clear context: use this for org-level incident listing with optional filters, and explicitly directs the user to diagnose_check 'for triaging a specific check's incidents in one call.' It lacks a broader when-not-to-use list, but the alternative guidance is concrete and useful.

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

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

No annotations are provided, so the description carries the full burden. It clearly indicates a read-only listing operation, and the absence of side effects is implied. It does not mention pagination or return format, but for a simple list tool with an optional filter, the description is adequate and does not hide any critical 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 two concise sentences: the first states the core purpose, and the second gives usage context. No wasted words, and the most important information (what it lists) is front-loaded. Excellent structure.

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 one optional parameter and no output schema, the description covers the essential purpose and usage. It does not explain return fields or pagination, but given the tool's simplicity and the clarity of its name, the description is sufficiently complete for an agent to call it correctly.

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

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

The schema provides 100% coverage for the single 'type' parameter, including allowed values and examples. The description mentions integration types but does not add extra meaning beyond what the schema already states. The baseline of 3 is appropriate given high schema coverage, and the description does not need to compensate further.

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

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

The description clearly states the tool lists integrations configured for the organization, with examples of types (Slack, webhook, email) and the context of discovering notification channels before attaching them to a check. This distinguishes it from sibling tools like create_integration, as it is explicitly a listing operation.

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 a specific use case: 'Use this to discover what notification channels are available before attaching them to a check.' This implies when to use it, though it doesn't explicitly contrast with create_integration or mention exclusions. Clear enough for an agent to understand the intended workflow.

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

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

No annotations are provided, so the description carries the burden. It usefully discloses that status is server-computed and that nextOccurrences are concrete activations, adding behavioral context beyond a simple 'list' statement. It does not discuss auth or rate limits, but for a read-only list operation 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?

Two sentences with no filler. The core action and scope are front-loaded, and the second sentence adds valuable detail about computed fields 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?

For a simple list tool with full parameter documentation, the description is complete enough. It states what is returned (maintenance windows with computed status and nextOccurrences) and the optional filter, and the lack of an output schema is adequately compensated by the clear return-value description.

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

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

Schema coverage is 100%, so the baseline is 3. The description reinforces the status filter by listing its values, but it adds no new meaning for limit or status 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?

The description uses a specific verb ('List'), names the resource ('maintenance windows'), and scopes it to the organization. It also clarifies the optional status filter and highlights two important fields, distinguishing it from single-window operations like get_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?

It clearly states this is a list operation with an optional status filter, and the schema documents the filter values. It does not explicitly name alternatives like get_maintenance_window, but the list-versus-get distinction is evident from the tool name and sibling set.

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

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

With no annotations provided, the description carries the burden of behavioral disclosure. It clearly indicates this is a read-only list operation, scoped to the organization, and specifies the return content (slug, label, metadata). It does not explicitly mention auth or rate limits, but for a simple zero-parameter list tool the behavior is sufficiently 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?

Two concise sentences deliver purpose, examples, return contents, and usage guidance with no filler. The most important information (what the tool lists) is front-loaded, and the practical usage note is placed 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 zero-parameter, read-only list tool without an output schema, the description provides everything needed: what the tool returns, what scope it covers, and how the result should be consumed. There are no obvious gaps that would prevent an agent from calling 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 input schema is empty with zero parameters, so there are no parameter semantics to document. The baseline for zero parameters is 4, and the description adds relevant context about how the output relates to other tools without needing to explain 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 states a specific verb ('List') and resource ('monitoring regions available to the organization'), with concrete examples ('eu-west-1', 'us-east-1'). It makes the tool's purpose unambiguous and naturally distinguishable from the many sibling list_* tools.

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

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

The description explicitly tells the agent where the returned slugs should be used: 'Use these slugs in the regions array of create_check or update_check.' This gives clear downstream guidance. It does not mention when not to use the tool, but no realistic alternative exists among the listed siblings, so the guidance is adequate.

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

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

No annotations are provided, so the description carries the full burden. It discloses the read-only query intent, the raw vs aggregated distinction, default fallback behavior for periodType and periodStartAfter, and the effectiveFilter transparency mechanism. It does not cover return shape or pagination behavior, but the disclosed defaults are meaningful behavioral context.

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

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

The description is compact and front-loaded: the main purpose comes first, then the alternative routing, then the default behavior and transparency guarantee. Every sentence earns its place without repeating the full 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 complex 10-parameter tool with no annotations and no output schema, the description covers scope, filters, aggregation modes, defaults, and filter transparency. It does not describe the default response fields or pagination flow explicitly, but the schema's parameter documentation carries most of the invocation burden.

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 the 'finest periodType requested' clarification and the effectiveFilter note, but the parameter meanings and defaults are already thoroughly documented in the schema. The description does not substantially enrich parameter semantics beyond the schema.

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

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

The description states a specific action and resource: 'Query monitoring results (raw or aggregated) with filtering by check, type, status, region, period type, and time range.' It also explicitly differentiates itself from diagnose_check, so an agent can distinguish it from sibling tools like list_checks, get_check, and diagnose_check.

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 explicit usage context: 'Use this for trend analysis or to inspect a specific window' and names the alternative for a different case: 'For investigating a single check's current state, use diagnose_check instead.' This is clear routing guidance with no inference required.

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

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

No annotations are provided, so the description carries the behavioral burden. The verb "List" implies a non-mutating read operation and the incident-publication distinction adds useful domain context, but the description does not mention pagination, response shape, default filtering behavior, or any access requirements.

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

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

The description is a single, efficient sentence that front-loads the core action and immediately provides the most important disambiguation from internal incidents. There is no filler or redundant restating of schema information.

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

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

For a list operation with one required parameter and full schema coverage, the description is largely complete. It explains the key domain distinction that could otherwise confuse an agent, though it does omit minor operational details like pagination or default filtering behavior.

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 all three parameters meaningfully. The description adds no additional parameter-level detail, matching the baseline expectation for fully covered schemas.

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: "List the incident publications on a status page." It also explicitly distinguishes these customer-facing incident publications from the internal `incidents` the monitoring system opens, which clearly separates this tool from the related `list_incidents` 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?

The description gives clear context: use this to list customer-facing incident publications, not internal monitoring incidents. It does not explicitly name `list_incidents` or provide a direct when-to-use/when-not-to-use rule, so it falls just 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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states the action and gives no indication of read-only status, pagination, rate limits, or any side effects. For a list operation, the absence of any safety or behavior notes leaves the agent without critical context. This is a significant gap.

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, well-structured sentence that front-loads the action and includes a clarifying parenthetical. There is no redundancy or wasted words.

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

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

For a simple list operation with no output schema, the description provides the essential information: what it lists and where. The parameter requirements are already covered by the schema. While it could mention that both identifiers are required, that is implicit in the schema. The description is complete for the tool's simplicity.

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

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

The schema descriptions cover both parameters fully (100% coverage), explaining that they accept a UID or URL-friendly slug. The tool description adds no additional parameter details. Per the rule, with high schema coverage, the baseline is 3, and the description doesn't enhance it.

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

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

The description uses a specific verb ('List'), specifies the resource ('resources'), and clarifies the scope ('within a status page section'). It also defines resources as 'checks pinned to a section,' which distinguishes this from sibling tools like list_checks or list_status_page_sections. The purpose is unambiguous.

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

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

The description implies when to use this tool: when you need the resources of a particular status page section. It doesn't explicitly state when not to use it or mention alternatives, but the context is clear enough for an agent to differentiate it from related list operations. No exclusions are given, so a 4 is appropriate.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states that it lists status pages, but does not disclose that this is a read-only operation, whether any permissions are needed, what the response format looks like, or if there is pagination or filtering. This is a minimal behavioral disclosure for a tool with no annotation backup.

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 front-loads the action and resource. Every word earns its place, and there is no redundancy or unnecessary detail.

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 output schema and no annotations, the description is very incomplete for an agent. It does not specify what the returned data looks like (e.g., an array of status page objects), any limitations (e.g., only active pages), or whether pagination is needed. For a simple list tool, some expectation of response structure would be helpful, but it is entirely absent.

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

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

The tool has zero parameters, and the schema coverage is 100% (empty schema). Per the rubric, a 0-parameter tool gets a baseline of 4. The description does not need to add parameter semantics because there are none, and it correctly omits any parameter-related information.

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), the resource (status pages), and the scope (for the organization). It is distinct from sibling tools like list_status_page_sections or list_status_page_resources because it specifically targets top-level status pages, and the verb+resource combination is unambiguous.

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

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

The description does not explicitly mention when to use this tool versus alternatives. While it is obvious that this lists status pages, it does not contrast with other list tools (e.g., list_status_page_sections) or state any prerequisites or exclusions. The guidance is implied by the name and resource, but not 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?

No annotations are provided, so the description carries the full burden. The verb 'List' implies a read-only operation, but the description does not disclose any side effects, authentication requirements, or rate limits. It adds minimal behavioral context beyond the obvious.

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 fluff, front-loading the core action and adding a brief explanatory clause about what sections are. 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?

The description explains the purpose and the concept of sections, which is sufficient for a simple list operation with a single well-described parameter. It does not mention return format, but that is not explicitly required given the tool's simplicity.

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

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

The tool description adds no detail about the pageIdentifier parameter beyond what the schema already provides. Since schema coverage is 100% and the parameter is well-described, the description contributes no additional semantic value.

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

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

The description uses a specific verb ('List') and identifies the exact resource ('sections within a status page'). It further clarifies the domain by explaining that sections group pinned checks, which distinguishes it from siblings like list_status_page_resources and list_status_pages.

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 states what the tool does but does not explicitly indicate when to use it versus listing resources or other related tools. It implies a use case but lacks explicit guidance on alternatives or 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?

No annotations are present, so the description carries the behavioral burden. It discloses that this is a full replacement operation, that empty arrays clear collections, and that partial updates are not supported. It does not detail return values or permissions, but the central destructive/replacement behavior is clearly communicated.

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 action is front-loaded, followed by the two most important behavioral caveats. 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 mutation tool with no output schema and no annotations, the description is quite complete: it states what is replaced, how to clear, how to preserve one collection, and that partial updates are not supported. It could also mention what happens to previously attached checks or the response shape, but the provided guidance is sufficient to invoke the tool correctly in most cases.

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 meaning beyond the schema by explaining that leaving one collection untouched requires passing its current contents, and reiterating that partial updates are not supported. This helps an agent understand how checkUids and checkGroupUids interact, which the raw schema does not convey.

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

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

The description opens with a specific verb and resource: 'Replace the set of checks (and/or check groups) attached to a maintenance window.' It clearly scopes the tool to maintenance-window check associations, distinguishing it from siblings like update_maintenance_window, get_maintenance_window, or delete_maintenance_window. The behavior is unambiguous and actionable.

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

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

It provides explicit operational guidance: how to clear via empty arrays, how to preserve a collection by passing its current contents, and a clear warning that partial updates are unsupported. It does not name alternative tools or explicitly say when to prefer this over update_maintenance_window, but the replacement semantics are clear enough for an agent to use 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?

With no annotations, the description carries the behavioral burden. It explicitly discloses PATCH semantics — only passed fields are modified, others remain unchanged — which is a critical behavioral trait beyond the schema. It does not cover permissions, response shape, or side effects, but the PATCH disclosure is genuinely informative.

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, tightly worded sentence front-loads the action and resource, then immediately states the most important semantic nuance. 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?

All parameters are thoroughly documented in the schema, and the description covers the core update behavior. However, with no annotations and no output schema, the agent is left without information about return values, error behavior, or side effects for this 12-parameter mutation tool, so the description is adequate but not 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 the schema fully documents all 12 parameters. The description adds the general PATCH interpretation of parameters but does not elaborate on any individual parameter beyond the schema, matching 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 clearly names the verb ('Update'), the resource ('an existing check'), and the identification method ('by UID or slug'). It is immediately distinguishable from siblings like create_check, delete_check, and get_check.

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 'Update an existing check' provides clear context for when to use this tool versus create_check or delete_check. However, it does not explicitly name alternative tools or state when not to use it, so it falls 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?

With no annotations, the description carries the full burden. It does disclose the key behavioral trait: only provided fields change, preventing the agent from assuming a full replace. However, it does not mention idempotency, whether the window must exist, how changing startAt/endAt affects recurrence, or what the response contains.

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 zero wasted words. The PATCH semantics note is essential and efficiently disambiguates the update behavior.

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

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

The input schema is unusually rich, covering all parameters and recurrence nuance, so the terse description plus schema gives an agent enough to invoke the tool correctly. The main omissions — usage guidance and response behavior — are minor for a straightforward partial-update 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 coverage is 100%, so each parameter is already documented in detail, including recurrence semantics and RFC3339 formatting. The description adds one useful general semantic — omitted fields retain their current values — but it is not parameter-specific and mostly reiterates what PATCH semantics implies.

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 ('Update') and resource ('maintenance window'), and adds PATCH semantics to clarify partial update behavior. It is clearly distinguishable from create/delete/get/list siblings, though it does not explicitly name or contrast any 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?

No guidance is given about when to use this tool versus create_maintenance_window, set_maintenance_window_checks, or other siblings. It does not state prerequisites (e.g., the window must already exist) or conditions under which this tool is preferred. The PATCH note explains how the update behaves, not when to choose 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?

With no annotations, the description carries the full behavioral burden. It usefully discloses PATCH semantics — that only provided fields change — which is a meaningful behavioral trait. Still, it omits side effects, permissions, validation failures, and return behavior, leaving notable gaps for a mutation tool.

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

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

The description is a single front-loaded sentence with no filler. It conveys the action and the most important semantic nuance in a compact, easily parseable form.

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 15-parameter mutation tool with no annotations and no output schema, the input side is thoroughly covered by the schema and PATCH note. However, the description does not explain return values, error/conflict behavior, or side effects, so an agent is left without key post-invocation context.

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 each parameter is already well documented. The description adds important cross-parameter meaning by stating that omitted fields remain unchanged, which is essential for correctly performing partial updates.

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 ('Update') and resource ('existing status page'), and adds PATCH semantics. This clearly distinguishes it from create_status_page and delete_status_page as well as from section/resource update 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 implies the correct context: use it when an existing status page must be modified, and only provided fields should change. However, it does not explicitly mention when to prefer this over create/delete or other update siblings, nor does it give any exclusion criteria.

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 a critical behavioral trait beyond the schema: any edit marks the publication as human-authored and stops the auto-resolve pipeline from closing it. This is valuable context that an agent would not know from the schema alone. With no annotations provided, the description carries the full burden, and it does a good job of surfacing this side effect. It doesn't mention other potential side effects like notifications to subscribers, but the disclosed side effect is significant.

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 waste. The first sentence states the action and scope, and the second discloses the critical side effect. The most important information is front-loaded, and 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 PATCH update tool with 100% schema coverage and no output schema, the description is complete enough. It covers the action, the fields, and the key side effect. It could be slightly more complete by mentioning that the state field has allowed values, but the schema already does that. The description adds the human-authored side effect, which is the main non-obvious context.

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 five parameters. The description adds the PATCH semantics, which clarifies that only provided fields are updated, and it mentions the fields that can be changed. However, it doesn't add detail beyond the schema for individual parameters, such as the meaning of clearing severity. Baseline 3 is appropriate when the schema covers everything.

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 ('Update'), a specific resource ('published incident'), and the exact fields that can be changed ('title, severity or state'). It also clarifies the PATCH semantics, which distinguishes it from a full replacement update. This clearly differentiates it from siblings like create_status_page_incident or create_incident_publication.

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 this tool: when you need to modify an already-published incident's title, severity, or state. It doesn't explicitly name alternatives or exclusions, but the PATCH semantics and the focus on 'published incident' provide clear context. It could be improved by explicitly stating when not to use it (e.g., for creating incidents or adding updates), but the context is strong.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It only says 'Update' and lists fields; it does not disclose partial-update semantics, whether unspecified fields are preserved, permission requirements, idempotency, or return behavior. This is a significant gap for a mutation tool.

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

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

The description is a single concise sentence with the action and object front-loaded and no wasted words. However, it offers little structural organization beyond a parenthetical field list, so it is not maximally helpful.

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

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

The tool has no annotations and no output schema, yet the description provides no usage context, behavioral notes, or return-value information. For a six-parameter mutation tool, this is incomplete; an agent would need to infer partial-update behavior and prerequisites from the schema alone.

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 six parameters with meaningful descriptions. The tool description adds no parameter-level detail beyond restating 'display name, explanation, position,' 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 the action ('Update') and the object ('a status page resource'), and it lists the updatable fields (display name, explanation, position). It is distinct from sibling tools like create_status_page_resource and update_status_page_section, though it does not explicitly name or contrast those alternatives.

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 use this tool versus create_status_page_resource, list_status_page_resources, or delete_status_page_resource. The word 'Update' implies an existing resource, but there is no explicit context, prerequisite, or exclusion.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions PATCH semantics, which is good, but fails to disclose that it modifies data (implies a write operation) and what the response format is. It also doesn't mention any side effects or that unchanged fields are preserved. Since annotations are absent, the agent has no safety context, making this insufficient.

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 very concise, consisting of a single sentence that clearly conveys the action and PATCH semantics. It is appropriately front-loaded, placing the key information at the beginning. There is no wasted text, and every word contributes to understanding the tool's purpose. The only slight deduction is for not providing additional context, but conciseness is a virtue here.

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

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

The tool is relatively simple with only 5 parameters, and the schema covers them entirely. With no output schema or complex behavior, the description could be more complete by noting that the section must exist and that updates are partial. However, since the schema is rich and the operation is straightforward, the description is adequate but leaves gaps around behavioral expectations, such as idempotency or error conditions.

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 provides 100% coverage of all 5 parameters with clear descriptions and examples Δ. The description adds minimal value by restating the PATCH behavior, but it reinforces that only provided fields change, which aligns with parameter semantics. However, since the schema is comprehensive, the baseline of 3 is appropriate; the description doesn't add significant extra 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 (update) and target resource (a section within a status page), and specifies PATCH semantics. While it doesn't explicitly differentiate from sibling tools like create_status_page_section, the verb 'update' distinguishes it from creation/deletion tools, though the purpose could be more specific about what fields are updatable.

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 by stating the tool updates a section but provides no guidance on when to use it versus alternatives like create_status_page_section or delete_status_page_section. There are no conditions, prerequisites, or exclusions mentioned. For an update operation, it would be helpful to note that the section must already exist, but this is not stated.

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

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

With no annotations, the description carries the burden. It clearly discloses the dry-run/no-create behavior and describes both success and failure return shapes. It does not mention permissions or rate limits, but the key side-effect and output behavior are well-covered.

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 with no filler. The main purpose is front-loaded, the return behavior is explained, and the usage direction is provided. 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 validation tool, the description covers the tool's purpose, side effects, return values, and usage context. No output schema exists, so the description's explanation of return results fills that gap. Missing minor details like auth requirements are acceptable for a dry-run 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%, so the schema already documents type and config with examples. The description adds no parameter-level semantics beyond what the schema provides, making baseline 3 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 ('validate') and resource ('check config'), and frames it as a dry-run that does not create the check. This clearly distinguishes it from create_check and diagnose_check 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?

Explicitly instructs to use this before create_check when assembling a config from scratch or modifying a sample. This gives the agent a concrete trigger and names the alternative tool, satisfying the when/alternative requirement.

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