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

Beyond the annotations, the description discloses genuinely useful behavior: results are recomputed roughly every 5 minutes during market hours, the response includes a `dip: {ok, codes, setup}` block only for oversold-pullback candidates, and a dip buy requires a completed hourly turn above entry-quality and depth floors. It also discloses the auth/payment failure mode clearly — without a subscription or x402 wallet it returns a PaymentRequired object and no data. The non-idempotent hint is consistent with the stated 5-minute recompute, so nothing contradicts the annotations.

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 opening example question is a good hook, but the description then restates the same idea three times ('Why a name is not a buy today', 'The reason one stock or ETF is not a candidate', 'Live intraday version') and buries the payment prerequisite at the very end. Clauses are strung together with colons and commas in a way that makes the answer-shape detail hard to parse.

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 one-parameter tool with no output schema, the description covers what matters: what the answer means, how fresh it is, the conditional `dip` sub-object, and the payment gate that can make the call return no data. The only real gap is that the full response shape beyond `dip` is not described, but the tool is simple enough that this is a minor omission.

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?

Schema description coverage is 100% and the single `symbol` parameter is already documented as 'Ticker, e.g. NVDA'. The description adds only the small clarification that the target may be 'one stock or ETF'. Baseline 3 is appropriate since the schema does the heavy lifting.

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 states a specific question the tool answers: why a given stock or ETF is not a buy candidate on the live board, and it enumerates the concrete causes (market gate, chase, falling trend, upcoming earnings, no entry window). It implicitly separates itself from the sibling `why_not` by calling itself the 'Live intraday version' and noting 'the same answer shape as the delayed read', though it never names `why_not` outright.

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 implied rather than stated: 'Live intraday version' signals this is the real-time counterpart to the delayed read, and the payment paragraph defines prerequisites (subscription or x402 wallet). There is no explicit 'use this instead of why_not when you need current intraday state' routing statement, so the agent must infer the choice from the sibling name alone.

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