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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, openWorldHint=true, so the safety profile is covered. The description adds non-obvious behavioral scope: the comparison is valuation-only and the output must not be framed as a recommendation. It does not discuss data freshness, partial coverage handling, or error behavior for invalid tickers, so it stops short of a 5.

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?

Three tightly packed sentences, front-loaded with the trigger condition, then the sibling exclusion, then the output guardrail. The final sentence addresses the agent's response style rather than the tool's mechanics, which is useful but slightly outside the tool's contract and keeps this from a 5.

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?

An output schema exists, so return-value explanation is unnecessary, and the single input parameter is self-describing in the schema. With annotations covering safety and idempotency, the description supplies everything else an agent needs: when to call it, what it covers, where to go instead, and how to frame results.

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?

Only one parameter, whose constraints (minItems 2, maxItems 6, pattern, maxLength) are fully encoded in the schema even though schema_description_coverage is 0%. The description restates 'two to six stocks' but adds no ticker-format or identifier meaning beyond the schema, so this is the baseline adequate score.

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?

States a specific verb (compare) and resource (stocks) with an explicit cardinality bound (two to six) and enumerates the exact dimensions compared (price, fair value, margin of safety, confidence, valuation risk, coverage). This clearly separates it from get_stock_valuation (single stock) and get_stock_fundamentals (non-valuation fundamentals).

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?

Gives the triggering condition ('when the user asks to compare two to six stocks') and names the sibling to use instead for out-of-scope needs ('use get_stock_fundamentals separately for growth, profitability, or balance-sheet claims'). It also states a hard prohibition (no universal winner, no buy/sell/hold), which is exactly the kind of when-not guidance an agent needs.

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