Exit1 Uptime Monitoring

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

Annotations already declare readOnly=false, openWorld=true, idempotent=false, destructive=false, so the mutating/side-effecting nature is covered. The description adds genuinely new behavior: the platform is auto-detected from the URL, which the agent cannot infer from annotations. It does not cover duplicate-URL handling, auth requirements, or delivery/verification 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, zero padding, and the invocation instruction (paste the URL) is front-loaded before the conditional auto-detection detail. Every clause carries information.

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

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

For a five-parameter creation tool with no output schema, the description covers channel support, the URL source, and type resolution, leaving events and secret to the schema. It is nearly complete, though it could note the relationship to send_test_alert for verifying a newly added webhook.

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 five parameters are already documented, including webhook_type's 'Override auto-detection'. The description's supported-platform list adds nuance (any HTTPS endpoint) but largely restates the schema's auto-detection/override relationship, 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 concrete purpose: registering an alert destination across Slack, Discord, Teams, or any HTTPS endpoint, with the mechanism (paste the incoming-webhook URL) spelled out. It implicitly distinguishes itself from sibling notification tools like set_email_alerts and send_test_alert by naming the channel types, but 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?

It gives clear operational guidance: paste the URL the user gives you, and pass webhook_type only when overriding auto-detection. That tells the agent the expected invocation pattern. It stops short of stating when not to use this tool or which sibling to prefer for related notification tasks.

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, destructiveHint=false, idempotentHint=false, openWorldHint=true, so the safety profile is covered. The description adds genuinely new context beyond the schema: the cross-tool prerequisite of consulting get_account for the plan's minimum interval, which behaves like a plan-tier/rate constraint.

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 purpose and then the type taxonomy plus one prerequisite. Every clause maps to a real decision the caller must make; nothing is redundant filler.

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

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

