Checkly MCP by usefulapi

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

With destructiveHint=true already present, the description adds meaningful context: it modifies the account, silences alerts for a time range, and omits repeatUnit for one-off windows. It does not detail auth requirements, reversibility, or what happens to existing windows, but it goes beyond the annotation to explain the operational effect.

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 account-modification warning, followed by the core behavior and a key parameter note. Every sentence adds value with no padding.

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

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

For a mutating tool with no output schema, the description covers purpose, effect, and the repeatUnit distinction while annotations and a fully documented schema handle safety and parameters. It could clarify default scoping behavior when no tags or silenceAllAlerts are provided, but it is otherwise sufficiently 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 all seven parameters are already documented. The description repeats the one-off guidance for repeatUnit but adds no new syntax or meaning beyond the schema, making the baseline 3 appropriate.

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

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

The description gives a precise verb and resource: 'schedules a maintenance window that silences alerts for a time range.' It also flags the mutating nature with 'MODIFIES THE CHECKLY ACCOUNT,' which separates it from the many read-only list/get siblings. An agent can identify exactly what this tool does 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?

The description offers a use case ('e.g. during a deploy') but no explicit when-not-to-use guidance or alternatives such as checkly_list_maintenance_windows. Usage is implied rather than stated, leaving the agent to infer when this create tool is preferable to checking existing windows first.

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 annotation only gives destructiveHint=true, so the description carries real weight here and delivers: it flags account mutation, clarifies the operation is additive and will not clobber existing keys, and cites the underlying endpoint POST /v1/variables. It stops short of disclosing auth/permission requirements or whether key uniqueness is enforced at write time.

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 fragments with zero filler, and the consequential mutation warning is front-loaded in caps. Every clause — mutation, additivity, endpoint — carries information an agent cannot get from the annotations alone.

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 leaves the return value entirely unspecified — an agent cannot tell whether the created variable (or its secret value) is echoed back. Auth scope and failure modes on duplicate keys are also unaddressed, though params are fully documented by the schema.

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

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

Schema description coverage is 100%, covering key, value, locked and secret, so the schema does the heavy lifting. The description adds only the account-level scope framing and the additive/no-overwrite constraint, which marginally informs key semantics but adds no syntax or format 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?

States a specific verb and resource ('creates a new account-level environment variable') and scopes it precisely to the account level, which cleanly separates it from sibling list_variables and the unrelated create_maintenance_window. 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?

The 'Additive (does not overwrite existing keys)' note implicitly tells the agent this is the right call when onboarding a new key rather than changing an existing one, but there is no explicit when-to-use guidance and no named alternative (e.g. what to call to update an existing variable). Usage is inferable 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?

The readOnlyHint annotation already establishes this is a safe read, so the description is not carrying the safety burden. It does add useful context beyond the annotations: the credential scoping and the underlying public endpoint GET /v1/accounts/me. It says nothing about auth failure modes, rate limits, or the shape of the returned account object.

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

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

Two short sentences, zero filler, with the core purpose front-loaded and the API endpoint as a compact secondary detail. Nothing could be removed without losing information.

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

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

For a zero-parameter read of the caller's own account, the description covers what the tool does, whose data it returns, and which endpoint backs it. Since no output schema exists, a brief note on returned fields would have been a bonus, but the omission is minor at this complexity level.

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 the baseline is 4. There is nothing to document and the description correctly avoids inventing parameter discussion; the schema coverage figure is nominal given the empty properties object.

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

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

The description gives a specific verb and resource: fetch the Checkly account bound to the caller's credentials. This is unambiguous and cannot be confused with the check/alert/variable list-and-get siblings, all of which target other resources. It stops just short of 5 only because it does not explicitly contrast itself with any sibling.

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

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

Usage is implied by the phrasing 'tied to your credentials' — an agent can infer this is the identity/account-context lookup. However there is no explicit when-to-use statement, no prerequisites, and no named alternative. With no competing account tool in the sibling list, the gap is tolerable 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?

readOnlyHint=true already tells the agent this is a safe, non-mutating read, so the description is not carrying the safety burden. It adds the underlying REST endpoint (GET /v1/checks/{id}), which is mildly useful for orientation but not behavioural detail; it says nothing about error behaviour for unknown ids or payload size.

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

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

