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

With no annotations provided, the description carries the full burden of behavioral disclosure. It explains what the response covers and how the include parameter changes the returned sections, which is useful, but it does not explicitly state that the operation is read-only or describe error behavior, pagination, or access 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 description is two sentences, front-loaded with the main action and resource, and includes a practical hint about where to find channel IDs. Every sentence earns its place with no filler.

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

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

For a simple two-parameter getter with no output schema, the description adequately covers what will be returned, how to identify a channel, and how to request additional sections. It could be more explicit about read-only semantics or failure cases, but the core invocation context is 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?

The input schema already describes both parameters with 100% coverage. The description adds a little extra meaning by explaining that IDs come from other tool results and mentioning 'additional settings sections', but it does not substantially go beyond the schema.

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

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

The description clearly identifies the verb ('Get'), the resource ('metrics and settings of a single channel on a sensor by ID'), and the main fields returned ('units, limits, current value'). It does not explicitly contrast with sibling tools, but the channel-level scope is distinctive enough to separate it from the other getters.

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 useful context by stating that channel IDs come from prtg_get_sensor_data and prtg_get_sensor results, which tells the agent where to obtain the required id. It does not explicitly list exclusions or alternative tools, but the source hint effectively implies the proper workflow.

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?

No annotations are provided, so the description carries the full burden. It says 'Get', which suggests a read operation, but it does not explicitly confirm read-only behavior, describe error handling for invalid IDs, mention rate limits, or any side effects. The description is too terse to disclose much beyond the core action.

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 a single, compact sentence with the key action front-loaded. There is no fluff, and every word contributes to stating the purpose. This is exemplary conciseness.

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 annotations, the description must provide enough context for an agent to invoke it correctly. It omits any hint about the return format, potential errors, or how 'metrics and settings' are structured. Given the tool's simplicity, some information is inferable, but the description is incomplete for a production-grade tool.

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

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

The input schema fully documents both parameters (id and include) with clear descriptions, achieving 100% coverage. The tool description adds no additional meaning beyond what the schema provides, so it meets the baseline for a schema-covered case.

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

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

The description states a specific verb ('Get'), a specific resource ('metrics and settings of a single device'), and the key identifier ('by ID'). This clearly distinguishes it from list tools like prtg_list_devices and other get tools targeting different resource types (group, probe, sensor).

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

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

The description implies usage when you have a device ID, and the schema notes the ID comes from prtg_list_devices, but it does not explicitly state when to use this tool versus siblings or provide any exclusions. No alternative tools are named in the description.

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 no annotations, the description carries the burden of signaling behavior. 'Get' strongly implies a read-only, non-mutating operation, and the description names the returned content ('metrics and settings'). It does not disclose auth requirements, error behavior, or response structure, but for a simple by-ID fetch this is a moderate rather than severe gap.

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

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

The description is a single sentence with no filler or repetition. It front-loads the operation, resource, and identifier constraint, which is exactly as concise and structurally efficient as a simple tool description needs to be.

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

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

For a simple two-parameter retrieval tool, the description plus fully covered input schema is nearly complete: it states what the tool returns, requires an ID, and makes the include option available. It is slightly incomplete because there is no output schema and the description does not enumerate default metrics/settings or explicitly route the user to prtg_list_groups for IDs.

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

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

Schema description coverage is 100%, so the baseline is 3 even though the description adds little parameter-level detail. The description's mention of 'metrics and settings' hints at what the `include` parameter might control, but the schema already documents both parameters adequately.

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

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

The description uses a specific verb ('Get') and a specific resource ('metrics and settings of a single group by ID'), making the tool's function immediately clear. It also distinguishes this tool from sibling list tools and other get tools by naming 'group' as the target resource.

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 'single group by ID' implies the intended use case: retrieving details for one known group rather than listing groups. However, there is no explicit guidance about when to use this tool versus prtg_list_groups or other get_* siblings, and no mention of the prerequisite that the ID typically comes from prtg_list_groups.

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 no annotations, the description carries the full burden. The verb 'Get' conveys read-only intent and the summary scope is stated, but the description does not disclose what the summary contains, whether it aggregates across child objects, or what happens for invalid IDs. No contradictions exist.

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

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

