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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false, so the description earns credit by adding failure semantics: USPTO PatentsView sunset soft-fails, empty fda_products is expected for non-biologic companies, empty sections are real no-data rather than bugs, and private companies return resolved:false with notes. This level of behavioral disclosure goes well beyond the annotations.

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 tool is complex with many data sources and edge cases, so most segments earn their place. The structure is logical: triggers and directive first, then output sections, then failure and input semantics. It could be tightened slightly, but overall it is appropriately sized for the tool's breadth.

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 carry return structure, and it does: it enumerates resolved entity info, filings, fundamentals, patents, federal contracts, FDA products, hiring, news, LEI, and sources_used/sources_failed. It also specifies empty-section behavior, private-company resolution, and soft-failure conditions, leaving little ambiguity for an agent invoking the tool.

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 meaning by showing the three accepted value shapes (ticker, zero-padded CIK, company name), explaining name resolution via SEC EDGAR, and clarifying that type is interchangeable across 'company' and 'ticker'. It reinforces and extends the schema rather than merely repeating 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 and names the deliverable: a full cross-source profile of a US public company in one parallel call. It clearly distinguishes the tool from chained single-pack SEC/XBRL/news lookups and specifies accepted inputs (ticker, CIK, or name), so an agent can identify when this tool is the intended target.

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 explicitly maps user intents ('Tell me about X', 'research Acme', 'brief me on Tesla') to this tool and says ALWAYS PREFER over chaining single-pack lookups when a holistic view is requested. This is both a clear when-to-use trigger and an explicit when-not-to-use instruction.

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