Regime

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

Annotations already declare readOnly/idempotent/non-destructive, so safety is covered; the description adds real method context beyond that — 'Spot tape, no fees, dead coins included' and 'started on every day of the history' — which materially affects how results should be interpreted. It stops short of stating limits or caveats on the statistics themselves.

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 routing paragraph is tight and earns its place, but the first paragraph is bloated with editorializing ('which is what spreading actually buys and the half nobody shows') and dense compound sentences. The genuinely useful constraints could be stated in far fewer words.

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?

With an output schema present, return values needn't be explained, and the description still adds the valuation methodology and sibling routing. Combined with 100% schema coverage and full annotations, an agent has what it needs; only the statistical caveats are unaddressed.

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 both enums are documented inline (days: 90/365/730; instalments: weekly/monthly with default). The description adds essentially no parameter meaning beyond what the schema already provides, so baseline 3 applies.

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, checkable operation: measuring whether spreading an entry (weekly/monthly DCA) beats lump sum on a single coin over a fixed window. The scope ('One amount into a coin over a window') distinguishes it cleanly from sibling checks without needing to open 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?

Explicit when-to-use ('dollar-cost averaging versus lump sum on one coin') plus concrete routing to alternatives: best_days_check/calendar_check for particular days or months, drawdown_check for a single-buy fall. Covers both the positive case and the exclusion conditions.

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

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

Annotations already establish readOnly, idempotent, non-destructive, closed-world, so the bar is lower. The description still adds substantive context beyond them: the data source (spot daily candles), the survivorship-bias stance ('dead coins included'), and the paired best/worst-day overlap diagnostic that determines whether the headline claim is meaningful.

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 with the claim being tested, then what is returned, then usage. The first paragraph is dense and long, but each clause (four-way decomposition, overlap count, candle type, dead coins) conveys distinct information, and the second paragraph is a tight routing sentence.

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?

An output schema exists, so return formatting need not be restated, yet the description still supplies methodology and scope an agent needs to set expectations. With annotations covering safety and the schema covering all three parameters, nothing material is missing for correct invocation.

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% with enums on days and best_days and a stated default of 10, so the schema carries the parameter detail. The description's 'without its N best days / N worst days' gives a little conceptual framing for best_days but no format or edge-case guidance beyond the schema, making 3 the right baseline.

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 analytical operation (decompose a window four ways with/without N best/worst days) on a specific resource (spot daily candles for a coin). It also explicitly names the sibling calendar_check as the tool for the adjacent weekday/month question, so the boundary is unambiguous.

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 an explicit trigger ('Use when someone argues for staying invested because missing the best days ruins returns, or for timing the market to dodge the worst ones') and routes the nearby-but-different question to calendar_check. Both when-to-use and the alternative are named.

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

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

Annotations cover the safety profile (readOnly, idempotent, non-destructive, closed-world), so the description's burden is lower. It still adds real substance beyond them: the permutation-test methodology, the small-sample caveat ('nine Octobers'), inclusion of round-trip cost, and the nine-year daily-candle data span. Only the runtime cost of hundreds of resamples is undisclosed.

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 ('Uptober. Mondays dip. Sell in May.') is ornamental and the sample-size aside ('279 days of bitcoin but nine Octobers') is dense prose that could be plainer. The substantive content is real, but it is spread across two paragraphs with some redundancy between them.

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?

An output schema exists so return values need no explanation, and annotations carry the safety profile. The description supplies methodology and data-scope context adequate for correct invocation; what is missing is only peripheral (determinism, expected computation latency) for a resampling-based 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?

Schema coverage is 100%, so 3 is the baseline; the description earns above it by adding meaning the schema lacks, namely the coin universe size ('34 coins'), unknown-ticker fallback behavior, and the constraint that 'hour_of_day' exists only for the 16 hourly-candle coins.

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 second paragraph states a precise verb and resource: 'Tests whether one day of the week, month of the year or hour of the day really beats the rest for a coin.' It also names the sibling tools it is not (best_days_check, averaging_in_check), so an agent can route without opening any 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?

Explicit when-to-use ('Use for seasonality claims (Uptober, Monday dips, Sell in May)') plus two named alternatives with their selecting conditions. Nothing 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.

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

