NodePing MCP by usefulapi

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

Annotations already flag destructive/not-idempotent/write, but the description adds real behavioral detail beyond them: checks are disabled then re-enabled, no alerts fire during the window, and the window is created inactive unless start_now=true starts it immediately. This lifecycle disclosure is exactly what an agent needs for a write tool.

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

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

Front-loaded WRITE marker, then the effect and the inactive/start_now nuance, then the endpoint. Three compact 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 no-output-schema write tool whose annotations carry the safety profile, the description covers lifecycle, effect and start behavior well. Minor gaps remain around auth/sub-account requirements and any rate or conflict behavior, but nothing an agent must know to invoke it 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 moderate (60%) and the schema already documents start_now's default and duration_minutes' max. The description reinforces duration_minutes and start_now semantics but adds little beyond the schema, and does not touch name or customer_id.

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 (create) and resource (one-off maintenance window) plus the effect: disables the listed checks for duration_minutes and re-enables them afterwards. This clearly distinguishes it from sibling maintenance tools like get/list/delete_maintenance.

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 (one-off maintenance that suppresses alerts), which implicitly differentiates it from recurring schedules or mute_check, but it never names an alternative or an exclusion condition explicitly. Clear context without explicit 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?

Annotations already declare readOnlyHint=false, destructiveHint=true, idempotentHint=false and openWorldHint=true, so the "WRITE:" prefix largely restates structured data. The description adds only the HTTP endpoint, and says nothing about what happens when member ids are invalid or whether a failed create leaves partial state. Some added value, but not much 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 with the action and method front-loaded and no filler. The trailing "POST /contactgroups" endpoint is of marginal value to an agent selecting the tool, keeping it just short of a 5.

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

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

There is no output schema and no return-format detail, and the description omits error/validation behavior for a non-idempotent write. The annotations do carry the safety profile, so this is adequate but with clear gaps for a mutation tool.

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

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

Schema coverage is 67%: the schema itself documents that members are contact ADDRESS ids (not contact ids) and explains customer_id for MSP accounts. The description's "existing contact address ids" reinforces the most error-prone parameter but adds no new syntax, limits, or meaning beyond the schema; baseline 3 is appropriate.

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

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

States a specific verb and resource ("create a contact group") plus the construction constraint ("from existing contact address ids"), which separates it from update_contact_group and delete_contact_group. It is clear but never names the siblings it is not, so it stops 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?

"from existing contact address ids" implies the prerequisite that contact address ids must already exist, but there is no explicit when-to-use versus update_contact_group, no guidance when a group already exists, and no mention of the list_contacts/list_contact_groups workflow. Usage is only implied.

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 carry destructiveHint=true, idempotentHint=true, and openWorldHint=true, so the safety profile is covered. The description adds genuine value beyond them by disclosing the concrete downstream effect: checks notifying the group lose that notification target.

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, with the destructive nature and the deleted resource front-loaded. No filler, no restatement of 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 two-parameter delete with no output schema, the definition covers the action, the side effect, and the endpoint. It stops short of noting permission requirements or that the operation is irreversible, but nothing essential to invoking 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%, so both group_id and customer_id are already documented in the schema. The description adds no format, constraint, or scoping detail beyond what the schema provides, which is the expected baseline.

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

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

States a specific verb (delete) and resource (contact group), plus the underlying endpoint DELETE /contactgroups/{id}. This cleanly separates it from siblings create_contact_group, update_contact_group, and list_contact_groups without naming them.

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

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

Usage is implied by the destructive header, but the description never says when to prefer this over update_contact_group or how to obtain a valid group_id (e.g. via list_contact_groups). No explicit exclusions or prerequisites are given.

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

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

Annotations already declare destructiveHint=true, readOnlyHint=false, and idempotentHint=true, and the description merely restates 'WRITE (destructive)'. It adds no extra behavior context such as whether the deletion is reversible, whether it cascades, or what happens to related checks/notifications.

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 compact line with the destructive marker and endpoint front-loaded. Nothing is wasted and the key signal appears 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?

For a one-parameter delete tool, the description plus rich annotations and a fully documented schema cover the essentials; return values are not needed for a destructive DELETE with no output schema. It stops short of describing any side effects or permission requirements.

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

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

Schema coverage is 100%, so both customer_id and maintenance_id are already documented in the schema. The endpoint path 'DELETE /maintenance/{id}' loosely implies maintenance_id is the target, but adds no format or scoping detail 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 (remove) and resource (maintenance entry), and the sibling set makes the target unambiguous versus delete_schedule or get_maintenance. 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?

