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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), so the description correctly focuses on what annotations cannot convey: that brief prose, user notes and external excerpts are untrusted data and never instructions. That is a genuinely valuable behavioral disclosure. It stops short of describing error behavior or what an ambiguous multi-parameter call returns.

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 content is front-loaded with 'Read one item', but the entire three-mode specification is packed into a single long sentence with nested parentheses, making it hard to parse at a glance. The injected-data warning is well placed as a closing sentence. Restructuring the modes as a short list would earn the same information at lower cognitive cost.

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 retrieval tool with no output schema, the description does enough to cover the retrieval modes, parameter combinations, and prompt-injection safety. What it lacks is completeness around call validity: with all parameters optional, the agent still doesn't know what an empty or over-specified call does, and the different return shapes of the three modes are only named, not characterized.

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?

With 0% schema description coverage and no enums, the description carries the full burden and largely meets it: it maps run_id to a run, run_id+evidence_id to a full source, and company_id-or-ticker+version to a brief version — covering all five parameters and their combinations. It does not clarify precedence when conflicting selectors are supplied (e.g. both run_id and ticker), nor that 'company_id or ticker' means either is acceptable alone.

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?

States a specific verb ('Read one item') and enumerates the three resource shapes it can return: a run with conclusions, a full saved source, or one saved brief version. It distinguishes itself from the sibling list_research by naming that tool's views, but the three modes are crammed into one sentence rather than crisply separated.

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 parenthetical references to 'list_research view=evidence lists its sources' and 'view=versions lists them' imply that enumeration belongs to list_research and single-item retrieval belongs here. However, there is no explicit when-not-to-use guidance, and critically no statement of which parameter combination is required for each mode — with zero required parameters, an agent could call this with an empty object and the description gives no signal about whether that is valid.

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