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

Beyond the readOnlyHint annotation, the description discloses genuinely useful behavior: alerts are deduplicated and rolled up per message, and storms collapse into a single counted entry. It stops short of stating whether results are truncated, paginated, or how the count is surfaced, so the behavioral picture is useful but not complete.

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 the operation type and core value proposition in the first two lines, then the argument note. The '[READ]' tag and 'Args:' block add slight redundancy against the readOnlyHint annotation, but nothing is wasted or buried.

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

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

For a low-complexity, single-optional-parameter read tool with no output schema, the description covers the operation, the dedup semantics, the supported backends, and the parameter default. Return-shape details are the only meaningful omission and are partly implied by 'one counted entry.'

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 a single optional parameter and 0% schema description coverage, the description carries the load and does so adequately: 'Monitoring target name from config; omit for the default' explains both the value source and the defaulting behavior. It does not enumerate valid target names, but config-sourced names are reasonably self-documenting.

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 (active alerts) and the distinctive behavior (dedup/rollup by message) plus the supported sources SolarWinds or PRTG. It does not, however, differentiate itself from conceptually adjacent siblings such as noc_rollup, prtg_alarms, or zabbix_problems, so an agent still has to guess which alert surface to pick.

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 dedup rationale ('so the signal isn't buried under duplicates') suggests using it during alert storms, and the target arg note says to omit it for the default. There is no explicit when-to-use versus when-not or named alternative, which matters given several overlapping monitoring 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?

Adds real context beyond the annotations: the three platforms use different endpoints and different id shapes, and dry_run reports which platform's acknowledge API would be invoked. Annotations already carry the write/destructive/idempotency profile, so the description's job is additive, which it does. Minor tension: it calls the action 'reversible' while destructiveHint=true, but this is state-modification vs. undo-ability, not a direct contradiction.

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

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

Front-loaded with the [WRITE][risk=medium] tag and the core action, then a genuinely useful dry_run note, then terse parameter docs. The structured Args block is slightly redundant with the prose but each line earns its place except target, which is thin.

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 3-param write tool with no output schema, the description covers parameters, the preview path, and cross-platform differences — enough to call it correctly. It stops short of stating auth/permission requirements or what a successful acknowledge returns, minor gaps given no output schema exists.

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 0%, so the description carries the full burden and does so: alert_id is explained as AlertActiveID on SolarWinds, sensor objid on PRTG, and problem event id on Zabbix — meaning that exists nowhere in the schema. dry_run and target are also given semantics (preview-without-acknowledging; omit for default).

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 with scope ('Acknowledge one active alert'), and immediately classifies it as a reversible triage action. An agent can distinguish it from sibling mutators like mute_alerts, unmute_alerts, or schedule_maintenance without opening any schema.

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

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

The description gives clear operational guidance for dry_run ('preview... the part of this call most worth confirming first') but never states when to prefer acknowledge over the similar sibling triage tools (mute_alerts, unmute_alerts, schedule_maintenance). Usage is implied by the 'reversible triage action' framing rather than explicitly routed.

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

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

Annotations already declare readOnlyHint=true, so safety is covered. The description adds a genuine behavioral trait, 'resilient if absent', telling the agent it won't error when the application is missing. It says nothing about return format or auth, so it adds some value but not rich context.

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

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

Short and front-loaded, with the read tag and purpose first and the single parameter documented after. The 'Args:' block is slightly heavy for one parameter but not wasteful.

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

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

For a one-parameter read tool with no output schema, the description covers purpose, the sole parameter's semantics, and the absent-data behavior. Sufficient for an agent to call it correctly.

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

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

Schema coverage is 0% and the schema itself gives no description for 'target', so the description carries the burden and does so well: 'SolarWinds target name from config; omit for the default' explains both the value source and the optional/default behavior.

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

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

The description states a specific verb+resource: '[READ] SAM application status (Orion.APM.Application)'. Naming the SAM application resource distinguishes it from the many sibling *_status tools (node_status, interface_status, volume_status), though it never explicitly routes away from 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?

There is no when-to-use guidance relative to the status siblings. The only usage note ('omit for the default') concerns the parameter, not the tool's 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?

readOnlyHint=true already covers the safety profile, so the '[READ]' tag is redundant. However, the description adds genuine behavioral context beyond the annotation: it explains that the whole table is fetched and ranked before the cut, making `truncated: true` a measured rather than inferred signal. That is a real disclosure an agent would not get from structured fields.

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 the read tag and resource, then a tightly worded note on the truncation flag, then an Args block. Every sentence carries information; the truncation explanation is verbose but earns its place by clarifying semantics an agent could otherwise misread.

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, two-optional-parameter tool with no output schema, the description covers purpose, both parameters, and the one non-obvious return behavior (the truncated flag). Return shape is otherwise unexplained, but the tool's simplicity makes that a minor gap.

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

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

Schema description coverage is 0%, so the description carries the full burden and largely meets it: `top` is documented as top-N by peak utilization, and `target` as a SolarWinds target name from config with the default omitted. This compensates well for the empty schema, though the expected type/format of `target` values is not illustrated.

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 ('Interface status + utilization') and pins the backing data source (Orion.NPM.Interfaces), which cleanly separates it from the parallel node_status, volume_status and application_status siblings. It stops short of explicitly naming those siblings or the topn tool as alternatives, so it is clear but not fully differentiated in text.

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 explains what `top` does mechanically but never states when to use this tool versus node_status, volume_status, application_status or topn, nor any prerequisites or exclusions. An agent must infer the selection context from the tool 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?

Annotations already declare readOnlyHint=true, and the description reinforces it with '[READ]'. It adds genuinely useful behavior the annotations don't cover: the 'truncated: true' signal when more events exist than returned, which matters because there is no output schema. It still omits auth requirements, rate limits, and pagination strategy.

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 opening sentences front-load the resource, ordering, and truncation behavior, followed by a compact Args block. Nothing is padding; every sentence adds 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 2-param read tool with no output schema, the description covers the key behaviors (ordering, truncation flag, param meanings). However, it says nothing about what an event record contains, how 'target' maps to config, or any limits on 'top', leaving some gaps for an agent reasoning about results.

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 0%, so the description carries the full burden, and it largely does: 'top' is explained as the count of events newest-first, and 'target' is explained as a config target name with 'omit for the default'. The default value of 50 for 'top' is left to the schema but the semantics are covered.

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 ('Most recent SolarWinds Orion events') with ordering ('newest first'), and the SolarWinds qualifier distinguishes it from the zabbix_events sibling. It stops short of explicitly contrasting with that sibling, so it's clear but not fully disambiguating.

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 '[READ]' marker and 'omit for the default' note imply read-only retrieval of recent events, but there is no explicit when-to-use or when-not guidance, and no sibling alternative is named. Usage must be inferred from the ordering hint.

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 [READ] tag in the description is largely redundant. What the description does add is the semantic scope of the result set (objects in a suppression window), which is useful context, but it says nothing about return format, pagination, or result limits.

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

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

Front-loaded with the read marker and the resource, then the parameter note. No wasted sentences, though the [READ] prefix duplicates the readOnlyHint annotation rather than adding 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 single-optional-parameter read tool with no output schema and annotations covering safety, the definition supplies what an agent needs: the result semantics and the target parameter's behavior. Only the absence of selection guidance against siblings 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 0%, so the description must carry the parameter meaning — and it does: 'target: SolarWinds target name from config; omit for the default.' That conveys both the value source (config) and the default behavior, which the bare anyOf/null schema does not.

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-plus-resource: objects currently in an alert-suppression (muted) window. That is clearly distinct from the mutation siblings mute_alerts and unmute_alerts, though it never names them explicitly. Purpose 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?

There is no statement of when to use this versus the nearby mute_alerts, unmute_alerts, or active_alerts tools. The only usage-like guidance is the parameter note 'omit for the default', which is not about tool selection. Usage is left entirely 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, so the safety profile is covered; the leading '[READ]' marker largely repeats that. The description does add genuine scope context by clarifying that 'unmanaged' includes nodes with a scheduled future unmanage window, which is useful behavioral detail beyond the annotation, but it says nothing about pagination, auth, or result 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?

Brief and front-loaded, with the core resource description first and the parameter note after. The 'Args:' block is a slightly clunky but efficient way to attach the parameter meaning.

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-optional-param read tool with no output schema, the description covers what is listed and how to scope the target. Little is missing for correct invocation, though the lack of any pointer to related mutation tools is a minor gap.

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

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

Schema coverage is 0%, so the description carries the param burden and does so reasonably: it explains that target is a SolarWinds target name from config and that omitting it selects the default. That meaningfully supplements the bare schema, though it doesn't clarify accepted formats.

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 clear resource (nodes unmanaged now or with a scheduled future unmanage window) and implies the list verb via the tool name. It distinguishes itself conceptually from the unmanage_node/remanage_node siblings by emphasizing the read/listing nature, though it does not name them directly.

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 alternatives like unmanage_node, remanage_node, or list_muted. Usage is only inferable from the name and the resource described. There are no exclusions or alternative-tool pointers.

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=false. The description adds real value on top: it flags the operation as a time-boxed (self-expiring) suppression and points to the inverse operation, which conveys reversibility and scope beyond the annotation flags.

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 the [WRITE][risk=medium] tag and a one-line purpose, followed by a compact Args block. No sentence is wasted and the most selection-relevant information 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?

For a destructive write tool with no output schema and no annotation coverage of duration/expiry semantics, the description supplies purpose, risk tag, time-boxing, inverse operation, and per-parameter meaning. It stops short of stating permission requirements or what the call returns, but what is present is sufficient to invoke correctly.

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

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

Schema description coverage is 0%, so the description carries the burden and does so for all three params: entity_uri is defined as a SWIS URI with a sourcing hint (list_muted/SWQL), minutes as a window length, and target as a config name with 'omit for the default'. It does not restate the schema defaults (minutes=60), a minor omission.

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: 'Time-boxed alert suppression for an entity.' It also names the inverse tool (unmute_alerts), letting an agent place it correctly relative to its one obvious counterpart without opening a schema.

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

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

The 'Time-boxed' qualifier and the named inverse imply the intended scenario (temporary suppression that can be reversed), but there is no explicit when-to-use vs when-not guidance, nor reference to list_muted or schedule_maintenance as alternatives for longer suppression.

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

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

Annotations only declare readOnlyHint, so the description carries the real behavioral burden and does meaningfully: it explains that unqueryable counts come back as null with the reason in countErrors, and warns against reporting a null as '0 down'. That is genuine return-semantics context beyond the annotations, though it says nothing about rate limits, latency, or auth requirements.

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?

Extremely tight: a bracketed read marker, one sentence on what it returns, one sentence on the null/countErrors pitfall, and a one-line arg note. The most important operational detail (never report null as zero) is included without 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?

There is no output schema, but the description compensates by sketching the return shape (counts, top-3 nodes, countErrors) and an edge-case convention. Combined with readOnlyHint, an agent has what it needs to call and interpret this correctly; only the exact field names/structure remain 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 0% — the single 'target' property has no description of its own — so the description must compensate, and it does: 'SolarWinds target name from config; omit for the default' explains both meaning and default behavior. With only one optional param there is little more to say.

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

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

The description states a concrete verb and resource: a one-shot rollup returning down/warning counts plus the top-3 worst-CPU nodes. The composite 'one-shot glance' framing implicitly separates it from granular siblings like node_status or topn. It never explicitly names an alternative tool, 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?

Usage is only implied by 'One-shot NOC glance' — an agent can infer this is a quick triage overview rather than a drill-down call. The only explicit guidance is for the target arg ('omit for the default'). No when-not or alternative-tool routing is 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 readOnlyHint=true, and the description reinforces this with a '[READ]' tag. It adds the useful detail that target comes from config and defaults when omitted, but discloses nothing about return volume, pagination, or ordering. With annotations covering the safety profile, this is adequate but thin.

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 the core action in one sentence, then lists the two args compactly. Slightly redundant to repeat '[READ]' when readOnlyHint is already set, but there is no wasted prose.

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-only list tool with no output schema, the description covers both parameters and the default behavior. It is nearly complete; only pagination/return-shape hints are missing, which is a minor gap given the low complexity.

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

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

Schema description coverage is 0%, so the description must carry the parameter burden, and it largely does: it decodes the status codes (1=Up, 2=Down, 3=Warning) and explains that target is a config name that defaults when omitted. This adds real meaning beyond the bare integer/string schema, though it omits what happens with invalid status 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?

States a specific verb and resource ('List SolarWinds nodes') with a clear scope modifier ('optionally filtered by status'). It does not explicitly distinguish itself from close siblings like node_status or list_unmanaged, so it stops short of a 5, but the purpose 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 implied: list nodes, optionally filter by status, and omit target for the default. There is no explicit when-to-use or when-not-to-use guidance relative to siblings such as node_status or list_unmanaged, so the agent must infer the choice.

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 [READ] tag is largely redundant. The description adds the Orion.Nodes source table, which is modestly useful context, but discloses nothing about return format, error behavior for an unknown caption/IP, 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?

Front-loaded with the [READ] marker and purpose, followed by a tight two-parameter arg list. Nearly every token earns its place; no wasted preamble.

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 tool with no output schema and only readOnlyHint, the description never says what 'health' actually returns (status, CPU, memory, threshold state), leaving the agent blind to the response shape. Adequate for invocation, incomplete for interpretation.

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 0%, so the description has to carry parameter meaning and it does: name_or_ip is defined as a caption OR IP address (resolving a real ambiguity), and target as a SolarWinds config target with a default. Minor gap: it doesn't say whether caption matching is exact or partial.

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 ([READ]) plus resource ('One SolarWinds node's health') and the source table (Orion.Nodes), making the singular lookup distinct from the bulk nodes_list sibling. It stops short of explicitly naming that sibling, but the scope contrast is obvious.

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

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

Usage is only implied by the singular-lookup framing; there is no explicit 'use this when you need one node vs. nodes_list when you need many' routing. The only real guidance is the target note ('omit for the default'), which is schema-level, not task-level.

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

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

Annotations declare destructive=true and it tells the agent the action is reversible via resume_sensor and describes the auto-resume timing, which is genuinely useful context beyond the structured hints. It stops short of stating required permissions or what happens to in-flight alerts when pausing.

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 the write/safety tag then a one-line purpose, followed by a tight Args block. Every line earns its place; the only minor cost is restating parameter meanings that already live in the schema titles.

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 with no output schema, the definition covers purpose, reversibility, parameter meanings, and the open-ended/auto-resume behavior. Annotations already carry the safety profile, so nothing critical is missing, though permission requirements remain 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 description coverage is 0%, so the description carries the burden and does so for all four parameters: object_id scope (sensor/device/group), minutes=0 semantics, message purpose, and target config override with default. This compensates well for the undocumented schema, though format details (e.g., valid target names) are absent.

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 (Pause) and resource (PRTG object/sensor) with a clear scope marker in the [WRITE][risk=medium] tag. It explicitly distinguishes itself from the resume_sensor sibling by naming it as the reversal path, so an agent can route between the two without opening 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?

It explains the key behavioral branch: minutes=0 means open-ended pause, otherwise auto-resume. It also names resume_sensor as the undo path. What's missing is explicit guidance on when to pause vs. alternatives like schedule_maintenance_prtg or mute_alerts, which overlap semantically.

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=true annotation is consistent with the '[READ]' marker, so safety is doubly clear. Beyond that, the description adds genuinely useful semantics — the alarm set is limited to sensors in a down state (status 5), which tells the agent what is and is not returned. It does not cover pagination or result volume, but the annotation already carries the safety profile.

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 lines: the operation and its defining filter first, then the single argument's semantics. No filler, nothing repeated from the schema, and the most important fact (what counts as an alarm) is front-loaded.

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

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

For a one-optional-parameter read tool with no output schema, the description supplies everything needed to invoke it correctly: the operation, the filter semantics, and the argument's origin. Only the shape of the returned alarm list is unstated, which is a minor gap for a simple read.

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 0%, so the description must carry the parameter, and it does: 'target: PRTG target name from config; omit for the default.' That explains both the source of valid values and the optional/null behavior, which the bare anyOf[string, null] schema does not convey.

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 ('Active PRTG alarms') and sharpens it with a precise definition — sensors in a down state, status 5. That definition distinguishes it from a generic sensor listing, though it never names a sibling (e.g. prtg_sensors or active_alerts) to route the agent 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?

The '[READ]' marker plus 'omit for the default' tells the agent this is a safe read and how to handle the optional target. However, there is no guidance on when to choose this over prtg_sensors, prtg_sensor_details, or prtg_system_status — all plausible siblings for 'what's wrong right now' questions. Usage is implied rather than stated.

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

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

Annotations already declare readOnlyHint=true, so the safe-read profile is covered, and the '[READ]' prefix is largely redundant with that. The description does add the returned field set, which is modest useful context, but omits pagination, filtering behavior, 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 compact parts: a front-loaded purpose with field list, then the single arg note. Nothing is padded, though the '[READ]' tag repeats what readOnlyHint already conveys.

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-optional-parameter list tool with no output schema, the definition supplies purpose, returned fields, and parameter behavior. Adequate, though cross-tool disambiguation from prtg_sensors/prtg_groups is left implicit.

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 0%, so the description must carry the burden. It does explain 'target' as a 'PRTG target name from config' and the behavior of omitting it (default), adding real meaning beyond the bare string|null 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 clear verb+resource: 'List monitored PRTG devices'. The parenthetical field list (objid, device, host, status, group) further clarifies scope. It implicitly distinguishes itself from siblings prtg_sensors and prtg_groups via the resource noun, but does not explicitly call out 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 description gives no when-to-use context, no prerequisites, and no alternatives among the many sibling list tools (prtg_sensors, prtg_groups, nodes_list). The only guidance is 'omit for the default', which concerns the parameter, not tool selection.

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

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

The '[READ]' tag merely restates the readOnlyHint=true annotation, adding no new information. No mention of return volume, pagination, ordering, or whether the default target vs. a named target behaves differently. With annotations covering only the safety profile, the description leaves the behavioral picture thin.

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 front-loaded sentence stating purpose, then a compact Args block. No filler, though the '[READ]' prefix is redundant with the annotation and could be dropped.

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

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

For a single-param read-only list tool with no output schema, the core purpose and the parameter semantics are covered. Still missing is any notion of what a group record contains beyond 'rollup status' or how results are ordered, which would help an agent consume the output.

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 0% – the schema gives only a nullable string titled 'Target' with default null. The description supplies the missing meaning: it is a 'PRTG target name from config' and omitting it selects the default. That compensates for the coverage gap, though it doesn't explain what valid target names look like.

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 clear verb+resource: 'List PRTG device groups' plus the distinguishing scope 'with their rollup status'. The resource (groups) separates it from siblings like prtg_devices and prtg_sensors, though the description never names those siblings to make the routing 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 use this versus prtg_devices, prtg_sensors, or prtg_sensor_details, all of which return related PRTG hierarchy data. The only usage note is that target may be omitted, which is a parameter detail rather than tool-selection 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?

readOnlyHint=true already establishes this is a safe read, so the '[READ]' label is largely redundant. The description adds that the window is bounded ('recent') and that target defaults from config, but says nothing about return shape, pagination, or data resolution. Moderate value 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?

Front-loaded with the purpose sentence followed by a compact args list; no filler. Slightly list-heavy but every line 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 history tool with no output schema and only one required parameter, the definition covers purpose and all parameters adequately. It could mention the granularity or format of returned points, but nothing critical 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 0%, so the description carries the full burden, and it does so well: sensor_id is tied to the PRTG objid concept, hours is defined as a look-back window with default 24, and target is explained as a config name that can be omitted for the default. Only minor detail (e.g. accepted hours range) is missing.

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: historic data points for one PRTG sensor over a recent window, with a '[READ]' marker. An agent can distinguish this from prtg_sensor_details (current state) and prtg_sensors (listing), though the differentiation is implied rather than named.

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 'recent window' and 'one PRTG sensor' implies when this is appropriate, but there is no explicit when-to-use, when-not, or named alternative (e.g. prtg_sensor_details vs prtg_history). 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?

The readOnlyHint=true annotation already establishes the safety profile, so the '[READ]' tag is largely redundant. The description does add useful context by indicating the fields returned (name, status, lastvalue), but says nothing about rate limits, output format, or how a missing sensor_id is 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?

Front-loaded with the core purpose and an efficient Args block; no filler sentences. Slightly more compressed than ideal but every element earns its place.

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

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

For a simple read-only detail tool with no output schema, the description is acceptable but thin: it hints at return fields without characterizing the response shape, and offers no guidance on errors or scope. Adequate but with clear 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?

With 0% schema description coverage, the description carries the full burden and does so: it clarifies sensor_id as a PRTG object id (objid) and explains target as a config name that defaults when omitted. This meaningfully compensates for the bare schema, though 'target from config' remains slightly vague about where that config comes from.

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 ('Detailed status for one PRTG sensor') and even enumerates return fields (name, status, lastvalue), so the purpose is unambiguous. It does not explicitly differentiate itself from the sibling list tool prtg_sensors or from prtg_history, leaving the 'one sensor vs. many' distinction to inference.

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 no when-to-use guidance and names no alternatives. It never explains why an agent would pick this over prtg_sensors or prtg_history when it wants sensor-level data, so routing must be inferred 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?

Annotations already declare readOnlyHint=true and the [READ] tag reinforces it, so the safety profile is covered. The description adds the returned field set and the config-based target selection, but says nothing about pagination, result limits, or ordering 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?

Front-loaded with the read tag and the core purpose, then a compact Args block. Every element earns its place, though the bracketed [READ] tag is somewhat redundant with the readOnlyHint annotation.

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 tool, the description is nearly complete: it names the resource, the returned fields, and both parameters. With no output schema it helpfully lists the return columns; only pagination/volume behavior is 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 description coverage is 0%, so the description carries the burden, and it does so well: status is documented as an optional PRTG status code with a concrete example ('5' for down), and target as a config name with 'omit for the default' semantics. Both parameters get meaningful context beyond the bare schema types.

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 (PRTG sensors) and even enumerates the returned fields (objid, sensor, device, status, message, lastValue). This is clearly distinguishable from siblings like prtg_devices and prtg_groups by the resource noun, though it never explicitly contrasts itself with prtg_sensor_details.

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

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

The description implies a listing/browsing use case and explains the target parameter's default behavior, but gives no explicit when-to-use guidance and never names alternatives such as prtg_sensor_details for drilling into a single sensor. Usage must be inferred.

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 the description's '[READ]' tag reinforces it consistently. It adds the useful 'system-wide' scope context and enumerates the counters, but says nothing about return format or freshness, so it only modestly exceeds the 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?

Purpose is front-loaded in a bracketed tag and one sentence, followed by a compact Args block. No filler; it is sized appropriately for a one-parameter read 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 simple read-only counter tool with no output schema, the definition covers what is counted and the optional target. It stops short of indicating the response shape or whether counters are point-in-time, leaving a small 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 coverage is 0%, so the description must carry the load, and it does explain the single parameter: target is a 'PRTG target name from config' and can be omitted for the default. That meaningfully clarifies origin and default behavior beyond the bare anyOf[string,null] in 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 resource and scope: 'System-wide PRTG sensor counters (up/down/warning/paused/alarms)'. An agent can tell this returns aggregate counts rather than per-sensor listings like prtg_sensors. It does not, however, explicitly name which sibling it differs from.

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 alternatives named, and no conditions for choosing this over prtg_sensors or prtg_alarms. The only context is the arg note about omitting target for the default.

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 '[WRITE]' tag restates readOnlyHint=false and '[risk=medium]' adds mild context beyond destructiveHint=true, but the description does not explain what state actually changes, whether the call is safe to repeat (annotations say idempotentHint=false, which for a 'return to managed' operation deserves explanation), or what auth/config is required. Given the annotations already carry the safety profile, this is minimal added value rather than a gap-filling description.

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

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

The tag prefix front-loads the operation class and risk, then the Arg list is terse and targeted. Slightly terse overall, but no wasted 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 write tool with no output schema, the description plus annotations give an agent enough to invoke it correctly: action, inverse operation, and both parameters. It omits return/confirmation behavior and error cases for nodes that are not currently unmanaged, which is a minor gap given the annotation coverage.

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 0%, so the description carries the full burden and does so reasonably: node_id is identified as the numeric Orion NodeID and target is explained as the SolarWinds config target name with an explicit 'omit for the default' default-behavior note that the schema itself does not state. It stops short of format examples or how the target name maps to config entries.

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 ('Return a node to managed state') and immediately clarifies with '(lift unmanage)', which pins it as the exact inverse of the sibling tool unmanage_node. An agent can pick between remanage_node and unmanage_node 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?

Usage is only implied: the inverse framing of 'lift unmanage' tells an agent this is for restoring monitoring, but there is no explicit when-to-use, no precondition (e.g., node must currently be unmanaged), and no pointer to unmanage_node/list_unmanaged as alternatives.

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 and readOnlyHint=false, so the bar is lower. The description goes beyond annotations by declaring permanence and irreversibility explicitly, and by explaining what dry_run reports (the node's caption), which is concrete behavioral detail not present in structured fields. It does not cover permissions or side effects on dependent interfaces/volumes.

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?

Risk marker and irreversibility warning are front-loaded in the first sentence. The args list is compact and each entry earns its place. 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?

A high-risk destructive tool with no output schema and no annotation contradiction. The description covers purpose, irreversibility, dry_run preview, and all parameter meanings. It lacks only explicit routing guidance versus the unmanage/remanage siblings and any note on auth or rate limits.

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 0%, so the description must compensate, and it does for all three parameters: node_id is 'Numeric Orion NodeID', dry_run explains preview semantics, and target is 'SolarWinds target name from config; omit for the default'. This meaningfully fills the gap left by an undocumented 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+resource ('Permanently delete a node from Orion') and immediately distinguishes severity with the IRREVERSIBLE marker. The dry_run mention further clarifies the exact behavior. Easily distinguished from siblings like unmanage_node or remanage_node which are non-destructive.

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 dry_run preview hint implies a safe-check workflow but does not explicitly state when to use this tool versus unmanage_node or remanage_node, which are the obvious alternative non-destructive operations. No when-not-to-use guidance is given. Usage is implied rather than stated.

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

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

Annotations already declare readOnlyHint=false, idempotentHint=false, and destructiveHint=true, so the description's [WRITE] tag largely restates structured data. It adds a 'risk=medium' qualitative severity signal and the inverse relationship to pause_sensor, but does not explain permissions, reversibility, or side effects beyond what annotations give.

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 the WRITE/risk tag and the one-line purpose, then tight arg notes; no filler. Slightly terse on object_id but nothing 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 2-parameter mutation tool with no output schema, the definition covers purpose, both args, and risk level adequately. Missing only operational context such as permission requirements or behavior if the object is not paused.

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 0%, so the description carries the burden. It does clarify the non-obvious 'target' parameter ('Monitoring target name from config; omit for the default'), which the bare schema property does not, but object_id is only restated ('PRTG object id to resume') with no format or source hints.

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 ('Resume a paused PRTG object') and proactively names the sibling it inverts ('inverse of pause_sensor'), which lets an agent distinguish it from pause_sensor 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 'inverse of pause_sensor' framing clearly implies when to use it (objects that are currently paused), and the target arg note explains the default target. There is no explicit when-not guidance or prerequisite (e.g. that the object must first be paused), so it stops short of a 5.

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

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

Annotations already declare readOnlyHint=false, idempotentHint=false and destructiveHint=true, so the safety profile is covered. The description adds real value beyond that by emphasizing that an end time is REQUIRED and open-ended maintenance is not allowed, but it says nothing about permissions, what state changes are made, or whether the window can be cancelled/edited.

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

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

The operation class and the key constraint are front-loaded, and the Args block is tight with no filler. The tag prefix duplicates the meaning of "Schedule", but the overall size is proportionate to a four-parameter mutation 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 destructive, non-idempotent mutation with no output schema and 0% schema coverage, the description covers inputs well and states the bounded-window rule, but leaves out everything about the result (does it return a window ID?), required permissions, and interaction with unmanage/remanage. Adequate but with visible 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 0%, so the description has to carry the load, and it does document all four parameters: node_id as a Numeric Orion NodeID, start_iso/end_iso as ISO-8601 UTC timestamps (with end_iso marked required), and target as a SolarWinds config name with a default when omitted. It adds timezone and default semantics the schema lacks, though it gives no example format or range constraints.

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+resource ("Schedule a bounded maintenance window for a node") and flags the operation class with [WRITE][risk=medium]. It is clear on its own, but it never differentiates itself from the sibling schedule_maintenance_prtg, so an agent must infer that this one targets Orion nodes and the other PRTG sensors.

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 or when-not guidance and no named alternative, despite schedule_maintenance_prtg and unmanage_node/remanage_node sitting in the same toolset. The only routing hint is the incidental "omit for the default" note on target, which is parameter-level rather than tool-selection 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 write/destructive/non-idempotent, but the description earns credit by adding behavior annotations don't carry: the window is time-boxed and minutes must be > 0 because 'maintenance windows are never open-ended'. It still omits what happens on repeated calls or whether the action is reversible.

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

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

The risk/write tag and the key constraint (minutes > 0, never open-ended) are front-loaded before the Args block, and every sentence carries information. No padding 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?

With no output schema, three params, and annotations covering safety, the description supplies the constraint, the object scope, and the default behavior. What's missing is minor: no statement of required permissions or the return/confirmation shape, though no output schema exists to offload that to.

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 0%, so the description must compensate and it does: object_id is 'PRTG object id to place in maintenance', minutes is the duration with a stated > 0 constraint, and target is a config name that can be omitted for the default. All three parameters gain meaning absent from the bare 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 (schedule) and resource (maintenance window) scoped to a PRTG object, and the [WRITE][risk=medium] tag plus 'PRTG object id' implicitly distinguishes it from the generic schedule_maintenance and zabbix_create_maintenance siblings. It's clear what the tool does, though it never explicitly names the alternative it replaces.

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 conveys that this places an object into maintenance and that target can be omitted for the default, which implies the usage context. However, it gives no explicit when-to-use vs when-not guidance and never names the sibling maintenance tools (schedule_maintenance, zabbix_create_maintenance) as alternatives.

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

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

With readOnlyHint=true already covering the safety profile, the description adds real behavior: the return envelope shape and a warning that 'truncated' is measured against the full result set so a capped result must not be treated as complete. It does not mention auth/target permissions or rate limits, 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?

Front-loaded verb+resource in the first line, then return shape, then a structured args list. No filler sentences; the truncation warning and per-arg notes all earn their 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?

There is no output schema, so the description usefully supplies the return envelope and truncation semantics, and it documents all four arguments. Slightly incomplete in that it doesn't describe valid params keys per canned query or behavior when name is unknown.

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 0% schema description coverage, the description carries the burden and mostly succeeds: it explains name comes from swql_library, gives a params example ({"min": 90}), and clarifies target omits for default. The limit line merely repeats the schema default, adding little.

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 (Run) and resource (named canned SWQL query) and gives concrete examples (nodes_down, flapping_interfaces). The 'canned' + 'from swql_library' framing clearly distinguishes it from the sibling swql_query (ad-hoc) and swql_library (catalog).

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

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

Usage is implied rather than stated: the reader infers you run this when a named query exists, and 'name ... from swql_library' routes to the catalog sibling. However, there is no explicit statement of when to prefer this over swql_query or any preconditions/exclusions.

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

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

Annotations already declare readOnlyHint=true, so the safety profile is covered; the description reinforces it with [READ] and discloses the return shape ('name + description'), which matters since there is no output schema. It doesn't cover pagination or ordering, but for a small static list that is minor.

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 the [READ] tag and purpose, then a rationale sentence, then the arg. No wasted prose. The args block is slightly redundant with the schema but stays short.

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

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

For a one-parameter read-only list with no output schema, the description covers purpose, next step, and the single parameter's default behavior. Only ordering/pagination details are absent, which is acceptable at this complexity.

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

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

Schema description coverage is 0%, so the description must carry the load, and it does: 'target: Monitoring target name from config; omit for the default' explains both the source of the value and the null-default behavior. This compensates well for the undocumented 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: 'List the canned-SWQL library (name + description)'. The [READ] tag and the parenthetical clarify both scope and output, making it trivially distinguishable from swql_canned and swql_query.

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

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

Explicitly routes the agent: browse this library, then 'run one with swql_canned instead of hand-writing the query.' It names the alternative tool and the condition that selects it, which is exactly what usage guidance should do.

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 covers the safety profile, and the description usefully adds what annotations do not: row capping, the exact return envelope, and the meaning of the truncated flag with remediation. It stops short of stating rate limits, auth requirements, or per-target behavior, but the added behavioral context is genuine.

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 the [READ] marker and the core constraint, then the return contract, then the Args block. Every element serves a purpose with little filler, though the return-envelope sentence is somewhat dense.

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 steps in to define the return shape and truncation semantics. Combined with the parameter documentation and the read-only constraint, an agent has enough to invoke it correctly; only target-discovery and error behavior 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 description coverage is 0%, so the description carries the full burden, and it does document all four parameters: query as a SWQL SELECT, params as @name named parameters, target as a config name with a default fallback, and limit with its default of 1000. This is meaningful compensation, though it omits format details (e.g. how params values are bound or how target names are discovered).

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: run a validated read-only SWQL SELECT, with the row-capped constraint and the SELECT-only rule. This clearly distinguishes it from write tools. It does not, however, distinguish it from siblings like swql_canned or swql_library, which are alternative query paths, so a 4 rather than 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 read-only SELECT restriction and the note that state changes go through write tools imply when to use it, and the truncation advice ('narrow the query or raise the limit') gives actionable guidance. But there is no explicit comparison against the swql_canned/swql_library siblings for when a prebuilt query is preferable. Usage is implied, 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?

With readOnlyHint already covering the safety profile, the description adds genuinely useful behavior: it discloses the return envelope and warns that a non-null error means the SWQL query failed, explicitly contrasting it with a 'no nodes under load' result. That is a real interpretation hazard the schema and annotations do not surface. It stops short of describing pagination, ordering direction, or how ties 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?

Front-loaded with a [READ] tag and the one-line purpose, followed by return shape, the error caveat, and a compact Args block. The Args section duplicates what a well-documented schema would carry and runs slightly long, but every line is informative and nothing is padded.

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

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

There is no output schema, so the description appropriately documents the return shape inline and flags the error-vs-empty-result ambiguity that matters most for correct reporting. For a 3-parameter read tool this is close to complete; only ordering/tie-breaking and target-name format remain 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 description coverage is 0%, so the description carries the full parameter burden and largely does: metric enumerates the four valid values (an enum the schema itself lacks), n explains the default-10 count semantics, and target explains config-name resolution plus the omit-for-default behavior. Values are documented but format for target (exact config key string) could be sharper.

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 operation ('Top-N ... nodes by a health metric') with the resource (SolarWinds nodes) and the ranking dimension, which distinguishes it from the flat listing siblings like nodes_list and node_status. An agent can tell what it produces (a ranked subset, not a full inventory) 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?

Usage is implied by the ranking concept rather than stated – the agent must infer that this is the tool for 'which nodes are most loaded' versus nodes_list for enumeration. It does mention that omitting target uses the default, a small contextual hint, but there is no explicit when-to-use or when-not-to-use guidance and no sibling 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?

Adds real context beyond the annotations: it flags the [WRITE][risk=medium] profile, explains the inverse is audited through its own governed tool with its own risk_level, discloses the once-only token constraint, and documents the dry_run preview. This is meaningful behavioral disclosure that aligns with (does not contradict) the destructive/non-idempotent hints.

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 the [WRITE][risk=medium] markers and core action, followed by a well-formed Args block. Given the zero schema coverage, the per-parameter lines are justified rather than 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 meta-write tool that fans out to other tools with no output schema and no annotations beyond hints, the description covers purpose, audit behavior, safety preview, idempotency limits, and all params. Return-side and error/failure behavior are not described, though an output schema is absent so this is a modest 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?

With 0% schema description coverage, the description carries the burden and mostly succeeds: undo_id's provenance, dry_run's preview behavior, and target's conditional pass-through are all explained. target's expected format/value is still somewhat vague, leaving a minor 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?

States a precise verb+resource ('Apply a recorded undo') and immediately clarifies the mechanism ('dispatching its inverse tool'). It is cleanly distinguished from its read sibling undo_list, which is named as the source of undo_id rather than a tool to 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?

Gives clear context: where to obtain undo_id (undo_list or an _undo_id from a write result) and when to use dry_run=True (to preview without executing). It stops short of explicit when-not-to-use or alternatives guidance, but the path to correct usage is well laid 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 only supply readOnlyHint=true; the description goes well beyond that by disclosing the return shape, that truncation is *measured* via an extra-row fetch, and that effectVerified=false means the reversed change is only PROBABLE, with a caution to check live state and not over-report. This is meaningful operational context the annotations cannot carry.

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 purpose and the sibling handoff, then structured paragraphs for return value and the effectVerified caveat. Every sentence carries information, though the emphasis on truncation being 'measured, not guessed from a length coincidence' is slightly verbose for the value it adds.

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 present, the description supplies the return JSON shape, the meaning of every field an agent must act on (returned, limit, truncated, effectVerified), and the follow-up behavior for truncation. Nothing needed to call or interpret 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 description coverage is 0% and no param has an enum, so the description must compensate, and it does fully: limit is documented as default 50 / capped at 500, and target is documented as ignored with the reason (host-local undo state, kept for CLI uniformity).

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 recorded, not-yet-applied undo tokens') plus ordering ('most recent first'). The [READ] tag and the reference to undo_apply make it clearly distinguishable from the sibling that actually applies tokens.

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

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

Explicitly routes the agent: 'Use the undoId with undo_apply.' and tells it to re-run with a higher limit when truncated rather than reporting a partial list as complete. It lacks an explicit 'when not to use this' condition, so it falls just short of a 5.

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

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

Annotations already declare write/destructive/non-idempotent, but the description adds real substance: it discloses the actual effect (monitoring masked, not deleted), that the action is reversible via remanage_node, the dry_run preview path, and the mandatory end time. It stops short of mentioning permissions or the masking scope 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?

Front-loaded with the [WRITE][risk=high] flag, then effect and inverse, then args — good structure. Minor redundancy: the dry_run preview is stated twice (once in prose, once in Args) and the remanage inverse is stated twice, but overall it is tight.

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 high-risk write with no output schema, it covers purpose, reversibility, dry_run, required parameters and timestamp format, which is what an agent needs to call it correctly. It omits auth/permission requirements and any note on output or confirmation behavior, a minor gap.

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

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

Schema description coverage is 0%, so the description carries the full burden and does: node_id (Numeric Orion NodeID), start_iso/end_iso (ISO-8601 UTC, end required), dry_run (preview), and target (config target name, omit for default). Nothing essential is left undocumented.

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 ('Unmanage a node') and immediately clarifies the effect ('masks its monitoring'). It explicitly names its inverse (remanage_node), letting an agent place it against siblings like remove_node and schedule_maintenance without opening a schema.

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

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

Provides actionable guidance ('Pass dry_run=True to preview', 'Reversible → remanage', 'no open-ended unmanage') and names the inverse tool. However it never contrasts with scheduling siblings like schedule_maintenance or remove_node, so the agent must infer when this is preferred over those.

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, idempotentHint=false and destructiveHint=true, so the safety profile is largely covered. The description adds a '[WRITE][risk=medium]' tag and the 'lift suppression' semantics, but says nothing about what state changes on resume, whether alert flooding can result, or any permission requirements.

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

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

The purpose is front-loaded in one bracketed sentence, followed by a compact Args block with exactly two entries. Nothing is padded, though the [WRITE] tag partially duplicates readOnlyHint=false.

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, both parameters, value provenance, and defaulting. Annotations carry the safety profile, so remaining gaps (post-resume effects, permissions) 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 description coverage is 0%, so the description must compensate, and it does: both parameters are documented, entity_uri as a 'SWIS entity URI to resume (from list_muted)' and target as a 'SolarWinds target name from config; omit for the default'. Provenance and default behavior are both given, though no URI format example is provided.

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: 'Resume alerts for an entity (lift suppression)' names the action and its effect clearly, and the [WRITE][risk=medium] tag signals the mutation class. It does not explicitly name the inverse sibling mute_alerts, but the behavior is unambiguous enough to distinguish it from list_muted or active_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 rather than stated: entity_uri is annotated '(from list_muted)', which tells the agent where to source the value, and target notes 'omit for the default'. There is no explicit when-to-use vs. when-not-to-use guidance and no alternative tool is 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 declare readOnlyHint=true, so the safety profile is covered. The description adds real behavioral value beyond that: it discloses the unreadableVolumes return bucket and explains that percentUsed: null means unmeasured rather than empty, plus the worst-first ordering — a semantic distinction an agent would otherwise get wrong.

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 the [READ] marker and the core purpose, then adds the return-semantics caveat, then a compact Args block. The Args entries restate schema defaults, but with 0% schema coverage that repetition is doing useful work rather than wasting space.

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 takes on return-value disclosure and covers the notable edge case (unreadable volumes) as well as both parameters. Nothing critical for a correct invocation appears missing, though pagination or result-size behavior is not mentioned.

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 0%, so the description carries the full burden, and it does: min_percent is defined as the minimum percent-used cutoff with default 0 meaning all, and target is defined as a SolarWinds target name from config that can be omitted for the default. Both parameters are fully explained.

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

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

States a specific verb+resource (list volumes), the data source (Orion.Volumes), the filter scope (at/above a fill threshold) and the ordering (worst first). Among siblings like interface_status, node_status and application_status, the resource name makes it unambiguous which domain this covers.

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 threshold framing — you call it to find volumes near capacity — but the description never states when to prefer it over siblings such as topn or noc_rollup, nor any prerequisite. The min_percent=0 default hints at the unfiltered case but no explicit when/when-not guidance is 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 flag this as a non-idempotent destructive write, and the description adds real value on top: a medium risk rating, the mandatory minutes>0 constraint, and the precise reversal path ('the undo deletes exactly the maintenance id this call created'). It does not discuss authentication/permission requirements or rate limits, so it is strong but not exhaustive.

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

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

Front-loaded with the [WRITE][risk=medium] tag and the action, followed by constraints, reversibility, and a compact Args block. Every line is useful 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?

For a 5-param mutation tool with no output schema, the description covers prerequisites, reversibility, and parameter provenance, which is nearly everything an agent needs. It is silent on return payload and permission requirements, which are minor residual 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 0%, so the description carries the full burden and does so: it documents all five params, tells the agent where ids come from (zabbix_hosts, zabbix_hostgroups), and explains the target default ('omit for the default'). This adds meaning the bare schema cannot.

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

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

The description opens with a specific verb and resource ('Create a time-boxed Zabbix maintenance window') and adds a scoping qualifier ('time-boxed') that separates it from an open-ended window or from the sibling zabbix_delete_maintenance / zabbix_maintenances tools. An agent can identify what this 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?

It states clear preconditions for use: minutes must be > 0 (never open-ended) and at least one host or group id is required. It gives strong context for when the call is appropriate but never names an alternative tool or an explicit when-not-to-use case.

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 and non-idempotent, but the description goes further: it states the operation is IRREVERSIBLE with no undo, explains exactly what dry_run returns (the window's full definition), and discloses that the BEFORE definition is captured in priorState. That is meaningful behavioral context an agent cannot derive from the annotations alone.

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?

Risk tag and irreversibility warning are front-loaded, followed by the dry-run contract, the priorState return note, and a tight three-line Args block. No sentence is wasted, and the most consequential fact (no undo) comes before anything else.

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 high-risk destructive tool with no output schema and no parameter documentation in the schema, the description covers risk, reversibility, dry-run preview behavior, where to source the id, and what gets captured on execution. An agent has everything needed to call it safely.

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 0%, so the description carries the full burden and does: maintenance_id is identified as coming from zabbix_maintenances, dry_run is defined as preview-without-deleting, and target is explained as a config target name with omission meaning the default. All three parameters gain semantics absent from 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 ('Delete a Zabbix maintenance window') and scopes it to Zabbix, placing it clearly apart from zabbix_maintenances, zabbix_create_maintenance and the PRTG/SolarWinds maintenance siblings. The risk tag signals impact immediately.

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 a clear usage path: pass dry_run=True to preview before committing, and obtain the id from zabbix_maintenances. It does not explicitly name when to prefer zabbix_create_maintenance versus a maintenance window edit, but the delete context is unambiguous for this 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?

readOnlyHint=true is consistent with the [READ] label, so no contradiction. Beyond the annotation, the description discloses genuinely useful behavior: results are newest-first, 'top' is capped at 500, and a 'truncated: true' flag signals an incomplete result set — non-obvious traits the annotation does not 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?

The description is short and front-loaded, leading with the resource and ordering before the pagination caveat. The boilerplate Args block is slightly redundant with the schema but stays brief and each line 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 and no annotation richness, the description adequately covers the call contract, ordering, and truncation behavior. It stops short of describing what an event record contains, but for a simple read/list tool that gap is 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 description coverage is 0%, so the description must carry the parameter meaning, and it largely does: 'top' is the count (newest first, capped at 500) and 'target' is a Zabbix config target name that may be omitted for the default. It does not document the default value of 50 or the default-target behavior in detail, but the 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?

The description names a specific verb-less but clear resource: the most recent Zabbix trigger events, newest first, and marks it [READ]. It is distinguishable from generic siblings like list_events by naming the Zabbix trigger-event domain, but it never explicitly contrasts with the closest Zabbix siblings such as zabbix_problems or zabbix_triggers.

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

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

It gives a concrete follow-up rule (re-run with a higher 'top' instead of treating a truncated result as the full history), which is real usage guidance. However, it never states when to reach for this tool versus zabbix_problems, zabbix_triggers, or the generic list_events, so routing is left 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?

The readOnlyHint annotation already covers the safety profile, and the '[READ]' tag is redundant with it. The description does add useful disclosure that the result is ids + names rather than full host objects, but says nothing about auth, scope, 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?

Front-loaded and short, with zero filler sentences. The only waste is the redundant '[READ]' prefix already implied by annotations.

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

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

For a single-optional-param read tool with no output schema, the description covers purpose, context, return shape (ids + names), and the parameter. It is adequate, missing only edge details like empty-result 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?

Schema coverage is 0%, so the description must carry the parameter burden, and it does: 'target: Zabbix target name from config; omit for the default' documents both the origin of the value and the default behavior for the single optional param. Remaining gap is only that it doesn't describe valid target-name format.

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 ('Zabbix host groups') and even the payload shape ('ids + names'). This distinguishes it from siblings like zabbix_hosts and zabbix_triggers, though it doesn't explicitly name an alternative. Clear enough that an agent knows what resource it reads.

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 parenthetical 'for inventory and maintenance' implies a use context, but there are no when/when-not rules and no routing to a sibling tool. Usage is implied rather than stated.

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

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

readOnlyHint=true already declares the safety profile, so the '[READ]' marker is largely redundant. The description does add what the result contains (hosts with interfaces and owning groups), which is useful, but says nothing about permissions, pagination, or freshness of the inventory.

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 lines plus a compact Args block; the resource scope is front-loaded before the parameter note. No filler, though the '[READ]' tag duplicates the annotation rather than earning space.

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

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

For a single-parameter read-only inventory call with no output schema, the description covers resource, contents, and the one parameter's behavior adequately. Only the absence of alternatives 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 coverage is 0% and the schema entry for 'target' is a bare anyOf string/null with default null. The description compensates by explaining that target is a 'Zabbix target name from config' and that omitting it selects the default — meaningful semantics the schema does not carry.

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 ('Zabbix hosts with interfaces + owning groups') and an implicit read verb, with '(health inventory)' clarifying the intent. It is distinguishable from siblings like zabbix_hostgroups or zabbix_problems, though the description does not explicitly contrast against 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?

The '[READ]' prefix and 'health inventory' hint at when the tool is appropriate, but there is no explicit when-to-use, when-not-to-use, or named alternative among the many Zabbix and non-Zabbix monitoring siblings. The agent must infer the role from the tool 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?

Annotations only provide readOnlyHint=true, so the description carries most of the burden — and it delivers real behavioral context: the truncated flag, that the returned series is the most recent slice rather than the full window, and the 168h/500 point caps. It doesn't cover auth or rate limits, so not 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?

Front-loaded purpose line followed by a single high-value sentence on truncation semantics and a compact Args block. Given 0% schema coverage, the Args list earns its space; there is no filler.

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

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

For a read-only tool with no output schema, the description explains the shape (meta + history points) and the important truncation caveat. It stops short of describing the exact return structure or pagination, but an agent has enough to call it correctly.

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

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

Schema coverage is 0%, and the description compensates fully: it documents all four parameters including their caps (hours capped at 168, limit capped at 500), the source of item_id, and the meaning of target ('from config; omit for the default'). Every parameter gains meaning beyond the bare 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?

The description states a specific verb and resource: fetch bounded metric detail (meta + history points) for one Zabbix item. The '[READ]' tag and the 'one Zabbix item' scoping clearly separate it from siblings like zabbix_hosts, zabbix_events, and the PRTG equivalents.

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 implies usage by noting item_id comes 'from the host's items', which points the agent at zabbix_hosts first, but there is no explicit when-to-use/when-not guidance or named alternative for retrieving 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 the safe-read profile, so the description only needs to add context. It does add the returned composition ('with their hosts/groups and periods'), but says nothing about pagination, time-range scoping, or empty results for a list 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?

Two tight lines: purpose first, then a single optional-argument note. Nothing is redundant or 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 one-optional-parameter read tool with no output schema, the description covers the resource, the returned structure, and the parameter semantics. Only the absence of filtering/pagination notes 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 0%, so the schema alone gives no meaning for 'target'. The description compensates by explaining it is a Zabbix target name from config and that omitting it selects the default, which is exactly the information an agent needs.

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 (read/list, marked [READ]) and a specific resource (Zabbix maintenance windows), plus what it returns: hosts/groups and periods. It is distinguishable from the zabbix_create_maintenance and zabbix_delete_maintenance siblings, but it never names an alternative explicitly, so it falls short of the top band.

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 [READ] tag and the plural-resource name; there is no explicit guidance on when to call this versus zabbix_create_maintenance, zabbix_delete_maintenance, or zabbix_events. The 'omit for the default' note is the only operational guidance offered.

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 the '[READ]' prefix largely repeats that rather than extending it. It adds the notion of 'current' problems and 'mapped severity levels,' hinting at the return shape, but discloses nothing about pagination, ack state, or result 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?

Purpose is front-loaded in a single clear sentence, followed by a compact Args block. No filler, though the man-page style args list is slightly redundant with the schema's presence.

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 should clarify what is returned; it gestures at problems with severity levels but does not describe fields, ordering, or volume. Adequate for a simple read, but leaves a gap an agent must discover.

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 0%, so the description must carry the load, and it does explain both params: min_severity as 'this Zabbix severity (0-5) or above' and target as a config name with 'omit for default' semantics. It compensates well, though it does not map the 0-5 values to severity names it references.

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: fetching current Zabbix problems (active alerts) with severity mapping. Clear what it does, but it does not differentiate from the sibling active_alerts or zabbix_events, which sound equally applicable to an agent choosing a 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?

No when-to-use guidance, no prerequisites, and no alternatives named. The agent cannot infer from the text alone whether this supersedes active_alerts or zabbix_events, or when min_severity should be raised.

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 a genuine behavioral fact beyond that – that results are filtered to PROBLEM state by default – but says nothing about return shape, pagination, or whether target resolution can fail.

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 the [READ] marker and resource, followed by a compact Args block. No filler sentences; each line adds something. Slightly terse on the resource line, but efficient overall.

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 tool with no output schema, the essentials are present. However, the description does not explain what a trigger record contains or how it relates to the near-identical zabbix_problems sibling, leaving the agent to guess at the boundary.

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 0%, so the description carries the full burden, and it does: only_problems is explained with its default and effect, and target is explained as a config name that can be omitted for the default. Both parameters gain meaning not present in the bare 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?

The [READ] tag supplies the verb and 'Zabbix triggers' names the resource, with the parenthetical 'by default only those currently firing (PROBLEM)' clarifying scope. It is clear what the tool does, but it never distinguishes itself from the sibling zabbix_problems, which appears to cover overlapping ground.

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 or when-not-to-use guidance, and no sibling is named as an alternative (e.g. zabbix_problems vs zabbix_events). The only contextual hint is the default PROBLEM filter, which is stated as behavior rather than as a routing rule.

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