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

Annotations already indicate readOnlyHint=true, idempotentHint=true, destructiveHint=false, openWorldHint=true. The description adds significant behavioral detail beyond this: it specifies data sources (SEC EDGAR/XBRL for companies, FAERS for drugs), mentions handling of off-calendar fiscal years, explains sorting by primary metric, and notes citation URIs in return. No contradictions with 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 thorough but slightly verbose. It is well-structured: starting with user-facing phrases, then behavioral explanation, then per-type details. Every sentence adds value, but a few phrases like 'head to head' and 'off-calendar fiscal years handled correctly' could be integrated more succinctly. Still, it earns its length.

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?

No output schema exists, but the description clearly states what is returned: 'paired data + pipeworx:// citation URIs per entity'. It covers the two distinct entity types, sorting behavior, and the source of data. For a comparison tool with 2 parameters and no output schema, this description is complete and leaves no critical gaps.

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 description coverage is 100% with both parameters documented. The description adds substantial meaning: for 'type' it details the specific data fields retrieved per type (revenue, net income for companies; adverse-event counts for drugs). For 'values' it provides examples and clarifies minItems and maxItems. This enriches the schema beyond the enum and array type.

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 explicitly states that the tool provides side-by-side comparison of 2-5 companies or drugs, with concrete examples like 'X vs Y' and 'rank these companies'. It clearly distinguishes itself from a single entity lookup by emphasizing parallel comparison over sequential lookups, and it differentiates from sibling tools such as entity_profile.

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 usage guidance: 'ALWAYS PREFER over sequential single-pack lookups when comparing entities.' It also lists triggers (e.g., 'which is bigger', 'head to head') which helps the agent decide when to invoke this tool. No when-not-to is needed since the tool is specialized for comparison and the guidance is clear.

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