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

The annotations already declare this is a non-read-only, non-destructive, non-idempotent mutation, so the safety profile is covered. The description adds one genuinely new behavioral fact — the acknowledgement is attributed to the API key's owner — but says nothing about the resulting state change (status transition, notification silencing) or side effects.

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 the verb and scope first and no filler. 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 mutation tool with no output schema and no annotations describing outcomes, the definition leaves the agent without knowing what acknowledgement actually changes about the incident. Parameter documentation is fully delegated to the schema, but behavioral completeness is thin.

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%: id, project, and workspace each carry their own descriptions including defaults and the list_workspaces source. The description adds no parameter-level meaning, so the baseline 3 applies.

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

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

The description gives a specific verb ('acknowledge') and resource ('incident'), so an agent can distinguish it from list_incidents, get_incident, or create_incident. It does not explicitly differentiate from the closest sibling, post_incident_update, but the action 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?

There is no when-to-use or when-not-to-use guidance and no alternative tool is named. The phrase 'as the API key's owner' implies a permission context but does not tell the agent when acknowledgement is the right action versus posting an update or leaving the incident alone.

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

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

Annotations already declare this is a non-read-only, non-destructive, non-idempotent write. The description adds the propagation behavior of the incident onto status pages, which is real context beyond the annotations. It omits auth/permission needs, whether duplicate incidents are possible (relevant given idempotentHint=false), and whether notifications are dispatched.

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

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

Two short sentences with zero filler; the scoping behavior is front-loaded immediately after the core action.

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 7-parameter tool with no output schema and 29% schema coverage, the description covers the monitor-scoping decision but leaves most parameters and the return value (incident id/handle) unexplained. Adequate but with visible gaps an agent may trip over.

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 only 29% (project and workspace only), so the description must compensate but largely does not. Effectively it explains monitorId's semantic effect and confirms it is optional, but severity, visibility, body, and title limits are left undocumented in both places.

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

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

States a specific verb and resource ('Open a manual incident') and clarifies the 'manual' nature versus system-generated incidents. It does not name any sibling tool (e.g., update_incident or post_incident_update) to disambiguate the lifecycle stage, but the action itself 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 gives a usable decision rule for the monitorId parameter: with a monitor the incident appears on status pages containing that monitor, without one it appears project-wide. However, it offers no guidance on when to prefer this over post_incident_update or update_incident, nor any prerequisites such as permissions.

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

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

Annotations already declare readOnlyHint=false, idempotentHint=false, destructiveHint=false, so the safety profile is covered. The description adds genuinely useful behavior detail by disclosing what omitted fields default to and how regions default to ["auto"], but it says nothing about side effects such as alerting channels firing or what happens on re-creation of a same-named monitor.

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

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

Three tight sentences, no filler, and the core parameters are front-loaded ahead of the defaults and regions detail. Slightly clipped syntax ('type is http, ...', the bare 'regions defaults to') costs a little readability but nothing is wasted.

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

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

For a 21-parameter creation tool with no output schema and 10% schema coverage, the description covers only a fraction of the surface. Critical creation concepts such as which channels receive alerts, failure thresholds, and monitor dependencies are never mentioned, leaving an agent unable to call this correctly for anything but a minimal monitor.

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 only 10% across 21 parameters, so the description has to compensate and it partially does: it defines target's expected formats and the defaults for intervalSec and expectedStatus. But the majority of parameters (channelIds, failureThreshold, minRegionsFailing, dependsOnMonitorId, keyword/keywordMode, graceSec, tags) get no explanation anywhere.

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

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

States a specific verb+resource ('Create a monitor') and immediately clarifies the two most important parameters, type and target, with concrete formats (URL, host:port, hostname). It does not explicitly differentiate itself from update_monitor/delete_monitor, but the verb makes the create role 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?

Provides useful context on defaults (60 s interval, expect HTTP 200) and points to list_regions for valid region names, which is a real routing hint. However, it never states when to prefer this tool over alternatives or what prerequisites (workspace/project) apply, so usage guidance remains implied rather than explicit.

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

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

