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

Annotations already declare a read-only, open-world, non-destructive call, so the description isn't needed for the safety profile. It adds genuinely non-obvious behavior: latest snapshot only, no point-in-time semantics, restatements/recasts served under the as-of citation, and that LOOK-AHEAD flags cover only later amendments of a period's own filing. The restatement caveat is valuable but dense and partly framed around sibling tools rather than this one's response.

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 lead sentence and the 'Includes:' block are well front-loaded and scannable. The third paragraph, however, spends substantial length on restatement/look-ahead mechanics and on how to pin get_xbrl_facts to an accession_number — guidance about other tools that dilutes this tool's core message.

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?

There is no output schema, but the 'Includes:' enumeration effectively describes the return payload field-group by field-group (valuation, profitability, cash flow, balance sheet, capital allocation, segment mix, earnings insights, flags). Combined with the scope and time-boundary caveats, an agent has everything needed to call it correctly.

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 100% and the `depth` enum already carries detailed preset semantics, so the schema does the heavy lifting. The description never mentions `depth` at all, even though the response shape varies by ~2K vs ~9K+ chars — that is the one parameter where a hint would have helped. Baseline 3 for a fully documented schema.

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 and resource (a one-call snapshot of price, valuation, margins, cash flow, balance sheet, segments) and enumerates exactly what is included. It explicitly distinguishes itself from get_financials, get_metric_history, and get_stock_price, so an agent can pick it without opening sibling schemas.

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?

Opens with the triggering condition ('when the user asks for a quick read on one company now') and then names alternatives with the conditions that select them: get_financials for multi-period, compare_companies for peer benchmarking, get_stock_price for historical/as-of closes, get_xbrl_facts for segment history. It also states the exclusion clearly ('Not point-in-time').

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