There is no when-to-use or when-not-to-use guidance, no prerequisites, and no named alternatives. The 'WRITE (destructive)' tag hints at mutation context but does not tell the agent under what conditions this deletion is appropriate.

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 annotations already declare destructiveHint=true, idempotentHint=true, openWorldHint=true and readOnlyHint=false, so the 'WRITE (destructive)' prefix largely restates structured data. It adds the endpoint path, but says nothing about reversibility, dependent resources, or permissions that the annotations don't cover.

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

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

One short line with the write/destructive classification front-loaded, followed by the action and endpoint. No filler sentences.

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

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

For a two-parameter destructive tool with no output schema, an agent has enough to invoke it correctly, and annotations carry the safety profile. However, nothing is said about side effects on resources referencing the schedule, which would be valuable for a deletion tool.

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

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

Schema description coverage is 100%, so both parameters (name, customer_id) are already documented in the schema. The description only echoes 'by name' and adds no format, scoping, or MSP multi-account nuance 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), a specific resource (notification schedule), and the identifying key (by name), plus the underlying HTTP route. This clearly distinguishes it from nodeping_put_schedule, nodeping_get_schedule, and the other delete_* siblings.

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

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

The destructive framing implies the appropriate context for use, but the description never states when to prefer this over alternatives or what preconditions must hold (e.g. whether the schedule may still be referenced by checks or notification profiles). Usage is inferable but not spelled out.

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

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

Annotations already declare the write/destructive/idempotent profile, and the description adds substantial context beyond them: history is retained after disabling, reversal is not available through the API, re-enabling carries billing implications, and the underlying call is PUT /checks/{id}. These are exactly the traits an agent needs before executing a mutation.

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

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

A single tight sentence pair with the WRITE marker front-loaded, followed immediately by the key behavioral caveats. No filler, no restatement of 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 two-parameter mutation tool with no output schema, the description covers purpose, irreversibility, retention, billing impact, and the endpoint. Only the return shape is left unaddressed, which is a minor gap given the annotations already establish the safety profile.

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 check_id documented (including an example format and sourcing from nodeping_list_checks) and customer_id documented for MSP accounts. The description adds no parameter detail and relies entirely on the schema, which is the expected baseline here.

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 ('stop a check from running (enabled=false)') and immediately distinguishes the operation from deletion by noting 'its history is kept'. Combined with the WRITE prefix and the endpoint, an agent can separate it from nodeping_mute_check, nodeping_update_check, and any delete tool.

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

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

Gives clear operational context ('stop a check from running') and a firm when-not rule: re-enabling must be done in the NodePing app because it changes billed checks, so the agent knows this tool is one-directional. It does not explicitly compare itself to the closely related nodeping_mute_check, leaving that choice to inference.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds the field-level payload contents and the sub-account access mode, which is modest useful context, but says nothing about auth requirements beyond the implied token scope 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?

A single dense sentence front-loads the resource and packs the returned fields into one parenthetical, with the endpoint mapping at the end. Nothing is wasted, though the field list crowds out behavioral detail.

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

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

There is no output schema, so the description usefully compensates by enumerating the return fields (name, status, timezone, next billing date, default probe locations). For a read-only, single-optional-parameter tool this is nearly complete; only error/permission behavior is unaddressed.

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

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

Schema description coverage is 100% and the schema already explains that customer_id is the SubAccount id and should be omitted for your own account. The description's mention of SubAccounts mirrors the schema rather than adding syntax, defaults, or edge-case behavior, so the baseline of 3 applies.

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

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

The description names the exact resource (the NodePing account tied to the current token), enumerates its key fields, and notes the SubAccount variant, plus the underlying call GET /accounts. It lacks an explicit verb phrase like 'Retrieve', but no sibling tool touches account data, so disambiguation 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?

Usage is only implied: an agent can infer it should call this for account metadata, and the customer_id note hints at MSP sub-account retrieval, but there is no explicit when-to-use statement or exclusion guidance. With no competing sibling, the implicit framing is adequate but not instructive.

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 and destructiveHint=false, and the description adds a genuinely useful behavioral fact beyond them: the returned configuration is "scrubbed," so an agent knows secrets are not exposed. It stops short of describing response size, pagination, or permission requirements, keeping it below the top band.

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

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

