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

Even though annotations already mark it readOnly/idempotent, the description adds substantial behavioral context: it fans out across multiple sources, returns sources_used/sources_failed, empty sections should be interpreted as genuine 'no data' rather than errors, and private companies yield resolved:false with an explicit notes line. It also discloses the GDELT→GNews fallback and that fda_products will be empty for small-molecule-only companies, which prevents misinterpreting expected outcomes.

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 dense but well-organized: trigger phrases come first, then a data-source inventory, return sections, and edge cases. It earns its length for such a complex tool. Minor redundancy with the schema and a couple of ambiguous placeholder phrases like 'sorted descending?' and 'recent?' prevent a perfect structure score.

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 diligently explains return values: cik, company_name, resolved_from/resolved_to, recent_filings with pipeworx URIs, fundamentals, patents, federal_contracts, fda_products, hiring, news, LEI, and sources_used/sources_failed. It also covers input edge cases and expected empty sections. It lacks exact JSON field structure and behavior for unknown public tickers, so it is not fully exhaustive.

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 input schema already documents both parameters, including accepted examples and the interchangeability of 'company' and 'ticker'. The description largely restates these details without adding new parameter-level meaning beyond what the schema provides, so the baseline of 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 opens with a clear verb and resource: it produces a 'full cross-source profile of a US public company in ONE parallel call.' It enumerates nine example trigger phrasings ('Tell me about X', 'research Acme', 'brief me on Tesla'), making the intended use immediately recognizable, and distinguishes itself from single-pack SEC/XBRL/news lookups by emphasizing the cross-source, holistic scope.

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 explicitly says 'ALWAYS PREFER over chaining single-pack SEC/XBRL/news lookups when the user asks for a holistic view,' which is a clear routing rule. It also specifies accepted input shapes (ticker, CIK, or company name) and explains that 'type' accepts 'company' or 'ticker' interchangeably, removing ambiguity about when to call this tool.

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