Annotations already cover readOnly/idempotent/non-destructive/openWorld=false, so the description focuses on what annotations cannot express: data comes from both spot and perpetual tapes, fees are charged, and results are unranked. It stops short of disclosing cost/latency or pagination, but the added behavioral context is substantive.

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 is front-loaded and the usage/routing guidance follows in its own short paragraph, which is good structure. The opening sentence is a dense comma-chained enumeration of five checks, which is informative but makes the reader parse a long list before reaching the distinctiveness statement.

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?

An output schema exists, so return values need not be explained. For a multi-check comparative tool the description supplies scope, tape sources, fee treatment, the 'no ranking' caveat, and sibling routing — enough for an agent to call it correctly and interpret results.

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%, so the schema already documents days, coins format, and leverage default. The description only restates the 2-3 coin constraint and order preservation, adding no syntax or format detail beyond the schema. Baseline 3 is appropriate.

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 names the resource (two or three coins) and the exact scope of the operation (every check at once: drawdown, leverage survival, averaging-in, stop-loss, bitcoin correlation). It is immediately distinguishable from the single-check siblings it names, and the 'Nothing is ranked' clause clarifies what the tool does not do.

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?

Explicit routing rule: 'Use when two or three coins are being compared or chosen between', with the negative case spelled out — for one coin or one question, use the specific check, and six alternatives are enumerated by name. Nothing 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.

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), so the description's added value is methodology: 4,000 randomly sampled accounts, not today's leaders, ~30 month pairs, and the comparison baselines (chance, bottom bucket, all active accounts). That tells the agent what the result actually represents and guards against misreading it as a live-leaderboard query. It does not mention cost/latency or caching, so a 4 rather than 5.

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 with the core question, then methodology, then usage and alternatives in a clearly separated second paragraph. The methodology sentence is long and packs several clauses, but each clause (sample size, sampling frame, month pairs, comparison groups) carries distinct meaning rather than filler.

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?

An output schema exists, so return-shape explanation is unnecessary; what the agent does need — the analytical question, the sampling basis, the comparison baselines, when to invoke, and which siblings to use instead — is all present. Nothing required to call this correctly 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 both enums are self-documented, so the baseline is 3. The description adds meaning beyond the schema by clarifying the negative space ('takes no account address') and by enumerating the analytical cut the parameters select (by return or by dollar profit). No parameter-specific edge cases are added beyond schema, hence not a 5.

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, measurable question — whether top-decile/per-centile Hyperliquid traders persist into the next month — and names the exact ranking dimensions (return, dollar profit). It is clearly distinguishable from siblings leaderboard_rank_check (single-return placement) and overfitting_odds (luck explanation), so an agent can route without opening schemas.

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?

Explicit trigger ('Use when someone proposes copying top traders, a leaderboard or signal leaders') plus explicit alternatives with the condition that selects each ('To place one specific return ... use leaderboard_rank_check; to ask whether luck explains a record, overfitting_odds'). It also states the negative constraint 'Takes no account address', preventing a common wrong invocation.

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

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive), so the bar is lower. The description adds real behavioral context: the outputs returned, that correlations are computed on 'real daily returns', and that dead coins are included in the basket. It does not discuss edge cases like minimum basket size or error behavior, so not a 5.

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 is front-loaded and the routing sentence is tight, but the first paragraph is a dense run-on that strings together four distinct outputs, making it slightly list-like. Most of it earns its place; minor trimming would sharpen it.

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?

With an output schema present, the description needn't detail return values, and it is otherwise complete: trigger, alternatives, params, and key behaviors all covered. The only gap is the optional/required window ambiguity, which slightly undermines caller confidence.

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%, so both parameters are documented in structured form, making 3 the baseline. The description reinforces the purpose of the coins list and the 90/365/730 window, but also introduces a mismatch by calling the window 'optional' while the schema lists days as required — a small inconsistency rather than added value.

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 names a specific analysis (how many independent bets a coin basket really is) and enumerates the concrete outputs: average pairwise correlation, independent-bet count, per-coin BTC correlation, and equal-weight basket behavior on days BTC fell 3%+. This clearly distinguishes it from siblings like drawdown_check and coin_comparison.

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?

