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

Annotations already declare readOnly/idempotent/openWorld/non-destructive, so safety is covered. The description adds non-obvious behavior: it searches only 'geschützte' (protected) assets, implying unprotected devices are excluded, and it discloses what is returned (device, client, backup status) — both are useful context beyond the 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?

A single dense sentence that front-loads the action, the search key and the scope before the return payload. Nothing is wasted, though the German title largely restates it.

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

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

With no output schema, the description usefully states the returned fields (device, client, backup status), and annotations cover the safety profile. Gaps remain on result cardinality (multiple matches), pagination/limits, and the precise meaning of 'geschützt'.

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

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

Schema description coverage is 100%, so all three parameters are already documented, including that hostname is a substring match and includeHidden defaults to false. The description only echoes the hostname/FQDN lookup and the fleet-wide scope, adding no format or matching semantics beyond the schema.

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

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

Names a specific verb (search) plus the resource (protected server/agent/share), the lookup key (hostname/FQDN), the scope (all devices), and even the return payload (device, client, backup status). It is distinguishable from get-device (single) and list-device-assets, though it never names a sibling explicitly.

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

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

Usage is implied by the lookup key and fleet-wide scope, but there is no explicit when-to-use versus when-not, and no guidance on preferring list-devices/get-device or on what happens when the hostname matches multiple assets. Adequate but leaves 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?

Annotations already cover the safety profile (readOnly, idempotent, non-destructive), so the description is free to add substantive behavior: it returns ONLY problem cases, skips archived agents, splits findings into critical vs warning, and states the default thresholds. That is real operational context beyond the annotations, though it omits things like result format or performance/rate considerations.

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, then the critical conditions, the warning conditions, the skipping rule, and the defaults in a logical order. It is dense and long, but nearly every clause carries distinct information; only minor tightening would be possible.

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

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

With no output schema, the description carries the return-value burden and does so by enumerating the finding categories and the 'only problem cases' behavior. Given 11 optional parameters and no required ones, plus the threshold defaults provided, an agent has enough to call it correctly, though it never describes how findings are grouped or returned.

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 low (45%), so the description must compensate, and it does: it supplies the defaults for snapshot (24 h), offsite (48 h), screenshot (7 d), offline (1 h), storage (85 %) and service contract (30 d), effectively documenting the six numeric parameters that have no schema description. This is exactly the parameter meaning the schema 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 and resource: it checks all devices/agents against thresholds and returns only problem cases, then enumerates the exact critical and warning conditions. This is precise and self-contained, but it never names or contrasts with overlapping siblings such as get-screenshot-failures or list-alerts, so the agent must infer the boundary itself.

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 scope ('alle Geräte', 'NUR Problemfälle') and by the list of conditions, which tells the agent when a device will surface. However, there is no explicit when-to-use vs when-not guidance and no alternative tool named, so selection against list-alerts or get-screenshot-failures 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?

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and non-destructive, so the safety profile is covered. The description adds real behavioral context beyond that: it discloses what the rollup aggregates, that severity counts and a traffic-light status are computed, and that threshold semantics are inherited from get-backup-health-summary, which warns the agent that results will be consistent with that sibling.

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 well-formed sentences, front-loaded with the aggregation content and followed by intended-use cases and a threshold note. Dense but every clause carries information; slightly long enumeration keeps it from a 5.

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

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

No output schema exists, so the description must convey the return shape, and it does by enumerating the rollup fields. Combined with annotations covering the read-only/idempotent profile and full schema coverage on inputs, an agent has enough to call it correctly; only explicit precedence rules vs. get-backup-health-summary are missing.

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

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

Schema description coverage is 100%, so both parameters (client substring filter, includeHidden with its default) are already fully documented in the schema. The description adds no additional parameter semantics beyond what the schema provides, which is the baseline 3 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 gives a specific verb-equivalent (Rollup) plus the exact resource (Kunde) and enumerates the returned facets: Geräte online/offline, geschützte Agents/Shares, kritische und Warn-Befunde, Ampelstatus. It also implicitly separates itself from the global sibling by noting it shares thresholds with get-backup-health-summary, so an agent can tell the per-client rollup apart from the portfolio-level 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?

