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

Annotations already cover read-only, idempotent, and closed-world, so the description's job is to add freshness and scope context — and it does: 'recomputed nightly from public filings and end-of-day prices', 'Not real-time quotes'. 'One covered stock' also signals a coverage boundary the agent must anticipate. It does not say what happens for an uncovered ticker (error vs. empty), which keeps it off 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?

Content is front-loaded with the resource before the field list, and nothing is truly wasted, but the payload is delivered as one sprawling sentence with an embedded parenthetical example. Bulleting or shorter clauses would make the returned-field inventory scannable, and 'the current price, the headline model value...' is dense for what it conveys.

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?

No output schema exists, so the description must carry the return-value burden — and it does, itemizing the major response components, plus data provenance, update cadence, and a disclaimer. The one gap is failure behavior for tickers outside the coverage universe, which an agent calling with an arbitrary ticker needs to know.

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 a single parameter at 100% schema description coverage (including length bounds and the 'Use search_stocks first when unsure' hint), the schema already carries the load, so 3 is the baseline. The description adds only the mild constraint that the ticker must be a *covered* stock — useful, but not a meaningful elaboration of the parameter itself.

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 names a specific resource — a single covered stock's valuation — and enumerates exactly what comes back (current price, headline model value, premium/discount, other models with ranges, valuation profile, discount-rate inputs, Quant and Valuation grades). That is far more informative than the title. It stops short of naming a sibling, but the field inventory makes the difference from get_market_context or get_13f_consensus obvious.

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?

Usage is only implied: 'One covered stock's valuation' plus 'Not real-time quotes' tells the agent this is a per-ticker deep-dive on delayed data, not a screener or quote feed. There is no explicit when-to-use statement, no when-not-to-use, and no alternative tool named in the description (search_stocks is only mentioned in the parameter schema).

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