Annotations already declare a non-readonly, non-destructive, non-idempotent write. The description adds genuinely new behavioral context beyond that: the access prerequisite on the connection, the default-workspace fallback, and that the project is immediately usable. It stops short of error/duplicate-name behavior, so not a 5.

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 short clauses, front-loaded with the action and parent resource, and each clause carries distinct information (default handling, permission constraint, readiness). Tight and waste-free, though not maximally compact.

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 3-parameter mutation tool with annotations and no output schema, the description covers the main agent concerns: parent scoping, default behavior, and the permission prerequisite. Minor gaps remain around failure modes (e.g., duplicate or reserved names), so it is strong but not exhaustive.

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 67% and both described parameters (project, workspace) already carry their own semantics in the schema. The description's note that you pass `workspace` and omit it for the default largely restates the schema text, adding little beyond it; `name` remains undocumented in both places.

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

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

States a specific verb+resource ('Create a project') and scopes it to a workspace, which separates it from create_workspace and create_status_page. It does not explicitly name a sibling it supersedes or is confused with, so it falls just short of a 5.

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

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

Gives a real precondition ('Only works where this connection has access to all projects of that workspace') and explains the default-workspace case, which is useful when-to-use context. However, it names no alternative tool or exclusion for when not to use this, so guidance is implied rather than complete.

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

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

Annotations already disclose a non-readonly, non-destructive, non-idempotent write. The description adds two facts beyond them: the created resource is publicly exposed ('public status page') and the slug must be unused. It does not describe failure modes or what happens on duplicate slug.

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 waste, and the essential facts (action, URL, contents, slug constraint) are front-loaded. Nothing extraneous, though it could be slightly tighter.

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 9 parameters and no output schema, the description gives enough to call the tool but omits return expectations and error/plan conditions. It is minimally adequate for a create operation of this complexity.

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

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

Schema coverage is only 44%, so the description should compensate. It does document the slug format and uniqueness, and it maps monitorIds to the page contents (a param with no schema description), but leaves theme, showLatency, and title details to the schema.

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

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

The description states a specific verb and resource: 'Create a public status page at /status/<slug>'. It also clarifies the core payload ('showing the given monitors (monitorIds)'). It is clear, though it does not explicitly name a sibling (e.g., update_status_page) to sharpen the boundary.

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

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

Usage is only implied by the description of what gets created; there is no explicit when-to-use or when-to-prefer-update_status_page guidance. The uniqueness prerequisite for the slug ('must be unused') is stated, but no auth or plan caveats appear beyond what the schema already carries.

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

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

Annotations already declare the write, non-idempotent, non-destructive profile, so the bar is lower. The description adds valuable context beyond them: the required 'all workspaces' authorization scope and that the workspace is user-owned, which the annotations do not convey.

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

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

Three tight sentences, front-loaded with the primary action, then the authorization precondition, then how to use the result. No filler; every sentence earns its place.

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

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

With no output schema, the description compensates by explaining what the return value is for ('Use the returned id as `workspace`'). Combined with the auth precondition and annotations covering the mutation profile, it is nearly complete, missing only edge cases like duplicate-name 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 67%, with the two optional params documented in the schema itself and `name` self-evident. The description only indirectly touches parameter semantics via the returned-id/`workspace` link and the 'first project' note, adding little beyond the schema, so the baseline 3 is appropriate.

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

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

The description states a specific verb and resource ('Create a new workspace') and adds scope detail ('with a first project, owned by the user'). It is clear what gets created, though it does not explicitly differentiate itself from the sibling create_project tool beyond the parent 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?

It provides a concrete precondition ('Only works when the user authorized access to all workspaces') and a follow-up action ('Use the returned id as `workspace` in other tools'). This gives clear context, but no explicit alternatives or when-not-to-use guidance beyond the auth gate.

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

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

