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

Annotations already mark it read-only and idempotent, and the description adds substantial behavioral detail: it fans out across multiple sources in parallel, soft-fails on certain APIs, returns resolved_from/resolved_to, and explicitly warns that empty sections mean genuinely no data rather than a bug. It also explains name resolution behavior and the private-company fallback, going well beyond the 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?

The description is long but information-dense, with the trigger examples front-loaded and the return structure and edge cases organized in a readable semicolon-separated flow. It could be better structured with line breaks, but every sentence carries substantive behavioral or usage information, so the length is justified.

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 takes on the burden of explaining return values, and it delivers: it lists returned fields (cik, company_name, resolved_from/resolved_to, recent_filings, fundamentals), source categories, sources_used/sources_failed semantics, and failure modes. It also covers type/value combinations and private-company behavior, making the tool callable end-to-end without additional documentation.

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%, but the description adds meaning by enumerating accepted value forms (ticker, zero-padded CIK, company name), explaining that type accepts 'company' or 'ticker' interchangeably, and describing how names resolve via SEC EDGAR. This is richer than the schema alone and reduces ambiguity for the agent.

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 user phrasings ('Tell me about X', 'research Acme', 'brief me on Tesla') and states it produces 'a full cross-source profile of a US public company in ONE parallel call.' It explicitly distinguishes itself from 'chaining single-pack SEC/XBRL/news lookups,' making its purpose and differentiation from siblings clear.

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?

The description gives explicit usage guidance: prefer this tool over chaining single-purpose lookups when the user asks for a holistic view. It does not name specific sibling tools as alternatives, but it clearly scopes when this tool is appropriate and even notes edge cases like private companies returning resolved:false rather than a bare failure.

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