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

With no annotations, the description carries the full burden and does well: it discloses caching (~10 minutes), a specific price ($0.01 USDC on Base), the payment mechanism (in-band x402 MCP via _meta "x402/payment"), and an alternate GET endpoint. It also defines the response semantics (tells_count, tier NONE/EARLY_TELL at 2+, CONFIRMED only when BTC reclaims). It omits failure behavior on unpaid calls and the meaning of the `fresh` flag.

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 detection tells and tier rules are front-loaded and useful, but there is real redundancy: 'Research data, not financial advice' appears twice, and the $0.01 USDC price is stated twice in adjacent sentences. The trailing alternate-URL sentence is useful but could be folded into the payment line.

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 returns adequately for a tool with no output schema — tier definitions and tells give the agent a usable mental model of the payload — and pricing/caching are stated. Gaps remain around the undocumented `fresh` parameter and what an unpaid or expired-pass invocation does, which matter for a paid endpoint.

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 coverage is 50%: `pass` is documented in the schema as a day-pass token that skips per-call payment, but `fresh` has no description in either place, and the description never mentions either parameter. It also never connects the $0.01 charge to the pass alternative it advertises elsewhere, leaving the agent to reconcile payment logic from the schema alone.

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?

States a specific resource and scope: a bottom-watch research feed covering a named coin list (BTC, ETH, SOL, XRP, AAVE, HYPE, MON, CC) with concrete detection tells (sweep-and-reclaim of 30-day low, 2x volume, RSI turning up, 4h higher low, funding/liquidation flush). It does not explicitly contrast with overlapping siblings like get_full_signal, get_regime, or get_crypto_rules, so differentiation is left to inference.

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?

There is no statement of when to use this versus the many adjacent signal tools (get_full_signal, get_regime, get_flows). The closest to guidance is the scope hint about which coins are covered and the tier semantics, which invite use for bottom-timing research but never exclude anything or name an alternative.

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