Annotations already declare destructiveHint=true, idempotentHint=false and readOnlyHint=false, so the safety profile is covered. The description adds real value beyond them by disclosing that the operation is permanent and that the monitor's history is destroyed along with it, which the annotations do not convey.

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

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

A single front-loaded sentence with zero filler; the consequential word 'Permanently' appears first so the risk is seen immediately.

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-sentence destructive tool there is no output schema to explain, annotations cover the safety profile, and the description covers the irreversible data loss. Missing details like required permissions or not-found behavior are minor for this shape.

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

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

Schema description coverage is 100%, so all three parameters (id, project, workspace) are already documented in the schema, including the fallback behavior for omitting project/workspace. The description adds no parameter-level meaning, so the baseline 3 applies.

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

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

States a specific verb (delete) plus resource (monitor) and scope (and its history), which an agent can distinguish from pause_monitor/resume_monitor. It does not explicitly name a sibling or contrast with non-permanent disable options, so it falls short of a 5.

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

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

No when-to-use guidance, no prerequisites, and no mention of alternatives such as pause_monitor for a reversible disable. The agent is left to infer that deletion is the appropriate action.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and closed-world, so the safety profile is covered. The description adds a meaningful content disclosure — that internal updates are included in the timeline — which is worth flagging, but it says nothing about permissions, pagination of the timeline, or behavior on a missing/inaccessible incident.

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 that packs the return payload into one line with no filler. Slightly dense and parenthetical, but every clause earns its place.

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

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

With no output schema, the description carries the return-value burden and does so well by listing the incident fields and the timeline/failed-checks context. It falls short only on timeline size/pagination and access constraints, which an agent would need for edge 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 description coverage is 100%, including helpful notes on project/workspace defaults, so the schema already documents all three parameters. The description adds no parameter-level meaning (e.g., whether internal updates require extra permissions), so the baseline 3 applies.

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

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

States a specific verb and resource ("Get an incident") and enumerates the returned payload: number, root cause, postmortem, update timeline, failed checks. It is clearly distinguishable from list_incidents, create_incident, and update_incident, though it never names a sibling explicitly.

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 when-to-use, when-not-to-use, or alternative guidance. Nothing tells the agent to prefer this over list_incidents for a single record or what preconditions (valid id, accessible workspace/project) apply.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is fully covered without prose. The description's added value is disclosing that the response bundles recent checks and uptime, which matters since there is no output schema. It does not say how many 'recent' checks are returned or over what window, which is the main behavioral 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?

A single front-loaded sentence with zero filler; the resource and payload appear immediately. It is arguably too terse for the payload claims it makes, but nothing in it is wasted.

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

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

For a three-parameter read tool with no output schema, the description does tell the agent roughly what comes back (recent checks + uptime), which is the minimum needed. However, 'recent' is undefined and there is no indication of response size or whether checks are truncated, leaving the return shape only partially characterized.

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% — id, project, and workspace are each documented in the schema, including the 'omit to use default' fallbacks. The description adds no parameter-level meaning beyond that, so the baseline 3 applies.

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

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

States a specific verb (Get) and resource (monitor) with a clear cardinality ('one monitor'), which implicitly separates it from list_monitors. It also names the payload ('recent checks and uptime'), so an agent knows this is a detail fetch rather than a listing. It stops short of explicitly naming the sibling it contrasts with.

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

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

Usage is only implied: fetch a single monitor's details when you already have its id. There is no explicit when/when-not guidance, no mention of alternatives like list_monitors for browsing or get_incident for related data, and no prerequisites stated (though the schema covers project/workspace defaults).

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, so the safety profile is fully covered structurally. The description adds that results carry ids for monitor attachment, but says nothing about pagination, ordering, or whether results are scoped to the caller's workspace.

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

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

One compact sentence with zero filler; the resource and the reason for the call are both front-loaded. 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 simple read-only list tool with a fully documented schema and no output schema, the description covers what the tool returns and why. The only gap is scope (workspace/project-level) and result size, which is minor given the annotations.

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 both parameters (project, workspace) are fully documented in the schema, including their fallback-to-default behavior. The description adds no parameter meaning beyond that, so the baseline 3 applies.

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

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

