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

Annotations already declare readOnlyHint, idempotentHint, non-destructive, so the safety profile is covered. The description usefully adds the data source (Yahoo Finance via yfinance) and that no API key is required, which is real operational context. Beyond that it discloses little new behavior, and the elaborate wholesaler_ids / source_resource_id caching semantics in the schema are not echoed here.

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?

Front-loads the core output (consensus, targets, history) then the usage bullets, then the source. Well-structured and mostly tight, though the bullet list repeats capabilities already stated in the opening sentence.

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 values need not be explained. However for a tool with a symbol defaulting to null, the description never says what happens if symbol is omitted, and the odd wholesaler/caching parameters (clearly from a different domain) are left unexplained relative to an analyst-ratings 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?

Reported coverage is 0% but the nested schema actually carries rich descriptions for symbol, wholesaler_ids, source_resource_id, include_upgrades_downgrades, etc. The description adds only the upgrade/downgrade content semantics, duplicating the include_upgrades_downgrades field. Baseline 3 for a schema that does the heavy lifting.

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: fetching analyst consensus ratings, price targets, and upgrade/downgrade history with named fields (firm, fromGrade, toGrade, action). This clearly distinguishes it from siblings like GetFinancials or GetTickerInfo. It lacks an explicit 'unlike X tool' contrast, so it stops short of 5.

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?

Provides three explicit 'Use this tool when' scenarios that map to the consensus, price-target, and rating-change use cases. It defines when to use but does not name an alternative tool or an exclusion case (e.g., distinguishing from a general ticker-info tool).

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