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

Annotations already declare readOnly, idempotent, non-destructive, closed-world, so the safety profile is covered. The description adds genuinely useful context beyond that: the data source (Yahoo Finance via yfinance) and that no API key/auth is required, which tells the agent about provenance and failure modes in this deployment. It does not mention rate-limit behavior or data latency, which keeps it below 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?

Front-loaded with the output summary, followed by a scannable when-to-use bullet list and a one-line source/auth note. No filler sentences; each block adds distinct information.

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 not required, and the description lists key fields anyway. However, for a tool whose only meaningful input is a ticker, the description never states that a symbol is required or how the noisy unrelated parameters should be left alone - a gap an agent may stumble on.

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 reported at 0% and the description does not compensate - it never mentions that a ticker symbol must be supplied, nor how the many unrelated-looking parameters (wholesaler_ids, source_resource_id, exclude_fillers) relate to an analyst-ratings call. The one sentence that touches inputs ('on a stock') leaves the agent to infer the symbol argument entirely from the schema.

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 (fetch) and precisely enumerates the resource: consensus ratings, price targets (low/high/mean/median), and upgrade/downgrade history with firm, fromGrade, toGrade, action. This is clearly distinguishable from siblings like GetPriceHistory, GetTickerInfo, or GetEarningsHistory without opening a schema.

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?

An explicit 'Use this tool when' block gives three concrete triggers (consensus view, target upside/downside, tracking rating changes). It lacks the negative side - no named alternative or when-not-to-use - but the positive framing is clear enough to route an agent.

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