States a specific verb (List) and resource (alert channels), enumerates the channel types, and notes the returned field (ids). It is clearly distinguishable from every sibling (list_monitors, list_regions, list_workspaces, etc.), none of which deal with notification channels.

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 implied use context – the ids exist 'to attach to monitors' – which hints at the follow-up workflow, but it never states when to call this versus other listing tools or any prerequisites. Usage is inferable rather than explicit.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true and destructiveHint=false, so the safety profile is covered. The description does add genuinely useful behavior not in structured fields: result ordering ("open ones first") and inclusion of both automatic and manual incidents. However it says nothing about pagination or result limits, so it is additive 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?

A single short sentence, front-loaded with the verb and resource, with no filler. The phrase "automatic and manual" is slightly terse and unexplained, but overall it is efficiently 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?

For a two-optional-parameter list tool with rich annotations the description is adequate, but with no output schema it leaves the shape of an incident, pagination behavior, and default result volume unstated. Nothing is wrong, but an agent lacks a couple of practical details.

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 optional parameters (project, workspace) are fully documented with their source and default behavior. The description adds nothing beyond the schema, which is the expected baseline when 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?

"List incidents" is a specific verb+resource, and "automatic and manual" clarifies the range of incident types returned. It does not differentiate itself from siblings like get_incident (single fetch) or post_incident_update, but the plural list intent is self-evident.

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 offers no when-to-use guidance, no mention of when to prefer this over get_incident for a single record, and no note on filtering/sorting behavior. Retrieval is only implied by the verb "List".

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true and destructiveHint=false, so the safety profile is covered. The description adds nothing further — no scope of listing (all projects/workspaces vs. filtered), no pagination or ordering behavior, and no auth requirements.

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

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

A single front-loaded sentence with zero filler — nothing to trim. However, its extreme brevity leaves it borderline under-specified, so it is not maximally helpful despite being maximally short.

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

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

Given a low-complexity read-only list tool with only two optional, fully documented parameters and complete annotation coverage, the description covers the essentials. The only real gap is that it never states whether the listing spans all workspaces/projects or just the default scope.

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 both optional parameters (project, workspace) are fully documented in the schema, including defaults and where the ids come from. The description contributes no additional parameter semantics, so the baseline 3 applies.

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

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

The description gives a clear verb (List) and resource (scheduled maintenance windows), so an agent knows exactly what it returns. It doesn't explicitly differentiate from siblings, but no sibling covers maintenance windows, so the risk of confusion is low.

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

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

Usage is only implied by the name and description; there is no statement of when to call it, what prerequisites exist, or which alternative tools to consider. For a simple read-only list tool this is minimally viable rather than misleading.

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

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

Annotations already declare readOnly, idempotent, non-destructive, closed-world, so the safety profile is covered. The description adds genuine value by naming the returned fields (status, uptime, latency), but says nothing about result size, pagination, or ordering.

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 the resource and the returned fields; nothing redundant or padding.

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, the description partially compensates by listing the fields returned, and the two optional scoping params are fully covered by the schema. The only gap is pagination/limits, which an agent might need for a list endpoint.

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 both optional params are fully documented in the schema (including where the ids come from). The description adds only the 'current project' framing and no syntax or defaulting details 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?

Specific verb (List) plus resource (monitors) and scope (current project), with the returned fields named. It is distinguishable from get_monitor by the plural/scope wording, but it never explicitly contrasts with it or with the other list_* 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?

Usage is only implied: the agent infers this is the enumeration tool while get_monitor fetches one monitor. There is no explicit when-to-use/when-not or named alternative, and no note about which of the optional project/workspace params selects scope.

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

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

Annotations already declare readOnlyHint, idempotentHint, and non-destructive, so safety is covered. The description adds real behavioral context beyond that: `auto` is always a valid region, and there is a maximum number of regions a single monitor may use — useful constraints an agent cannot infer from structured fields.

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

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

