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

Beyond the readOnly/openWorld/idempotent annotations, the description discloses the parallel fan-out across sources, the exact return sections, fallback behavior (GDELT→GNews, USPTO sunset soft-fail), the meaning of sources_used/sources_failed, and the expected empty result for FDA products. This is extensive behavioral context.

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 it front-loads the query triggers and the 'ONE parallel call' value proposition, then organizes the fan-out and return sections in a scannable semicolon-delimited list. It is dense rather than padded, though the six leading paraphrases and some repetition of schema details keep it from being perfectly crisp.

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 carries the burden of explaining return shape; it does so in detail for every section. It also covers input forms, resolution behavior, failure semantics, and empty-section expectations, leaving an agent with everything needed to invoke it 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?

Schema coverage is 100%, so the schema already documents type and value. The description adds value by giving concrete examples (AAPL, 0000320193, Moderna), stating that type values are interchangeable and both accept the same shape, and explaining that company names resolve via SEC EDGAR's company-name match. It doesn't redefine the schema, just enriches it.

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', 'company profile for Microsoft') and then defines the operation as a 'full cross-source profile of a US public company in ONE parallel call.' This states a specific verb, resource, and scope, and its 'ALWAYS PREFER over chaining single-pack SEC/XBRL/news lookups' line distinguishes it from the narrower lookup-style tools in the sibling list.

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 gives explicit trigger conditions: use when the user asks for a holistic view/brief/profile, and ALWAYS PREFER this over chaining single-pack SEC/XBRL/news lookups. It also discloses what happens for out-of-scope inputs (private companies return resolved:false with a notes line), giving clear usage boundaries.

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