Three short clauses, front-loaded with the primary purpose, and nothing wasted. The trailing "GET /checks/{id}" restates the endpoint somewhat redundantly, which costs it the top score.

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 lookup with 100% parameter coverage and no output schema, the description covers what is returned (full scrubbed config, optional result/uptime) well enough to call it correctly. It could be more explicit about how the optional flags change the payload, preventing a 5.

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 are already documented in the schema (including the customer_id sub-account nuance and the example check id). The description only echoes the optional last_result/uptime behavior, adding no syntax or format detail beyond the schema. 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 ("One check by id with its full (scrubbed) configuration") and names the scope, which clearly separates it from list_checks. It does not explicitly name the closely-related siblings (get_check_summary, get_check_results, get_check_uptime), so an agent must infer the boundary from the "optionally include" clause.

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 phrase "Optionally include its latest result and uptime" hints that result/uptime data can be requested here rather than via a separate tool, but no when-to-use condition or alternative is stated. Nothing tells the agent when to prefer get_check_summary over this call.

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, openWorldHint=true and destructiveHint=false, so safety is covered. The description adds genuine context beyond that: the event types returned, the fields available (start, end, message, open), and the newest-first ordering, which is real behavioral information.

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

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

One dense sentence plus an endpoint reference. The return fields, ordering, limit behavior, and route are all front-loaded with no filler; 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?

With no output schema, the description usefully enumerates the event fields and ordering. It does not explain how the start/end range parameters filter the incident history or whether results paginate beyond the 5000 limit, which are minor gaps for a read-only lookup tool.

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

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

Schema coverage is 80%, and the schema leaves 'limit' entirely undocumented. The description compensates by explaining that limit=1 yields the most recent event, adding semantics the schema lacks, plus the newest-first ordering that governs how start/end and limit interact.

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: retrieves down/disabled events for a check, characterized as an incident history, and even names the underlying endpoint. It does not explicitly differentiate itself from the sibling nodeping_get_current_events, though 'history' and 'newest first' imply the 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 note 'limit=1 returns the most recent event' gives an implied usage pattern, and 'incident history' hints at the historical use case. However, there is no explicit when-to-use guidance or contrast with nodeping_get_current_events, nodeping_get_check_results, or nodeping_get_check_summary.

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 it a safe read (readOnlyHint=true, destructiveHint=false), lowering the bar. The description adds genuine context: default sort is newest first, and it enumerates the returned fields (su, rt, m, sc, s, l), which is useful for a tool with no output schema.

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

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

Front-loads what gets returned, then covers bounding rules and the endpoint, with little waste. The field-abbreviation list is dense but directly informative for a tool lacking an output 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 compensates by describing the result fields and the sorting order, and it covers the range-bounding parameters. Complete enough for correct invocation, though it stops short of sibling routing.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds real meaning beyond the schema: span is in hours, while start/end accept ms epoch, ISO 8601, or RFC 2822 and are GMT unless a zone is given.

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: retrieving the raw results of a check, and names the underlying endpoint (GET /results/{id}). It is clearly distinguishable from summary/uptime siblings in spirit, but never names or contrasts them 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?

Explains how to bound the query (span vs start/end), which implies usage, but gives no guidance on when to prefer this over nodeping_get_check_events, nodeping_get_check_summary, or nodeping_get_check_uptime.

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, destructiveHint=false, openWorldHint=true, so the safety profile is covered structurally. The description adds the underlying API route (GET /results/summary/{id}), but says nothing about retention window, rate limits, or whether the summary is computed live or cached. Adequate, not rich.

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

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

Two compact sentences, front-loaded with the output content and followed by the endpoint mapping. No filler, no restatement of 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?

With no output schema the description carries the burden of describing returns, and it does list the aggregated metrics. However, for an hourly summary tool there is no date-range parameter and the description never states the default time window or number of hours returned, which an agent needs in order to interpret the result 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%: check_id's format and provenance (from nodeping_list_checks) and the MSP-only semantics of customer_id are fully documented in the schema. The description adds no parameter detail, so the baseline of 3 applies.

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

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

