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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, establishing the tool's safety profile. The description goes far beyond that, explaining tier-based availability (free vs pro), that missing data is omitted rather than nulled, the distinction between ai_score and get_signals' signal_score (different pipeline, same scale), how relative_strength computes percentage-point differences, and that some fields may be null if not precomputed. This is rich behavioral context that an agent could not infer from annotations alone. No contradictions found.

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 extensive yet well-structured, using bullet points and clear sections. It front-loads the core purpose and then expands into field lists, tier differences, and related-tool pointers. While long, every section serves a purpose given the tool's complexity (e.g., explaining pro-tier additions, null behavior, and the relationship to get_stock_research). It does not waste words, though a more concise summary of the basic fields could be trimmed without loss of essential guidance.

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?

The description covers the full scope of the tool: all return fields, nested object structures (indicators, signals, stance_signals, relative_strength, market_risk), tier differences, null-handling conventions, and explicit pointers to the only alternative for fuller research. It also explains numerical scales (analyst_rating_score, ai_score) and how they relate to other tools (signal_score). Given the richness of the output and the annotation baseline, nothing an agent needs to call this tool correctly is missing.

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 schema defines the only parameter, symbol, with a clear description: 'Stock ticker symbol. Also accepts a company name as a fallback (e.g. "Apple") when it uniquely resolves to one symbol.' The tool description does not add additional parameter semantics beyond what the schema already provides. Since schema description coverage is 100%, a baseline of 3 is appropriate; the description does not need to compensate for any gap.

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 opens with a clear statement: 'Price, fundamentals, technical indicators, and company profile for a stock.' and reinforces with 'Returns all data needed to understand a stock in a single call.' It explicitly lists the categories of data and distinguishes the tool from get_stock_research, which is referenced as the only tool with the full AI narrative bundle. This gives an agent a precise mental model of what the tool does and how it relates to its siblings.

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 explicitly directs users to get_stock_research for full narrative and cross-source context: 'For the full text... call get_stock_research(symbol) instead — that's the only tool with the complete bundle.' It also mentions that the base tool is available to all tiers and that pro tier adds specialized indicators and interpreted blocks. However, it does not explicitly compare against other siblings like get_stocks (plural) or get_stock_history, leaving some ambiguity about when those would be preferred. Still, the guidance for the primary alternative is clear.

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