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

Annotations already mark it read-only, open-world, idempotent, and non-destructive, so the bar for behavioral disclosure is lower. The description still adds valuable behavior: one parallel fan-out across many sources, soft-fail behavior for patents, expected empty results for FDA products in small-molecule-only companies, and a real 'no data' vs bug distinction via sources_used/sources_failed. It also explains name resolution and the resolved:false outcome.

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 information-dense; every sentence adds a distinct fact an agent needs. The user-intent phrases are front-loaded, followed by input flexibility and failure semantics. Some length is justified by listing the fan-out sources, though it could be tightened without losing value.

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 complex multi-source tool with no output schema, the description covers input variants, resolution behavior, per-source failure modes, expected-empty nuances, and return fields such as cik, filings URIs, fundamentals, and sources_used/failed. The only minor gap is that it doesn't enumerate every return field exhaustively or describe limits like the 'up to 5 filings' cap in more depth, but it is largely complete.

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%, so the schema documents both parameters. The description adds meaning by clarifying that type='company' and type='ticker' are interchangeable and that value may be a ticker, CIK, or company name regardless of type. That goes beyond the schema, which says type is either but does not explicitly say both behave identically for value shapes.

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 opens with concrete natural-language queries and states a precise purpose: a one-call, cross-source profile of a US public company. It names the resource (US public company via SEC EDGAR, XBRL, USPTO, USAspending, Purple Book, DOL LCA, news, GLEIF) and differentiates from single-pack lookups, so an agent can distinguish it from siblings like resolve_entity and deep_research.

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 says explicitly to ALWAYS PREFER this over chaining single-pack SEC/XBRL/news lookups for holistic views, and it defines accepted input forms: ticker, zero-padded CIK, or company name. It also explains when resolution fails (private company → resolved:false with notes), which helps an agent decide whether to fall back to another tool.

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