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

The description goes far beyond the readOnlyHint/destructiveHint annotations. It discloses refusal behavior with failure feedback, render failure handling ('attach render_error and never drop the report JSON'), tier-based restrictions, watermark behavior on free/solo, and the policy of refusing unsupported formats instead of quietly downgrading. This is rich behavioral context that the annotations alone do not provide.

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 front-loaded with the core purpose, then usage triggers, then behavioral details, each sentence earning its place. Despite its length, it is dense with actionable information and has no filler or redundancy.

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 covers the return format ('structured report with findings, citations, and recommendations'), failure modes, tier-specific behavior, error keys, and even the fact that render failures never drop the JSON. With an output schema present and full parameter coverage, this description is complete for the tool's complexity.

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 provides 100% coverage for both parameters, so the baseline is 3. The description adds meaningful behavior around the format parameter: 'branded rendered artifacts as short-lived download URLs', 'sibling render key', and explicit tier consequences. However, there is a slight inconsistency between the schema enum (json/html/pdf) and the description's mention of docx/all, which creates minor ambiguity even though the schema's own description also lists those values. Hence 4 rather than 5.

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 opens with a specific verb and resource: 'Produce the final compliance report from a completed workflow.' It also provides concrete trigger phrases ('generate the gap analysis report', 'I need the DPIA report as a document') that distinguish it from sibling tools like start_workflow or get_workflow_threats. This is a clear, differentiated statement of purpose.

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?

Explicit when-to-use guidance is given via example user requests. It also states preconditions ('from a completed workflow', 'Refuses until every quality gate passes') and an explicit when-not: formats the caller's tier does not serve are refused rather than downgraded. This fully meets the 5-level criteria of explicit when/when-not and alternatives.

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