Healthchecks.io MCP by usefulapi

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

Annotations only declare destructiveHint=true; the description adds real context beyond that — that it mutates live monitoring config, that duplicate matches return the existing check instead of erroring, and the HTTP outcomes (201 created vs 200 existing). Auth/permission requirements are not mentioned, which keeps 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?

Three dense, front-loaded sentences: the mutation warning leads, then the parameter contract, then the return behavior. No filler, and the most consequential constraint (mutual exclusivity) is stated before the optional extras.

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 12 optional parameters, no required fields and no output schema, the description covers the essential contract (one of timeout/schedule, dedupe, notifications) and return shape. It leaves per-field descriptions to the schema, which is fully documented, so the coverage is adequate though not exhaustive on 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 coverage is 100%, so the baseline is 3, but the description adds cross-parameter constraints the schema cannot express: `timeout` XOR `schedule`+`tz`, and the dedupe semantics of `unique` that control whether a create actually happens.

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 ('CREATES a new check') and immediately scopes it ('MODIFIES live monitoring config'), which cleanly separates it from update_check, delete_check, and the list/get siblings. An agent can identify the tool 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?

Gives concrete conditional guidance: provide `timeout` OR `schedule`+`tz` (mutually exclusive), use `unique` to avoid duplicates, assign notifications via `channels`. It does not explicitly contrast create vs update_check for an already-existing check, so it stops short of full when/when-not routing.

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

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

Annotations already declare destructiveHint=true, so the safety signal is partly redundant, but the description adds real value: irreversibility, that live monitoring config is modified, and that the deleted check's last known state is returned. No output schema exists, so that return-value note is genuinely informative. It stops short of stating permission/auth requirements or downstream effects on pings.

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

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

Three compact clauses, front-loaded with the irreversible action and capped with the API route and return behavior. No filler sentences.

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

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

For a single-parameter destructive tool with no output schema, the definition covers what is destroyed, that it cannot be undone, the underlying API call, and what comes back. Nothing essential to calling it correctly is missing.

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

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

