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

Annotations already define readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds meaningful behavioral context: the output fields, the api_data precision caveat ('use it when precision matters'), the handling of empty vs. provided ticker, and sourced catalyst data (off_hours-flagged, verified earnings dates). This goes well beyond the annotation safety profile.

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 information-dense with no filler: every clause adds specifics (ratings, columns, tags, api_data, mode). It is well front-loaded with the primary purpose. However, it lists five analysis columns while claiming '4 analysis columns', a minor structural inconsistency, and the single paragraph could benefit from light segmentation.

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?

Given there is no output schema, the description carries full responsibility for explaining what the tool returns. It does so comprehensively: rating scale, column details, api_data fields, tag conventions, and the two modes (with/without ticker). It even notes when to favor api_data over derived numbers, making it highly complete for a research-report tool.

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. The description fully compensates by explaining the behavioral difference: with a ticker it returns 'one card + live basis join', empty returns 'full report'. This is critical semantics not available in the schema, though it stops short of giving examples or ticker format guidance.

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 clearly states the tool produces a 'Daily deep-research report' with a specific rating scale (0-100 score, strong_buy|buy|hold|avoid) and detailed analysis columns (thesis, catalysts, financials, competitors, news_summary). It distinguishes itself from sibling tools like hood_quote or hood_ticker_brief by emphasizing in-depth research output and per-ticker or full-report behavior.

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 provides concrete usage context: 'With ticker: one card + live basis join; empty: full report.' It implies this is the deep-research tool, but it does not explicitly name alternatives or exclusions. Context is clear, but a reference to lighter-weight tools would earn a 5.

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