A single front-loaded sentence with no filler. Every word contributes meaning: action, resource, and scope.

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, the description is mostly adequate, but with no output schema and no annotations, it does not explain what a sensor-state summary looks like or how it differs from the similarly named prtg_get_sensor_status_summary. An agent could still call it correctly, but with some ambiguity.

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

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

Schema description coverage is 100% and the id parameter is well-documented with its source listing functions. The description itself adds no parameter detail, so the baseline 3 applies.

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

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

The description clearly identifies a specific verb and resource: get a sensor-state summary scoped to a probe, group, or device. It distinguishes itself from most siblings by naming the object scope, though it does not explicitly contrast with prtg_get_sensor_status_summary, which sounds very similar.

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 scope phrase 'scoped to one probe, group, or device' implies the appropriate context, and the id parameter description indicates source tools. However, there is no explicit guidance on when to choose this over prtg_get_sensor_status_summary or prtg_get_sensor_data, nor any 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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It conveys that the operation is a read ('Get'), but it does not disclose response format, error behavior, permission requirements, or how the 'include' parameter affects the result.

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 a single focused sentence with no filler. It front-loads the core action and resource, and every word contributes 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 getter with a fully documented schema, the description is mostly complete: it states the operation, resource, and ID mechanism. The lack of an output schema and minimal return-format detail leave a small gap, but the tool's simplicity keeps this from being a major issue.

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

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

Schema description coverage is 100%, so the schema already documents both the id and include parameters. The description adds only high-level meaning ('metrics and settings') and does not provide additional parameter-level detail beyond what the schema already states.

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

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

The description uses a specific verb ('Get'), a clear resource ('metrics and settings of a single probe'), and a precise selection criterion ('by ID'). It clearly distinguishes this from sibling list tools like prtg_list_probes and from prtg_get_probe_network_info.

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

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

The description does not explicitly state when to use this tool versus a sibling such as prtg_get_probe_network_info. However, the schema provides helpful context by stating that the id comes from prtg_list_probes, implying a list-then-get workflow.

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 no annotations provided, the description must carry the full burden of behavioral disclosure. It implies a read-only operation ('Get') but does not explicitly state that it is safe or non-mutating, nor does it describe error behavior, authentication requirements, or the exact format of the returned data. The description adds minimal behavioral context beyond what the name and title already imply.

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 a single sentence that is both concise and informative. It front-loads the core action and resource, then adds a clarifying parenthetical that enriches meaning without padding. There is no wasted wording or unnecessary detail.

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

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

For a simple one-parameter read tool with no output schema, the description gives a reasonable hint of the returned data ('connectivity details') but remains vague about the structure or content of the response. It doesn't specify whether the result is a status, a list, or a detailed report, leaving some ambiguity for the agent. However, given the tool's simplicity, this level of completeness is borderline adequate, scoring 3.

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

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

The input schema provides 100% coverage for the single parameter, with a clear description ('Probe ID (from prtg_list_probes)') that adds provenance. The tool description itself does not elaborate on parameters, but the schema already fully documents the parameter, so the description doesn't need to compensate. Baseline 3 applies given high schema coverage.

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

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

The description clearly states the action ('Get') and the resource ('network information for a probe'), with a clarifying parenthetical that specifies it's the probe host's own connectivity details. This distinguishes it from sibling tools like prtg_get_probe, which likely returns general probe configuration, making the purpose 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?