It gives an explicit trigger ('Use when a basket of two or more coins is called diversified or hedged') and routes to named alternatives with conditions: drawdown_check for one coin, coin_comparison for two or three coins side by side. Nothing 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.

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

Annotations already declare the safe read-only, idempotent, non-destructive profile, but the description adds substantive measurement context beyond them: spot tape, no fees, and dead coins included (an explicit survivorship-bias disclosure). It does not address data freshness or performance, so it falls just short of exhaustive.

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 is front-loaded and the usage paragraph is cleanly separated, but the first sentence is dense and prose-heavy ("what it cost to collect the return you were shown") before the concrete method arrives. Every sentence still carries information.

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?

With an output schema present, the description need not enumerate return fields, yet it still sketches what comes back and, more importantly, defines the data universe and exclusions. Combined with annotations covering the safety profile and 100% schema coverage, nothing needed to call the tool correctly 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 description coverage is 100% – both coin and days are documented in the schema, including the enum values and the unknown-ticker fallback behavior. The description adds only the framing "the period you name," so the baseline 3 is appropriate.

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 names a specific computation (buy at every daily close, hold for the named period) and the exact outputs (drawdown, share of starts that fell 30%/50%, days underwater, outcome). It explicitly distinguishes itself from siblings by naming leverage_survival and stop_loss_check with the conditions that select them.

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 a concrete trigger scenario ("when a return is quoted for holding a coin ('BTC did +150% in a year')") plus explicit alternative routing: leverage → leverage_survival, stop-cut → stop_loss_check. Both when-to-use and when-to-use-something-else are stated.

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

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

Annotations already cover the read-only/idempotent/non-destructive profile, yet the description adds substantial context beyond them: the data source is the exchange's own full public table, refreshed daily, and the denominator is accounts that traded rather than idle ones. These are exactly the behavioral facts an agent cannot infer from 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?

Front-loads the core computation and keeps the usage guidance in a separate paragraph. The opening fragment 'How much company a return has' is slightly cryptic and the parentheticals make it denser than necessary, but there is little outright waste.

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?

With an output schema present the description needn't enumerate return values, yet it still conveys source, freshness, denominator semantics, and sibling boundaries. Nothing an agent needs to select or invoke the tool correctly 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 documents both parameters including the '+340%' example and the window enum, so the description's '+340%' and window list add little beyond what the schema provides. Baseline 3 is appropriate when 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?

States a specific computation (given a return and window, how many leaderboard accounts did the same or better, out of how many traded, plus percentile and median) rather than restating the name. It explicitly differentiates from siblings by naming copy_trading_check and overfitting_odds as different questions.

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 an explicit trigger ('Use when a trader or an ad quotes a return and you want to know how rare it is') and routes the agent away from two named alternatives. The scope limit ('Hyperliquid accounts only') further constrains correct use.

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

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

Annotations already cover safety (readOnly, non-destructive, idempotent, closed-world), but the description adds behavioral substance an annotation cannot: funding actually paid is charged daily and eats into margin, the tape is real perpetual data, and delisted/blown-up coins are retained rather than dropped. It also enumerates the returned statistics, so the agent knows the shape of the answer.

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 organized as purpose-then-routing, with the alternative tools last. It is slightly longer than needed in the opening clause ('instead of the one day that worked'), but every sentence still carries information.

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 read-only analytics tool with an output schema, the description covers everything an agent needs: data source, cost assumptions, universe handling (delisted coins), the metrics returned, and the sibling routing. Return values need not be re-explained because an output schema exists.

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 three of four parameters carry enums, so the schema already documents syntax and allowed values. The description only restates the four inputs ('give coin, side, leverage and holding period') without adding units, defaults, or interpretation beyond what the schema says. Baseline 3 is correct here.

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 exactly what is computed: a leveraged trade opened on every historical day, returning liquidation share, median outcome, best day, and the unleveraged comparison. It names the data source (real perpetual tape) and scope (coins that blew up included), which an agent can use to distinguish it from drawdown_check or coin_comparison 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?

Explicit routing: 'Use when the question involves leverage, perpetuals or liquidation,' plus two named alternatives with the condition that selects each ('the fall an unleveraged holder sits through' -> drawdown_check; 'two or three coins at once' -> coin_comparison). Nothing 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.

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

