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

Annotations already mark the tool read-only, idempotent, and non-destructive, and the description adds meaningful behavior beyond that: it lists the exact data sources fanned out, states that sources_used/sources_failed indicate real data absence ('an empty section is a real "no data", not a bug'), and explains name resolution behavior and private-company handling. This is substantial context for an agent.

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 packs a lot of valuable information into a single dense, unstructured block with numerous parentheticals, semicolons, and repetitive example phrases. It is harder to parse than it should be, and the source/return list is unwieldy. Concise it is not, and the structure obscures otherwise useful guidance.

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 burden of explaining return behavior, and it largely does: it lists return sections, source status indicators, input variants, and the private-company failure mode. It is not perfectly structured or exhaustive on output formatting, but it covers the essential context needed to invoke the tool 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%: both parameters are described, including the type enum and the ticker/CIK/name formats for value. The description reinforces this with examples and adds the private-company resolution note, but it does not meaningfully change or enrich the parameter semantics beyond what the schema already provides. Baseline 3 is appropriate.

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-intent examples and defines the tool as a 'full cross-source profile of a US public company in ONE parallel call.' It clearly identifies the resource and action, and distinguishes it from chaining single-pack SEC/XBRL/news lookups. An agent can confidently determine when this tool is the holistic-profile option.

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 explicitly says 'ALWAYS PREFER over chaining single-pack SEC/XBRL/news lookups when the user asks for a holistic view,' which gives a clear when-to-use signal. It also documents accepted input forms and the private-company edge case. However, it does not explicitly contrast with alternatives like resolve_entity or compare_entities, leaving some selection ambiguity among siblings.

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