Two compact sentences with no filler; the primary purpose and the key output facts are front-loaded, and the usage hint follows economically.

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 enumeration tool with full annotations and no output schema, the description adequately conveys both what is returned (regions, the always-present `auto`, the per-monitor cap) and how to use it. Only the precise return shape is left implicit, a minor gap given the annotations cover the rest.

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

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

Schema description coverage is 100% with both optional params (project, workspace) fully documented, including their source (list_workspaces) and omit-for-default behavior. The description says nothing about these params, so baseline 3 applies 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?

States a specific verb and resource (list the regions checks can run from) and enriches it with the exact content returned: the available regions plus the per-monitor cap. The mention of `auto` being always present further pins down the result set, so an agent can distinguish this config-lookup from sibling list tools like list_monitors or list_channels.

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 closing sentence 'Set a monitor's `regions` to use them' gives clear intended context, implying this should be called before create_monitor/update_monitor. It does not name those siblings explicitly or state any when-not condition, so it stops short of full routing guidance.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false, fully covering the safety profile. The description adds no behavioral context beyond that – no pagination behavior, result ordering, or volume caveats.

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

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

A single front-loaded sentence with no filler. Nothing could be trimmed without losing the scope qualifier.

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

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

For a low-complexity read-only list tool with full annotation coverage, complete schema descriptions, and no output schema, the definition is essentially complete. The only minor gap is the absence of any note about result size or pagination.

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 optional parameters (project, workspace) are fully documented in the schema itself, including the 'omit to use default' fallback. The description adds nothing 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?

States a specific verb and resource ("List the status pages") with a scope qualifier ("of the current project"). An agent can distinguish this from create_status_page/update_status_page by the 'list' verb, though the description never names those siblings explicitly.

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

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

Usage is implied by the 'list' verb, but there is no explicit when-to-use or when-not-to-use guidance, and no mention of the sibling tools (create_status_page, update_status_page) or of other list_* tools it might be confused with. Adequate but leaves routing to inference.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=false, so safety is covered. The description still adds real context beyond that: the listing is scoped to what 'this connection can use' and returns ids explicitly intended to be reused as arguments elsewhere. It omits pagination or completeness details, keeping it from a 5.

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 primary capability is front-loaded and the actionable follow-up ('pass an id ... to any other tool') follows immediately.

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, the description carries the burden of explaining returns, and it does state that workspaces and projects are returned with their ids. It does not describe the shape of the response (e.g. nesting of projects under workspaces or list format), but for a simple discovery tool this is nearly 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?

Schema description coverage is 100% and both parameters already document their origin ('from list_workspaces') and default-omission behavior. The description only echoes that ids come from this tool, adding no syntax or filtering semantics beyond the schema, so the baseline 3 applies.

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

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

The description gives a specific verb ('List') and resource ('workspaces and projects'), plus the useful detail that ids are included. It implicitly separates itself from the sibling create_* tools by being the read-only enumerator, but it never names a sibling it is not, so it falls short of full sibling differentiation.

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

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

It clearly states the purpose-driven workflow: fetch ids here, then 'Pass an id as workspace / project to any other tool to act there.' That is strong contextual guidance for when to use this tool, though it does not state any when-not conditions or name an alternative tool.

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

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

Annotations already declare this is a non-read-only, non-destructive mutation, and the description adds the concrete behavioral consequence: checks stop running and no alerts are sent, and the state persists until resumed (implying reversibility). It stops short of explaining idempotency behavior (e.g., what happens if the monitor is already paused), which the idempotentHint=false annotation leaves open.

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 tight sentence that front-loads the action and then the consequence. No filler or redundancy.

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

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

For a simple 3-parameter mutation with no output schema and full schema coverage, the description covers purpose and effect adequately. A brief note on idempotency or the required monitor id scope would make it fully complete.

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

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

Schema description coverage is 100%, including notes on the optional project/workspace params and their fallback behavior, so the schema carries the parameter burden. The description adds no syntax or format meaning beyond it, making the 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?