Annotations already declare readOnlyHint, idempotentHint and openWorldHint=false, so the safety profile is covered. The description adds real behavioral context beyond that: it is pure arithmetic with no market data, model or opinion, and it specifies the three distinct results returned, which is meaningful for a stats 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?

The purpose and the query pattern are front-loaded before the when-to-use guidance and sibling routing. It is a touch long and the arithmetic sentence packs several clauses, but each sentence carries information and none is filler.

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?

An output schema exists, so return values need no prose explanation, and the description still covers when to reach for it, what it computes, and which siblings handle the adjacent questions. Nothing an agent needs to call it correctly 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 description coverage is 100%, so the baseline is 3, but the description adds interpretive value by framing wins/losses/tries as 'the track record you were shown and how much searching went into finding it' and illustrating the tries parameter with the 62%-over-100-trades-first-try-vs-fiftieth example.

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 (exact binomial odds that a shown track record arose from chance) and names the exact three outputs produced. It clearly distinguishes itself from the strategy/leaderboard siblings by being arithmetic-only rather than data-driven.

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?

Explicit when-to-use ('when you are shown a win rate, a backtest or a signal channel's record and need to know whether luck explains it') plus two named alternatives with their selecting conditions: strategy_grid_lookup for a named rule on real prices, leaderboard_rank_check for placing a return among real accounts.

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

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

Annotations already cover readOnly/idempotent/non-destructive, but the description goes well beyond: it discloses the simulation internals (stop fires on the day's low not the close, fees charged to both, every day of history as a start date, spot tape with dead coins included) and the outputs returned. This is exactly the context annotations cannot carry.

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?

Dense but front-loaded: the core purpose leads, the mechanics follow, and the sibling routing sits last. Some sentences are long and packed, but each earns its place by adding behavioral detail rather than restating the name or schema.

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 three-parameter analytical tool with full schema coverage, an output schema, and rich annotations, the description supplies everything else an agent needs: scope (spot, dead coins included), mechanics, and correct routing to alternatives. Nothing material 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%, so the enum values and the '0.05 is read as 5' convention are already documented. The description still adds meaning the schema lacks: it frames days as the holding period and stop as the distance below entry, and clarifies that every day of history is used as a start date, which shapes how the parameters are interpreted.

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 verb+resource (a measured backtest of whether a stop-loss helps a spot buy-and-hold) and immediately distinguishes itself from siblings by naming leverage_survival and strategy_grid_lookup as the alternatives for leveraged or stop+take-profit cases. An agent can route correctly without opening any 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?

Explicitly says when to use it ('asked whether a stop-loss protects a spot buy-and-hold') and names the two competing tools with the conditions that select them (leveraged positions/liquidation vs. stop+take-profit rules). Nothing 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.

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

Annotations already declare readOnly, idempotent, closed-world and non-destructive, so the safety bar is low. The description adds real provenance the annotations cannot: results come from a downloadable static file rather than live computation, over nine years of prices, sixteen coins, fees charged on both sides. It does not cover refresh cadence or result-size limits, so it stops short of a 5.

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 scope are front-loaded in the first clause, and the routing sentence at the end is exactly where an agent needs it. The middle sentence is rhetorically padded ('sixteen coins, three of which died', the em-dash inventory), which is characterful but slows scanning for a structured-field reader.

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?

An output schema exists, so return values need not be enumerated, and the tool is still complete: source data, coverage, alternatives and invocation shape are all present. Minor residual gaps are the interaction between family and the dip/cross-only parameters, which the description leaves to the schema.

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 every parameter already carries a per-field description and family-gating note ('dip only', 'cross only'), so the schema does the heavy lifting. The description adds only a generic 'give the coin and the numbers', which hints that coin alone is sufficient but adds no syntax or defaulting detail beyond the schema. Baseline 3 is correct.

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 verb (backtest lookup) on a specific resource (one exact strategy version), and enumerates the two strategy families it covers (dip-buy, moving-average cross) along with the outputs returned. An agent can distinguish it from the eleven siblings without opening any 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?

Names three alternatives with the exact condition that selects each: leverage_survival for leverage, stop_loss_check for a stop on plain buy-and-hold, overfitting_odds for judging a quoted win rate. The trigger condition ('when someone quotes a specific dip-buying or moving-average rule') is stated explicitly.

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