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

Beyond the readOnly/openWorld/idempotent annotations, the description discloses substantial runtime behavior: it fans out across multiple source families, returns `sources_used` / `sources_failed`, soft-fails on the USPTO PatentsView API sunset, and treats empty FDA sections as expected for small-molecule-only companies. It also defines edge-case outputs (private company returns `resolved:false` with a `notes` line). This far exceeds what annotations convey.

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 tightly packed: each source listing maps to a return field and each example maps to an accepted input shape. Core intent is front-loaded, with details structured from fan-out sources to edge-case behavior; there is little redundancy beyond the deliberately varied query phrasing examples.

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 carries full responsibility for return values and does so thoroughly: it enumerates recent_filings, fundamentals, patents, federal_contracts, fda_products, hiring, news, and LEI, and explains the semantics of empty sections and `sources_used` / `sources_failed`. It also covers input resolution and private-company outcomes, so an agent can predict the response shape and failure modes.

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?

Although the schema already documents `type` and `value` at 100% coverage, the description adds crucial nuance: the two enum values are "interchangeable," `value` can be a ticker, zero-padded CIK, or company name, and name lookup resolves via SEC EDGAR with explicit `resolved_from/resolved_to` fields. The examples ("AAPL", "0000320193", "Moderna") ground the semantics without contradicting the schema.

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 natural-language triggers ("Tell me about X", "research Acme") and states the core action: "full cross-source profile of a US public company in ONE parallel call." It names the resource set (SEC EDGAR, XBRL, USPTO, USAspending, Purple Book, DOL LCA, news, GLEIF) and explicitly differentiates from "chaining single-pack SEC/XBRL/news lookups," so an agent knows exactly what this tool is and is not.

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?

Explicit guidance appears as "ALWAYS PREFER over chaining single-pack SEC/XBRL/news lookups when the user asks for a holistic view." Query examples like "give me the rundown on NVDA" serve as positive triggers, and the note that "person/place coming soon" signals exclusions. This tells the agent when to select it over granular lookups, even though it stops short of naming sibling tools.

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