States a specific verb and resource (pause a monitor) plus the operational scope of the action. It gestures at the sibling resume_monitor via 'until it is resumed' but never names it, so the differentiation is implicit rather than explicit.

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

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

The description conveys the effect of using it (checks and alerts stop) which implies the situation for use, but gives no explicit when-to-use guidance or prerequisites, and does not name resume_monitor as the complementary action.

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

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

Annotations only give the safety profile (readOnly=false, destructive=false, idempotent=false). The description adds genuinely non-obvious side effects: a resolved status closes the incident, public updates appear on status pages and are emailed to subscribers, and internal updates stay team-only. Those downstream notification effects are exactly what an agent needs and are not derivable from the annotations or 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, no waste, and the core action is front-loaded before the two conditional semantics (resolved, visibility). Every clause earns its place by changing how an agent would call the tool.

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 6-parameter mutation tool with no output schema, the description covers the highest-risk behaviors (incident closing, public email/status-page broadcast). It leaves minor gaps such as idempotency expectations and how the body is rendered, but nothing that would cause a clearly wrong invocation.

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

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

Schema coverage is 50%, so the description must carry weight, and it does for the two most consequential fields: it explains that status=resolved closes the incident and that visibility defaults to public with distinct distribution consequences. It adds nothing about id, body, project, or workspace, but those are either self-evident or covered by inline schema descriptions.

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

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

States a specific verb and resource ('Post a status update on an incident'), which is clearer than the bare tool name and separates it from a generic incident mutation. It does not explicitly contrast itself with close siblings like update_incident or acknowledge_incident, so an agent still has to infer the boundary.

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 through the effect descriptions ('status resolved closes it and must be public') and the default visibility behavior, which tells the agent what a call will do in a given case. However, there is no explicit when-to-use-this-vs-alternatives guidance against update_incident or acknowledge_incident, and no stated prerequisites or permissions.

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

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

Annotations already declare this is a non-readonly, non-idempotent, non-destructive mutation, so the safety profile is covered. The description adds only the precondition 'paused' and says nothing about side effects, what happens if the monitor is already running, or required permissions.

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 short sentence with no filler and the action front-loaded. It is efficient, though arguably terse to the point of omitting useful context.

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 state-toggle mutation with full schema coverage and annotations declaring the safety profile, the description is minimally adequate. It leaves gaps around behavior when the monitor is not paused and routing versus pause_monitor.

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 id, project, and workspace are all documented in the schema itself, including that project/workspace may be omitted for defaults. The description adds no parameter meaning beyond that, so the baseline 3 applies.

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

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

States a specific verb (resume) and resource (monitor) plus the precondition (paused). It is clearly distinguishable from the inverse sibling pause_monitor, though it does not name any sibling explicitly.

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

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

Usage is only implied by the phrase 'paused monitor' — the reader infers it should be used to bring a paused monitor back online. There is no explicit when/when-not guidance or mention of the natural alternative pause_monitor.

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

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

Annotations declare a non-read-only, non-idempotent mutation but say nothing about what it does. The description adds real value: a check normally records a result, while supplying region turns it into a one-off probe from that region with nothing recorded. That behavioral distinction is the kind of context annotations cannot express.

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, tightly front-loaded with the default behavior first and the region variant second. Every clause carries information; nothing is redundant or padded.

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

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

For a mutation tool with no output schema, the description covers the core side effect and the important region exception. It could still note whether the call is synchronous or how the returned result is shaped in the region mode, but the essentials for correct invocation are present.

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 75%, and the schema's `region` property has no description at all. The description compensates by defining region as an id from list_regions and explaining its effect, and the schema already covers id, project, and workspace.

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 gives a specific verb and resource ('Run a check for a monitor right now') plus the side effect (records the result). It is unambiguous, though it does not explicitly distinguish itself from siblings like get_monitor or create_monitor, which is a minor gap given no direct sibling performs this 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?