The description provides no guidance on when to use this tool over its siblings, such as prtg_get_probe. It doesn't mention alternatives or indicate situations where this tool is preferred (e.g., when you need connectivity details rather than general probe info). The absence of any usage context leaves the agent to infer the appropriate scenario.

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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. 'Get' implies a read operation, but the description does not state what the response contains beyond 'metrics and settings', whether the include parameter changes the payload, or how errors and permissions behave. It is minimally informative but not misleading.

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 a single, efficient sentence with no filler. The key resource, action, and selection criterion are front-loaded, and every word 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 two-parameter read operation with fully documented schema, the description adequately states what the tool returns and how the sensor is identified. It lacks explicit guidance about choosing among sibling tools, but the essential invocation information is present.

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

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

The schema already documents both parameters with descriptions and examples at 100% coverage. The description only reiterates the 'by ID' concept and adds no additional semantic meaning beyond the schema, so the baseline 3 applies.

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

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

The description uses a specific verb ('Get'), names the resource ('metrics and settings of a single sensor'), and specifies the selection method ('by ID'). It is clear, but it does not distinguish this from the sibling prtg_get_sensor_data, whose name suggests it also returns sensor metrics, so the description lacks sibling differentiation.

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 guidance on when to use this tool versus prtg_get_sensor_data, prtg_get_sensor_status_summary, or prtg_list_sensors. The schema mentions that the ID comes from list tools, but the description itself does not state any usage context, exclusions, or 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 no annotations, the description carries the full burden. 'Get ... history' conveys a read-only, time-series-oriented behavior, and 'actual monitoring/performance data' clarifies what is returned. However, it does not describe the response structure, whether multiple channels are included, or any constraints beyond what the schema already states.

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 a single well-structured sentence with no filler. It front-loads the core purpose and adds a clarifying parenthetical that helps distinguish it from sibling tools.

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

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

The schema fully documents parameters, and the description clarifies the tool's purpose. However, with no output schema and no explicit guidance about when to use this versus related sensor/channel tools, the description leaves moderate gaps for an agent deciding whether to invoke it.

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

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

The input schema has 100% description coverage for all five parameters, so the description does not need to add parameter details. The description adds no extra meaning beyond the schema, which meets the baseline for full schema coverage.

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

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

The description states a specific action and resource: 'Get channel measurement history ... for a sensor.' The parenthetical 'the actual monitoring/performance data' clarifies that this returns measured data rather than sensor metadata, which distinguishes it from siblings like prtg_get_sensor.

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 'actual monitoring/performance data' implies this tool should be used when historical measurements are needed, but the description does not explicitly state when to prefer this over related tools such as prtg_get_sensor_status_summary or prtg_get_channel. No alternatives or exclusions are 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?

No annotations are provided, so the description carries the full behavioral burden. It discloses that the tool returns aggregate counts by status and is scoped to the entire instance, implying a read-only summary operation. However, it does not mention the exact status set, output shape, authentication needs, or any operational constraints.

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 sentence with no filler. It front-loads the action, specifies the scope, and gives concrete examples of the statuses included. Every part 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 zero-parameter aggregation tool, the description is largely complete: it states what is returned, the scope, and the kind of breakdown. It does not enumerate every possible status or the response container, but those are minor gaps for selecting and invoking this tool.

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

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

The tool has zero parameters, so the baseline of 4 applies. There are no parameter semantics to clarify, and the description adds meaning about the result being status count summaries.

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 ('Get a summary') and a precise resource: all sensor states with counts by status. The phrase 'across the whole PRTG instance' clearly distinguishes it from per-object or per-group summary tools like prtg_get_object_sensor_summary.

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

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

The instance-wide wording implies an overview use case, but the description does not explicitly state when to choose this tool over siblings such as prtg_get_object_sensor_summary or prtg_list_sensors. There are no alternatives or exclusions mentioned, leaving routing 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?

No annotations are provided, so the description carries the burden. It describes the tool as a sanity check for credentials and connectivity, implying it is a read-only diagnostic call. This gives the agent useful behavioral context without needing to guess side effects.

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

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

