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

With no annotations present, the description carries the full burden and does so: it discloses default resolution behavior (listed tickers read from exchange-session daily series), the fallback rule (any unlisted ticker treated as crypto), refusal conditions (min 15 sessions with a close), the calendar-days-vs-sessions interpretation of the lookback, that `venue` reports which feed was read, and the full auth/payment model (0.02 USDC via x402 or API key). That is unusually complete for a mutation-free read tool.

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?

Purpose and the strategy-style rationale are front-loaded, and every sentence carries information. However, the description is one dense semicolon-chained paragraph, and the 28-ticker enumeration is bulky for content that arguably belongs behind list_approved_assets. Slightly heavy but not wasteful.

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?

There is no output schema, so the description must describe the return shape — and it does, in detail (three-horizon bands, annualised volatility as a percentage, bucket, z-score against the asset's own baseline, and per-length sweep labels). Combined with the auth/payment note, the supported universe, and the minimum-history refusal rule, an agent has everything needed to call this correctly and interpret the result.

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 already 100%, but the description adds semantics the schema cannot express: `asset` resolution rules (catalog membership vs. implicit crypto fallback, plus the DIA/META disambiguation note), the pairing requirement 'supply quote_token and market_data_venue together' for an exact crypto market, how `provider`/market args switch to the crypto history path, and that `lookback_days` means calendar days (~250 sessions at 365) for listed tickers. These are real constraints an agent could not infer 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?

Opens with a specific verb+resource: 'Classify an asset's regime using a lookback of 1-365 days of daily closes', then enumerates exactly what the classification contains (return, bull/neutral/bear band at 90/180/365d, annualised vol, bucket, z-score, sweep-catalog labels). This is the regime classifier, distinct from neighbours like get_market_data/get_ohlcv (raw series) and build_strategy_for_regime (downstream action). No ambiguity about what comes back.

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?

Gives clear when-to-use ('Use it before recommending a strategy style, because a mean-reversion design and a trend-following design suit opposite regimes') and explicit when-not conditions (a ticker not in the listed catalog 'cannot be read'; fewer than 15 sessions is 'refused as too little history'). What's missing is naming the sibling alternative it hands off to — build_strategy_for_regime is never mentioned, so the sequencing must be inferred from the generic phrase 'before recommending a strategy style'.

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