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

Annotations already declare readOnlyHint=true and idempotentHint=true, so the safety profile is covered. The description adds rich behavioral context beyond annotations: the USPTO patents API soft-fails on sunset, FDA products being empty is 'expected, not a failure,' empty sections mean real 'no data' not a bug, private companies return resolved:false with an explicit notes line, and sources_used/sources_failed report which sources actually returned data. This fully discloses error and edge-case behavior.

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 long, but the tool is genuinely complex (8+ sources, no output schema, many edge cases) and every sentence earns its place — triggers are front-loaded, followed by the preference directive, sources, return shape, and failure semantics. A small deduction for being a dense wall of text without line breaks or sectioning.

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 no output schema, the description fully compensates: it enumerates return fields (cik, company_name, resolved_from/resolved_to, recent_filings with URIs, fundamentals from the LATEST 10-K), documents per-source behavior and fallbacks (GDELT→GNews), and explains failure semantics for private companies. Nothing an agent needs to call this correctly is omitted.

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% — both `type` and `value` are fully documented in the schema, including the accepted input shapes (ticker, zero-padded CIK, company name). The description adds marginal nuance (resolved_from/resolved_to when a name is passed, interchangeable type values), but the schema already carries the parameter documentation burden, so the baseline 3 applies.

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 a specific verb+resource: 'full cross-source profile of a US public company in ONE parallel call,' with concrete trigger examples ('Tell me about X,' 'research Acme,' 'brief me on Tesla'). It distinguishes itself from sibling tools by explicitly contrasting with 'chaining single-pack SEC/XBRL/news lookups,' making its scope unmistakable.

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?

Provides an explicit when-to-use directive: 'ALWAYS PREFER over chaining single-pack SEC/XBRL/news lookups when the user asks for a holistic view,' naming both the condition and the alternative. The trigger examples further clarify when the tool is appropriate, and the input-format guidance (ticker, CIK, or name) removes ambiguity about invocation.

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