Only one parameter, and schema description coverage is 100% ('The check's UUID to delete.'). The description's phrase 'by UUID' merely echoes the schema and adds no format, source, or lookup guidance beyond it.

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

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

States a specific verb (PERMANENTLY DELETES) on a specific resource (a check, identified by UUID), and the API mapping (DELETE /checks/{uuid}) removes ambiguity. It is immediately distinguishable from siblings like pause_check or update_check.

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

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

The description makes the destructive, irreversible nature clear, which implicitly gates usage, but it never names a non-destructive alternative such as pause_check or resume_check even though those siblings exist. Usage context is implied rather than stated.

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

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

Annotations only supply readOnlyHint=true, so the description adds genuine value by listing the returned state fields (status, timeout/schedule, grace, tags, last ping) and noting the read-only key alternative. It still omits auth requirements and error behavior, keeping it below 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 compact sentences with the purpose and identifier front-loaded, followed by return contents. The trailing API mapping is mildly redundant but compact and places no burden on the reader.

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

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

For a single-param read-only tool with no output schema, the description compensates by enumerating the returned fields and annotation coverage handles the safety profile. Complete enough to invoke correctly.

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

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

Schema description coverage is 100% and the sole param is fully documented there. The description restates the UUID/read-only-key duality but adds no syntax or format detail 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?

States a specific verb and resource ("Get a single check") plus the identifier syntax, and "single" implicitly contrasts with the sibling list_checks. An agent can distinguish this from the list/ping-body siblings without opening a 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?

Usage is implied by "single check by its UUID" but no explicit when-to-use or when-not guidance is given against list_checks or get_ping_body. No prerequisites or exclusions are 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 readOnlyHint=true, so safety is covered. The description adds genuinely useful behavior: the response is PLAIN TEXT, verbatim, not JSON, which matters because there is no output schema to convey this. It does not cover edge cases such as missing/empty bodies or size limits.

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 dense sentence front-loads the purpose and the plain-text return. The appended REST path is somewhat redundant given the schema, but it is short and harmless.

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

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

For a 2-param read tool with no output schema, the critical missing piece is the return format, and the description supplies it (plain text, not JSON). What remains unstated is failure behavior when no body was logged, which is a minor gap.

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

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

Schema description coverage is 100%, so both parameters are already well documented, including the useful hint that n comes from list_pings. The description only restates the path placeholders ({uuid}, {n}) without adding format or range semantics, 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 ('Get') and resource ('the logged request body of a single ping'), with scope narrowed to one ping rather than the ping list. It is clearly distinguishable from sibling list_pings and get_check.

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

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

Usage is implied: fetch this when you need the raw body of one already-identified ping. There is no explicit when-to-use/when-not guidance or routing to a sibling alternative, and nothing tells the agent how this differs from list_pings beyond granularity.

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

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

Annotations declare readOnlyHint=true, so safety is already covered. The description adds value beyond that by disclosing the return shape ({badges:{...}}) and the mapping granularity (per tag, plus '*' for overall), which the agent could not infer from the empty 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?

One dense sentence plus the upstream endpoint reference. The key detail (per-tag badge URLs, with '*' for overall) is front-loaded and 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 parameterless read-only tool with no output schema, the description supplies the return structure and the tag semantics an agent needs to consume the result. It stops short of describing exact URL formats or auth requirements, but nothing essential is missing.

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

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

The tool takes zero parameters, so the baseline is 4. The description's tag/'*' note describes the structure of the returned data rather than input arguments, so there is nothing else to document.

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 (the project's status-badge URLs), and names the tag grouping plus the '*' overall-status special case. Badges are distinct from every sibling (checks, flips, pings, integrations), so an agent can route to it unambiguously.

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 rather than stated: the tool clearly returns badge URLs for the project, but there is no explicit when-to-use guidance, no prerequisites, and no named alternatives. With zero parameters and no overlapping sibling, this gap is minor but real.

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 declare readOnlyHint=true; the description goes further by sketching the response envelope ({checks:[...]}) and the per-check fields returned, and by citing the underlying GET /checks/ endpoint. It still omits pagination behavior and any default result limits.

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: the primary action and filters come first, then the return shape and endpoint. No filler, and nothing an agent needs is buried.

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 usefully compensates by naming the return envelope and key fields, and it covers both optional filters and the API route. Minor gaps (pagination, ordering, empty-result behavior) keep it short of full completeness.

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 are documented there in more detail (e.g. the AND-semantics of tags) than in the description. The description only restates the filter axes, 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 all checks in the project') plus the optional filter dimensions, which clearly separates it from create/delete/pause siblings. It does not explicitly point to get_check for single-check retrieval, so sibling differentiation is implicit rather than stated.

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

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

The phrase 'optionally filtered by slug and/or tags' implies when the filters are useful, but there is no explicit guidance on when to use this list tool versus get_check or the pings/flips listers. Usage is inferable from the description, not spelled out.

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

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

Annotations already declare readOnlyHint=true, so safety is covered; the description adds the concrete return shape [{timestamp, up}] and maps the tool to the underlying endpoint GET /checks/{uuid}/flips/. It stops short of noting pagination or result-count limits, so it is good but not exhaustive.

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: purpose and return shape first, scoping options second, API path last. No filler, and the most decision-relevant information is front-loaded.

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

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

There is no output schema, and the description compensates by describing the returned elements. It is close to complete for a 4-param read tool, but omits default behavior (what happens with no time filter) and any ordering/pagination expectations.

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 every parameter (uuid, start, end, seconds) is already documented in the schema. The description restates the two scoping modes at a high level without adding format or precedence details (e.g., seconds vs start/end conflict), 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?

The description names a specific verb+resource ('List a check's status changes ("flips")') and even sketches the return shape [{timestamp, up}], which cleanly separates it from siblings like list_pings and list_checks. An agent can distinguish it 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 states how to narrow results ('Optionally scope by a lookback window or an explicit start/end range') but never says when to prefer this tool over list_pings or other history tools, nor any prerequisites beyond the required uuid. Usage is implied rather than guided.

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

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

readOnlyHint=true already declares the safety profile, so the description only needs to add context, which it does by disclosing the response shape ({channels:[{id, name, kind}]}) and how the returned ids are consumed. It says nothing about pagination or filtering, but with zero parameters there is little else to disclose.

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 clauses with no filler: purpose first, then response shape, then the field-consumption note and endpoint. Everything is front-loaded and each element earns its place.

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

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

Although no output schema exists, the description inlines the return structure and the meaning of its ids, and the no-param schema plus readOnlyHint cover the rest. An agent has everything needed to call and consume it.

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

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

The tool takes no parameters, so there is nothing for the description to clarify; the 4 baseline applies. The description usefully explains the semantics of the returned `id` fields instead.

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 — list the project's notification integrations — and disambiguates the nomenclature by equating "integrations" with "channels" and naming the upstream endpoint GET /channels/. It is clearly distinguishable from siblings such as list_checks, list_badges, and list_flips.

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 real usage context: the ids returned are what you assign to a check's `channels` field, which tells an agent why it would call this before create_check/update_check. It does not name a competing alternative or state when not to use it, but for a parameterless list tool the guidance is adequate.

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

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

Annotations only declare readOnlyHint=true, so the description usefully adds ordering ('most recent first'), plan-dependent result caps, and the exact fields returned. This is meaningful behavioral context beyond the safety profile, though it omits pagination navigation details.

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

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

Purpose is front-loaded in the first clause, followed by limits, ordering, and return fields. The field enumeration is dense but earns its place given no output schema exists. Slightly list-heavy but no filler.

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

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

With no output schema, the description compensates by listing the ping fields returned and stating result limits and ordering. Combined with readOnlyHint covering safety, an agent has enough to invoke and interpret results, though pagination behavior is unstated.

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?

One required parameter with 100% schema description coverage, so the schema already documents uuid fully. The description adds nothing about the parameter, making this the baseline 3.

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

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

States a specific verb and resource: 'List a check's logged pings,' which is unambiguous about what is returned. It does not explicitly distinguish itself from siblings like get_ping_body or list_flips, but the resource scope makes the distinction obvious.

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

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

The description gives no guidance on when to use this tool versus alternatives, nor prerequisites. The plan-based limit (100 vs 1000) hints at pagination scope but is not framed as usage guidance.

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

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

Adds real behavioral context beyond the destructiveHint annotation: missed pings no longer trigger downs, the state auto-clears on the next ping, and live monitoring config is modified. It is consistent with destructiveHint=true (config mutation) and does not contradict it. It could still note whether the change is reversible only via resume.

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 plus the endpoint; the action and its non-destructive scope are front-loaded, and every clause (state change, alert suppression, auto-recovery, endpoint) 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 one-parameter state-mutation with no output schema, the description covers action, effect, and endpoint adequately. It omits what the call returns or whether paused state is idempotent, but those gaps are minor for this tool's 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 description coverage is 100% and the single uuid parameter is fully documented there, so the baseline is 3. The description adds no meaning about the parameter itself, only the REST path POST /checks/{uuid}/pause, which is endpoint context rather than parameter semantics.

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

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

States a specific verb (PAUSES) and resource (check) with immediate clarification of what pausing means: 'disables monitoring without deleting it'. This clearly separates it from sibling delete_check (destructive removal) and resume_check (undo), so an agent can distinguish it 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?

Explains the scenario that selects this tool — temporarily silencing a check without removing it — and the parenthetical 'until it next receives a ping or is resumed' implies resume_check as the reversal path. It stops short of naming the alternative tool explicitly the way an ideal routing statement would.

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

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

With destructiveHint=true already flagged, the description adds the mutation reality ('This MODIFIES live monitoring config'), the specific error condition (409 if not paused) and the underlying endpoint semantics. It stops short of describing auth requirements or the resulting check state, but the added error behavior is genuinely 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: action, side effect, failure mode, plus the raw endpoint. Front-loaded with the verb and zero 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?

Covers purpose, mutation side effect, error handling, and the concrete API route with empty body — enough for a simple single-parameter state-change tool with no output schema. Minor gap: it does not say what state the check reports afterward or whether resuming resets anything.

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% for the single uuid parameter, so the schema carries the documentation burden. The description only restates the uuid inside the endpoint template (POST /checks/{uuid}/resume) without adding format or sourcing detail, which is the expected baseline.

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

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

States a specific verb and resource ('RESUMES a paused check — re-enables monitoring') and makes the state transition explicit. An agent can distinguish it from the sibling pause_check 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?

Clearly frames the precondition ('paused check') and what happens when it does not hold (HTTP 409 when the check is not currently paused), which tells the agent when this tool is applicable. It does not explicitly name pause_check as the inverse alternative, but the routing is unambiguous.

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, so the mutation risk is partly covered by structured data. The description reinforces this with 'MODIFIES live monitoring config' and adds the partial-update contract and the timeout/schedule exclusivity rule, but discloses nothing about permissions, failure modes, or what happens to omitted fields. It adds some value over the annotation without being 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?

Four tight clauses, front-loaded with the verb and the risk, then the partial-update rule, then the exclusivity caveat and return statement. Every clause carries information, though the em-dash-dense single sentence is slightly harder to scan than a short multi-sentence form.

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

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

For a 13-parameter mutation tool with no output schema, the description covers the mutation semantics, the partial-update contract, and the return value ('Returns the updated check'). The main remaining gap is that fields like 'unique' and 'channels' behave differently on update than on create, which is not addressed.

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 13 parameters are already documented, including the timeout/schedule mutual-exclusion rule and the tz dependency. The description merely restates the exclusivity constraint rather than adding syntax, defaults, or format guidance beyond the schema. Baseline 3 applies.

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

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

States a specific verb (UPDATES), a specific resource (an existing check) and the addressing key (by UUID), plus the consequence ('MODIFIES live monitoring config'). The sibling set is cleanly partitioned into create/delete/get/pause/resume, and this description makes clear it is the in-place mutation path.

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 actionable usage guidance: send only the fields you want to change (partial update), and flags that timeout and schedule remain mutually exclusive. It stops short of explicitly naming alternatives such as create_check for new checks or pause_check for state changes, so it earns a 4 rather than a 5.

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