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

Annotations already declare readOnlyHint=true, so the bare 'Read-only' adds nothing, but the description contributes real semantics beyond annotations: the meaning of protection_state=unknown ('Ankra could not establish it, NOT that the stack is unprotected'), the availability precondition, and the shape of what scope=stack returns. Pagination or result-size behavior is not disclosed, but with no output schema the tool is still well characterised.

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 answer-oriented purpose is front-loaded and the scope/state semantics follow in a logical order with no filler sentences. The phrasing is densely packed and the aside about being 'the twin of the Backups posture the portal renders' is low-value for an agent, costing a top score.

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

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

For a read-only query tool with four fully documented parameters, no output schema to explain, and annotations covering the safety profile, the description supplies everything needed: purpose, scope semantics, scope derivation default, the unknown-state caveat, and the availability condition. No material gap remains for correct invocation.

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

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

Schema description coverage is 100%, so the schema already carries the parameter contract and the baseline would be 3. The description adds genuine meaning beyond it by explaining what each scope value semantically returns (fleet rollup with vault counts, every stack on one cluster, one stack's protection state/schedule/vault/last restore point/failing runs), which helps an agent pick a scope value rather than just pass it.

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 opening clause states a precise verb+resource ('Answer whether data is protected, and if not why not') and the description then fans that out into three explicitly named scopes, each with what it reports. An agent can tell this apart from sibling backup tools like get_backup_vault, list_backup_vaults and get_restore_point 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?

It gives explicit routing guidance for scope selection ('Omit to derive it: a stack_name means the stack... neither means the whole organisation') and the non-obvious case of passing organisation explicitly from inside a cluster-bound conversation. It also states the availability gate: only offered when backups are enabled for the organisation. It stops short of naming alternative tools to use instead when backups are not enabled.

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