Two short sentences, with the primary action stated first and an additional usage hint second. No filler or redundant content.

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

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

For a zero-parameter, no-output-schema tool, the description tells the agent what the tool returns conceptually (the version) and why to use it. It is sufficient for correct invocation.

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

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

The input schema has no parameters, so there is nothing to explain. Baseline 4 applies.

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

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

States a specific verb and resource: getting the PRTG core server and appserver version. This clearly distinguishes it from sibling tools that handle groups, devices, probes, sensors, or summaries. No ambiguity.

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 an explicit use case as a quick credential/connectivity sanity check. This tells an agent why it would call this tool before others. It doesn't spell out when not to use it, but the context is clear.

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 no annotations provided, the description carries the burden of behavioral disclosure. It conveys that the tool returns only sensors in alarm states and frames it as a health/alerting query, but it does not state read-only behavior, pagination behavior, or any side effects. This is adequate but not rich.

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

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

Two short sentences convey the core purpose and the intended use case with no filler. The key scoping detail ('currently in an alarm state') is front-loaded, and every word 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-style list tool, the description covers the core selection criterion and use case, and the schema covers all parameters. However, with no output schema and no annotations, the agent is left without guidance on return shape, default pagination behavior, or how the filter interacts with the listed alarm states.

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

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

Schema description coverage is 100%, so the schema already fully documents all five parameters. The description adds only the high-level notion of filtering by alarm state, which does not meaningfully deepen parameter understanding beyond what the schema provides.

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

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

The description names a specific verb (List), a specific resource (sensors), and a specific condition (currently in Down/Warning/Unusual/etc. alarm state). This clearly separates it from the generic prtg_list_sensors sibling and tells the agent exactly what the tool surfaces.

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 'PRTG's alerting surface - use this to find what's currently wrong' gives clear situational context: this is the tool for discovering active problems. It does not explicitly name the alternative prtg_list_sensors or state when not to use it, 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?

There are no annotations, so the description carries the behavioral disclosure burden. It does disclose useful behavioral context: the returned device objects include hostname/IP, status, parent group/probe, and the `id` is the linkage key to downstream tools. It stops short of noting read-only safety explicitly, pagination behavior, or response shape beyond those fields, though the schema covers limit/offset details.

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

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

Two sentences with no filler. The first sentence front-loads the core purpose and output fields; the second sentence adds actionable chaining guidance. Every clause earns its place.

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

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

For a read-only list tool with five optional, fully documented parameters, the description is largely complete: it states what is returned, names the key field (`id`), and points to the natural next tools. The only real gap is the absence of explicit guidance on when to use this tool instead of sibling list tools, which is minor given the self-explanatory resource names.

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

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

Schema description coverage is 100%, so the schema already documents all five parameters. The description adds no parameter-level semantics of its own; 'filter by parent' refers to prtg_list_sensors, not the `filter` parameter of this tool. Baseline 3 is appropriate because the schema does the heavy lifting.

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

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

The description clearly states the tool's action and resource: 'List monitored devices' and even previews the relevant fields (hostname/IP, status, parent group/probe). It does not explicitly contrast itself against siblings like prtg_list_sensors or prtg_list_groups, but the device-specific language and the mention of chaining into prtg_get_device and prtg_list_sensors make the distinction reasonably apparent.

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 second sentence gives implied usage guidance: after listing devices, an agent should use each device's `id` to chain into prtg_get_device, prtg_list_sensors, and prtg_get_object_sensor_summary. However, it does not state when to choose this tool over alternatives such as prtg_list_groups or prtg_list_probes, nor does it give exclusions or when-not-to-use conditions.

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

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

No annotations are provided, so the description carries the burden of behavioral disclosure. The verb 'List' implies a read-only operation, and the id-chaining note adds useful workflow behavior. However, it does not describe the return shape, pagination behavior, or any access/rate considerations beyond what the schema already implies.

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

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

