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

Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so safety is covered. The description adds genuinely non-obvious context: the comparison method (thesis direction vs. four independent signals) and the invalidation score scale of 0-100. Auth, limits and failure modes remain unstated.

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 dense sentences, front-loaded with the purpose, then the comparison logic, then the return shape. No filler or repetition.

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?

Inputs are just ticker plus direction, and an output schema already documents the return shape, so the description's explanation of the signal breakdown and score range is more than sufficient. Nothing an agent needs to call it correctly is missing.

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% and the enum for direction is documented in the schema, so the description's restatement of bullish/bearish/neutral adds nothing beyond structured fields. Baseline 3 is correct when the schema does the work.

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 and resource ('Check if an investment thesis for an NZX company is still valid') and enumerates the four signals it aggregates, which distinguishes it from sibling signal tools like get_analyst_consensus and get_fair_value. An agent can tell this is the composite validity check rather than an individual data fetch.

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 implies the use case (you hold a thesis direction and want to test its validity) but never states when to use this versus the individual signal tools it wraps, nor any exclusions. Honestly adequate but leaves routing to inference.

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