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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering safety. The description adds useful context: 'Source: Yahoo Finance via yfinance. No API key required.' It also implies return fields ('exchange and asset type'). However, it does not disclose rate limits, caching behavior, or potential external API availability issues, which are relevant for a network-backed lookup.

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 well-structured with clear sections (purpose, usage, asset types, source) and uses bullet points effectively. Every sentence carries information, and the most important details are front-loaded. It is slightly verbose, but the 'Use when' list earns its place by guiding agent decision-making.

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?

For a low-risk read-only lookup, the description covers purpose, usage scenarios, asset types, and authentication. It does not mention the optional caching/follow-up parameter (source_resource_id) or the tracking parameters (mcp_prompt_id, question_asked), but these are advanced and mostly irrelevant for the core lookup. The presence of an output schema also offloads return-value details, so the description is sufficiently complete for typical agent use.

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 top-level parameter 'params' has no description in the schema (0% coverage), so the description must compensate. It lists asset_type options and implies the query string, but does not explain the params structure or other schema fields like max_results, source_resource_id, or wholesaler_ids. This is minimal compensation for a parameter that is an object with many nested properties.

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 uses a specific verb ('Search'), names the resource ('Yahoo Finance ticker symbol'), and states the input type ('by company name, fund name, or keyword'). It clearly distinguishes from siblings like GetTickerInfo (which assumes a known ticker) and other search tools by focusing on name-to-symbol resolution.

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?

The description includes an explicit 'Use this when' section with three concrete scenarios and the general rule 'you have a name but need the ticker symbol.' It provides clear context but does not state when not to use the tool or name a preferred alternative, so it stops short of a full 5.

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