States a specific verb+resource ('Hourly summary of a check's results') plus the exact aggregation granularity (per UTC hour) and the returned metrics (count, min, max, average run time), which distinguishes it from siblings like get_check_results and get_check_uptime. It does not, however, explicitly name which sibling to prefer for which need.

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

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

Usage is only implied: an agent can infer this is for aggregated run-time statistics rather than raw results. There is no explicit when-to-use guidance, no mention of when to prefer get_check_results / get_check_uptime instead, and no stated prerequisites or check_id sourcing (that only appears in the schema).

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 cover the safety profile (readOnly, non-destructive, openWorld), and with no output schema the description usefully discloses the payload contents: enabled and down milliseconds plus uptime percentage, with a total. It does not mention rate limits, auth requirements, or how large ranges are handled.

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 dense sentence that front-loads the returned metric and appends the endpoint. Every clause carries information and nothing is padding.

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

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

With no output schema, the description does the important work of sketching the return shape (per-bucket milliseconds and uptime %, plus a total). It is reasonably complete for a read-only reporting tool, though it omits how the total is computed across buckets and whether results are truncated for long ranges.

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 six parameters (start, end, offset, interval, customer_id, check_id) are already documented in the schema. The description only echoes the day/month bucket notion that maps to the interval enum, adding no syntax or default detail beyond the schema; baseline 3 applies.

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

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

Names a specific resource (uptime of a check) and scope (per day or month, with a total), and even cites the underlying endpoint GET /results/uptime/{id}. It is clear what the tool returns, though it does not explicitly contrast itself with nearby siblings such as nodeping_get_check_results or nodeping_get_check_summary.

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

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

There is no statement of when to choose this over nodeping_get_check_results, nodeping_get_check_summary, or nodeping_get_check_events, and no prerequisites or exclusions. Usage is only implied by the word 'uptime'.

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 cover the safety profile (readOnlyHint, destructiveHint=false, openWorldHint), so the bar is lower. The description still adds genuinely useful behavior: the response embeds addresses and masks secret-like values, which the agent could not learn from the annotations or schema.

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

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

Two compact sentences, zero filler, with the resource and the notable masking behavior front-loaded before the endpoint string.

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 appropriately indicates what comes back (the contact plus its addresses, some masked), which is the key thing an agent needs for a single-record getter. A note on not-found behavior or id source would make it fully complete.

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

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

Schema description coverage is 100%, with contact_id's format and the MSP-only customer_id both documented in the schema itself. The description only restates the id in the URL form and adds nothing about parameter semantics, so the baseline of 3 applies.

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

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

States a specific verb and resource ('One contact by id') and adds scope detail — it returns the contact's addresses, with secret-like ones masked. It is clearly distinct from nodeping_list_contacts by virtue of the id-based lookup, though it never names the sibling explicitly.

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

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

Usage is only implied: an agent can infer this is the right call when it already has a contact id, and that listing requires the sibling tool instead. There is no explicit when-to-use or when-not-to-use statement and no named alternative.

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, destructiveHint=false, and openWorldHint=true, so the safety profile is covered structurally. The description adds only the endpoint path and the real-time 'right now' semantics; it discloses nothing about auth scope, rate limits, or result freshness/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?

Three tight fragments: scope, value proposition, endpoint. The scoping statement is front-loaded and nothing is 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?

With no output schema, the description usefully enumerates the returned fields (type, label, since when), which is more than most tools of this type offer. It is complete for invocation; only ordering, volume, and pagination behavior are unstated.

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

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

There is a single optional parameter with 100% schema description coverage, so the schema already explains customer_id and the MSP/omit-for-own-account behavior. The description adds no additional meaning about the parameter, which is the expected baseline when the schema does the work.

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

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

Specific verb+resource: it lists everything currently down or disabled, scoped 'across the account', and even names the endpoint (GET /results/current). The account-wide scope implicitly separates it from per-check siblings like nodeping_get_check_events, but no sibling is named explicitly, so it falls short of a 5.

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

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

The tagline 'The quickest "what is broken" view' implies the use case (triage of current outages) but states no explicit when-not conditions and does not name an alternative tool for historical or per-check investigation. Usage is implied rather than prescribed.

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, destructiveHint=false, and openWorldHint=true, so the safety profile is fully covered structurally. The description's only additional content is the raw REST endpoint mapping (GET /maintenance/{id}), which adds no behavioral insight such as auth requirements, error behavior for a missing id, or response shape.

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 terse sentences with the core purpose front-loaded and zero filler. The endpoint fragment is arguably redundant with the schema, but it costs almost nothing.

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

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

For a simple single-resource read with full annotation and schema coverage, the definition is minimally adequate. However, with no output schema, the agent gets no hint about what a maintenance entry contains, and the MSP/customer_id scoping caveat is never surfaced in the description.

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 maintenance_id (with its NZT101 example) and customer_id (MSP subaccount scoping, 'Omit for your own account') are already documented in the schema. The description's 'by id' adds nothing beyond that, so the baseline 3 applies.

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

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

States a specific verb+resource: retrieve one maintenance entry by id. The phrase 'One maintenance entry' implicitly distinguishes it from nodeping_list_maintenance, which returns many. It stops short of naming that sibling explicitly, so it lands just under full marks.

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 can infer 'use this when you already have a maintenance id' versus the list tool for discovery, but no condition or alternative is stated. There is also no mention of when the subaccount customer_id parameter applies.

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, openWorldHint=true, and destructiveHint=false, so the safety profile is covered. The description adds the code formats (two-letter probe codes, region names) and the underlying endpoint paths, but says nothing about the return shape or error behavior on an invalid code.

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 core resource front-loaded; the region examples are dense and useful. The opening is a fragment, but no sentence 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 reference lookup with no output schema, the description is adequate: it identifies the data, the valid value formats, and the endpoints. Only the return shape/error semantics are left implicit, which is a minor gap for this tool type.

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

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

Schema coverage is 100%, so the baseline is 3, but the description earns extra by supplying concrete region values (nam, lam, eur, eao, wlw) and the two-letter code format that the schema does not enumerate. This materially helps the agent pick valid values.

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

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

The description names the specific resource (probe servers and regions) and clarifies it is the reference data that a check's run locations use. Combined with the name/title, an agent can tell what it retrieves, though it never states the verb 'retrieve/list' explicitly. It is clearly distinct from the check/contact/schedule siblings.

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

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

The phrase 'the values a check's run locations use' implies the context (resolving codes for check configuration), but there is no explicit when-to-use, when-not-to-use, or named alternative. Usage is inferable but not stated.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=true, so the safety profile is covered. The description contributes the return shape (seven weekday entries) and the underlying GET path, which is modest but real added context. It says nothing about behavior when the named schedule does not 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 what is returned and then the endpoint path. No filler; every clause carries information. Slightly clipped rather than padded.

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

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

For a two-parameter read with full annotation coverage and no output schema, the description is largely sufficient: it states the input identity key and the return contents. It omits any note on failure modes (unknown schedule name) or the meaning of the optional customer_id, leaving minor gaps.

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

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

Schema description coverage is 100%, so the baseline is 3. The description's 'for example Days or All' gives the agent concrete sample values for the name parameter, which is genuinely useful beyond the schema's bare 'Schedule name.', but it says nothing about the customer_id sub-account parameter.

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?

Names a specific verb+resource ('One notification schedule by name') and even describes the payload shape ('seven weekday entries'), which an agent can act on. It does not explicitly contrast with siblings like nodeping_list_schedules or nodeping_put_schedule, so it stops 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?

There is no when-to-use guidance, no mention of list_schedules as the alternative for browsing, and no stated prerequisite (e.g. that the name must already exist). The single-schedule-by-name framing only weakly implies usage, and nothing tells the agent how to choose between this and list_schedules.

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 safety profile (readOnly/openWorld/non-destructive), and the description goes well beyond them: it decodes the status encoding (1 = passing, 0 = failing), explains firstdown, notes that full objects are 'scrubbed', and names the underlying GET /checks call. That is real added context, though response size/pagination behavior is unaddressed.

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?

Dense and front-loaded: the returned fields come first, then filtering, then the compact/detail switch, then the endpoint. Every clause carries information, with only minor slack in the parenthetical status decoding.

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 correctly takes on the burden of describing the return shape, including field list, status encoding and firstdown semantics. Combined with full annotation coverage and 100% schema coverage, an agent has enough to call this correctly, missing only pagination/volume expectations.

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

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

Schema description coverage is 100%, so all five params are already documented, which sets the baseline at 3. The description adds the notable detail that filtering happens 'client-side', but this sits in tension with the schema wording ('Only this check type'), so it adds ambiguity as much as clarification.

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 monitoring checks') and enumerates the returned fields (label, type, target, interval, enabled state, pass/fail), which clearly separates it from the singular nodeping_get_check and from the summary/uptime/events siblings. An agent can identify this as the bulk-listing tool without opening the schema.

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

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

It says filtering is available 'by status, type or label text' and that detail=true switches to full objects, which implies when to use each mode. However it never states when to prefer this over nodeping_get_check, nodeping_get_check_summary or nodeping_get_current_events, so the selection guidance is only partially there.

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, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds value beyond that by documenting the return payload shape (name + member address ids, keyed by group id), which matters because there is no output schema. It still omits pagination and the fact that the map key type is the group id string.

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 terse fragments, zero filler, with the data shape front-loaded before the endpoint reference. 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 simple read-only list with no output schema, the description supplies the essential return contract (keys and member fields). Only pagination/result-size behavior and any scoping caveat for the customer_id parameter are left unstated.

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

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

Schema coverage is 100% and the single optional customer_id parameter is fully documented in the schema itself (SubAccount id, omit for own account). The description adds nothing about this parameter, so the baseline 3 applies.

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

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

States the resource (contact groups) and the exact shape returned: name plus member address ids, keyed by group id. Combined with the title the verb 'list' is unambiguous, though it does not explicitly differentiate itself from nodeping_list_contacts or nodeping_list_notification_profiles.

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

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

No when-to-use guidance, no prerequisites, and no mention of alternatives such as nodeping_get_contact or nodeping_create_contact_group. The agent must infer that this enumerates all groups for the account.

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, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds genuinely new behavior: webhook/Slack/PagerDuty/Pushover addresses are masked in the response, plus the underlying endpoint (GET /contacts). It does not discuss pagination or how large a full list may be.

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

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

Three compact sentences with no filler, and the high-value scoping information (what is returned, what is masked, what the ids are for) is front-loaded. The trailing 'GET /contacts.' endpoint hint is terse and 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 single-parameter list tool with a fully documented schema and no output schema, the description covers the return shape and the masking caveat an agent needs. The only real gap is the absence of any guidance on result size or pagination behavior.

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

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

One optional parameter with 100% schema description coverage, so the schema already explains customer_id and the MSP omit-case. The description adds nothing about the parameter, which is the expected baseline when the schema carries the load.

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 ('All notification contacts') and enumerates the address types returned (email, SMS, webhook, Slack). Scope word 'All' distinguishes it from the singular nodeping_get_contact sibling without needing to name it.

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 or when-not-to-use guidance and no alternative tools are named. The line 'Address ids are what contact groups and checks reference' implies the tool's place in the workflow (getting ids before configuring groups/checks), which is implied usage rather than stated routing.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=true and destructiveHint=false, so the safety profile is covered. The description adds the concrete data shape (checks disabled, cron, duration, run history) and the underlying endpoint, but says nothing about pagination, result volume, or auth/subaccount scoping 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?

A single compact sentence front-loads the resource and its contents, followed by the endpoint. Nothing is padded, though the 'GET /maintenance.' fragment is close to redundant with the tool name.

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

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

For a low-complexity read-only list tool with a fully documented single parameter and annotations covering safety, this is nearly sufficient. It still omits any mention of the customer_id scoping parameter or how the result differs from nodeping_get_maintenance, which an agent calling an MSP-aware endpoint would benefit from knowing.

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

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

Schema description coverage is 100% and the single optional customer_id parameter is fully documented in the schema, including its MSP/omit-for-own-account semantics. The description adds nothing about parameters, 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 the resource (maintenance entries) and enumerates the salient contents (disabled checks, cron, duration, next/last runs), which is more specific than the title alone. It does not, however, explicitly distinguish this list operation from the sibling nodeping_get_maintenance, so an agent must infer the difference.

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

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

There is no statement of when to use this versus nodeping_get_maintenance (single entry) or nodeping_list_schedules, and no prerequisites or exclusions are given. The GET endpoint hint implies a read but offers no routing guidance.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety/scope profile is covered. The description adds that profiles are reusable composite sets built from contacts/groups, which is useful context, but says nothing about auth needs, result ordering, or pagination.

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 fragments with no waste; the concept definition is front-loaded. Slightly fragmentary but appropriately sized for a simple list tool.

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

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

For a read-only list tool with full schema coverage and no output schema, the essentials are present. What is missing is any hint of return shape (array of profiles with embedded delay/schedule) or the sibling differentiation that would let an agent pick this over list_contacts or list_notifications.

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 single customer_id parameter is fully documented in the schema, including the 'omit for your own account' rule. The description adds nothing on parameters, but with zero required params and full schema coverage the baseline of 4 is warranted.

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 the resource (notification profiles) and elaborates what a profile is: named sets of contacts/groups with delay and schedule, reusable across checks. The 'list' verb is implied by the name and GET endpoint rather than the prose, but the resource is well defined against other list_* siblings.

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

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

No when-to-use guidance, no alternatives named. It never tells the agent how this differs from nodeping_list_contacts, nodeping_list_contact_groups, or nodeping_list_notifications, which are the most likely confusion points given near-identical 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 cover the safety profile (readOnlyHint=true, destructiveHint=false, openWorldHint=true), so the bar is lower. The description still earns credit for disclosing that webhook URLs and keys in contact addresses are masked and that results are ordered newest first, neither of which is derivable from annotations or schema.

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

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

Two compact sentences plus an endpoint path, with the returned fields and ordering front-loaded and no filler. Every clause carries information an agent can use.

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

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

With no output schema, the description does the work of characterizing the response (who/when/what, newest first, masked addresses) for a five-parameter read tool, which is largely sufficient. It stops short of covering pagination or default record count behavior, which remain only in 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 the schema already documents span, limit, check_id, customer_id and include_subaccounts, including the span-vs-limit precedence rule. The description adds only the account-vs-check scope intent, 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?

Names a specific resource (alert notifications NodePing sent) with the tuple it returns (who, when, what) and its ordering (newest first). Scope is stated as one check or the whole account, though it never names the closest sibling (nodeping_get_check_events) to draw the boundary between 'notifications sent' and 'events'.

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 scope phrase 'for one check or for the whole account,' which hints at when check_id should be set. There is no explicit when-to-use/when-not framing, no mention of prerequisites such as needing an account or SubAccount context, and no routing to any alternative tool.

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

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

Annotations already declare readOnlyHint, openWorldHint and destructiveHint=false, covering the safety profile. The description adds only the resource definition and a redundant 'GET /schedules' endpoint note, disclosing no behavioral traits such as pagination, result ordering, or account-scoping 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 tight fragments with no filler, and the resource definition is front-loaded ahead of the endpoint reference. Appropriately sized for a simple list tool.

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

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

Adequate for a one-param read-only list: annotations cover safety and the schema covers the parameter. However, with no output schema, the description could hint at what a returned schedule contains beyond the brief parenthetical, and it never addresses the account-targeting behavior.

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

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

The single customer_id parameter is fully documented in the schema (100% coverage), including the MSP sub-account semantics. The description adds nothing beyond the schema, which is the expected baseline when coverage is complete.

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

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

States a specific resource (notification schedules) and defines the concept as per-weekday time windows a contact is alerted in, so an agent understands what is listed. The list vs. get_schedule (singular) distinction is implied by the name but never made explicit.

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

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

No guidance on when to list schedules versus fetching one with nodeping_get_schedule, nor prerequisites for the customer_id sub-account path. The agent must infer usage entirely from the name.

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

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

Annotations already declare readOnlyHint=false, destructiveHint=true, and idempotentHint=true, so the safety profile is covered. The description still adds real context the annotations lack: that the check continues running and recording while muted, and that omitting mute_until_ms with mute=true mutes indefinitely. It does not describe auth requirements or the response, keeping it short of a 5.

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

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

Three tight sentences, front-loaded with the WRITE: marker and the operation, followed by the duration semantics and endpoint. No filler; 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?

No output schema exists, so the description needn't explain returns, and it covers the write nature, the non-destructive-to-check behavior, the indefinite-mute case, and the endpoint. Only gaps are auth/permission context and confirmation of the toggle's reversibility, which are minor.

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

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

Schema coverage is 100%, so the baseline is 3, but the description goes beyond it by explaining the omitted-mute_until_ms case means 'mute until unmuted' and that the value is ms since epoch in the future. Minor mismatch: description says 'mute_until' while the schema field is 'mute_until_ms', but semantics are clear.

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 (mute/unmute a check's notifications) and, crucially, the parenthetical 'the check keeps running and recording' distinguishes it from the disable_check sibling without the agent needing to open a schema. The WRITE: prefix and endpoint reinforce the operation unambiguously.

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

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

Usage is implied through the mute/unmute toggle mechanics and the 'until a time or indefinitely' framing, but it never explicitly states when to choose this over nodeping_disable_check or nodeping_update_check, nor any prerequisites (e.g. ownership/permissions). Adequate but no explicit when-to-use routing.

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

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

Annotations already flag destructiveHint=true, idempotentHint=true and openWorldHint=true, so the safety profile is partly covered. The description adds genuinely new behavior beyond annotations: the all-seven-weekdays storage model and the partial-merge rule for updates, which is critical to avoid unintended overwrites.

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 tightly packed sentences, front-loaded with the WRITE designation and the merge rule. Each sentence delivers distinct operational value (mutation semantics, merge model, per-weekday fields) 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 destructive, nested, 9-parameter write tool with no output schema, the description covers the mutation, the merge model, the per-weekday field meanings, and the endpoint. Missing only ancillary details like auth/permission requirements or whether name must pre-exist for update, which are minor against the whole.

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?

With only 22% schema description coverage across 9 params, the description carries real weight: it explains the per-weekday shape (time1/time2 24h window, exclude to invert, disabled, allday) and, crucially, the merge semantics that govern how partial weekday objects are interpreted. It doesn't address customer_id or the name-as-identifier behavior, leaving some gap.

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?

Opens with "WRITE: create or update a notification schedule," giving a specific verb (create/update) and resource (notification schedule). This cleanly distinguishes it from sibling read tools (nodeping_get_schedule, nodeping_list_schedules) and the delete tool without needing to consult 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?

Explains the create-vs-update distinction via merge semantics: an existing schedule merges the weekdays passed, while a new schedule requires all seven. Also sketches the operational flow ("GET then PUT /schedules/{name}"). It stops short of explicitly saying "call get_schedule first to read current state," so it is clear context rather than 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?

Annotations already declare readOnlyHint=false, destructiveHint=true, and idempotentHint=true, so the write/safety profile is covered. The description still adds a crucial non-obvious behavioral fact for a PUT: 'Only the fields you pass change,' correcting the default assumption that PUT replaces the whole object, and clarifies the scope (no enable/create/billing side effects).

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

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

Front-loaded with 'WRITE:' and the field list, then the partial-update rule, then the exclusions, then the endpoint. Every clause carries information; no filler sentences.

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

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

For an 8-parameter mutation tool with no output schema, the description covers what can be changed, how partial updates behave, and what the tool avoids. It lacks a note on return shape or what happens to unspecified fields beyond 'only what you pass changes', but that is a minor gap given the annotations carry the safety profile.

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 88%, so the baseline is 3, but the description earns more by mapping human-readable concepts onto confusing parameter names — 'timeout (threshold seconds)' and 're-checks before alert (sens)' — which the schema alone does not disambiguate. It also conveys the partial-update rule for all optional fields.

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

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

States a specific verb (change/update) and resource (a check), then enumerates the exact updatable fields (label, description, tags, target, threshold, sens). It explicitly excludes enabling, creating, and billing, which separates it from siblings like nodeping_disable_check and any create tool without requiring the schema to be opened.

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

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

Gives clear context (WRITE to an existing check, partial update, PUT endpoint) and negative guidance ('does not enable the check, create checks or touch billing'). It does not explicitly point at the alternative tools for those tasks (e.g. nodeping_disable_check, nodeping_mute_check), so routing is implied rather than named.

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 flag destructiveHint=true and idempotentHint=true, but the description adds real value by explaining the destructive mechanism: members is a full replacement and 'omitted members are removed'. It also labels the operation WRITE and gives the PUT semantics, which clarifies the idempotent behavior. It stops short of covering authorization or rate-limit 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?

A single dense sentence with the most important constraint (full-list replacement/destructive removal) front-loaded right after the WRITE label, plus the endpoint for reference. 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 4-parameter mutation tool with no output schema, the description covers the key risk (member removal), the replacement contract, and the transport endpoint, and the annotations carry the safety profile. Return-value behavior is undescribed, but with no output schema that is a minor omission.

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

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

Schema coverage is 75% (members, group_id, and customer_id carry descriptions, only name is bare), so the schema already does most of the work and the baseline is 3. The description's 'send the FULL list' adds a replacement-semantics nuance the schema doesn't state, but offers nothing new for name, group_id, or customer_id.

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 (rename/replace) plus the resource (contact group) and even the underlying endpoint PUT /contactgroups/{id}. It clearly distinguishes itself from the sibling create_contact_group, delete_contact_group, and list_contact_groups 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?

Usage is implied: use it to change an existing group rather than create or delete one, and the 'and/or' phrasing signals both fields are optional modifications. However, it never explicitly names an alternative tool or states when-not-to-use conditions, so the agent must infer routing from the sibling names.

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