healthchecksio

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

Beyond the destructiveHint annotation, the description adds meaningful behavioral context: it modifies live monitoring config, explains the two mutually exclusive check modes, and discloses that a duplicate match returns 200 while creation returns 201. It also references the exact POST endpoint, giving the agent a fuller picture of side effects and outcomes.

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

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

The description is compact and front-loaded with the most important fact—that this mutates live config. Every sentence adds useful information: mutually exclusive modes, dedupe behavior, channel assignment, endpoint, and return statuses. 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?

The description covers endpoint, mutation warning, parameter mode selection, deduplication, notifications, and return status codes. With no output schema, it appropriately discloses what the caller will receive. It is complete for a create operation with 12 fully documented schema parameters.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds value by grouping parameters semantically: timeout for period-based checks, schedule+tz for cron-based checks, unique for dedupe, and channels for notifications. This helps the agent reason about parameter relationships beyond individual 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?

The description clearly states the specific verb and resource: CREATES a new check. It distinguishes itself from sibling tools by emphasizing it mutates live monitoring config, separating it from list/get/update/delete operations.

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 clear context for when to use the tool—creating a new check—and gives operational guidance on the mutually exclusive timeout vs schedule+tz modes, using unique for deduplication, and assigning channels. It doesn't explicitly name alternatives or when-not scenarios, but the context is strong enough to guide selection.

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 provide destructiveHint=true, so the description carries the disclosure burden for what destruction means. It adds irreversibility, impact on live monitoring configuration, the HTTP endpoint, and the return value (the deleted check's last known state). This goes well beyond the annotation.

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

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

Three short sentences, each earning its place: the action and permanence, the endpoint mapping, and the return value. Critical warnings are front-loaded and there is no filler.

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

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

For a single-parameter destructive tool with no output schema, the description is complete: it names the param, explains the danger, gives the HTTP verb/path, and states what the response contains. Nothing an agent needs to invoke it correctly is missing.

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

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

Schema coverage is 100%, and the schema already describes the uuid parameter as 'The check's UUID to delete.' The description repeats 'by UUID' and adds an endpoint reference, but does not add meaningful new parameter semantics beyond the schema.

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

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

States a specific verb (DELETE), the resource (a check), and the identifier (UUID). It also emphasizes permanence, which distinguishes it from pause_check, resume_check, and update_check even without reading sibling schemas.

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

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

The description does not name an explicit alternative, but the strong context 'cannot be undone' and 'MODIFIES live monitoring config' makes it clear this is only for intended permanent deletion, not temporary disabling. This is clear contextual guidance even without explicit when-not statements.

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, and the description reinforces this by using 'Get' and stating the operation returns state. It goes beyond the annotation by detailing exactly what is returned: status, timeout/schedule, grace, tags, and last ping, plus the underlying REST endpoint. There is no contradiction.

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

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

The description is two compact sentences with no filler: it front-loads the primary purpose, lists the returned payload, and includes the endpoint reference. 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 single-parameter GET with no output schema, the description supplies the endpoint, supported identifier forms, and the key fields of the returned state. Sibling tools cover alternative operations, so nothing essential is missing for an agent to select and call it correctly.

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

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

The only parameter, uuid, is already fully documented in the schema with 100% coverage. The description's mention of 'UUID (or unique read-only key)' mirrors the schema rather than adding new meaning, so the baseline score of 3 is appropriate.

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

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

The description states a specific action ('Get') against a specific resource ('a single check'), identified by UUID or read-only key. It also lists the returned state fields, making the operation unambiguous and distinct from sibling operations like create, delete, or list_checks.

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 'a single check by its UUID' clearly establishes that this tool is for retrieving one check by identifier rather than for collection-level operations. It does not explicitly name alternatives such as list_checks for listing all checks, so it provides clear context without explicit exclusions.

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

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

Annotations already mark readOnlyHint=true, so the description's key added value is disclosing that the response is verbatim plain text, not JSON. This is important for avoiding incorrect parsing. It doesn't cover error cases or auth, but the most significant non-obvious behavior is disclosed.

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

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

Two compact sentences: the first gives the core purpose and response format, the second gives the canonical endpoint. There is no filler, repetition, or unnecessary 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 two-parameter read-only endpoint with full schema descriptions and explicit plain-text response disclosure, the description is nearly complete. It could mention error/not-found behavior or explicitly state that n comes from list_pings, but those are minor gaps given the schema already provides that link.

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?

Both parameters are fully described in the schema: uuid is the check's UUID and n is the ping's sequence number from list_pings. The description essentially restates these in the endpoint path and adds no further semantic detail, so it stays at the baseline for 100% schema coverage.

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

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

Description states a specific action ('Get'), resource ('logged request body of a single ping'), response format ('PLAIN TEXT'), and the exact endpoint. This clearly differentiates it from sibling tools like list_pings and get_check, whose scope is different.

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

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

The description clearly implies it should be used to retrieve a single ping's request body, and the schema context points to list_pings for obtaining n. However, it does not explicitly state when to prefer this over alternatives, nor does it mention any exclusions or prerequisites.

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

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

The readOnlyHint annotation already flags safety; the description adds the HTTP GET method and the {badges:{...}} response envelope. This gives useful behavioral context without contradicting the annotation.

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

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

A single sentence that leads with the purpose and scope, then supplies the response envelope and endpoint. Every element is informative with no filler.

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

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

For a zero-parameter read-only endpoint, the description provides the resource, the per-tag structure, the overall-status key, the response envelope, and the endpoint. No critical information 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?

There are zero parameters and schema coverage is complete, so no parameter documentation is required. The description still contributes value over the empty schema by stating the output envelope structure.

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

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

The description names a specific verb ('List'), a concrete resource ('status-badge URLs'), and scopes it by tag plus the '*' overall entry. This distinguishes it clearly from sibling list_* tools that target checks, pings, flips, or integrations.

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 intended use is clear: call this when needing the project's badge URLs, not when fetching checks or pings. It does not explicitly name alternatives or exclusion cases, but the resource-focused context is sufficient for selection.

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 provide readOnlyHint, and the description adds meaningful detail: it returns {checks:[...]} and enumerates the per-check fields (status, schedule, last ping, ping URL). This gives the agent a concrete picture of the read-only response without contradicting the annotation.

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

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

Three short sentences with no filler; the main purpose and filters are front-loaded, followed by the return shape and endpoint reference. 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 listing tool with two fully documented optional parameters, the description is sufficient. It states output shape and key fields, and no pagination or side effects need to be disclosed given readOnlyHint=true. There is no output schema, but the description provides the essential return information.

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

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

Schema coverage is 100%, so the schema already fully documents 'tag' and 'slug'. The description only lightly paraphrases the filters and adds no new meaning beyond 'and/or', matching the baseline rather than exceeding it.

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

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

The description names the specific operation ('List all checks in the project'), identifies optional filters, and contrasts naturally with sibling tools like get_check (single check) and list_pings. The action and resource are unambiguous.

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

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

It clearly states the list scope and the optional slug/tag filters, so an agent knows when a filtered list is appropriate. It does not explicitly name alternatives or say when not to use it, such as routing single-check lookups to get_check, so it stops short of a 5.

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

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

Annotations cover the read-only safety profile, and the description adds useful behavior beyond that: flips are status changes, the response is an array of timestamp/up pairs, and filters can constrain the range. It doesn't mention pagination or rate limits, but for a simple read-only list endpoint the description gives adequate behavioral context.

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

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

Two sentences cover purpose, response shape, optional scoping, and the REST endpoint with no filler. The most important action is front-loaded and every clause earns its place.

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

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

For a read-only list tool with no output schema, the description compensates by stating the response shape and filter semantics, and the required uuid is in the schema. It is missing only minor operational details such as pagination or maximum result limits, so it is nearly complete.

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

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

Schema description coverage is 100%, so the schema already documents each parameter. The description adds only light grouping—calling seconds a 'lookback window' and start/end an 'explicit range'—which is helpful but not substantial enough to move beyond the 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?

Description uses a specific verb and resource: 'List a check's status changes (“flips”) over time' and even gives the response shape [{timestamp, up}] and endpoint. It is clear, but it does not explicitly differentiate itself from sibling tools such as healthchecksio_list_pings or healthchecksio_get_check, so it falls short of full sibling distinction.

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

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

The description implies usage by describing what the tool returns and offers parameter guidance ('Optionally scope by a lookback window or an explicit start/end range'). It does not state when to prefer this over list_pings or list_checks, nor does it give exclusions or alternative conditions.

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

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

The readOnlyHint annotation already declares this is safe and non-destructive. The description adds meaningful behavioral detail beyond the annotation: it states the exact response shape, explains the semantics of the ids, and references the underlying Healthchecks GET endpoint. No contradiction with the annotation 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?

The description is compact and front-loaded with the primary action and object. It packs the response shape, the practical significance of the ids, and the underlying endpoint into two tight sentences with no filler.

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

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

For a parameterless, read-only listing tool, the description is complete: it identifies the resource, states the output format, clarifies how the output should be used, and there is no output schema requiring additional return-value documentation. No important calling information 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 input schema has zero parameters, so there is nothing for the description to explain about parameters. The baseline for a parameterless tool is 4, and the description appropriately focuses on the output rather than inventing parameter guidance.

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

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

The description uses a specific verb ('List') and a clear resource ('the project's notification integrations'), immediately clarifying what the tool does. It distinguishes this from sibling tools like list_checks, list_badges, and list_pings by explicitly framing the resource as 'channels' rather than checks, badges, or pings.

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

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

The description gives clear usage context: the returned ids are what you assign to a check's `channels` field. This tells the agent when this tool is relevant. It does not explicitly state when not to use it or name alternatives, but for a simple read-only list tool that is a minor omission.

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, and the description adds meaningful behavioral context: free vs paid plan limits, ordering by most recent first, and the exact set of fields per ping. It does not contradict annotations and goes beyond what the structured data already reveals.

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

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

The description is tightly packed in two sentences plus an endpoint reference. Every element adds value: plan limits, ordering, returned fields, and the underlying API call. No filler or repetition is present.

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 listing tool with one required parameter, the description covers the operation, the response fields, ordering, and limits. No output schema exists, but the listed ping fields compensate well, making the tool safely callable by an agent.

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% for the single uuid parameter, and the schema already explains it as 'The check's UUID.' The description adds the endpoint template but no new semantic meaning for the parameter, so the baseline of 3 is appropriate.

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

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

The description states a specific verb and resource ('List a check's logged pings'), distinguishes pings from sibling tools like list_flips and get_ping_body, and enumerates the returned fields. The endpoint mention further grounds the operation.

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

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

The description gives clear context: it lists all logged pings for a single check, returns them most-recent-first, and indicates plan-based limits. It does not explicitly name alternatives or when-not-to-use, but the context is sufficient for this simple list operation.

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

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

Beyond the destructiveHint annotation, the description explains the live monitoring impact, the 'stops going down' behavior, the resume condition, and even specifies the HTTP endpoint and empty body. This is rich behavioral disclosure that matches the annotation.

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

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

The description is two focused sentences plus an endpoint reference. Every clause adds meaningful context, and the core purpose is front-loaded before the modifying behavior is explained.

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

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

For a single-parameter tool with no output schema, the description covers what the tool does, the side effects, the condition for returning to normal, and the exact API call. Nothing essential for 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?

Schema coverage is 100% and the uuid parameter is already documented in the schema. The description adds little beyond restating the endpoint placeholder, so it meets the baseline without adding meaningful new parameter detail.

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

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

The description clearly states the tool pauses a check, disables monitoring without deleting it, and gives the exact behavior difference from deletion. This distinguishes it from siblings like delete_check and resume_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 implies when to use the tool: when you want to stop monitoring temporarily without deleting the check. It also contrasts with deletion and mentions resumption, giving enough context to route an agent correctly, though it does not explicitly list alternative tools.

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

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

The description adds meaningful behavior beyond the destructiveHint annotation: it modifies live monitoring config and returns HTTP 409 cleanly when the check is not paused. It does not cover auth, side effects, or reversibility, but that is not a major gap for a one-parameter state transition.

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-load the action and consequence, then give the endpoint and edge-case behavior. Every sentence earns its place with no filler.

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

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

For a single-parameter tool with no output schema, the description covers what it does, the state it requires, the error when that state is absent, and the exact HTTP call. Nothing essential is missing for correct invocation.

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

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

Schema coverage is 100%, so the schema already fully documents the uuid parameter. The description mentions {uuid} in the endpoint but adds no extra semantics beyond what the schema provides.

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

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

Description names the exact verb ('resumes'), resource ('a paused check'), and outcome ('re-enables monitoring'), and the endpoint makes the operation unambiguous. It is easily distinguished 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 intended use is clear: call it when a check is currently paused, and the 409 note defines the boundary for incorrect use. It does not explicitly name an alternative for pausing checks, so it stops short of full when/when-not guidance.

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

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

Goes beyond the destructiveHint annotation by disclosing that this modifies live monitoring config, supports partial updates, and maintains mutual exclusivity between timeout and schedule. It also states the HTTP endpoint and confirms the return value, giving the agent a clear behavioral picture.

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

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

Three sentences with no filler: the purpose, the critical usage rule, and the endpoint/return contract are all front-loaded. 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?

Despite having 13 parameters and no output schema, the description covers the essential behavioral context: partial updates, destructive live-config modification, mutual exclusivity, and the returned updated check. The schema handles parameter-level detail, so nothing critical is missing for invoking this tool correctly.

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

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

Schema coverage is 100%, so individual parameters are already documented. The description adds the key cross-cutting semantic that only fields the caller wants to change should be sent, which is not encoded in the schema itself and meaningfully guides parameter usage.

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 precise verb and resource ('UPDATES an existing check by UUID') and immediately distinguishes itself from create/delete tools. The phrase 'MODIFIES live monitoring config' reinforces the update semantics, making the tool's purpose unmistakable.

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

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

Provides clear usage context: update an existing check by UUID, send only fields to change, and keep timeout/schedule mutually exclusive. It does not explicitly name sibling alternatives like get_check or create_check, but the UUID-targeted update phrasing makes the intended use obvious.

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