For an 11-param, no-required, nested-object creation tool the description covers purpose, type selection, and a prerequisite well. Gaps: it omits the 'redirect' type that appears in the enum, and does not state what is returned (no output schema exists, and a created check's ID matters for chaining).

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 91%, so baseline is 3. The description exceeds it by explaining type semantics the enum cannot ('rest_endpoint' supports JSONPath assertions, 'dns' means record drift, 'domain' means registration expiry), clarifying which values to pick for each param.

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 new monitor') and immediately differentiates the tool by enumerating the eight check types and what each monitors. An agent can tell this is the creation entry point versus list_checks/get_check/update_check without opening any schema.

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

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

Gives explicit when-to-use guidance per type ('website' for a page returning 200, 'rest_endpoint' for an API, 'heartbeat' for cron jobs) and a prerequisite ('Check the plan's minCheckIntervalMinutes via get_account before setting check_frequency_minutes'). It does not state when NOT to use it (e.g. use update_check to modify an existing check), so it stops short of the 5 bar.

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

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

Annotations already declare destructiveHint=true, readOnlyHint=false, and idempotentHint=false, so safety is structured data. The description still adds real context beyond that: irreversibility ('This cannot be undone') and the side effect that monitoring stops. It stops short of detailing downstream effects (e.g., alert/history loss), so it's strong but not maximal.

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 sentences: the operation, the irreversibility warning, then the alternative — front-loaded and waste-free. 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 one-parameter destructive tool with rich annotations and full schema coverage, the description supplies everything an agent needs: scope, consequence, irreversibility, and the safer alternative. Nothing material is missing.

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

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

Schema description coverage is 100% and the single check_id parameter is fully documented in the schema, including its origin (list_checks or create_check). The description adds nothing beyond that, so 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 ('Permanently delete a check') plus the consequence ('stop monitoring it'), which cleanly separates it from toggle_check. An agent can identify the operation without opening the schema.

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

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

Explicitly names the preferred alternative (toggle_check) and the precise condition that overrides it ('unless the user explicitly wants it gone'). This is a textbook when-not/alternative routing instruction.

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, openWorld, and non-destructive behavior. The description adds useful context beyond the annotations: it specifies that the return covers plan limits and current usage, and frames the call as a guard against later errors.

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 what the tool returns and then its recommended timing and purpose. No filler; each sentence carries distinct, non-redundant 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 zero-parameter, read-only retrieval with rich annotations and no output schema, the description gives enough: what is returned, why it matters, and when to call it. It could be slightly richer about the return shape, but it is adequate.

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

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

The tool takes zero parameters, so schema coverage is 100% by default and the description need not explain parameter usage. The baseline of 4 applies because there are no parameters to misinterpret.

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: get the current plan, its limits, and how much of them is used. It distinguishes itself from siblings like get_alert_settings or list_checks by scoping to account-level plan data rather than checks, alerts, or 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?

It explicitly says to 'Call this FIRST when setting up monitoring' and explains the payoff: knowing check limits and the fastest interval. It gives clear context for use, though it does not name a specific alternative tool or state when not to use it.

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

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

Annotations already declare readOnly, idempotent and non-destructive, so the safety profile is covered. The description adds value beyond them by disclosing what the call returns (email recipients and connected webhooks), which matters because there is no output schema; it omits any note on permissions or empty-state 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, no filler, with the resource description front-loaded and the actionable instruction second. Every clause carries information an agent can use.

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 tool with no output schema, the description supplies the missing return-value information (the channel types inspected), and the annotations carry the safety semantics. Nothing an agent needs to invoke it correctly is 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 takes zero parameters, so there is nothing for the description to disambiguate; the schema is trivially complete. Baseline for a parameterless tool is 4, and the description does not need to compensate for anything.

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 ('Show') and resource ('where alerts currently go'), and enumerates the two channel types returned (email recipients, connected webhooks). It reads clearly as the read-side counterpart to set_email_alerts/add_webhook_alert, but it never names or contrasts those siblings explicitly, 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?

Gives concrete timing guidance — call it before configuring alerts to avoid duplicating an existing channel — which is real when-to-use context rather than a restatement. It does not name the specific alternative tools (set_email_alerts, add_webhook_alert) an agent should follow it with, so it stops at a strong 4.

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 behavior, so the safety profile is covered without description help. The description adds value by enumerating what is returned (status, response time, SSL state, maintenance mode), but says nothing about error cases, unknown IDs, or freshness of the data.

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; the scope ('one check') precedes the field enumeration, and every clause carries information.

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

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

For a simple single-resource read with full annotation coverage, a 100%-covered one-param schema, and no output schema, the description's field enumeration is nearly sufficient. Only the lack of distinction from get_check_history/get_check_stats keeps it from being 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 coverage is 100% with a single well-documented check_id, so the schema carries parameter meaning. The description restates the scope ('one check') but adds no format, syntax, or sourcing detail beyond the schema's own note.

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 one check) and enumerates the returned fields, so the agent knows exactly what it retrieves. It implicitly distinguishes itself from list_checks by scoping to 'one check', but it never clarifies how it differs from siblings like get_check_history or get_check_stats.

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 schema notes check_id comes from list_checks or create_check, which suggests a follow-up lookup after listing. There is no explicit when-to-use guidance or routing away from get_check_history/get_check_stats, leaving ambiguity about which detail tool to pick.

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, openWorldHint and destructiveHint=false, so the safety profile is fully covered without the description. The text usefully lists what each record contains, but says nothing about pagination behavior, retention windows, or result ordering that a caller investigating an incident would care about.

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: the first front-loads what is returned, the second states when to use it. No filler, no repetition of the title or 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?

With no output schema, the description carries the return-value burden and does enumerate the record fields, which is genuinely helpful. It is still silent on result ordering and how the page/limit pair behaves across a large incident window, leaving a small gap for a 6-parameter history query.

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%: check_id, from, to and limit are documented in-schema, while page and status carry no description. The prose adds no filtering or paging semantics beyond the schema, so it neither compensates for those gaps nor extends what is already there — baseline 3 for this coverage level.

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 ('Get individual check results over time') and enumerates the payload (timestamps, status codes, response times, errors), which separates it from get_check (current state). It never explicitly contrasts itself with the sibling aggregate tool get_check_stats, so it stops short of 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?

'Use when investigating an incident or confirming a fix held' gives a concrete, actionable scenario for invoking it. It offers no exclusion or named alternative (e.g. use get_check_stats for trends), so it lacks the when-not half of a 5.

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

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

Annotations already declare readOnly, idempotent, openWorld and non-destructive, so the safety profile is covered. The description adds that the result is an aggregate spanning one or more time ranges, which is useful behavioral context, but says nothing about cost, rate limits, or how multiple ranges are 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 tight sentences with zero waste. The core capability is front-loaded and the usage hint follows immediately, making it easy to scan.

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 does the work of naming what comes back (uptime percentage and response-time statistics). That covers the essentials for a 2-parameter read tool; only details on multi-range output shape are 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?

Schema description coverage is 100%, so both parameters (check_id and ranges, with its allowed values and default 1d,7d,30d) are already fully documented in the schema. The description adds no syntax or format detail beyond what the schema provides, so the baseline 3 applies.

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

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

States a specific verb (get) and resource (aggregate uptime percentage and response-time statistics for a check), which implicitly separates it from siblings like get_check (config) and get_check_history (raw events). It does not explicitly name those siblings, but an agent can tell the aggregate-statistics purpose apart from the raw-history and config 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?

Gives clear usage context: 'Good for how has this been doing questions and week-over-week comparisons.' This tells the agent when this tool is the right fit versus raw history. It stops short of naming an alternative or an explicit when-not condition.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is covered. The description adds genuinely new context beyond that: this returns a point-in-time snapshot (no history) and includes per-check status and uptime percentage, which no structured field conveys.

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

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

One sentence, front-loaded with the action and resource, with the return content trailing. Nothing is padded or repeated from the title.

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 tool with no output schema, the description covers both what it fetches and the shape of what comes back. It stops short of noting snapshot freshness/refresh semantics or how to obtain the status page ID, which would be the only remaining 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?

There is a single parameter at 100% schema description coverage, so the schema already documents status_page_id fully. The description adds no format, source, or lookup guidance for that ID, 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?

States a specific verb and resource ('Get the current snapshot of a public status page') and even summarizes the payload ('each check's status and uptime percentage'). It does not explicitly name a sibling, but the resource is distinctive enough against the check/account/alert tools in the sibling list to be 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?

Usage is implied by the scope ('public status page' snapshot) but there is no explicit when-to-use guidance, no prerequisites, and no mention of alternatives such as get_check or get_check_stats. An agent can infer intent but must guess at the boundary cases.

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

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

Annotations already establish the safety profile (readOnlyHint, idempotentHint, destructiveHint=false, openWorldHint), so the description's job is to add context. It does: folder matching is exact unless recursive is set, recursive nests subfolders, and include="uptime" augments each record with computed uptime/response-time fields. No mention of pagination totals or rate limits, but the added semantics are useful.

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

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

Three tight sentences with no filler: purpose first, then filtering semantics, then the include augmentation. Every sentence carries information an agent needs before calling.

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 six-parameter, all-optional listing tool with annotations covering safety and no output schema, the description covers purpose, filtering, and what extra fields appear. It never touches pagination behavior or the overall result shape, which is the only remaining gap given there is no output schema to lean on.

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 page, limit, folder, status, include, and recursive. The description's parameter statements (folder, recursive, include) largely restate what the schema says, adding little beyond a readable summary, 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 opens with a specific verb and resource ("List monitored checks") plus the payload fields returned ("current status and folder"), which cleanly separates it from the singular sibling get_check and the mutating create_check/delete_check/toggle_check tools. An agent can identify the tool's role without opening the schema.

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

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

It gives three concrete use cases (overview, find offline checks, verify what is already monitored before creating duplicates), which effectively routes the agent away from create_check when discovery is needed. There is no explicit when-not-to-use statement or named alternative tool, so it stops short of the top band.

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

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

Annotations declare the safety profile (readOnlyHint=false, destructiveHint=false, idempotentHint=false, openWorldHint=true), so the bar is lower. The description adds genuine context beyond them: the alert is REAL, not a dry run, and it exists to verify external delivery — exactly the kind of side-effect disclosure 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?

Three short sentences, front-loaded with the action and ending with the call syntax. The middle sentence is justification rather than instruction but it earns its place by explaining why the tool must be used.

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, non-destructive action with annotations and no output schema, the description covers purpose, timing, and invocation. Return-value details are not required given no output schema, though it could say what the agent should report back after a test.

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

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

Schema coverage is 100% and the schema already documents both parameters, including the enum and the conditional webhook_id requirement. The description's 'Pass channel=... with a webhook_id' merely restates what the schema encodes, so 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 ('Fire a real test alert') plus its purpose ('so the user can confirm delivery works'). This clearly distinguishes it from the configuration siblings set_email_alerts and add_webhook_alert, which set up channels rather than exercise them.

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

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

Gives explicit, strongly-worded timing guidance ('ALWAYS finish a monitoring setup with this') and explains the failure mode it prevents. It does not name a when-not condition or an alternative tool, so it falls just short of the top band.

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, openWorldHint=true, destructiveHint=false and idempotentHint=false, so the safety profile is covered. The description adds the effective default configuration when no arguments are supplied, which is net-new behavioral information. It does not state whether a call replaces or merges the existing recipient/event set, which is the key ambiguity for a 'set' tool.

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

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

Three sentences, front-loaded with the action and scope, then the event vocabulary, then the default. The trailing clause 'which is the right pair for most people' is mildly editorial but does convey a recommended configuration. No meaningful waste.

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 required parameters, the description covers what an agent needs to invoke it: the operation, the valid event values, and the no-argument default. Remaining gaps (replace-vs-merge semantics, whether disabled alerts retain recipients) are secondary but would matter for a mutation tool.

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

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

Schema coverage is 100%, so the per-parameter descriptions carry the basic meaning and the baseline would be 3. The description goes beyond the schema by enumerating the concrete allowed event strings (website_down, website_up, website_error, ssl_error, ssl_warning, domain_expiring, domain_expired, domain_renewed) - the schema's 'events' property has no enum for its array items, so this list is the only place those valid values appear.

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 ('Set which email addresses receive alerts and which events trigger them') and enumerates the triggerable events, so the agent immediately knows this writes email-alert configuration. It does not explicitly position itself against the closest siblings (get_alert_settings for reading, add_webhook_alert for the other channel), so differentiation is only implicit.

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 default guidance ('Defaults to website_down + website_up, which is the right pair for most people') tells the agent what happens when it omits options, which is useful context. However, there is no explicit when-to-use guidance versus get_alert_settings (inspect current config) or add_webhook_alert (non-email channel), leaving the 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 idempotentHint=true and destructiveHint=false; the description adds genuinely new behavioral context by explaining the functional consequence of the flag ('stop probing and stop alerting'), which an agent cannot infer from the annotations alone. It stops short of stating reversibility or persistence of the disabled 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 action and scope, then the routing advice. Zero filler and nothing redundant with the title.

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 2-parameter toggle with no output schema, the description covers purpose, effect, and the sibling alternative. Only minor gaps remain, such as whether the state persists or how it interacts with update_check.

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

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

Schema description coverage is 100% and the schema already spells out both parameters, including the true/false meaning of 'disabled' and where check_id comes from. The description adds no syntax or format detail beyond that, so 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 pair (enable/disable) on a specific resource (check) and immediately scopes it as non-destructive, which distinguishes it from delete_check and update_check in the sibling 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?

Explicitly names the alternative and the selecting condition: 'use this rather than delete_check for a temporary pause.' It does not address the toggle vs. update_check boundary, but the when-to-use guidance is clear and actionable.

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

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

Annotations already declare non-readOnly, idempotent, non-destructive, so the safety profile is covered. The description adds a genuinely useful trait beyond the annotations: partial-update semantics ('Only the fields you pass are modified'), telling the agent unpassed fields are preserved rather than cleared. It stops short of noting auth needs or side effects, but this is meaningful added 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?

Two short sentences, zero padding, with the core action front-loaded and the partial-update constraint following immediately. 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 an 8-parameter mutation tool with nested objects and low schema coverage, the description covers the essential partial-update behavior but omits parameter-level guidance and any hint about the result of the update. Annotations absorb the safety burden, keeping this minimally adequate rather than 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 only 25%, so the description is expected to compensate, and it does not. 'The fields you pass' is a generic phrase that names no parameter, gives no format guidance for url/http_method/expected_status_codes, and leaves the nested response_validation object undescribed beyond a schema pointer.

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 ('Change an existing check's settings'), clearly distinguishing this from create_check/delete_check. However, it does not name or differentiate from the closest sibling toggle_check, so the boundary between changing settings and toggling enablement is left implicit.

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 verb 'change'; there is no explicit when-to-use, no mention of prerequisites, and no contrast with alternatives like create_check or toggle_check. The reader can infer this is the settings-mutation path, but nothing routes them there.

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