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

Beyond the readOnlyHint annotation, the description discloses critical behavioral details: the correlation is computed on log returns, not raw price levels, dividends are excluded, only overlapping trading days are used, and candidates must meet a $100M market cap and sufficient overlapping days. It also notes that each row reports the observation count, adding transparency about data quality without contradicting 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 a single dense paragraph that front-loads the main action and method, then efficiently covers scope options, direction, filters, output details, and alternatives. Every sentence adds value, with no redundancy or filler, making it highly information-dense yet concise.

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?

Despite the absence of an output schema, the description is nearly complete: it explains the computation method, candidate selection criteria, output semantics (each row reports observation count), and provides explicit cross-references to related tools. It gives users a thorough understanding of what to expect and when to use it, with no significant gaps for a read-only data retrieval tool.

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?

With 100% schema coverage, the schema already documents parameter basics. The description adds meaningful context for scope (e.g., 'Industry ranks the subject's direct industry peers; Market surfaces cross-industry relationships') and direction (negative for hedge candidates), which goes beyond the schema's brief descriptions. However, it does not add much for days or maxResults, which are adequately covered by the schema alone.

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 clearly states the tool's function: finding stocks whose daily price returns are most or least correlated with a given stock. It specifies the statistical method (Pearson correlation of daily log returns) and distinguishes itself from sibling tools by emphasizing correlation rather than price or 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?

It explicitly instructs when to use this tool versus alternatives: 'Use GetStockPrices for the underlying series and the screener for fundamentals-based peer sets.' It also explains the scope choices (Industry, Sector, Market) and when negative correlation is useful for hedging, providing clear context for tool selection.

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