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

With no annotations provided, the description carries the full burden. It mentions the Annex III template and voluntary nature, but fails to disclose side effects, required permissions, or what happens after submission. It doesn't specify whether the notification is stored, forwarded, or validated, making it insufficient for an agent to anticipate consequences.

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 present purpose and template context with minimal waste. Each sentence contributes necessary information, making it highly concise and 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 tool with 8 parameters, no annotations, no output schema, and no parameter descriptions, the description is too sparse to enable correct invocation. It lacks guidance on required fields, parameter formats, or relationship to sibling notification tools, leaving significant gaps in context.

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 has 8 string parameters with 0% description coverage, and the description provides no parameter-level meaning. It only references the template, which vaguely implies structure but does not explain fields like iocs, ttps, or affected_systems. The low coverage requires compensation that the description does not provide.

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 function as a voluntary notification for significant cyber threats, referencing specific legal context (Art. 19(2)) and a template (ITS 2025/302 Annex III). It distinguishes from sibling tools like initial_notification by emphasizing 'voluntary' and 'threat' rather than incident reporting, though it doesn't explicitly name alternatives.

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 for voluntary threat notifications under Art. 19(2), suggesting it's for non-mandatory reporting. However, it does not explicitly state when not to use it or mention alternative tools like initial_notification or intermediate_report, leaving the when-to-use guidance implicit rather than explicit.

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