Concrete use cases are named ('Monatsreports, QBRs, wie steht Kunde X da?'), which gives the agent a clear context for invocation. It references get-backup-health-summary, but only to note shared thresholds rather than to state explicitly when to prefer that sibling over this one, so the when-not guidance is implied rather than spelled out.

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

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

Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so the safety profile is covered. The description adds useful context about what data is returned (local/offsite storage, warranty, region), but says nothing about auth requirements, freshness of the online status, or error behavior for unknown serials.

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 naming the resource first and the returned fields after. No filler, no repetition of the title.

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

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

With no output schema, the description carries the return-value burden and does list the key fields, which is genuinely helpful. It is slightly incomplete in not explaining the 'CLDSIRIS' region notation or handling of invalid serials, but it is adequate for a single-record 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 100% and the sole parameter (serial) is documented in the schema with an example source. The description adds no additional meaning about the serial format or where it comes from, 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 states the resource (Gerät) and enumerates the specific fields returned (Modell, Kunde, Online-Status, Speicherbelegung, Region, Garantie), which is more informative than a bare 'get'. However, it never contrasts itself with siblings like list-devices or find-asset, so an agent has to infer that this is a single-record fetch by serial.

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 is given: nothing says this is the lookup for one device by serial, nor points to list-devices/find-asset as alternatives. The only hint ('z. B. aus list-devices') lives in the schema parameter description, not the tool 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?

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint, so the safety profile is covered. The description adds value beyond that by noting it returns the *last* screenshot (latest only) and that the response includes the image plus status, which matters given no output schema exists.

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

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

Two front-loaded sentences with the action first and the diagnostic rationale second. The parenthetical symptom list is slightly verbose but earns its place by helping the agent recognize the failure scenarios the image depicts.

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-parameter tool with full schema coverage and annotations, the description covers purpose, scope (latest image) and return content. The main remaining gap is disambiguation from get-screenshot-failures, which is left unaddressed.

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

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

Schema description coverage is 100%, so both parameters (serial, asset) are already documented in the schema, including the substring-matching hint. The description adds no syntax or format detail beyond the schema, so the baseline of 3 applies.

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

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

States a specific verb (Lädt) and resource (letztes Screenshot-Verification-Bild eines Agents) and explains the diagnostic intent (warum der Boot-Test fehlschlug). It is clear on its own, but it does not distinguish itself from the very close sibling get-screenshot-failures, which an agent could easily confuse it with.

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

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

The description implies the usage context (diagnosing a failed boot test) and lists failure symptoms, but it never states when to use this tool versus get-screenshot-failures or the other diagnostic siblings. The routing decision 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?

Annotations already declare readOnly, idempotent, non-destructive, openWorld behavior. The description adds genuinely new semantics by defining what counts as 'failed' — the last attempt or backups within the period — which the annotations do not cover. It does not describe result volume or ordering, but the failure criterion is meaningful added 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?

A single, tightly-worded sentence with no filler, front-loading the result set before the qualifying definition. Efficient, though the parenthetical definition 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?

For a read-only query tool with full schema coverage and no output schema, the description states the returned entity type and the failure criterion, which is close to adequate. It is silent on result shape, ordering, or pagination, leaving minor gaps.

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

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

Schema description coverage is 100%, so all three parameters (days, client, includeHidden) are already documented in the schema. The description only references the 'letzten X Tagen' window and adds no syntax or format detail beyond it. Baseline 3 applies.

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

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

The description names a specific result set — agents whose screenshot verification failed — which is clearly distinct from siblings like get-screenshot (retrieves a screenshot) or get-backup-health-summary. It is a noun phrase rather than a verb+resource statement, but the scope is unambiguous. No explicit sibling differentiation is provided.

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

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

There is no when-to-use guidance, no mention of alternatives (e.g. list-alerts or get-backup-health-summary), and no prerequisites or exclusions. The agent must infer the invocation context entirely.

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

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

Annotations already cover the safety profile (readOnlyHint, idempotentHint, destructiveHint=false), so the bar is lower. The description adds real behavioral context beyond them: without a serial the entire fleet is scanned and only devices with active restores are returned, clarifying the filtering semantics of the call.

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

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

Two tight sentences, front-loaded with what the tool returns before the scoping rule. No filler, though it is terse enough that it could say a bit more about the includeHidden/client interplay.

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 fully documented parameters and no output schema, the description covers purpose, the serial-absent filtering rule, and result scope. It stops short of describing the shape of returned items or pagination, which is a minor gap given annotations already carry the safety profile.

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

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

