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

Annotations already mark the tool read-only/idempotent, and the description adds substantial behavioral detail: it fans out across many sources, soft-fails on patents, reports sources_used/sources_failed, treats empty sections as real 'no data', and returns resolved:false with notes for private companies. No contradiction with 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 definition is long, but the tool is genuinely complex and the detail about sources, return sections, and failure modes earns its place. It is front-loaded with user phrasings and the decisive usage preference; minor redundancy with the schema and a dense wall-of-text style keep it from a 5.

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 present, the description fully enumerates the returned sections (cik, filings, fundamentals, patents, contracts, FDA products, hiring, news, LEI) plus sources_used/sources_failed. It covers failure behavior, name resolution, and the private-company case, leaving an agent with everything needed to invoke the tool 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?

The schema already documents both parameters completely, including the type enum and the accepted ticker/CIK/name forms, so the description is not strictly required to compensate. It reinforces examples and 'interchangeably' behavior but mostly repeats schema content rather than adding new meaning.

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 and resource: full cross-source profile of a US public company, with concrete trigger examples ('Tell me about X', 'brief me on Tesla'). It also marks itself as the holistic alternative to single-pack lookups, separating it from siblings such as resolve_entity and search_articles.

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?

Gives explicit when-to-use triggers and says 'ALWAYS PREFER over chaining single-pack SEC/XBRL/news lookups when the user asks for a holistic view.' It also describes the private-company and no-data cases so the agent knows what to expect and when not to retry.

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