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

Annotations already establish read-only/safe/open-world, so the bar is lower, yet the description adds real behavioral context beyond them: 'Only the LATEST filing is indexed', facts are presented neutrally with LLM-derived ones labeled, each fact carries evidence plus a pointer to the next section, and vantage_date enables point-in-time backtesting. These are non-obvious constraints an agent could not infer from annotations.

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?

Front-loaded with the core purpose and use cases before the dense 8-K rerouting paragraph, and every sentence carries weight. The second paragraph is long and heavy on cross-tool routing detail, which makes the body denser than strictly necessary for this single tool, but nothing is filler.

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?

No output schema exists, so the description carries the return-value burden and does so: it explains the returned facts include evidence and a next-section pointer, notes neutrality and LLM labeling, discloses the latest-filing-only limitation, and covers the optional lens and vantage_date. An agent has everything needed to call this 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 description coverage is 100%, so the enum semantics of lens and the vantage_date format are already documented; the description mostly reinforces rather than adds. It does add usage-level meaning by pairing lenses with concrete scenarios (ENPH accounting red flags, UNH risk trajectory), which helps an agent pick the right lens value.

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 (returns the extracted facts) and resource (a signal index over the latest 10-K/10-Q), and enumerates the substantive domains covered (red flags, accounting quality, debt/liquidity, risks, tone, segments). It clearly distinguishes itself from get_filing_section, list_filings, and compare_earnings_calls by naming what each of those is for instead.

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 (user asks what matters in a company's LATEST 10-K/10-Q), explicit when-NOT-to-use (prior-quarter KPIs, guidance, beat/miss questions), and names the alternative workflow with concrete call syntax (list_filings(form_subtype="8-K-earnings") then get_filing_section). It also routes cross-quarter earnings-call trends to compare_earnings_calls.

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