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

Beyond the annotations (readOnly, idempotent, non-destructive), the description discloses behavioral traits: the tool fans across multiple sources, returns specific fields, includes a soft-fail for patents, and a fallback for news. It also states that only 'company' type is supported, and names are not allowed. This adds significant value beyond the annotation hints.

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 fairly long but front-loaded with example queries and structured into bullet points. Every sentence serves a purpose, explaining sources and return fields. It could be slightly shortened while retaining clarity, but overall it is well-organized and informative.

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?

There is no output schema, so the description must explain return values. It does so comprehensively, listing CIK, company_name, recent_filings with URIs, fundamentals, patents, news, and LEI. It also covers the patents sunset and news fallback, providing the agent with sufficient understanding of what the tool returns.

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?

With 100% schema coverage, the schema already documents both parameters. The description adds value by providing examples ('AAPL' or '0000320193') and reiterating that names are not supported, directing the agent to resolve_entity. This extra context helps the agent use the parameters correctly.

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 clearly states the tool's purpose: 'full cross-source profile of a US public company in ONE parallel call.' It provides numerous example queries and details the scope, making the action and resource explicit. While it does not explicitly differentiate from sibling tools like compare_entities, the guidance to prefer this over chaining single-pack lookups provides a clear use case distinction.

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 clear context on when to use the tool: for holistic company profiles. It advises using resolve_entity first if only a name is available, and implies it is not for specific single filings. However, it does not explicitly state when not to use it (e.g., for non-US companies), which prevents a perfect score.

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