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

Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, establishing a safe read-only profile. However, the description adds no additional behavioral context—no details about return format, edge cases, or operational semantics. It simply states the action without exceeding what annotations already provide, so it falls short of the minimum value expected.

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 is front-loaded with the verb and concisely encapsulates the tool's main purpose. Every word contributes to understanding, making it appropriately sized for the information it 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?

This is a relatively complex analytical tool with 6 parameters, no output schema, and many sibling tools. The description is too sparse to provide a complete picture—it omits what the tool returns, how 'outlook' and 'consistency' are quantified, and when an agent should prefer this over other waveguard tools. The lack of an output schema places more burden on the description, which it fails to meet.

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

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

Schema description coverage is 100%, so the baseline is 3. The description mentions 'horizon-specific' and 'windows,' which loosely align with the 'horizons' and 'sequence' parameters, but it does not add substantive meaning beyond the schema's own parameter descriptions. It offers no extra clarification of units, formats, or default behaviors.

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 'Compute' and identifies a clear resource: 'horizon-specific anomaly outlook and consistency across windows.' It distinguishes itself from sibling tools by emphasizing the multi-horizon aspect, which is unique among the listed waveguard tools. Even though it is brief, it conveys the tool's primary function without 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?

The description provides no guidance on when to use this tool versus alternatives. It does not mention any specific context, prerequisites, or exclusions. With 18 sibling tools, some usage direction is essential for an agent to select the correct tool, but none is given.

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