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

Annotations already declare readOnly, idempotent, openWorld and non-destructive behavior, but the description adds genuine context: what gets returned (original product evidence, source URL, retrieval time, content hash), the caveat that prepared_response signals reviewability only and not freshness/safety/task completion, and that it carries no account or execution authority. This meaningfully extends the safety profile beyond the structured hints.

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?

It is dense but front-loaded, leading with the action before the mode options, defaults, return payload and caveats. Every sentence conveys distinct information; the only cost is a slightly run-on flow between the mode list and the return/caveat clauses.

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 an output schema present and read-only annotations supplied, the description need not detail return structure or safety, yet it still covers modes, selection formats, the default, and the limits of prepared_response. Nothing an agent needs to invoke it correctly is 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 coverage is 0%, so the description carries the full burden, and it largely delivers: it maps each enum value to a selection format ('institutions, one to five slugs, for example au-sfb'; 'exit, one to four USD sizes, for example 10000,100000') and notes the default for empty input. The 'funding (selection: USD)' phrasing is cryptic about the actual expected format, leaving one mode under-specified.

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 action (run a financial-evidence workflow) and enumerates the three concrete modes (funding, institutions, exit), so an agent knows what the tool produces. However, it frames the purpose by reference to an external product ('the same task as the public Research Desk and REST API') rather than with a self-contained verb+resource, and it does not differentiate itself from the many financial_evidence_* siblings.

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 explains how to choose among the tool's own workflow modes and what an empty selection does, which is implicit usage context. It gives no guidance on when to pick this tool versus sibling tools such as financial_evidence_query, financial_evidence_review or financial_evidence_agent_query, so an agent must infer the routing.

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