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

Annotations already mark the tool read-only, idempotent, and non-destructive, and the description adds substantial behavioral detail beyond that: fan-out across sources, patent data soft-failing after the USPTO API sunset, empty sections being genuine 'no data' rather than errors, and resolved_from/resolved_to behavior for name inputs. It also explains that an empty FDA products section is expected for non-biologic companies, which prevents false failure interpretation.

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 appropriately dense for a complex multi-source tool; it front-loads invocation examples and the core purpose before enumerating sources and outputs. It is slightly run-on in places, but each clause carries distinct information rather than padding.

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 must explain what is returned, and it does: every section of the profile is listed with its source and shape, including edge cases like source failures and empty sections. It also explains how to pass identifiers and what happens for private companies, leaving little ambiguity for an agent.

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 input schema already covers both parameters at 100% and documents the enum and value shapes, so the baseline is 3. The description adds useful nuance — zero-padded CIK format, SEC EDGAR name resolution, private companies returning resolved:false with a notes line, and type interchangeability — which goes beyond a bare schema restatement without being redundant.

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 prompts and immediately defines the operation as a 'full cross-source profile of a US public company in ONE parallel call,' giving a specific resource and scope. It also distinguishes itself from the alternative of chaining single-source SEC/XBRL/news lookups, making its role clear relative to the broader toolset.

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 tells the agent when to prefer this tool — whenever the user asks for a holistic view ('Tell me about X', 'research Acme') — and instructs it to prefer this over chaining individual lookups. It also covers input-format flexibility and the private-company edge case so the agent knows what to expect and can pick the tool appropriately.

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