The description is two tight, purposeful sentences. The first defines the tool's purpose and resource; the second explains how its output links to downstream tools. There is no filler, redundancy, or restatement of the tool name.

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

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

For a simple list operation with a fully documented schema, the description covers scope and downstream usage well. The main gap is the absence of an output schema and no explicit statement of what a returned group object contains, though the id-chaining note partially compensates.

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

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

The input schema already documents all four parameters with explicit descriptions, so schema coverage is 100%. The description adds no parameter-specific detail beyond that, but none is necessary because the schema fully carries the parameter semantics.

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

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

The description uses a specific verb and resource: 'List groups', and clarifies that groups are 'organizational folders that contain devices.' This distinguishes it from sibling tools like prtg_list_devices, prtg_list_probes, and prtg_list_sensors. The follow-up note about `id` chaining into prtg_get_group and prtg_get_object_sensor_summary further clarifies the tool's role.

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 definition makes clear that this tool is for enumerating groups, and that each returned group's id is the input for detail/summary tools. It does not explicitly state 'use this instead of prtg_list_devices', but the resource definition is distinct enough that an agent can infer when this tool applies.

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

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

No annotations are present, so the description carries the full burden. 'List' signals a read-only enumeration, and the note about probe ids implies the returned objects include an id field. It does not disclose pagination behavior, default limits, or any access requirements, but it is not misleading or contradictory.

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 tightly-written sentences earn their place: the first defines the resource being listed, and the second states the chaining relationship to related tools. There is no filler or redundant schema restatement.

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 list tool with fully documented parameters and no output schema, the description is sufficient. It explains the entity, the probe id's downstream value, and does not omit anything needed to invoke the tool correctly. An explicit alternative to prtg_get_probe would improve it, but it is not critical.

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

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

Schema description coverage is 100%, meaning all four parameters (limit, filter, offset, sort_by) are already documented in the input schema. The description adds no parameter-specific meaning, so the baseline score of 3 is appropriate.

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

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

The description clearly states the operation ('List') and the resource ('probes'), and adds a helpful definition of what probes are. It also mentions that probe ids chain into other tools, which situates this tool among siblings, but it stops short of explicitly contrasting it with prtg_get_probe for single-object retrieval.

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 chaining sentence implies when to use this tool: obtain probe ids first, then feed them into prtg_get_probe, prtg_get_probe_network_info, or prtg_get_object_sensor_summary. However, there is no explicit statement of when not to use it or which sibling alternative to choose instead.

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

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

With no annotations, the description carries the behavioral burden. It discloses that the response includes each sensor's current status and that the returned id is a key for follow-up calls. It does not describe pagination or rate limits, but the schema documents limit/offset behavior, and 'list' clearly signals a read operation.

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

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

Two sentences with no filler. The first defines the tool and its output scope, and the second gives the key integration detail for follow-up calls. The most important information is front-loaded.

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

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

The description is largely complete for a simple collection-list tool: it explains the resource, status return, and downstream id usage. There is no output schema, so the mention of id and status partially compensates, though a bit more detail about the result shape or explicit device-scoping behavior would make it fully complete.

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

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

Schema description coverage is 100%, so the parameters are already well documented. The description adds no parameter-level meaning beyond the schema; its id-chaining note is about output/usage rather than parameters, which is acceptable but not extra param semantics.

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

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

The description names a specific verb and resource: 'List sensors' and clarifies what sensors are ('individual checks - ping, HTTP, SNMP, etc. - attached to a device'). It also connects to sibling tools by explaining that each sensor's id feeds into prtg_get_sensor and prtg_get_sensor_data, which separates this list operation from detail/get operations.

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

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

The description gives clear context: if you need the individual checks on a device and their current status, this is the tool. The mention that ids chain into prtg_get_sensor and prtg_get_sensor_data implies the intended downstream usage, though it does not explicitly state when to prefer list_devices or when not to use this tool.

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