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

Annotations already declare read-only, idempotent, open-world, and non-destructive behavior, and the description adds substantial transparency beyond that: it discloses the USPTO API sunset with soft-fail behavior, the GDELT→GNews fallback, the expected empty FDA section for non-biologic companies, and the meaning of sources_used/sources_failed. It also pre-empts misreading empty results as bugs.

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 the tool is genuinely complex — it fans out across many sources and returns many fields. It front-loads the purpose with examples and routes the agent to the right choice, then systematically enumerates outputs. A slight deduction for density: it is a large single block where some repeated source mentions could be tightened.

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 fully carries the burden of explaining return values — and it does, covering resolved identity, recent_filings with URI shape, fundamentals ordering, patents, contracts, FDA products, hiring, news fallback, LEI, and the sources_used/sources_failed pair. Edge cases like missing FDA data and soft-failed patents are explicitly addressed.

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%, yet the description still adds real value: it explains that type 'company' and 'ticker' are interchangeable, gives exact value examples including zero-padded CIK, and clarifies what happens when a name resolves vs. a private company. The resolved_from/resolved_to and 'not a bare failure' notes are meaningfully beyond the schema text.

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 verb+resource: it builds a "full cross-source profile of a US public company in ONE parallel call," and immediately grounds it with concrete user phrasings like "tell me about X" and "company profile for Microsoft." It clearly distinguishes itself from narrower single-pack lookups by insisting this is the holistic, fan-out alternative.

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 explicit when-to-use guidance: "ALWAYS PREFER over chaining single-pack SEC/XBRL/news lookups when the user asks for a holistic view." It also enumerates acceptable inputs (ticker, CIK, company name) and explains the private-company edge case, so an agent knows the runnable scope and the expected non-failure outcome when resolution fails.

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