Two short sentences with zero filler; the core action is front-loaded and the endpoint reference is a compact second sentence. Nothing could be removed without losing content.

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

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

For a simple read-only single-resource getter with no output schema and fully documented parameters, the description is largely sufficient, and 'full configuration' hints at the return shape. The remaining gap is disambiguation from the four sibling check-scoped getters, which the description does not address.

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, including includeDependencies and its 'dependent resources (snippets, alert channels)' meaning, are already fully documented. The description adds no format or default information beyond the schema, so the baseline 3 applies.

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

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

The description names a specific verb (Retrieve) and resource (a single check's full configuration) scoped by id, and the word 'full' implicitly separates it from the partial sub-resource getters (status, result, alerts). It never names a sibling outright, so an agent still has to infer the routing among checkly_get_check_status / _result / _alerts rather than being told.

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 one check by id when you need its complete configuration. There is no explicit when-to-use or when-not-to-use guidance and no pointer to the sibling tools that return narrower slices, so the agent must infer the choice from the tool names.

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 the safety profile is covered by structured data. The description adds only the underlying public API path (GET /v1/check-alerts/{checkId}), which confirms the read nature but discloses nothing about pagination behavior, default range, or result volume.

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: the scoping statement first, then the API mapping. No filler, no redundancy, front-loaded with the differentiating information.

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

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

With five parameters (including pagination and a time range) and no output schema, the description should do more: it never mentions paging defaults, whether the range is optional, or what the returned alert records look like. It is adequate for routing but thin 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 description coverage is 100%, with from/to/page/limit/checkId all documented in the schema itself, so the baseline is 3. The description adds no additional meaning about filtering, timestamp format, or paging beyond what the schema already states.

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

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

States a specific verb (list) and resource (alert notifications) with an explicit scope qualifier ('for one specific check'). That scope qualifier is precisely what separates it from the sibling checkly_list_check_alerts, so an agent can pick correctly without opening either 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?

The description never says when to use this tool instead of checkly_list_check_alerts, nor does it name any prerequisite (e.g. needing a known checkId first). Usage must be inferred entirely from the scope phrase.

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 the agent knows this is a safe read. The description adds only the raw REST route (GET /v1/check-groups/{id}) and no behavioral context such as error handling for a missing/invalid id, auth requirements, or rate 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 short sentences, purpose front-loaded ahead of the API route. No filler or redundancy.

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

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

For a trivial one-parameter read tool with a readOnly annotation and no output schema, the description is sufficient to invoke correctly. It could note the 404 behavior or that the id comes from the list tool, but nothing critical 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% for the single id parameter, so the schema already documents it ('The check group id.'). The description adds no format or constraint detail beyond that, which is the baseline case.

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: retrieve a single check group by id. The word 'single' implicitly distinguishes it from the list_check_groups sibling, though no sibling is named outright.

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

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

Usage is only implied: the agent infers this is the tool to call when it needs one group and already has its id. There is no explicit statement of when to prefer this over checkly_list_check_groups or what to do without an id.

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 tells the agent this is a safe read. The description adds the underlying public API route and the 'in full' hint that the response is unsummarized, but says nothing about rate limits, permissions, or error 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 short sentences, purpose front-loaded, endpoint reference second. No filler or redundancy.

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

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

For a two-param read tool with annotations and no output schema, this is minimally viable. It doesn't explain where the two IDs originate (typically a preceding list call), which is the main thing an agent needs to sequence 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 description coverage is 100% for both required parameters, so the schema already carries the parameter documentation. The description adds no syntax, format, or sourcing guidance (e.g., where checkResultId comes from) beyond what the schema provides, 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 ('Retrieve') and resource ('a single check-run result'), with 'in full' and 'single' implicitly distinguishing it from the plural checkly_list_check_results and from checkly_get_check (a different resource). One more explicit contrast with siblings would earn a 5.

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

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

No when-to-use guidance or alternatives are given. The agent must infer that this is the detail lookup following a list call; nothing routes it away from checkly_list_check_results or checkly_get_check.

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 tells the agent this is a safe read. The description adds only the REST endpoint mapping (GET /v1/check-statuses/{checkId}), which is useful for orientation but discloses nothing about freshness, caching, rate limits, or the shape of the returned status.

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, front-loaded with the purpose before the API reference. Nothing is padded, though the raw endpoint line earns its place only marginally for an agent that cannot call REST directly.

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?

No output schema exists, so the description carries the burden of explaining what 'status details' means — and it does not, leaving the return shape vague. For a simple one-parameter read with full schema coverage this is adequate but not complete.

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

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

Schema description coverage is 100% for the single checkId parameter, so the baseline is 3. The endpoint template shows checkId is a path parameter, adding slight value, but no format, ID-source, or validity guidance 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 and resource (retrieve status details for a check) and the word 'single' implicitly contrasts with list-oriented siblings like checkly_list_check_statuses. However, it never distinguishes itself from checkly_get_check or checkly_get_check_result, which an agent could easily confuse it with.

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

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

Usage is only implied by the phrase 'for a single check'; there is no explicit when-to-use statement, no when-not, and no named alternative among the several status/result/check getters in the sibling list. The agent must infer routing on its own.

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 tells the agent this is a safe read, and the description adds the underlying endpoint (GET /v1/reporting), which is mildly useful context. It does not disclose return shape, time-series bucketing behavior implied by granularity, rate limits, or empty-range behavior. Given annotation coverage, a 3 is appropriate.

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 scope front-loaded and the API mapping as secondary detail. Nothing is wasted and the most important qualifier (aggregated, across checks and groups) comes first.

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 six optional time-range parameters and no output schema, the agent must infer the quickRange vs from/to relationship and what a response bucket looks like. The description supplies resource identity but not enough to call it confidently; an output schema would have relieved much of this.

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 (to, from, timezone, quickRange, granularity, filterByTags) is already documented with examples and an enum. The description adds no parameter meaning, and its phrase "across checks and groups" could suggest filtering by check/group that no parameter actually supports. 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: an aggregated availability/performance/SLA report spanning checks and groups, which separates it from result-level siblings like checkly_get_check_result or checkly_list_check_results. It stops short of naming an alternative or scoping its aggregation window, so it is clear but not fully differentiated.

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

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

There is no when-to-use guidance: nothing says to pick this over checkly_list_check_results or checkly_get_check_status when the user wants rollup metrics. The description also omits how to choose between quickRange and from/to, which is the main decision an agent must make here.

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 safe-read profile, so the description isn't required to explain side effects. It adds a small amount of context by naming the underlying public REST endpoint (GET /v1/alert-channels), but says nothing about pagination behavior, default/max page size, or what the returned channel objects contain.

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

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

Two short sentences with no filler; the resource list and examples come first and the API endpoint detail last. 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 simple zero-required-param read-only list tool with full schema coverage and annotations covering safety, the description is sufficient. The only residual gap is pagination/return-shape expectation, which matters mildly for a list endpoint with no output schema.

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

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

Schema description coverage is 100% — both 'page' and 'limit' are documented inline — so the schema carries the parameter burden and a 3 is the baseline. The description adds no additional semantics (no default page size, no max limit guidance, no pagination notes).

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 all') and resource ('alert channels') and adds concrete examples of channel types (email, Slack, webhook, PagerDuty). The scoping phrase 'configured in the account' cleanly separates it from account-vs-check scoped siblings like checkly_list_check_alerts and checkly_get_check_alerts.

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 resource name — an agent knows to call this when it needs the account's alert channel inventory. However, there is no explicit when-to-use guidance, no mention of filtering or when to prefer a get-by-id call, and no exclusions relative to the many other list_* siblings.

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 the safety profile is covered. The description adds the account-wide reach and the underlying REST endpoint, but says nothing about ordering, pagination behavior (despite page/limit params), or the volume/recency window implied by 'recent'.

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, front-loaded with the purpose and scope. The API path sentence is marginally useful for debugging and does not bloat the description.

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 zero required params and no nested structure, the description covers purpose, scope, and endpoint. With no output schema, a brief note on what an alert record contains would be nice but is not essential 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 description coverage is 100%, so from/to/page/limit are already documented in the schema. The description adds no parameter detail (e.g., format constraints, default page size, how from/to interact), so the baseline 3 applies.

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

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

States a specific verb (List) and resource (alert notifications) plus the scope ('fired across the whole account'), which lets an agent distinguish it from the per-check sibling checkly_get_check_alerts. It stops short of naming that sibling explicitly, but the account-wide scope is clearly conveyed.

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 'across the whole account' implies when this is appropriate versus the singular get_check_alerts, but there is no explicit when-to-use/when-not or named alternative. Usage is inferable 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?

readOnlyHint=true already establishes this as a safe read, so the description need not restate safety; it adds a useful domain gloss on what a check group is and names the underlying endpoint (GET /v1/check-groups). It does not disclose pagination behavior, default page size, or whether results are truncated despite the presence of page/limit parameters.

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

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

Two short sentences with zero padding; the core purpose is front-loaded and the endpoint reference is a compact, useful tail. Nothing is wasted.

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

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

For a read-only list tool with full schema coverage and an explicit readOnlyHint, no output schema is needed and the description is largely sufficient. The gap is that pagination — the page/limit parameters — goes unexplained behaviorally (defaults, max page size, whether all results return), which is the main thing an agent would need beyond the schema.

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

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

Schema description coverage is 100%, so all four parameters (tag, name, page, limit) are already documented in the schema, and the description adds nothing about filtering or paging semantics. Baseline 3 is appropriate when the schema carries the parameter burden.

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 check groups') and even disambiguates the domain object with a parenthetical ('shared config for a set of checks'), which is genuinely useful for an agent unfamiliar with Checkly. It does not explicitly differentiate itself from the singular sibling checkly_get_check_group, but the list-vs-get distinction is readily inferable from the names.

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 says what the tool returns but gives no when-to-use guidance and names no alternative. It does not tell the agent whether to prefer this over checkly_get_check_group for a single group, nor mention that tag/name filters exist for narrowing results. Usage is only implied by the word 'List'.

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

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

readOnlyHint=true already tells the agent this is a safe read, so the description's marginal burden is low. It adds that results are individual runs with per-run fields, but says nothing about pagination behavior or result volume, which matters for a list endpoint with page/limit parameters.

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

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

Two tight sentences with the purpose front-loaded and the API endpoint appended as reference. Nothing is wasted or repeated from the schema.

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

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

With no output schema, the description partially compensates by naming the returned fields, and annotations cover the safety profile while the schema covers all parameters. It is adequate for the tool, though a note on pagination or typical result size would close the remaining 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 all eight parameters (from, to, page, limit, checkId, location, resultType, hasFailures) are already documented. The description 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 (List) and resource (individual run results for a check), and enumerates the result fields (latency, success, location, response), which separates it from the singular checkly_get_check_result and from checkly_list_check_statuses. It does not explicitly name those siblings, 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?

Usage is implied by 'for a check' plus the filter parameters shown in the schema, but the description never states when to prefer this over checkly_get_check_result or checkly_list_check_statuses, and offers no 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?

readOnlyHint=true already establishes the safety profile, and the description adds the underlying endpoint (GET /v1/checks). It does not disclose pagination behavior or that a full account enumeration could be large/paginated, which is relevant given page/limit parameters.

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 resource meaning front-loaded and the endpoint reference trailing. 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?

Adequate for a read-only list tool with a fully documented schema, but with no output schema the description omits what a result looks like and how pagination works, both of which an agent would need 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 description coverage is 100%, so all five filters are already documented in the schema. The description adds no syntax, format, or filtering semantics beyond what the schema provides, which matches the baseline for full 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?

States a specific verb (list) and resource (synthetic monitoring checks) plus the scope (in the account) and enumerates check types. It is clearly distinct from the singular checkly_get_check sibling, though it does not name any sibling explicitly.

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

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

No guidance on when to use this versus checkly_get_check for a single check, nor on when to apply the filter parameters. The reader must infer usage entirely from the name and resource.

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

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

readOnlyHint=true already establishes this is a safe read, so the description only owes extra context. It adds that results are a current snapshot ('current', "what's down right now") rather than historical, which is useful, but it says nothing about freshness lag, result shape, or result-set size.

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

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

Two short sentences with zero waste. The scope and semantics come first, with the API endpoint note in a trailing clause that an agent can ignore or use for raw HTTP calls.

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

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

For a zero-parameter list tool with no output schema, the description covers what is listed and the currency of the data, which is nearly enough to call it correctly. A brief note on the returned object shape would close the remaining gap left by the absent output schema.

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

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

The tool takes zero parameters, so there are no parameter semantics to explain; baseline for a no-param tool is 4. The description correctly implies no filtering or pagination knobs are available.

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 ('check statuses') with an explicit scope: 'every check'. The scope phrase distinguishes it from the singular sibling checkly_get_check_status without needing to name it, and the pass/fail/degraded enumeration tells the agent what values to expect.

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 gloss "the 'what's down right now' view" implies the use case (fleet-wide current-state triage), but there is no explicit when-to-use/when-not and no named alternative such as checkly_get_check_status for a single check or checkly_list_check_results for history. Usage is inferable 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?

readOnlyHint=true already establishes this as a safe read, so the bar is lower. The description adds the backing endpoint (GET /v1/dashboards) and confirms the read-only nature, but says nothing about pagination behavior despite the page/limit parameters.

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

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

Two short sentences with the resource scope front-loaded and no filler. The API endpoint clause is mildly redundant but not wasteful enough to penalize further.

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-required list tool with annotations covering safety and schema covering params, this is adequate. It omits any note on pagination or return volume, which is a minor gap given there is no output schema.

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

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

Schema description coverage is 100%, so both page and limit are already documented in the schema with their 1-based and page-size semantics. The description adds no additional parameter meaning, making the baseline 3 appropriate.

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

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

States a specific verb (List) and resource (public/private status dashboards), so the agent knows exactly what is returned. No sibling lists dashboards, so differentiation is implicit rather than stated, which keeps it just below 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?

There is no explicit when-to-use guidance, no prerequisites, and no named alternatives. The only guidance is the implied 'this lists dashboards' which an agent could infer from the name alone.

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

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

readOnlyHint=true already establishes the safe-read profile; the description adds the useful scoping fact that these are public locations, plus the underlying API route. It does not disclose the return format, pagination, or whether the list is static or account-dependent, so it adds modest context beyond annotations.

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, purpose front-loaded with no filler. The trailing 'Public API: GET /v1/locations' is marginally useful for traceability but does not help an agent decide or invoke.

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 listing tool with readOnlyHint covering the safety profile, the description is close to complete. The one residual gap is that no output schema exists, so the shape of a returned location object is never described.

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. There is nothing for the description to clarify beyond confirming that the listing is unfiltered and global.

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 (public checking locations Checkly can run checks from), and the qualifier 'public' implicitly contrasts with the sibling checkly_list_private_locations. It never names that sibling explicitly, so the differentiation is inferable 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?

No explicit when-to-use statement or named alternative, but the phrasing 'locations Checkly can run checks from' implies the purpose (discovering location identifiers for check configuration). Usage is inferable for a zero-parameter read-only listing tool, 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?

The readOnlyHint annotation already establishes this is a safe read. The description adds useful domain context (what a maintenance window is: a period where alerts are silenced) and the underlying API route, but says nothing about pagination behavior or result volume, which is the main behavioral gap.

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

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

Two tight sentences with zero filler; the scope ('List all') leads and the clarifying definition and endpoint follow. Nothing could be cut without losing information.

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

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

For a zero-required-parameter list tool with no output schema and a readOnlyHint annotation, this covers what an agent needs: what the resource is and that it is a safe read. Only the absence of pagination-scope guidance 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 description coverage is 100% — page and limit are both documented with 1-based/page-size semantics — so the schema does the heavy lifting and the baseline is 3. The description adds no parameter detail of its own.

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 (maintenance windows), and clarifies the concept with '(periods where alerts are silenced)'. The sibling set contains create_maintenance_window, so list vs. create is unambiguous from the name, though the description itself does not name an alternative.

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 'List all maintenance windows' — an agent can infer this is the read/enumeration path — but there is no explicit when-to-use, when-not-to-use, or prerequisite guidance, and no routing toward checkly_create_maintenance_window.

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 the safety profile is covered. The description adds the backing endpoint (GET /v1/private-locations), but says nothing about pagination, result size, or return shape for a list operation.

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

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

Two short sentences with no waste and the purpose front-loaded; the API path is a minor, non-essential addition but does not bloat the text.

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 no-arg, read-only list tool this is largely sufficient, but with no output schema the description could have noted what a private location record contains or whether results are paginated — neither is covered anywhere.

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?

Zero parameters, so per calibration the baseline is 4. There is nothing for the description to clarify beyond the empty input object.

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 (private/self-hosted checking locations), and the parenthetical '(self-hosted)' distinguishes it from the sibling checkly_list_locations (public locations). It never names that sibling explicitly, but the qualifier makes the distinction inferable.

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 name and scope — an agent can infer this is the read path for private locations — but there is no explicit when-to-use guidance or statement of when to prefer checkly_list_locations instead.

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

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

readOnlyHint=true already tells the agent this is a safe, non-mutating read, so the description carries a lighter burden. It adds that this maps to a public API endpoint (GET /v1/runtimes), suggesting no auth/account scoping, but discloses nothing about return shape, ordering, or caching.

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, front-loaded with the resource and its contents, with the API endpoint as a compact trailing note. No filler and nothing redundant.

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

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

For a zero-parameter, read-only list tool with no output schema, the description gives enough to call it and understand roughly what comes back (Node versions plus bundled dependencies). A brief note on return format would make it fully complete, but the essential context is present and consistent with the annotations.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate; baseline 4 applies. Schema coverage is 100% and the empty object schema is consistent with the description's no-argument claim.

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 (runtimes), and disambiguates the resource by spelling out what a runtime contains (Node versions + bundled dependencies) and the check types it applies to. It does not name a sibling to distinguish from, but the resource is unique among the sibling 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?

Usage is only implied — an agent infers it should call this to discover available runtime versions, and 'for browser/API checks' hints at the context. There is no explicit when-to-use, no prerequisites, and no when-not-to-use guidance or alternative tool mentioned.

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 a safe read operation, so the description carries a lighter burden, but it adds no behavioral context beyond a terse endpoint reference. Pagination behavior is not explained in the description even though page/limit parameters exist.

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, front-loaded with the purpose, with no filler. The second sentence (API endpoint) adds marginal value for an agent that has no other use for the raw HTTP path.

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 trivial zero-required-parameter list tool with full schema coverage, readOnlyHint annotations, and no output schema, this is minimally adequate. It lacks any mention of response shape or pagination semantics, which keeps it from being 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% and both parameters (page, limit) are documented in the schema, so the baseline of 3 applies. The description adds no parameter meaning beyond what the schema already states.

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

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

The description gives a specific verb and resource ('List all reusable code snippets'), which is clear enough to distinguish it from the many sibling list_* tools by resource. It does not explicitly contrast itself with any sibling, but the resource noun is unambiguous.

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

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

No when-to-use, when-not-to-use, or alternative guidance is provided. For a simple list tool the usage is largely implied by the name, but the description itself adds nothing about context 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?

Annotations already declare readOnlyHint=true, so the safety profile is covered. The description adds genuine value beyond that: it discloses that secret variable values are redacted by the API, which the agent would otherwise only discover from the response.

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: the purpose is front-loaded and the redaction caveat follows immediately. 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 two-parameter, zero-required read tool with full schema coverage and readOnlyHint, the description covers purpose, scope and the one non-obvious behavioral caveat. Minor gap: no mention of pagination behavior or result ordering, though the schema supplies the paging 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 description coverage is 100%, so page and limit are already documented in the schema, and the description correctly does not repeat them. It adds no pagination semantics beyond the schema, 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 (List) and resource (account-level environment variables), with the scope qualifier 'account-level' narrowing it. It does not name a sibling to contrast against, but a read/list tool is unambiguous here.

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 'List all account-level environment variables' — the agent can infer this is the read path for variables versus checkly_create_variable. However, there is no explicit when-to-use, no exclusion, and no alternative named.

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