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

Annotations already declare readOnlyHint=true, destructiveHint=false, openWorldHint=false, so safety is covered; the description adds the behavioral layer that matters: hard input validation failures, estimator noise on short samples, and an explicit caution that H near 0.5 is not a verdict. It also names the method family (R/S) so the agent knows which estimator's caveats apply.

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?

Front-loaded and information-dense, but the "takes returns, not price levels" instruction is stated three times (edge cases, usage trigger, and return description), and the opening sentence is a long one-breath run-on. Trimming the duplication would make it sharper without losing content.

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 two-parameter read-only computation with no output schema, everything needed is present: input domain, validation thresholds, output field names (hurst, interpretation, window_sizes, rs_values), interpretive thresholds for H, and known limitations. Nothing an agent needs to call it correctly or to report results responsibly 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?

Schema coverage is 100% and the schema already says values is a return series, so the description's restatement of that point is redundant. It does add real semantics beyond the schema for min_window: a whole number of at least 4, default 8, and the coupling constraint that the series must yield at least 3 window sizes — constraints the schema does not express.

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 computation (Hurst exponent via rescaled-range R/S analysis) and immediately grounds it in the interpretive question it answers (trending/persistent vs mean-reverting vs random walk). An agent can distinguish this from neighbors like run_garch, run_cointegration, or run_sharpe_stats without opening the schema.

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 explicit triggers ("is this asset trending or mean-reverting?", "does this series show long-range dependence?"), an explicit input precondition (returns, not price levels), explicit exclusions (no confidence intervals, no bias correction, no DFA/wavelets), and error conditions (32+ values, min_window whole ≥4, at least 3 window sizes). Nothing about when or when-not to call it is left to inference.

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