Schema coverage is 100%, so baseline is 3, but the description goes further by explaining the default fleet-wide behavior when `serial` is omitted — meaning that is not captured by the schema itself. This adds genuine parameter-level value for the serial argument.

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 resource — running VM restores/virtualizations ("Laufende VM-Restores/Virtualisierungen") — which is a distinct concept from sibling listings like list-devices or list-alerts. It is clear what the tool enumerates, though it does not explicitly name any sibling it is not, leaving differentiation implicit.

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 note that omitting the serial checks the whole fleet hints at the narrow-vs-broad query modes, but there is no explicit guidance on when to reach for this tool over alternatives such as get-backup-health-summary or list-devices.

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, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds meaningful behavioral context beyond that: only non-cleared alerts are returned, and the fleet-wide mode returns only devices that actually have alerts. It stops short of describing ordering or return shape, but the extra semantics are real.

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

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

Two compact sentences, front-loaded with the resource and scope before the parameter-conditional behavior. No filler or repetition.

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

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

For a read-only list tool with no output schema, the description covers the resource scope and the serial/no-serial behavior sufficiently. It does not mention the client or includeHidden filters, but those are fully documented in the schema, so the 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 coverage is 100%, so the baseline is 3. The description goes beyond the schema by clarifying what happens when serial is omitted (fleet-wide, devices with alerts only), which the schema's per-parameter text does not state. This adds genuine meaning for how the optional parameters interact.

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

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

States a clear verb (list) and resource (alerts) scoped to active/not-cleared ones, which distinguishes it from siblings like list-devices or get-device. However, it does not explicitly differentiate itself from related alert/failure tools such as get-screenshot-failures, so sibling routing relies on 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 explains the conditional behavior (with serial = one device, without = fleet-wide), which is useful context. But it gives no guidance on when to prefer this over sibling tools (e.g., get-screenshot-failures or get-backup-health-summary), so alternative-selection guidance is implied at best.

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, idempotentHint and destructiveHint=false, so the safety profile is covered. The description earns credit by disclosing what the call returns (last snapshot, offsite sync, screenshot verification, last backup status) — the only place that payload is described since there is no output schema. It omits auth requirements, pagination and scale caveats.

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 that identifies the subject first and the returned fields after. Nothing is wasted, though the enumerated return fields make it slightly 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 is the sole source of return-value information and it supplies it at a useful summary level; parameters are fully covered by the schema and safety by the annotations. Only minor gaps remain, such as result volume or pagination behavior for a device with many shares.

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

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

Schema description coverage is 100%, with both 'serial' and the 'name' substring filter documented inline, so the baseline is 3. The description adds no extra meaning about the parameters (e.g. that 'serial' must come from list-devices), so it does not exceed the baseline.

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

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

Names a specific resource ('geschützte Agents und Shares eines Geräts') and enumerates the data returned (letzter Snapshot, Offsite-Sync, Screenshot-Verification, Backup-Status), which clearly separates it from list-devices or get-device. It does not explicitly name a sibling, but the resource+scope combination 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 tool versus get-device, list-devices, or find-asset. The only routing hint ('z. B. aus list-devices') lives in the schema, not the description, so the description itself offers no guidance or 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?

The annotations already declare readOnlyHint=true, idempotentHint=true, openWorldHint=true, and destructiveHint=false, so safety behavior is covered. The description adds the returned data fields, which is useful context beyond the annotations, but it does not describe pagination, freshness guarantees, authentication needs, or what 'offene Alerts' means operationally. With annotations carrying the safety profile, a 3 is appropriate.

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

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

The description is a single, well-structured sentence with no wasted words. The main action and the key returned fields are 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 read-only list tool with complete parameter descriptions and safety annotations, the description is nearly complete: it explains the resource scope and the summary columns returned, compensating for the absence of an output schema. It is only held back by not mentioning filtering behavior or routing guidance relative to sibling tools.

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 four filter parameters with examples and defaults. The description adds no additional parameter semantics, and per the calibration baseline, 3 is correct when 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 gives a specific verb and resource ('Listet alle BCDR-Geräte') and enumerates the returned fields (Kunde, Modell, Online-Status, Agent-/Share-Anzahl, offene Alerts), so an agent can tell this is a summary-listing tool rather than a detail-getter or asset-list tool. It also names the supported device families (SIRIS, ALTO, CLDSIRIS), which sharpens scope.

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 states what the tool returns but gives no guidance on when to use it versus siblings such as get-device, find-asset, or list-device-assets. It also does not mention the available filters (model, client, onlyOffline, includeHidden) as usage conditions, so the agent must infer when this is the right call.

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