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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive), so the description wisely spends its space on data semantics instead: it discloses that specialist_model.fair_value_blend may be null, and that blending_applied is reconciled independently from top-level DCF/multiples values while valuation_method_label can describe a blended headline from a DCF source. These are non-obvious provenance traits an agent could not infer from structured fields.

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?

Usage trigger is front-loaded in the first clause, followed by field disambiguation; there is no filler. The middle sentence on official_fair_value_source vs valuation_method_label is dense jargon but earns its place as an anti-confusion note.

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?

With an output schema present, the tool is largely self-documenting, yet the description invests most of its length in return-field semantics while leaving input handling (invalid or unknown ticker, symbol normalization, market coverage) unaddressed. Adequate to call correctly, but not complete for a query tool where a bad symbol is the most likely failure mode.

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?

The single parameter (ticker) has 0% schema description coverage, so the description carries the full burden here — but it says nothing about ticker format, exchange suffix, or accepted symbol conventions (e.g. BRK.B, ^GSPC) allowed by the pattern. "One stock's" only weakly implies a single symbol argument.

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?

Names the resource precisely and enumerates the exact fields it returns (fair value, price, margin of safety, method, assumptions, confidence, risk), which pins down scope well. It differentiates only from the private-portfolio case, not from the nearest sibling get_stock_fundamentals, so an agent still has to infer that boundary.

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?

"Use this when the user asks for one stock's ValuEdge fair value..." is a concrete trigger condition, and "Do not use it for a user's private portfolio" states an explicit exclusion. The exclusion does not name the correct alternative (get_my_portfolio / analyze_my_portfolio), leaving the redirect implicit.

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