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

Beyond the readOnly/idempotent annotations, the description discloses rich behavioral detail: it fans out across many sources, returns synthetic sections like sources_used/sources_failed, treats empty sections as real 'no data' rather than bugs, soft-fails on the USPTO PatentsView API sunset, and explicitly handles private companies with resolved:false plus a notes line. This is exemplary transparency for a multi-source read tool.

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 and dense, but the complexity of the tool justifies most of it. It front-loads the core purpose and preference rule, then moves through input variants and output sections in a logical order. It is not as scannable as it could be — a bulleted structure or shorter return-field list would help — but every sentence carries information an agent needs.

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 the full burden of explaining the return shape, and it does so thoroughly: it enumerates every returned field (cik, company_name, recent_filings, fundamentals, patents, federal_contracts, fda_products, hiring, news, LEI), explains edge cases like empty sections and private companies, and documents failure modes like the USPTO sunset. This is complete enough for correct tool invocation and result interpretation.

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 baseline is 3, but the description adds substantial meaning beyond the schema. It clarifies that 'type' accepts 'company' or 'ticker' interchangeably, that 'value' can be a ticker, zero-padded CIK, or company name, and how name resolution works via SEC EDGAR. The examples ('AAPL', '0000320193', 'Moderna') make the parameter semantics actionable.

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 states a precise purpose: 'full cross-source profile of a US public company in ONE parallel call.' It gives concrete example queries, enumerates the data sources, and explicitly positions itself as the preferred tool over chaining single-pack SEC/XBRL/news lookups, distinguishing it from nearby sibling tools like profile, quote, stock_news, and deep_research.

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 when-to-use guidance: 'ALWAYS PREFER over chaining single-pack SEC/XBRL/news lookups when the user asks for a holistic view.' It also documents the accepted input forms (ticker, CIK, name) and the expected behavior for private companies. It does not explicitly name sibling tools or state when to prefer them instead, so it falls just short of full alternative routing.

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