'Right now' implies the on-demand-trigger use case versus scheduled checks, and the region clause covers a conditional mode. However, it never states when not to use it or names an alternative tool, so the guidance is implied rather than explicit.

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

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

Annotations already declare the read-only, idempotent, non-destructive, closed-world profile, so the description only needs to add what they don't cover. It does: the auth requirement ('No credentials needed'), the ordering guarantee ('newest first'), and that nested updates are included. It stops short of saying how many incidents are returned or whether paging exists.

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, zero filler, with the resource and ordering stated up front and the auth note appended. Nothing could be cut without losing information.

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

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

With no output schema, the description carries the return-value burden and does so partially — it names the payload (incidents with their updates) and ordering, which is enough to call the tool correctly. Result volume/pagination and the exact update fields remain unstated, a minor gap for a read-only endpoint.

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

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

Schema description coverage is 100% and the single 'slug' parameter is documented in the schema with its format, pattern, and address position. The description adds nothing about the parameter, so the baseline 3 applies.

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

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

States a specific resource ('recent incidents of a public status page with their updates') and a clear ordering rule ('newest first'). The 'public status page' scoping implicitly separates it from sibling list_incidents (the account's own incidents) and status_page_maintenance (maintenance windows), but neither sibling is named explicitly.

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

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

Usage is only implied: 'No credentials needed' signals this is the unauthenticated public-page route, contrasting with the account-scoped incident tools. There is no explicit when-to-use statement, no mention of when to prefer status_page_overview or list_incidents instead.

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

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

Annotations already declare readOnly, idempotent, non-destructive, closed-world behavior, so the bar is lower. The description adds the genuinely useful non-annotated fact that no credentials are required, but says nothing about return shape, pagination, or window fields.

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

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

Two short sentences, resource scope front-loaded and the auth note appended. Nothing redundant; 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 simple read-only tool with full annotation coverage and one well-documented parameter, the description is nearly complete, and 'scheduled and ongoing' hints at the returned content. It stops short of noting pagination or whether historical windows are included, which matters slightly given no output schema.

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

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

There is a single parameter (slug) with 100% schema description coverage, so the schema carries the full burden. The description adds no format hints beyond the schema's pattern and address-derived explanation; baseline 3 applies.

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

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

The description names the specific resource (scheduled and ongoing maintenance windows) and scopes it to a public status page, which distinguishes it from the workspace-level sibling list_maintenance. However, it omits an explicit verb, so the agent must infer that it retrieves/lists rather than manages these windows.

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 credentials needed' gives an implied usage condition (public status page, no auth), but there is no statement of when to prefer this over list_maintenance or status_page_overview/status_page_incidents. Usage is inferable from the suffix pattern of the sibling tools but not stated.

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

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

Annotations already declare readOnly/idempotent/non-destructive, so the description's main added value is the explicit auth disclosure 'No credentials needed', which tells the agent this is an unauthenticated public read. It also describes the return payload shape, which matters since there is no output schema; it does not cover error behavior for an unknown slug.

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

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

A single sentence, front-loaded with the resource and followed by the returned contents plus the no-credentials note. Every clause carries information an agent needs; nothing is padded.

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

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

For a one-parameter, read-only, non-openWorld tool with no output schema, the description adequately covers what comes back and the auth posture. The only gap is failure behavior when the slug does not resolve to a public page.

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

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

Schema description coverage is 100% and the slug parameter already documents its format and the /status/<slug> address pattern. The description adds no further parameter meaning, so the baseline 3 applies.

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

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

States a specific verb+resource ('Current state of a public status page') and enumerates exactly what is returned: overall status, per-component status and 90-day uptime, and active incidents. This clearly separates it from write-oriented siblings like update_status_page, though it does not explicitly name status_page_incidents or status_page_maintenance as 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?

Usage is only implied: an agent can infer this is the read path for a status page's public snapshot, reinforced by 'No credentials needed'. There is no explicit when-to-use/when-not guidance and no mention of the sibling tools (status_page_incidents, status_page_maintenance) that offer narrower slices of the same resource.

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

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

Goes well beyond the annotations (which only declare readOnly=false, destructive=false, idempotent=false) by disclosing a non-obvious visibility lifecycle: content stays private until publishPostmortem=true, then surfaces on the public status page only once the incident is resolved, and false reverts it. It also discloses the empty-string-clears convention that no structured field states.

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

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

Three dense sentences with no filler, and the core operation (set/clear root cause and postmortem) is front-loaded before the publishing caveat. Slightly long clauses, but every clause carries information an agent needs.

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 6-parameter mutation tool with no output schema and only partial annotation coverage, the description supplies the missing behavioral and field semantics. It stops short of documenting auth/permission requirements or what the response looks like, but those gaps are minor given the audience.

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 50% and the three undocumented parameters (rootCause, postmortem, publishPostmortem) are exactly the ones the description explains: length limits, markdown format for the postmortem, publish semantics, and empty-string clearing. It does not clarify the null-vs-empty-string distinction even though the schema allows null for both text fields.

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

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

States a specific verb ('set or clear') applied to two named fields of a named resource (incident's root cause and postmortem). An agent can identify the operation immediately, though it does not explicitly contrast itself with siblings like post_incident_update or acknowledge_incident.

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

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

Usage is only implied: the description explains what the fields mean and how publishing works, but never says when to reach for this tool instead of post_incident_update or get_incident, nor any prerequisites such as needing the incident to exist or be resolved. Adequate but no explicit routing guidance.

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

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

Annotations already disclose a non-read-only, non-idempotent, non-destructive mutation. The description adds genuinely useful PATCH semantics ('only the named fields are modified'), but says nothing about side effects, permission needs, or what happens to omitted fields' derived state.

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 core action, and no filler. It is efficient, though borderline terse given the tool's 22-parameter surface.

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 22-parameter mutation with 14% schema coverage and no output schema, the description is far too thin. It omits parameter meaning, interaction with sibling pause/resume tools, and any behavioral detail an agent needs to invoke it safely.

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 only 14% across 22 parameters, so the description must compensate, yet it explains only 'paused'. The remaining 21 fields (target, method, headers, regions, thresholds, channelIds, etc.) get no meaning beyond their bare JSON schema types.

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 clear verb+resource ('Change fields of a monitor') and adds PATCH scope ('only the named fields are modified'). However, it does not distinguish itself from the dedicated pause_monitor and resume_monitor siblings despite mentioning the paused field.

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 when-to-use or when-not-to-use guidance. The line 'Set paused to pause or resume it' creates ambiguity against the dedicated pause_monitor/resume_monitor tools without explaining which to prefer, leaving the agent to guess.

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

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

Annotations already declare the safety profile (readOnly=false, destructive=false, idempotent=false). The description adds genuinely useful behavioral context with 'monitorIds replaces the list', clarifying replacement rather than append semantics. It still omits whether unspecified fields are preserved, permission requirements, and the result of the mutation.

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

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

A single well-formed sentence that front-loads the verb and packs the updatable fields efficiently with no filler. Only slightly dense at the tail with the parenthetical clarification.

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

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

For a 9-parameter mutation with 56% schema coverage and no output schema, the description covers only about half the parameters and gives no guidance on partial-update semantics or auth. An agent would need to infer a lot 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 56%, and the description adds real value for monitorIds (replaces the list) beyond the bare array schema. However it says nothing about externalUrl, hideBranding, project or workspace, so roughly half the parameters rely entirely on the schema.

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

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

States a specific verb ('Change') and resource ('status page') and enumerates the mutable fields (title, theme, latency display, monitors), so an agent can distinguish this from create_status_page and list_status_pages. It does not explicitly name siblings, but the verb+resource 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?

There is no statement of when to use this tool versus alternatives (e.g., create_status_page, update_monitor), nor any prerequisite or exclusion guidance. Usage is only inferable from the tool name and the implied mutation semantics of the field list.

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