Backtesting Arena

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

No annotations are provided, so the description carries the full behavioral burden. It discloses partial success semantics (each query returns a result or a structured error, one failure doesn't abort the rest), the rate-limit accounting (batch saves roundtrips, not quota), and that payloads, tier gates, and source attribution are identical to the single tools. This gives the agent a precise model of side effects and error handling.

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 description is dense but every sentence adds information: purpose, allowed tools, failure behavior, rate-limit nuance, payload equivalence, and an exclusion. It is front-loaded with the core value proposition. While it is a longer description, it avoids filler and is well-structured for an agent to scan.

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?

Given there is no output schema and no annotations, the description adequately covers all essential details: the allowed set of reads, query count limits (1-6, enforced by schema), behavior on partial failure, rate-limit implications, and how to route any request outside the batch to a single tool. The agent has enough to call the tool correctly without additional context.

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?

The schema already describes the queries array and the tool enum, with 100% coverage. The description adds value by providing an explicit example ({tool: 'iv_snapshot', args: {currency: 'BTC'}}), clarifying that args map to the single tool's parameters, and noting that args should be omitted when the underlying tool takes none. This goes beyond the schema's generic 'Args of the underlying single tool' text.

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 clearly states the tool batches multiple market snapshot reads into one call, and it enumerates the 14 specific supported reads (spot_price, pulse, cycle, etc.). This distinguishes it from the sibling single-read tools (arena_get_spot_price, arena_get_cycle, etc.) and leaves no ambiguity about which tool to use for batching.

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?

The description explicitly tells the agent when the batch tool is appropriate (multiple reads of the listed types) and when it is not: 'For history tools, backtests or anything not in the list, call the single tool.' It also explains the practical benefit (saves roundtrips, not quota) and gives a concrete example of query construction, so the agent knows exactly how to invoke it.

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?

No annotations exist, so the description carries the burden and does well: it discloses that mode="call" has 'same result, auth, tier and rate limits as calling it directly' and that describe is a safe preflight. It does not, however, warn that the catalog itself includes destructive/state-changing members (arena_cancel_subscription, subscribe_*), nor does it note any caveats about the truncated one-line summaries.

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 gateway purpose and mode semantics before the catalog, so the important content comes first. The 48-entry catalog is long but is the functional payload; however several entries are visibly truncated ('i.e.', trailing ellipses), which blunts their value.

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 meta-dispatch tool with no output schema and no annotations, the description covers purpose, routing, mode behavior, and parity of auth/limits. It leaves the return shape of mode="call" only implied ('same result ... as calling it directly'), which is acceptable since the underlying tools define it.

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 real meaning: it explains what mode="call" versus mode="describe" actually do at runtime and that `arguments` must be 'exactly as the tool itself takes them', which is not stated in the schema.

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 role: a gateway that exposes 'EXTENDED' tools one line each rather than as separate entries, and explains the reason (keeping the tool list short). An agent can immediately distinguish this from the ~50 flat sibling tools like arena_get_pulse or arena_get_cycle.

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 gives the selection condition: 'Use it when no listed tool fits', and then sub-routes internally with mode="call" vs mode="describe", recommending describe 'if the arguments are unclear'. That is a complete when-to-use and how-to-decide story.

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?

No annotations are provided, so the description carries the full disclosure burden — and meets it thoroughly. It reveals the non-equalized evaluation window (long-warmup strategies start trading later; compare actual_date_from and check result.benchmark before ranking by CAGR), the multiple-testing upward bias of reporting a winner, sequential execution with 10–50s latency, per-day quotas (Pro=20, Power=200), and the Pro-tier API requirement. This is far beyond a generic 'runs a comparison' statement.

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 disciplined — the opening question front-loads the purpose and each subsequent sentence adds a distinct fact: same-data guarantee, sibling differentiation, evaluation-window caveat, multiple-testing caveat, latency, quota, tier. The tail stacks several caveats and operational notes in quick succession, which is slightly heavy, but there is no redundant filler or repetition of the 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 an 8-parameter tool with no output schema, no annotations, and a family of 75+ siblings, this is remarkably complete: purpose, scoping guarantees, the metric categories returned (best by CAGR, best by win-rate, worst by drawdown), behavioral caveats, latency, quota, tier, and sibling routing all appear. The high-level return shape compensates adequately for the missing output 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%, so the baseline is 3. The description adds genuine meaning on top: it establishes the core guarantee that pair, interval and date range are held constant across all strategies, and warns that date_from clamping interacts with warmup so the actual data windows differ across runs. It correctly avoids restating per-parameter docs the schema already covers.

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 concrete question ('Which of these strategies performed best on the same data?') and states the verb-resource pair: run 2–5 strategies against the same pair/interval/date range and return per-strategy metrics plus a comparison summary. It explicitly distinguishes itself from a series of separate arena_run_backtest calls and from arena_run_universe_backtest (one strategy across many pairs), so an agent can select it correctly 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 an explicit trigger: 'Use this when the user asks which of several strategies fits a market.' It names the alternative it competes with (a sequence of arena_run_backtest calls) and explains why this tool is superior (it holds pair/interval/date range fixed, which separate runs do not guarantee). It also routes the inverse case to arena_run_universe_backtest and the multiple-testing follow-up to arena_get_robustness_field — full when-to-use and when-not-to-use coverage.

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?

With no annotations provided, the description carries the burden of behavioral disclosure. It explicitly states it returns scenario numbers and the winner on expected value, and explicitly denies being a buy/sell recommendation. It also notes that calculations are over the user's own assumptions (not live data) and mentions a free tier, adding transparency. It doesn't cover edge cases like inconsistent probabilities, but this is acceptable for a math 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 description is long (~200 words) but well-structured: it leads with a clear question and purpose, then details modes, clarifies the non-recommendation aspect, and ends with a practical URL. While not as terse as ideal, every sentence carries information relevant to correct invocation, and the structure is logical and front-loaded.

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?

Given the tool's complexity (two modes, many parameters, no output schema), the description covers the essential items: what each mode does, the input types (multiples vs absolute), the non-recommendation nature, and guidance to ask for missing inputs. It lacks a precise description of return format, but the stated 'scenario numbers and which option wins' is adequate for an agent to interpret results. The URL fallback also compensates for missing interactivity.

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. The description adds meaningful context beyond the schema by explaining that 'compare' prices are multiples of today and 'allocate' uses absolute prices, and by describing the risk-aversion parameter in a practical way. This enhances understanding without being redundant.

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 clearly states the tool's purpose: decision-math over the user's own assumptions to decide buy-now vs wait, with two explicit modes ('compare' and 'allocate'). It distinguishes itself from siblings by detailing what each mode computes (expected value vs risk-adjusted allocation) and explicitly says it is not a buy/sell recommendation, making its role 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?

The description gives practical guidance: 'Ask the user for the missing inputs, then call' sets a clear precondition. It also provides a fallback alternative for the full interactive version via URL, clarifying when to direct users elsewhere instead of calling. It does not explicitly compare to sibling tools, but the guidance is sufficient for typical 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?

With no annotations provided, the description carries the full burden. It discloses the data fields returned, the update frequency ('Daily'), and a 'Free tier' caveat suggesting possible limitations. It does not explicitly state that it is read-only, but the verb 'get' and the nature of a snapshot make it implicit. The methodology mention adds valuable context. Overall, it provides solid transparency beyond trivial details.

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 description is a single, well-structured sentence that front-loads the core question ('Is it altcoin season?') and then compresses the key details into a list. There is no fluff, and every phrase adds value—methodology, data fields, color scheme, and tier note. It is appropriately concise and immediately scannable.

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 zero-parameter tool with no output schema, the description must convey what the call returns. It lists all major fields: BTC-Dominance, Alt-Dominance, 4 Layer-1 signals, overall color, and a Top-50 snapshot. It also notes the daily update cycle and methodology. While the exact structure of the Top-50 snapshot is not detailed, the description is sufficient for an agent to understand what to expect and to call the tool correctly. Minor lack of formatting details keeps it from a 5.

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?

The input schema has zero parameters, so there is nothing for the description to clarify. Per the rubric, a baseline of 4 applies when there are no parameters. The description does not need to add parameter semantics, and it correctly omits them. It adds no redundancy with the schema, which is empty and trivially 100% covered.

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 clearly states the tool's purpose: it reports the current altcoin season status using a specific methodology (v7 Native-Filter). It lists exact outputs (BTC-Dominance, Alt-Dominance, Layer-1 signals, color, and Top-50 snapshot). The word 'Daily' and 'snapshot' differentiate it from the sibling 'arena_get_altcoin_season_history', establishing it as the current-state version. This is a specific verb+resource with clear distinguishing scope.

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?

The description implies usage for current altcoin season state through 'Daily' and 'snapshot', but it never explicitly states when to use this tool versus alternatives like the history version or other snapshot indicators. No exclusion conditions or alternative names are provided. An agent would infer the usage from context, but explicit guidance is missing, which is a gap given the large sibling list.

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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It goes beyond basic operation to reveal failure modes ('Every source can fail independently'), data-quality caveats ('history span, candle count, missing days... delisted pairs are flagged'), the mechanical A/B/C grade rule that travels in the payload, and an interpretive caution ('the median altcoin loses against Bitcoin, so a positive number is a description, not an edge'). This is exemplary transparency.

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 description is a single, very dense paragraph with a long enumeration of metrics, conditions, and caveats. It lacks visual structure (bullets, sections) and is considerably longer than needed for an agent to parse quickly. While every sentence carries useful information, the lack of organization and sheer length hinder readability.

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?

Given the tool's high complexity and the absence of an output schema, the description covers the major return components comprehensively (returns, trend, ATH, volatility, liquidity, tokenomics, derivatives, data quality, sources used/unavailable). It does not specify the exact response format, but it still gives an agent enough context to predict what the tool will return and how to interpret it.

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 both parameters. The description adds no new semantic detail beyond what the schema provides (pair case-insensitivity, any Binance USDT pair, detail full adds raw returns). While it reinforces the pair scope, it doesn't add meaning beyond the schema, so the baseline of 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 answers 'Where does this coin stand?' and enumerates a specific set of metrics (returns, relative strength, trend, drawdown, volatility, liquidity, tokenomics, data quality), making the resource and scope clear. It also explicitly differentiates from arena_get_signal_context ('For the strategy-side question...'), which distinguishes it from the closest sibling.

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?

The description states when to use the tool (descriptive snapshot for any Binance USDT pair) and when not to use it ('Descriptive, no signal', and 'For the strategy-side question... use arena_get_signal_context'). It also identifies an alternative tool by name, which is exactly what high-quality usage guidance should do.

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?

With no annotations provided, the description carries the full burden. It discloses access control (own runs only, admin override) and the API Pro tier requirement, both behavioral traits. However, it doesn't mention error behavior (e.g., 404 for nonexistent id) or response format details, but for a simple get-by-id operation the key caveats are covered.

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 description is front-loaded with a purpose question, then compresses a full field list, access rule, sibling pointers, and tier note into three sentences. All sentences carry useful information with no filler, though the density might be slightly high for quick scanning.

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 simple tool with one param and no output schema, the description covers what it returns, how to get the id, alternatives, access control, and tier requirement. Nothing essential is missing for an agent to call it correctly; even edge cases like permission and tier are addressed.

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% (id is described as 'UUID of the backtest run'), so the baseline is 3. The description adds value by instructing where to obtain the id (arena_list_backtests) and reinforcing that the id identifies a single run, going beyond the schema's terse field description.

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 opens with a concrete question that frames the tool's purpose, then states precisely: 'Returns the full record of ONE backtest run by id' and enumerates the exact contents (strategy, pair, interval, metrics). It explicitly differentiates from siblings by naming arena_get_backtest_trades and arena_run_backtest, so an agent can distinguish it without ambiguity.

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?

The description gives explicit routing: 'Get ids from arena_list_backtests', 'for the individual trades add arena_get_backtest_trades', and 'to create a new run use arena_run_backtest'. It also clarifies access scope ('Only your own runs (admins may read others)') and tier requirement ('[API Pro tier]'), giving an agent clear when-to-use and when-not-to-use signals.

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?

With no annotations, the description carries the full burden of behavioral disclosure. It discloses the underlying timeframe, the 1000-bar sample, the trend_context fields, and even the interpretive caveat that a fresh same-day flip is the least settled observation. The 'Educational analysis' tag further signals that this is analytical, not financial advice.

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 description is longer than average but densely packed with essential information: inputs, timeframe, all returned fields, and interpretive guidance. It is front-loaded with the core question and purpose. Slightly run-on in places, but no sentence is pure 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?

Given there is no output schema and no annotations, the description fully compensates by enumerating every major return component: current_trend, timestamp, wave/fractal counts, last-5 fractals per side, and the entire trend_context object with its base-rate stats. The agent can understand what call will yield and how to interpret the freshest flip.

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?

The tool takes zero parameters, so the baseline is 4. The description provides all necessary context about what the tool outputs without needing to explain parameter behavior. There is nothing missing 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 opens with a concrete question ('Is the trend up or down, and how fresh is the flip?') and names the exact resource: daily Bitcoin market structure from a 1000-bar Phantomflow adaptation. It clearly identifies the tool as a trend-structure getter, distinct from the many other arena_get_* indicator tools.

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?

The description gives clear context around when this is relevant: for daily BTCUSDT trend direction, flip freshness, and historical flip behavior. It stops short of explicitly naming alternatives or stating when not to use it, but the data source and 'educational analysis' framing give the agent enough context to select it from the sibling list.

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?

No annotations exist, so the description carries the burden, and it discloses substantial behavior: output shape (active_count, stages[], stage_history), the null `since` edge case for pre-400-day states, per-day booleans, weekly 20W/50W-MA evaluation, and free-tier status. It doesn't explicitly address rate limits or side effects, but the read-only nature is strongly implied by 'Returns'.

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 description is dense but mostly front-loaded: it leads with the purpose, then return structure, parameter behavior, interpretation, and cadence. A few long parentheticals make it parse slightly harder, but no sentence is wasted.

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 no output schema, the description must explain return values, and it does: active_count, stages[] fields including the null `since` semantics, and stage_history as per-day booleans. The parameter bounds, default, evaluation frequency, and free-tier context are also present, so an agent has enough to invoke and interpret the result correctly.

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's parameter description already contains the same detail about history_days bounds, default, and per-day booleans. The tool description repeats that content without adding new meaning, so the 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?

The description opens with the exact question it answers and names a specific resource: the Bitcoin Bullmarket-Ampel. It clearly defines scope (current state 0-5 plus history) and the unique 'stages' concept, distinguishing it from generic market/correlation siblings without ambiguity.

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?

The rhetorical 'Is this still a bull market?' and 'Higher count = more bull-market signals firing' imply the use case: assessing bull-market strength via the Ampel stages. However, it does not state when to prefer this over related siblings (e.g., cycle, market structure, macro regime), leaving the selection logic implicit.

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?

No annotations are provided, so the description carries the full burden, and it excels. It discloses the aggregation logic (9 indicators, weights, renormalization when components are missing), the ATH block details, the per-coin behavior for ETH/SOL (returning not_applicable for BTC-native indicators), the signal enum being a fixed score-band label rather than market-phase detection, the highlights and price_context blocks, and the fact that scores are point-in-time and not reconstructable. It even explains the z-score fields and the halving_context field. This is exemplary transparency.

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 description is long, but every sentence carries meaningful information. It is structured with a clear lead-in (core purpose), then detailed blocks for ATH, per-coin behavior, signal enum caveat, highlights, price_context, and related tools. The most critical facts (default asset, indicator aggregation, signal meaning) are front-loaded. It is dense but not redundant; it earns its length, though it could be tightened slightly without losing value.

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?

Given the complexity of the tool and the lack of an output schema, the description is remarkably complete. It explains what is returned (raw + Z-Score, signal enum, percentiles, ATH block, highlights, price_context), the meaning of the signal enum, the scoring methodology, and the relationship to other tools. It also covers edge cases (excluded indicators, not_applicable fields) and the non-reconstructability of scores. There is no missing information that would prevent 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?

The schema covers the single parameter (asset) with an enum and a brief description. The tool description adds substantial meaning: it explains the default value (BTC), the different behavior for ETH/SOL (price-derived indicators vs. not_applicable for BTC-native ones), and the implications of choosing each asset. This goes well beyond the schema's 'Which asset’s cycle' and provides context that helps the agent select the correct parameter.

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 clearly states what the tool does: 'Crypto cycle position — where are we in the cycle?' and specifies the default asset (BTC), the 9-indicator aggregation, and the optional per-coin read for ETH/SOL. It distinguishes from siblings like arena_get_cycle_history and arena_get_historical_analog by focusing on the current cycle snapshot rather than history or analog states. The verb is specific ('get'), the resource is unambiguous, and the scope (point-in-time aggregation) is explicit.

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?

The description explicitly names related tools and their purpose: 'Related: arena_get_historical_analog (what followed states like this one), arena_get_bullmarket_ampel, arena_get_pulse.' It also clarifies a key distinction: 'The volatility series itself is arena_get_volatility_history; this tool carries the regime context around it.' This tells the agent when to use this tool vs. alternatives, and what it does not cover. The guidance is direct and actionable.

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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It does this exceptionally well: explains the non-trivial delta_cagr computation, the bootstrap-based verdict logic, the gating and null reasons, the response structure, pagination behavior, and even that filters are evaluated in isolation with net vs gross distinction. Nothing is hidden; the tool's quirks (e.g., delta differs from filtered−baseline) are transparent.

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 description is long but every sentence carries substantive information needed for correct invocation given the tool's complexity and lack of output schema. It front-loads the core question and then cascades into details logically. While it could be restructured with sections, it avoids fluff and repetition. The length is justified by the information density.

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 tool with 5 parameters, no output schema, and complex gating/grouping behavior, the description is thoroughly complete. It explains the response envelope, per-strategy blocks, folding of empty cells, pagination with truncation, and the free-tier note. An agent has everything needed to call the tool correctly and interpret results without additional schemas.

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 baseline is 3. The description goes further by explaining the verdict parameter's nuanced meanings (already partially in schema but reinforced), the paging semantics (strategies per page), and how the strategy param restricts to a single key. It adds context about the response grouping that clarifies parameter effects, though some concrete param guidance (e.g., exact values for market) is already in schema.

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 opens with a clear question and then states the tool's purpose precisely: 'Platform-wide aggregated analysis: how each Pro+ entry filter affects strategy CAGR'. It mentions specific filter names and the exact metric (delta_cagr) and distinguishes its aggregated, platform-wide scope from the many sibling get_* tools that are per-strategy or narrower. The verb 'get edge reports' is clear and the description leaves no ambiguity about what resource is returned.

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?

The description gives detailed context about the tool's aggregation semantics, gating rules, and response grouping, but it never explicitly says when to choose this tool over alternatives like arena_get_strategy_filter_effect or arena_get_filter_insights. It implies it is the platform-wide edge analysis, but does not name alternatives or exclusion criteria. An agent would need to infer the differentiation.

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?

With no annotations, the description carries the full burden and does so thoroughly: it clarifies the apparent contradiction between acceleration_usd_m and the boolean accelerating, defines impulse states, explains that reversal_recovered_pct/reversal_basis_usd_m are null otherwise, documents source_inconsistencies dates, market_closed:true on NYSE holidays (closed market != zero flow), and availability timing. This is unusually rich behavioral disclosure.

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 purpose and result shape, and nearly every sentence carries unique field semantics. It is dense and formatted as one long block, which slightly hurts scannability, but little is wasted.

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 explain returns — and it does comprehensively: series contents, resolution, direction labels, null semantics, and provenance caveats. An agent has everything needed to call and interpret it correctly.

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 baseline is 3, but the description adds meaning: it ties format:'columns' to long-window efficiency, implies the 30d/90d windows that days spans, and notes the default asset. It goes beyond restating the schema even if the schema already covers most fields.

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?

Specific verb and resource: it exposes the spot-ETF net-flow TREND (30d/90d net flow, direction label, daily series) rather than point-in-time deltas, and explicitly contrasts itself with 'the summary' that only gives deltas. An agent can distinguish it from the many arena siblings without opening a 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 concrete selection guidance: pass format:'columns' for long windows, default asset is BTC with ETH/SOL alternatives, and use availability for point-in-time work. It stops short of naming a competing sibling or stating when NOT to use it, so it is clear context without explicit exclusions.

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?

With no annotations, the description carries the full burden and meets it: it discloses the default 90-day window, the size/position semantics of days vs end_date, the range block's requested/granted/available behavior, tier-based nulls for cadence/tempo on Free, and how cadence/tempo are computed. It also warns against misreading a short series as a young index.

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 description is long but front-loaded with the core answer and then walks through output, window semantics, tier behavior, and siblings in a logical order. A few rhetorical flourishes (e.g., 'a move or a plateau') are not strictly necessary, but the density is high and every substantive claim supports correct use.

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, yet the description explains the shape of the response (value, classification, history, range, cadence, tempo) and the tier differences on top of the schema's parameter detail. It also covers edge semantics such as end_date positioning and Free-tier nulls, making it complete enough to invoke correctly without further documentation.

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 schema already documents days and end_date exceptionally well, including the 2018-02 position, the last-day semantics, and the cap-not-position rule. The description restates the same mental model but adds little literally new about parameter syntax or meaning, so the high-coverage baseline of 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?

Description names the specific resource (Crypto Fear & Greed Index from alternative.me), the exact output fields (value, classification, history, cadence, tempo), and how it differs from adjacent tools by naming arena_get_cycle and arena_get_historical_analog. The 'get' verb is backed by concrete return content, so an agent knows immediately what this tool does.

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?

The description not only states when to use this tool ('to see whether today is a move or a plateau') but explicitly routes to alternatives: 'For the regime around a reading use arena_get_cycle; for what followed comparable sentiment states use arena_get_historical_analog(preset="deep_fear")'. This is explicit when/when-not guidance.

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?

With no annotations the description carries the full burden and does so well: it explains the sign convention, the exchange-averaging basis, the composition caveat via coverage/venues_present/venues_missing, and the 0.0001 base-rate clamp that could otherwise be misread as a capped value. It also flags the free-tier status.

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 question it answers, then progressively deeper interpretive detail. Dense but nearly every sentence adds decision-relevant meaning; the base-rate-clamp passage is long yet guards against a real misreading, so only mild trimming is warranted.

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?

No output schema exists, yet the description names the returned components (value, 30d moving average, Z-Score) and the diagnostic fields, covering everything needed to both call and interpret the result. Complete for a zero-parameter snapshot 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?

Zero parameters, so the baseline is 4 and there is nothing for the description to compensate for. The field-level guidance it provides (coverage, venues_present/venues_missing) concerns return values rather than inputs.

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: the latest BTC perpetual funding rate averaged across up to four named exchanges on an 8h cadence, plus 30d MA and Z-Score. An agent can distinguish it from siblings like arena_get_spot_price or arena_get_iv_snapshot without opening a 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?

Opens with the decision it answers ('Are longs or shorts paying right now?') and gives a clear interpretive caveat: read `coverage` before comparing values across dates because composition shifts can masquerade as market moves. It never names a sibling alternative or an explicit when-not, so it falls short of a 5.

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?

With no annotations provided, the description carries the full behavioral burden. It discloses the exact universe, the composite scoring model, the response shape including the `plain` summary and `scored_total`, tier-based limit gating, and daily refresh behavior. This is strong transparency for a read-only screener.

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 description is information-dense but every sentence earns its place: scope, scoring model, output format, validation credibility, tier limits, and refresh cadence. It is front-loaded with the most important question and contains no 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?

Given no output schema and no annotations, the description is remarkably complete for calling the tool correctly. It explains what the tool returns, how scores are composed, which top coins are included, and how the `limit` parameter interacts with the user's tier. Nothing critical 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 baseline is 3. The description adds meaningful parameter semantics by explaining that `limit` is tier-gated (Free top-10, Pro top-50, Power up to 200), which is not in the schema. It does not add much about `from_rank`, but the schema already documents it clearly.

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 verb and resource: it is an altcoin screener ranking of today's CoinGecko Top-200, scored by a composite of three named factor groups. The title and phrasing clearly separate it from sibling tools like arena_get_gem_score, which implies single-coin scoring, and arena_get_winners.

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?

The description gives clear context for when to use it — 'which altcoins look strong right now?' — and sets expectations with 'Backtest-validated factors, not a hype list.' It does not explicitly name alternatives or state when not to use it, so it stops short of a 5.

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?

With no annotations provided, the description carries full disclosure responsibility, and it delivers. It transparently discloses point-in-time integrity, look-ahead-free episode matching, small-n warnings, the 'study_finding' field with NULL results, the vs_unconditional_drift separation and its interpretation (excess can be negative while raw median is positive), circularity suppression for horizons within direction_window_days, and the fact that study_finding_applies=false when non-default parameters are used. It also clarifies that quiet_volatility's vol_rank_threshold has fixed steps and different semantics. No contradictions with any structured metadata exist.

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 description is long but exceptionally information-dense and front-loaded. It opens with the core purpose, then systematically covers output fields, parameter nuances, asset limitations, and related tools. While it could be broken into bullet points for scannability, every sentence carries unique information and none is filler. The length is justified by the tool's complexity (6 parameters, 5 presets, multiple conditional behaviors). It loses a point only for being a single dense paragraph that might overwhelm an agent scanning quickly.

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?

Given the tool has no output schema and no annotations, the description must compensate for both. It does so comprehensively: it explains the return structure (median/IQR, positive-share, per-horizon n, small-n warnings, evidence block with gate_applies_to), the preset definitions and their semantics, asset support restrictions, the special quiet_volatility parameters and their implications, and the relationship to unconditional drift. It even notes which presets carry study_finding fields. For an agent to call this tool correctly and interpret results, nothing critical 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?

Even though the input schema covers 100% of parameters with descriptions, the tool description adds substantial meaning beyond the schema. It explains the conceptual meaning of presets (e.g., 'cycle_bottom_cluster' as a named condition set), the special default behavior for forward_horizons under quiet_volatility, the semantic difference between vol_rank_threshold values (50 vs 5/10/20) and the 'unusually quiet' interpretation, and the directional conditioning semantics. The description enriches the schema with protocol-level nuance (e.g., horizons beyond study are flagged as outside protocol) that is not present in the schema fields.

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 opens with a concrete question ('What happened historically after the Bitcoin cycle looked like this?') and defines the tool as a 'Conditional forward-return distribution for a named preset cycle state.' It specifies the verb (returns a distribution), the resource (historical analog episodes), and the distinguishing feature (point-in-time, look-ahead-free matching). It also names three sibling tools and when to use them, clearly differentiating itself from the broader family of arena_get_* dataset tools.

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?

The description states explicit usage context: it is not obtainable from web search or public APIs and requires point-in-time history and look-ahead-free episode matching. It names related tools (arena_get_volatility_history, arena_get_cycle, arena_dip_scenario) and states when each is appropriate. It also spells out asset restrictions (ETH/SOL only for price-derived presets) and parameter-specific usage (vol_rank_threshold, condition_on_direction only for quiet_volatility). No ambiguity remains about when to invoke this tool versus alternatives.

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?

With no annotations, the description carries the full burden and delivers: percentile rank methodology, ATR normalization, OBV slope normalization, null percentile thresholds, additional weekly/4w fields, state naming, and the null-result verdict behavior. This is far beyond a generic read snapshot.

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?

Long but information-dense; every sentence adds a distinct behavioral or interpretive fact. Front-loaded with the core question and indicator list, then caveats, then related tools. No 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?

For a 2-param read tool with no output schema, this is unusually complete: it covers what is returned, how metrics are computed, when percentile is null, what extra fields appear, and related tools. An agent can call it correctly without further documentation.

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 already documents pair and interval 100%. Description adds meaning by explaining interval='1w' changes all indicators to weekly bars, and gives example pairs. It also explains the threshold behavior tied to interval, so it adds value beyond the schema.

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 opens with a concrete question and enumerates the exact indicators (RSI(14), MACD(12/26/9), Bollinger(20,2), ATR(14), OBV) plus percentile ranks, making the resource and scope unmistakable. It also distinguishes itself from sibling tools by naming related tools and their different purposes.

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 explicitly lists related tools with parentheticals explaining what each is for, and tells the user to set interval='1w' for the weekly view. It doesn't provide strict when-not-to-use rules, but the context is clear enough to route an agent.

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?

With no annotations provided, the description fully bears the burden of behavioral disclosure. It reveals the exact fields returned, the semantics of both trailing and forward risk premiums (including their non-interchangeability and sign opposition), what include_implied adds, the edge case of recent 30 days with premium_complete=false, and source/history dates. This is comprehensive and goes far beyond a bare 'get snapshot' statement.

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 description is dense but each sentence contributes: purpose, returned fields, flag behavior, edge cases, source, and history. Use of bolding, backticks, and code-style names aids scannability. It is longer than typical but not bloated; it earns its length. A minor deduction for not front-loading the most common usage (snapshot) vs. the detailed metric explanations.

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 tool with no output schema, the description covers all essential returning fields and their meanings, the optional block, data availability caveats, and historical start dates. It tells the agent exactly what to expect in the response (e.g., implicit JSON structure with an 'implied' block). Nothing critical is missing for correct invocation or interpretation.

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% (both params described), so baseline is 3. The description adds substantial meaning: it explains that include_implied appends a forward premium block, clarifies the difference between trailing and forward premiums, details the implied block fields, and notes the exclusion of incomplete recent data. For currency, it reinforces the BTC/ETH scope. This far exceeds merely restating schema.

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 clearly states it returns the latest Deribit volatility snapshot for BTC or ETH, enumerating specific metrics (DVOL, implied vols, realized vol, premiums). It distinguishes itself from siblings like arena_get_volatility_history by emphasizing 'latest snapshot' and answering 'are options priced expensively right now?'. The verb+resource is explicit and differentiated.

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 provides a clear use case ('are options priced expensively right now?') and explains when to set include_implied (to answer a different forward-looking question). It also warns about the non-interchangeability of trailing and forward premiums and the incomplete recent 30 days. However, it does not explicitly name alternative tools or state when to prefer history/insights siblings over this snapshot tool, leaving some ambiguity for an agent choosing among many volatility tools.

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?

No annotations are provided, so the description carries the full burden, and it delivers: it discloses the status lifecycle (pending/running/completed/failed), the intermediate progress fields (progress_pct, pairs_completed), and the transition to full results upon completion. It does not address polling cadence or rate limits for a repeated-poll operation, which would strengthen it further.

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?

A single dense sentence that front-loads the question, states the verb, names the provenance, and enumerates return fields with no filler. The opening conversational fragment is slightly unusual for a formal definition but works well for orientation; otherwise it is tightly packed with no wasted 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?

For a simple one-parameter polling tool with no output schema, the description covers purpose, usage provenance, the parameter, and the return shape across lifecycle states. Minor gaps are the absence of error/status semantics (e.g., handling of failed jobs) and no recommended polling interval, but the core is complete.

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 schema already describes job_id as the UUID returned by arena_run_universe_backtest. The description's reference to job_id largely restates what the schema provides, adding minimal beyond-schema meaning, so the baseline of 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?

The description states a specific verb ('Polls') and resource (async job by job_id) and orients the reader with the opening question 'Is my universe backtest finished?'. It names the provenance tool (arena_run_universe_backtest), which clearly distinguishes this polling endpoint from sibling sync-retrieval tools like arena_get_backtest and arena_get_report_status.

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?

The description implies the usage context clearly: it polls an async job created via arena_run_universe_backtest, and it notes the [Free tier] cost signal. It does not explicitly name alternatives or state when not to use it, but the 'created via' provenance effectively separates it from synchronous backtest retrieval siblings.

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?

With no annotations provided, the description carries full behavioral burden. It adds meaningful context: levels are 'reproducible', 'measured price clusters' not 'defended levels', and notes a free tier. It discloses that the two classes are kept separate on purpose. This goes beyond a generic 'get levels' description, though it does not mention rate limits or response format.

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 description is somewhat long but well-structured with a front-loaded question and clear numbered classes. Every sentence adds distinct information (provenance, purpose, free tier). No redundancy, but slightly verbose for a zero-parameter tool.

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 zero-parameter, no-output-schema tool, the description is complete. It explains what levels are included, how they are derived, the separation of classes, and the free tier limitation. Nothing essential is missing for an agent to invoke the tool correctly.

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?

The input schema has zero parameters, so the baseline is 4. The description correctly focuses on the output content rather than parameter details, which is appropriate. No further parameter clarification is needed.

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 verb ('Get') and resource ('BTC Key Levels') and immediately clarifies it returns structural levels in two provenance classes (pivot clusters and indicator levels). It clearly distinguishes this from the many sibling tools by enumerating what is included, without needing to compare to others.

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?

The description implies usage: it answers 'Which price levels matter above and below spot?' and explains the two classes. However, it does not explicitly name alternative tools or state when not to use this tool. Given the large sibling list, more explicit routing (e.g., 'for indicator-only values use arena_get_indicator_snapshot') would improve clarity, but the context is understandable.

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?

With no annotations provided, the description carries the full behavioral burden. It discloses the exact return envelope (payload, explanation, provenance, ontology binding, compute version), notes the objects are versioned and published, and explains the include_graph extension with edge details (api_path + seo_slug). It also mentions per-object access gating by min_tier. These are substantive behavioral disclosures beyond a simple 'fetch' description, though it omits error or rate-limit behavior.

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?

Well-organized: starts with a framing question, then purpose, response envelope, scope ('ONE tool'), graph extension, and access note. The rhetorical opener adds flavor but every following sentence delivers concrete information. It is slightly long but efficiently structured with key details front-loaded.

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?

Comprehensive for a tool with no output schema. It specifies the full return envelope fields, the graph traversal behavior with edge attributes, and the access gating condition. The scope clarification and examples ensure an agent can call it correctly without needing an output schema. All essential information for successful invocation is present.

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. The description adds practical value by giving example values for type and subject, clarifying that as_of defaults to the latest when omitted, and explaining the effect of include_graph on graph traversal. These clarifications go beyond the schema's brief property descriptions, making the parameters more actionable for an agent.

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 'Fetch' and resource 'Knowledge Object' by type and subject, with concrete examples (type='market_regime', subject='GLOBAL'). The phrase 'ONE tool covers ALL knowledge types' clearly differentiates it from the many specific arena_get_* siblings, establishing that this is the general knowledge retrieval tool. The description is unambiguous and immediately scopes the operation.

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?

Provides clear context by stating it covers ALL knowledge types, which implies it is the general-purpose alternative to the numerous type-specific getters (e.g., arena_get_macro_regime, arena_get_btc_market_structure). It gives practical examples and explains the optional include_graph for graph traversal. However, it does not explicitly enumerate when-not-to-use cases or name specific alternatives, so the guidance is strong but not fully exhaustive.

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?

With no annotations, the description carries the full burden and does so thoroughly. It discloses FRED sourcing, stale-component freshness quantification, discontinued flags, and detailed semantic caveats for component keys like vix_score, broad_dollar_index, fed_funds_rate, and global_m2_yoy. It even documents removed legacy names, giving agents strong behavioral grounding.

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 description is long but front-loaded with the core snapshot summary and output fields. The caveats are dense and mostly necessary given the absence of an output schema, though a few details (deprecation history, 'Free tier') could be trimmed without losing essential guidance.

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?

Because there is no output schema and no annotations, the description must fully specify return values and interpretation. It does: composite_score, regime_label, cycle_phase_label, matrix_quadrant, tier_scores, components, stale_components_detail, and component_notes are all described. It also explains freshness quantification and key naming traps, making it complete for a zero-parameter snapshot 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?

The tool has zero parameters and schema coverage is 100%, so the baseline is 4. The description adds no parameter-level semantics because there are none to document; it instead uses the space to explain output semantics, which 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 opens with a specific question ('What is the macro backdrop doing?') and names a concrete resource: a Daily Macro Regime snapshot built from 18 components in 6 tiers. It clearly distinguishes this from sibling tools by focusing on the composite macro regime output rather than single indicators or strategies.

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?

The intended use case is clear: retrieve the current macro backdrop as a daily snapshot with composite scores, regime labels, and tier breakdowns. It does not explicitly name alternative tools or state when not to use it, so it stops short of a 5, but the context is unambiguous.

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?

With no annotations, the description carries the full burden and discharges it unusually well: it discloses the collection cadence ('Cron collects daily 02:00 UTC from Deribit Public API'), the ~10 min GEX cache and that gex_data_as_of is a different observation time than the snapshot fields, the dealer-sign ASSUMPTION with both conventions published, the structural (not missing) null in short-all zero_gamma_level, and the historical recomputation of pre-2026-08-31 rows. These are exactly the provenance/assumption caveats an agent would otherwise misread.

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 answer is front-loaded (the core question leads), which is good, but the passage runs several hundred words and re-explains the GEX and strike-ladder parameters in nearly the same detail the input schema already provides, so those sentences do not fully earn their place. Density is high but so is duplication.

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 and this is a rich options-analytics payload, yet the description defines the key fields (max_pain_strike, spot_at_expiry per venue, open_interest_contracts vs total_contracts, total_notional_usd vs open_notional_usd, oi_available, nested expiry flags, ladder and GEX blocks) and their observation-time distinctions. An agent has enough to interpret results correctly without further documentation.

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 all four parameters in near-identical terms, establishing a baseline of 3. The description adds limited marginal value (rationale that ladder/GEX responses get large, notes about nesting expiry flags), and the statement 'Pass `market` to switch venue (DERIBIT_BTC default, IBIT)' actually conflicts with the schema enum, which permits only DERIBIT_BTC and states IBIT is no longer delivered.

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 framing ('What happened at the last Deribit expiry? Max pain and how spot settled against it') and enumerates the concrete return fields (max_pain_strike, spot_at_expiry, put_call_ratio, notional) plus up to 10 upcoming expiries, so the resource and scope are unambiguous. It also names two siblings (arena_get_max_pain_history, arena_get_iv_snapshot) with their distinct roles, letting an agent route without opening either 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?

It routes explicitly: history tool for 'base rates + daily snapshots', iv_snapshot for 'implied vol for the same expiries', and it tells the agent to pass expiry_date when combining ladder/GEX because 'the full ten-expiry response with both is large'. What's missing is any negative guidance on when NOT to call this (e.g. vs live spot/options tools), so it stops short of a 5.

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?

With no annotations provided, the description carries the full burden and does so thoroughly: it discloses that max-pain levels are its own aggregation (chain not redistributed), that IBIT is no longer delivered due to licensing, that open snapshots start on a fixed date and are not backfillable, that days are tier-capped, and that base_rates are computed before expiry_type filtering. No contradictions.

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 description is long but every sentence earns its place: purpose, data contents, base_rates rationale, filtering advice, open-snapshot caveats, tier caps, source, and related tools. It's front-loaded with the core question and logically organized, though slightly dense.

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 6-parameter tool with no output schema and no annotations, the description is fairly complete: it explains the row contents, the base_rates block, the open_snapshots series and its caveats, and the tier caps. It could explicitly list the response fields or pagination, but the main behavioral aspects are covered.

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 covers all 6 parameters with detailed descriptions (e.g., market explains IBIT exclusion, expiry_type explains filtering). The description adds extra semantics: explains the base_rates block, that base_rates are computed before the filter, that snapshot_expiry_date is only meaningful with include_open_snapshots=true, and the tier caps on days. Adds value beyond the schema.

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 opens with a specific research question ('Does max pain actually pull price to the strike?') and states the exact resource: settled Deribit BTC options expiries with computed max-pain levels. It clearly differentiates from siblings by naming arena_get_max_pain (current + upcoming) and arena_get_iv_snapshot as related, and by describing its unique historical/convergence focus.

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?

Provides explicit guidance on how to filter (use expiry_type/min_contracts/snapshot_expiry_date instead of post-processing), explains why per-class base_rates are preferred over pooled medians, and warns to check open_snapshot_coverage before computing anything. Names related tools for current/upcoming data, though it doesn't explicitly state 'use this for X, not Y' with direct contrast.

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?

With no annotations, the description carries the full burden. It discloses that values are as-reported and can be revised retroactively (not point-in-time), and it transparently explains tier-based clamping via the 'range' block. It could add more on response format or error behavior, but the key caveats are covered thoroughly. The lack of annotations is mitigated by this strong prose.

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?

Every sentence earns its place. The description leads with intent, explains the data, routes to alternatives, and flags caveats. It is dense but not bloated, and it front-loads the core function. The structure is a model of clarity without superfluous wording.

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 time-series tool with no output schema, the description covers the essential contextual needs: what is returned, how to use it, alternatives, data revision caveat, and tier clamping behavior. It omits explicit mention of pagination or exact number of data points, but the range block and history depth are explained. Minor gaps but overall complete enough for an agent to call confidently.

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 parameters are documented. The description adds value by explaining the 'days' parameter's interaction with tier limits (Free 30d / Pro 365d / Power unlimited) and by mentioning the 'range' block that reports clamping. It also gives an example series_id ('mvrv'). This goes beyond the schema's basic descriptions, enriching the semantics.

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 clearly states the tool returns the full time series of one on-chain metric as date/value pairs, with history back to 2009. It distinguishes itself from siblings by explicitly naming arena_get_onchain_latest for single readings and arena_list_onchain_series for discovering series IDs. The verb 'returns' and resource 'time series' are specific and actionable.

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?

Provides explicit guidance: 'for the single current reading call arena_get_onchain_latest, and to discover valid series_ids call arena_list_onchain_series.' It also states the intended use case ('trend and percentile work'). This is a textbook example of alternating tool routing with clear 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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool returns a single reading, notes it has no context ('A single reading has no context') and advises pairing with the series percentile, and hints at cost with '[Free tier]' and 'Cheapest way'. While it doesn't explicitly say 'read-only' or cover error behavior, the description provides substantial operational context beyond the bare function.

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 description is front-loaded with the core purpose and output format, then adds practical guidance (alternatives, context warning, free tier) in a compact set of sentences. Every sentence earns its place: the opening question captures intent, the return format is explicit, and the caveat prevents misuse. It is dense but not bloated.

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 tool is simple (1 parameter, no output schema), and the description covers everything an agent needs: the return shape, how to discover valid inputs, the relationship to history, and a usage pitfall (single reading lacks context). Since there is no output schema, the explicit field list is essential and provided. Nothing critical 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?

The schema already covers the parameter with examples ('mvrv', 'sopr', 'realized_price'), so baseline is 3. The description adds value by explaining that series_ids come from a separate listing tool and by reiterating the output fields, which clarifies how to interpret the response. This goes beyond merely restating the schema and compensates slightly for the lack of an output schema.

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 action ('Returns the most recent value of ONE on-chain series') with a concrete output format and examples ('MVRV, SOPR, realized price, hash rate'). It clearly distinguishes itself from arena_get_onchain_history by contrast, and names the discovery tool arena_list_onchain_series. The purpose is unambiguous and immediately separates it from dozens of siblings.

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 explicitly frames the tool as 'Cheapest way to answer "what is X right now"' and gives direct alternatives: 'for the history behind the number use arena_get_onchain_history' and 'Discover valid series_ids with arena_list_onchain_series'. This tells the agent exactly when to use this tool versus its siblings, leaving nothing 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?

Given no annotations are present, the description carries the full responsibility of explaining behavior, and it does: it discloses the frozen vs. live preliminary state, the cron-based daily freeze, and the percentile comparison base. It wisely doesn't include what happens on failure or the exact caching, but the most important behavioral nuance is there.

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 description is three sentences but avoids wasted words: it leads with the core question, enumerates components and outputs, and then adds the crucial interpretation detail. It is slightly long, but for a helper with no output schema every sentence provides useful knowledge that would otherwise have to be discovered at runtime.

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?

Because there is no output schema, the description is the sole guide to the return shape: it lists all fields and explains score_percentile with a concrete example. It also covers the cron/frozen context and the [Free tier] access notion. The only missing piece is a note about error behavior when no data exists, but otherwise an agent can call and interpret the response correctly.

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?

With zero parameters, schema coverage is trivially 100%, so there is nothing missing for the agent to clarify. The description mentions score_semantics, which is a value of the returned object rather than a parameter, and this does not confuse the param attributes. Baseline for a 0-param tool is 4, and no deduction is warranted.

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 explicitly states it provides a daily 0-100 heat score for the Bitcoin market, lists the 8 component indicators, and names all the return fields (score, band, color, delta, verdict, components, percentile). This makes it easy to tell apart from the many sister get_* tools in the sibling list.

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?

The description conveys the context that this is a current-day snapshot and introduces the cron/live semantics, but it never spells out when to prefer it over alternatives such as arena_get_pulse_history or other single-indicator getters. There is clear implied usage but no explicit when-not/exclusion guidance.

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?

With no annotations, the description fully owns behavioral disclosure. It reveals that the tool is read-only and look-ahead free, states the honest small-n handling (no DSR-N claimed under 15 neighbors), and explicitly labels the parameter axis as 'always anecdotal'. It also explains the counted-N logic for DSR, providing a complete picture with no contradictions.

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 description is dense but every sentence carries value: the hook, the input, the output, the caveat about small-n, and the axis distinction. It is front-loaded with the core question and adds specifics in a natural progression, with zero filler or redundancy.

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?

Given the tool's complexity (8 params, nested object, no output schema), the description is remarkably complete: it explains the output shape (distribution metrics, verdict, DSR threshold), the edge case handling, and the semantic difference between axes. An agent can confidently call this tool without additional inference.

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 each parameter is already documented. The description adds meaning by explaining the conceptual role of params ('Only numeric params define the neighborhood'), how user_sharpe feeds into the counted-N DSR, and what axis values mean. This goes beyond a bare schema listing, though it doesn't re-explain each field individually.

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 opens with a direct, specific question ('Is this backtest result real, or a lucky cell?') and a clear verb ('Assess one backtest result against its neighborhood'). It names the exact resource (a strategy+interval+pair cell) and what it returns (distribution, verdict, DSR), making it unmistakably distinct from sibling tools like arena_get_backtest or arena_is_distinguishable, even without naming 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?

The description explicitly contrasts this tool with a naïve approach ('instead of trusting a single "+X% CAGR" cell'), giving a clear when-to-use. It also provides conditional guidance: 'Set axis="parameter" for the secondary, always-anecdotal view' and explains the small-n rule ('fewer than 15 neighbors → "insufficient"'). This is actionable and non-ambiguous.

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?

With no annotations, the description carries full behavioral burden and handles it exceptionally. It discloses that 'anticipated is always false' before candle close, that edge_vs_benchmark is gated by the measured noise floor with artifacts flagged, that contradictions are reported but never resolved, that each source can fail independently with auditable sources_used/sources_unavailable, and that the answer never silently narrows. This is comprehensive disclosure beyond what any schema could provide.

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 description is long but every sentence earns its place. It front-loads the core question, then logically organizes the response blocks, caveats, error handling, and composition guidance. Dense with actionable information but never verbose or repetitive, making it efficient for an agent 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 complex tool with no output schema, this description is remarkably complete. It explains the response structure (filters[], edge_vs_benchmark, contradictions, invalidation zones), the detail modes, source auditability, failure independence, and the confidence/reason block. Unusual edge cases like the pre-candle-close signal state and the noise-floor artifact are explicitly covered. Nothing an agent needs to call and interpret the result 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 provides rich descriptions for all four parameters, including the alignment caveat for multi-day intervals and the detail enum values. The description reinforces these meanings but doesn't add new parameter-level semantics beyond what the schema already documents, so the baseline of 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 opens with the exact question it answers ('Should I take this entry?') and states the precise scope (one strategy/pair/interval in one call instead of seven). It explicitly differentiates from sibling arena_get_strategy_filter_effect by showing how it aligns historical filter effect with current signal state. The purpose is unambiguous and distinctive.

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?

Provides clear context: it's a one-call replacement for a seven-call flow, and it names two companion tools for composition (arena_get_strategy_performance_by_regime and arena_is_distinguishable). However, it doesn't explicitly state when NOT to use this tool or list mutually exclusive alternatives, so it's a slight step below the highest bar.

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?

With no annotations provided, the description carries the full burden. It discloses the data source (Binance), freshness ('Live'), and that it is on the free tier, implying accessibility. While it doesn't mention rate limits, authentication, or response structure, for a no-parameter read tool this is reasonable. No contradiction exists.

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 description is three sentences with no fluff. The core purpose is stated first, followed by specific data details and a practical usage note. The '[Free tier]' tag is a useful addition without verbosity. It is well-organized and front-loaded.

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?

Given the simplicity of a no-param get with no output schema, the description adequately conveys what is returned (prices, change, high/low), the source, and the intended use case. It does not explicitly state that all three assets are returned simultaneously, but the wording implies it. Minor ambiguity aside, it is complete enough for an agent to call correctly.

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?

There are zero parameters, so the schema provides no semantic detail; per the rubric, the baseline for 0 params is 4. The description doesn't need to explain parameters and does not attempt to, so it maintains the baseline without additional 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 explicitly states the tool retrieves the current BTC, ETH, and SOL spot price, and specifies the exact data points: USDT-quoted last price, 24h change %, high, and low, sourced from Binance. The phrase 'what is Bitcoin (or ETH/SOL) worth right now?' makes the purpose immediately clear, and it is distinct from siblings like funding rate or fear-greed tools.

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?

The description directly instructs to use this tool to anchor the connector's analytics (cycle, historical-analog, gem scores) with current market price, and explicitly says 'instead of switching to web search mid-analysis.' This provides clear context and an alternative (web search), though it doesn't name specific sibling tools, which is acceptable given the large sibling list.

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?

With no annotations, the description carries full behavioral burden and does well: it discloses the data source (DefiLlama peggedUSD), the free-tier status, and the structure of the returned trend (current supply plus 30d/90d change and a daily series). It explains tricky field semantics such as what `impulse` states mean, how `acceleration_usd` behaves on reversal, and why it can be large while `accelerating` is false. Return format is described at concept level, though exact response shape is left undefined since no output schema exists.

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 single paragraph is front-loaded with the tool's purpose and then elaborates on field interpretation. It is dense and information-rich without being repetitive; a minor deduction for packing several concepts (trend, impulse, acceleration_usd, accelerating) into a long sentence that could be split for scanability.

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?

Given one optional parameter, no annotations, no output schema, and a complex set of sibling tools, the description supplies enough conceptual guidance about returned fields and their interpretation to call and use the tool correctly. It remains slightly short of fully describing the response shape, but no output schema exists, so the conceptual description is reasonable.

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?

Only one parameter exists and schema coverage is 100%, so baseline would be 3. The description goes beyond the schema by restating the default (365), the control over both points and spacing via `resolution`, and the effective meaning of `days` for the series length. That is real added value over the schema's clamp range.

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 verb and resource ('Aggregate stablecoin supply') and explicitly differentiates itself from the sibling 'macro_regime,' which 'only gives the 30d delta.' This distinguishes scope and intent clearly. It stops just short of 5 because the routing language names one sibling but doesn't provide a positive selection rule across the broader toolset.

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 a clear context for use - determining whether the liquidity impulse is turning or accelerating - and explicitly contrasts the tool with arena_get_macro_regime as the alternative for a single 30d delta. There is no explicit 'when not to use,' but the comparative framing is strong enough to route an agent.

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?

With no annotations, the description carries the full burden and does this well: it discloses the 730-day rolling sigma window, the 'own convention' construction, the band coverage caveat, and the free-tier status. There is minor ambiguity about whether sigma_method/sigma_window_days are response fields or request payload fields, but overall the behavior is unusually well disclosed.

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 description opens with a plain-language hook and then layers definitions, output fields, and interpretive caveats in a sensible order. It is dense and somewhat long, but the measured-coverage statistics and convention caveat earn their place by helping the agent interpret the bands.

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 no-argument latest-value tool, the description is nearly complete: it names the returned metrics, explains band construction, and tells the agent how literally to read the bands. With no output schema, explicit units and exact response field names would be the only meaningful additions.

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?

The input schema has zero parameters, so there is nothing for the description to document and the baseline is 4. The mention of sigma_method/sigma_window_days 'traveling in the payload' is slightly confusing against the empty schema, but it does not harm parameter understanding because no parameters exist.

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 exact resource (BTC short-term-holder cost basis) and the operative action (get latest), then enumerates the derived metrics: STH-MVRV, in_loss flag, sigma bands, band_zone, and percentile. This makes it clearly distinct from the large sibling list, especially with the explicit 'own convention — not a rebuild' note.

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?

The intended use is implied: an agent needing the latest STH cost basis and how far spot is from it can infer this tool fits. However, there is no explicit 'when not to use' or a pointer to sibling alternatives such as arena_get_cost_basis_spread or arena_get_onchain_latest, so routing guidance 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?

With no annotations, the description carries the full burden and does so well: it discloses the baseline+variant structure, delta metrics, the best_by_cagr null-and-reason logic, the data gate, the not_applicable_filters list, and the time-normalization/window caveat. It omits auth or rate-limit context, but the behavioral semantics of the call are unusually rich.

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 with parentheticals but front-loaded with the guiding question, and each clause carries signal (deltas, gate logic, window caveat). Slightly heavy but nearly every sentence earns its place.

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 no output schema and a genuinely complex return shape, the description explains the baseline/variant/delta/pick structure thoroughly enough that an agent knows what to expect. Nothing essential for correct invocation appears 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 schema already documents asset, interval (including the alignment caveat) and strategy. The description adds little parameter-level meaning beyond what the schema provides, so the baseline of 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?

Opens with a concrete question ('What would each entry filter have changed for this strategy?') and immediately narrows scope to per-(strategy, asset, interval) filter-effect analysis, distinguishing it from sibling analytics like arena_get_filter_insights and arena_get_strategy_insights. An agent can tell what resource this operates on without opening another 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?

Provides an explicit use case: 'Use this to answer "Which filters would improve my backtest for X on Y?"'. This gives clear context for selection, but does not name a when-not condition or a specific alternative sibling tool for adjacent questions.

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?

With no annotations present, the description carries the full behavioral burden and does so: free-tier strategy caps plus `plan_capped`/`plan_cap_note`, 403 rather than silent empty detail on Pro-only strategies, and precise definitions for `runCount`/`inertRuns`/`runs_total` and `avgWinRate`. It also discloses the >=50% `bhAssetCoverage` gate before benchmark fields are shown, which is exactly the kind of non-obvious behavior an agent needs.

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?

It is long, but front-loaded with the purpose and mode logic before the definitional detail, and each clause (counts, win-rate definition, benchmark gate, free tier) earns its place given there is no output schema. Slightly dense for a single paragraph.

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 complex, zero-annotation, no-output-schema tool, the description covers mode selection, error behavior, tier limits, return-field semantics and the embedded definition envelope. An agent has everything needed to call it correctly and interpret the response without guessing.

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 baseline is 3, but the description adds mode semantics the schema does not: `strategy`+`interval` jointly select detail mode, `min_runs` is matrix-only, and it names the free strategies explicitly. The `ref_strategy`, `asset_type` and `assets_mode` params get no added meaning beyond the schema.

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 opening question and the phrase 'Aggregated backtest performance per (strategy × interval) cell' give a specific verb and resource, and the matrix/detail duality is spelled out. It does not, however, explicitly differentiate itself from close siblings such as arena_get_strategy_performance or arena_compare_strategies, so an agent must infer the split from the schema shape.

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?

Routing is well specified internally: supplying both `strategy` and `interval` yields detail (with a 403 for Pro-only strategies), otherwise the matrix, and `min_runs` is scoped to matrix mode. There is no guidance on when to prefer this over the sibling performance/compare tools, which keeps it below 5.

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?

No annotations exist, so the description carries the full burden. It discloses not just the return fields but also the machine-readable `evidence` block, the gate threshold (5 runs), and a critical behavioral nuance: the interval alignment issue for 2d/3d candles and its measurable impact on CAGR (6.66 pp on average). This is rich, honest behavioral disclosure beyond any annotation.

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 description is dense but every sentence earns its place: the opening question orients the agent, the return list is compact, the sibling pointer is explicit, and the interval caveat is crucial. It is longer than the two-sentence gold standard but not bloated; a 4 reflects the tight packing rather than fluff.

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 5-parameter tool with no output schema, the description provides a complete picture: it names the output fields and their sematics (including the evidence block with gate_applies_to, threshold, benchmark, aggregation window), states the defaults, and covers the alignment caveat that could otherwise lead to misinterpretation. An agent has everything needed to invoke and interpret results correctly.

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 baseline is 3. The description adds value by specifying defaults for `interval` and `ref_strategy` (not in the schema) and by explaining the alignment-dependent behavior of multi-day intervals — semantic nuance that materially affects result interpretation. It stops short of fully explaining `asset_type` disambiguation beyond what the schema already says, hence 4 rather than 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 verb ('Get'), a precise resource ('strategy performance snapshot per asset'), and clearly delimits scope ('ONE specific (strategy, asset, interval) combination'). It lists the exact returned fields and explicitly distinguishes this from the multi-strategy sibling `arena_get_strategy_insights`. No ambiguity about what the tool does.

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 when-to-use ('Use this to answer ...') and names the alternative for multi-strategy overview (`arena_get_strategy_insights`). This is enough for an agent to choose correctly, and the contrast with the sibling is clear.

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?

With no annotations, the description carries the full burden and does so well. It discloses that regime classification happens at trade entry date, that trades_per_config counts all parameter-variant configs, that avg_pnl_pct is not annualized, reward_risk_ratio is not annualized Sharpe, and that share_of_time_pct is calendar-day-weighted to avoid cadence skew. It also explains the benchmark anchor's purpose. Minor gaps remain around the rating scale and live regime presentation.

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 description is dense and informative, but it is long and structured as a single block, which reduces scannability. Many parentheticals and qualifiers are valuable, but some could be trimmed or front-loaded more effectively. It earns a mid-range score because every sentence carries meaningful content, but formatting and pacing are not optimal.

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?

Despite having no output schema, the description compensates by enumerating most returned fields and their semantics, explaining the benchmark block, and addressing the large interval caveat. It also references sibling tools for composition. Missing details such as rating scale or live regime format are minor. Overall, the description is robust enough for an agent to call and interpret results correctly.

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. The description adds meaningful context beyond the schema, especially for the interval parameter: it warns that multi-day candle alignment can move CAGR by 6.66 pp on average and that 1d/2d/3d behaved as one block. This enriches interpretation of the interval parameter. The description doesn't add much for asset or asset_type, but the schema already covers them.

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 verb and resource: it retrieves historical backtest performance split by macro regime for ONE (strategy, asset, interval) combination. It also distinguishes itself from related tools by clarifying that per-bucket verdicts live elsewhere and that the benchmark block matches arena_get_strategy_performance. This provides clear differentiation.

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?

The description gives clear context for when to use the tool: when you need per-regime numbers to weigh directly and align with the current live regime. It also suggests composing with arena_get_strategy_filter_effect and arena_is_distinguishable for a decision-grade view. It lacks explicit when-not-to-use instructions, but the guidance is adequate.

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?

With no annotations provided, the description fully carries the burden of behavioral disclosure. It explains the survivorship bias without as_of, the forward-only nature of point-in-time universes, the rejection of earlier dates, and the difference in ranking methodology (market cap vs 24h quote volume). This is exemplary transparency for a tool with subtle behavioral nuances.

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?

While long, every sentence earns its place. The first sentence states the core purpose; subsequent sentences cover usage guidance, the as_of semantics, the bias warning, and the free tier. Information is front-loaded, and the structure flows logically from purpose to parameters to caveats. No fluff.

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 tool has inherent complexity (current vs point-in-time membership, survivorship bias, forward-only recording), and the description addresses all of it. It tells the agent exactly what is returned and how to interpret the as_of parameter. No output schema exists, so the description's explicit statement of the return fields ('id, label, selection rule and the complete list of pairs') covers that gap. Nothing an agent needs 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?

Even though schema description coverage is 100%, the description adds substantial meaning beyond the schema. For as_of, it clarifies the format, the minimum date (2026-07-14), the definition of 'measured on that day', and the consequence of using it (no survivorship bias). For universe_id, it implies the format via the example. This goes well beyond the schema's terse descriptions.

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 verb ('Returns') and resource ('one pair universe in full') and enumerates the exact fields (id, label, selection rule, complete list of pairs). It clearly distinguishes itself from arena_list_universes and arena_run_universe_backtest by naming them as siblings with different purposes.

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 explicitly tells when to use the tool: 'to see what you are about to test BEFORE handing a universe_id to arena_run_universe_backtest, or to resolve a universe into explicit pairs.' It also names the alternative for listing universes ('call arena_list_universes'). No ambiguity remains.

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?

With no annotations, the description carries the full burden and does so richly: it discloses the free-tier 365-day cap, that ATR is null before the Binance era, that history reaches 2009 via a stitched series, that rvRank/atrPctAnnRank are look-ahead-free but trend-biased while the Rolling variants are not, and that the size block measures savings. These are non-obvious behavioral traits an agent could not infer from the schema.

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 question ('How volatile has Bitcoin been?') front-loads the purpose, and each subsequent sentence carries distinct information (rank semantics, coverage caveats, affordability knobs, related tools). It is dense and long, but not padded — though the savings/format guidance could be tightened for an agent skimming 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?

No output schema and no annotations, yet the description names the returned fields, explains the two rank families and their trade-offs, documents data-coverage limits (ATR null pre-Binance, 2009 stitching, free-tier window), and points to the meta.coverage/size blocks for self-description. Nothing an agent needs 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 description coverage is 100%, so the baseline is 3; the description goes beyond it by explaining the rank-flavour distinction behind rvRankRolling, why `format: "columns"` produces the largest saving, how fields/granularity/format combine in the size block, and that schema_version 2026-08 is opt-in with a default flip date. It adds real interpretive value without re-documenting the enum values already in the schema.

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 ('Daily Bitcoin volatility time series') and enumerates exactly what is returned: realized volatility (30d/90d, √252-annualized) and ATR% (Wilder EMA-14). It also names the differentiating sibling (arena_get_iv_snapshot) and explains the methodological distinction, so an agent can separate it from related tools without opening a 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 is provided: use `from`/`to` rather than pulling everything, use `granularity`/`fields` for affordability, and pass `format: "columns"` + `schema_version: "2026-08"` for long ranges. It also states the free-tier limit and directs to sibling tools for the questions this one does not answer (arena_get_volatility_phases, arena_get_cycle).

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?

With no annotations, the description carries the full burden. It discloses it is read-only ('Read-only, no market data touched'), describes the return contents (whether gap clears noise floor, the floor itself, dominant axis, probe and date), explains the consequence of omitting an axis (answer looks more certain than it is), and documents the hard error for grid_phase with non-multi-day intervals. This goes well beyond a minimal behavioral statement.

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 description is dense but every sentence earns its place. It front-loads the core question, then methodically explains the return, the axes, the aggregation, the optional interval, the labels, and the safety guarantee. No fluff or repetition; structured with clear logical flow from purpose to parameters to behavior.

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?

Given the tool's complexity (6 parameters, multiple axes, error conditions, no output schema), the description is complete. It explains the return structure, the error condition, the aggregation rule, and every parameter's role. An agent has everything needed to call it correctly and interpret the result, even without an output schema. The only minor omission is the exact JSON return shape, but the description's narrative covers the components.

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 baseline is 3, but the description adds substantial meaning: it explains the axes enum in detail (including that parameter_choice is the largest axis), clarifies the floor aggregation rule, defines the error condition for interval/grid_phase, and explains that labels are display names echoed back. This transforms the schema's raw definitions into practical, operational guidance.

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 opens with a crisp question — 'Do these two CAGR figures actually differ?' — and states the verb ('Check') and the resource (two CAGR values). It distinguishes itself from sibling tools by being the only one that performs a noise-floor significance test on CAGR differences, rather than retrieving data or running strategies. The phrase 'before ranking them' positions it clearly in the analysis workflow.

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?

The description gives explicit when-to-use guidance: 'Check before ranking them.' It instructs the caller to pass all axes that genuinely varied and clarifies the floor is their maximum, not sum. It also warns about the hard error when combining grid_phase with a non-multi-day interval. Though it doesn't name alternative tools, the context makes the intended use unambiguous and the conditions precise.

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?

With no annotations provided, the description carries the full burden of behavior disclosure. It discloses the operation is a read-only list ('Lists the backtest runs'), scopes results to the authenticated user, describes ordering ('newest first'), and states the tier ('API Pro'). It does not explicitly say there are no side effects, but 'list' implies a read. It could have noted that no mutation occurs or described auth failure behavior, but overall it provides sufficient behavioral context.

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 description is three sentences with no filler. The opening question 'Which backtests have I run?' immediately orients the agent, followed by the core purpose, usage flow, scope, and pagination note. Every clause earns its place, and the structure is front-loaded with the most critical 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?

As a list tool with no output schema, the description compensates by listing the fields returned (id, strategy, pair, interval, date range, headline metrics), pagination parameters, scope, and related tools. It does not describe error or empty-result behavior, but that is a minor gap given the tool's simplicity and the absence of annotations. The mention of the API tier and the authenticated-user scope adds context. Overall, it is near-complete for its purpose.

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%, with all six parameters already described in the input schema (e.g., pair filter, limit max 100, offset default 0, interval enum, strategy, asset_type). The tool description adds only 'Paginated via limit + offset', which reinforces but does not extend beyond schema. Since coverage is high, the baseline is 3 and the description adds no new parameter meaning.

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 clearly states the verb 'list' and the resource 'backtest runs', specifies the scope 'belonging to the authenticated user', and lists the fields returned (id, strategy, pair, interval, date range, headline metrics). It explicitly differentiates from sibling tools by naming arena_get_backtest for detail and arena_get_winners for the public leaderboard, so an agent can distinguish it without ambiguity.

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?

The description gives direct usage guidance: 'Use it to find a run_id, then call arena_get_backtest for its detail or arena_get_backtest_trades for the individual trades.' It also states when not to use it ('Only your OWN runs; for the public cross-user leaderboard use arena_get_winners') and mentions pagination via limit+offset. This is explicit and actionable.

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?

With no annotations provided, the description carries the full burden. It states it's a listing operation (implying read-only) and notes the free tier, giving cost context. It does not explicitly declare side effects or rate limits, but the nature of a zero-parameter list operation and the detailed output fields make behavior sufficiently clear.

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 description is front-loaded with the core purpose, followed by usage guidance and a note about free tier. It is a bit conversational ('What knowledge objects exist here?') but each sentence earns its place, with no redundancy. Length is appropriate for the information conveyed.

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 parameterless list tool, the description is complete: it states what is returned, when to use it, and cost implications. It does not describe the exact response format or pagination, but these are less critical for a simple listing. The absence of an output schema is mitigated by listing the returned fields.

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?

The tool has zero parameters, so schema coverage is trivially 100%. The baseline for 0 params is 4. The description adds value by explaining the output contents (types, subjects, and the specific fields), which compensates for the lack of an output schema.

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 clearly states the tool lists all published knowledge types and their subjects, with specific fields (min_tier, api_path, seo_slug, latest as_of). It distinguishes itself from arena_get_knowledge by positioning itself as a discovery step, making its purpose 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?

Contains an explicit directive: 'Use this BEFORE arena_get_knowledge to learn valid type/subject pairs instead of guessing.' It also notes that new types appear automatically, implying the tool should be re-run to stay current. This clearly tells the agent when and why to use it.

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?

No annotations are provided, so the description carries the burden, and it does reasonably well: it discloses the cardinality (69 series), the grouping taxonomy, the exact return shape (id + label + group), and the pricing tier ([Free tier]). It does not state whether the list is static or updates over time, which is a minor gap for a no-parameter 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?

Front-loaded with the core question and answer, followed by tier and return shape in compact sentences. The parenthetical example list (MVRV, NUPL, SOPR, ...) is long but earns its place by letting the agent recognize series names without a second call.

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 parameterless catalog with no output schema, the description supplies everything needed: what is returned (id, label, group), how many items, the group taxonomy, and the follow-up tools. Nothing required for correct invocation 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?

The tool takes zero parameters, which sets the baseline at 4. The description correctly implies no filtering is possible and instead points to the consumer tools that accept the returned ids.

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 direct question that names the resource ('on-chain series'), then states it lists all 69 BRK on-chain series with the enumeration groups. An agent can immediately distinguish this catalog tool from arena_get_onchain_latest / _history, which consume the ids this tool returns.

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 routes the agent downstream: 'Use the id with arena_get_onchain_latest / _history.' That tells the agent this is the entry point before fetching data, but it does not say when NOT to use it or contrast against other list_* siblings (list_strategies, list_universes, list_backtests).

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?

With no annotations provided, the description carries the full behavioral burden. It discloses that deprecated entries intentionally stay listed, that they carry deprecated_for and deprecation metadata, and that invalid combinations fail with 400. This exposes important non-obvious behavior. It doesn't mention response shape, pagination, or auth, but the key traps are covered.

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 description is compact and front-loaded with a natural question, then the core behavior, then the critical deprecation caveat. The deprecation sentence is long but packs essential warning details. Overall it earns its place without unnecessary fluff.

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 simple optional-parameter list tool with no output schema, the description covers what the tool returns, what filters exist, how it relates to arena_run_backtest, and the important deprecation edge case. A small example of output shape or a note about lang default would push it higher, but nothing critical 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. The description adds only minimal parameter semantics by mentioning filterability by asset class and plan; it doesn't add new meaning for lang or any details beyond the schema. No penalty is warranted because the schema already documents each parameter well.

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 starts with a concrete user question and states the exact function: 'Lists all backtest strategies' with the specific fields returned (key, label, plan, supported asset classes, primary indicators). It also frames itself as a discovery tool for arena_run_backtest, which distinguishes it from the many other list/get tools in its sibling set.

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 guidance is explicit: 'Use this before calling arena_run_backtest to discover valid strategy names.' It also gives a clear negative directive — do not call arena_run_backtest or validate_strategy for deprecated asset-class combinations, and states the consequence (they return 400). This is strong, unambiguous routing.

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?

No annotations are provided, so the description must carry the burden. It states the core action (lists all universes) and clarifies what universes are (underlying pair-sets), which is helpful. However, it does not mention side effects, auth requirements, error cases, or output format. The '[Free tier]' hint is a minor behavioral note. For a read-only list tool, this is adequate but not rich in disclosure.

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 description is two sentences plus a bracketed note, with no fluff. The front-loaded question immediately signals the tool's purpose, followed by a precise definition and usage context. Every word contributes meaning.

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 zero-parameter, read-only list tool, the description covers the essential aspects: what it does, what it returns conceptually (a list of universes), and why it matters (used by specific endpoints). It does not detail the exact output structure, but given no output schema, that is acceptable. It is sufficiently complete for an agent to call correctly.

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?

The input schema has zero parameters, so the baseline is 4 as per rubric. The description adds value by giving examples of expected universe names (BTC, top-10, etc.), which helps an agent anticipate the output, but there are no parameter semantics to elaborate on.

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 uses a specific verb ('Lists'), names the exact resource ('all crypto asset universes'), and provides concrete examples (BTC, top-10, top-50). The opening question 'Which asset universes can I test against?' directly addresses an agent's selection need and clearly differentiates this from other list tools (e.g., arena_list_backtests) by focusing on universes.

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?

The description gives useful context on when to use it: it lists the pair-sets used by 'custom-report and universe-backtest endpoints', implying the tool is needed when selecting a universe for those operations. It does not explicitly name alternatives like arena_get_universe, but the context is clear enough for appropriate 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?

With no annotations, the description carries the full burden, and it delivers: synchronous with 3-10s latency, per-day quota, filters only remove entries, and a detailed benchmark-window caveat that prevents misreading cagr versus buyhold_cagr. It even warns that matches_strategy_window:false means different annualization periods.

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 description is long but every sentence earns its place: outcome first, then latency, then routing, then filters, then the critical benchmark caveat. It front-loads the decision-relevant facts and does not pad.

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 9-parameter tool with nested filters and no annotations or output schema, the description is remarkably complete: it lists the result metrics, explains how to retrieve later via run_id, warns about benchmark windows, and states quota limits. The absence of an output schema is compensated by the explicit mention of key result fields and the comparison caveat.

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 schema already explains every parameter, which sets the baseline at 3. The main description adds only mild reinforcement ('filters are optional and only remove entries') rather than new per-parameter semantics; most of its added value concerns result interpretation, not parameters.

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 opening line frames the user question and then states exactly what the tool does: run ONE strategy on ONE pair over a date range and return the full result, including CAGR, drawdown, win-rate, and a run_id. It also names the sibling tools it is not (compare_strategies, run_universe_backtest), so there is no ambiguity with the large sibling list.

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 'Use this when' condition, then names concrete alternatives for adjacent use cases: several strategies, many pairs, and judging existing results. This is exactly the routing guidance an agent needs.

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?

With no annotations, the description carries the full load and does so: it discloses the returned fields, the zerlegung sub-reports, that runs persist to the account with a run_id, tier/quota limits, the simulation-not-advice caveat ('can be a total loss of the margin'), and range-exit pausing semantics with stop_on_range_exit as the override.

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?

It is long, but the length is justified by a 16-parameter tool with no output schema, and the value proposition is front-loaded in the first sentence. A few clauses (tier tags, T&C-style caveats) sit near the end and could be trimmed, keeping it short of a 5.

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 no output schema or annotations, the description compensates fully: it enumerates return values and the decomposition/benchmarks/fee_economics breakdown, explains the legacy vs entry-price anchoring discrepancy, and covers leverage, funding, quotas and persistence. Nothing needed to invoke 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 coverage is 100% and the schema descriptions are already rich, so the baseline is 3. The description still adds real meaning beyond the schema for leverage ('margin = total_investment, the grid trades margin × leverage, funding accrues daily ... liquidation is checked per candle at the low') and reinforces the low_price/high_price range dependency.

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 opening states a concrete verb and resource ('Simulate a GRID BOT ... on historical candles') and defines the mechanism (buy-low/sell-high ladder inside a fixed range). It explicitly distinguishes itself from the sibling strategy backtester ('This is a different machine ... for signal-based strategies use arena_run_backtest instead'), so an agent can route without opening either 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?

It names the alternative (arena_run_backtest) and the condition selecting it, points to arena_suggest_grid_range when range choice is unresolved, and to arena_share_grid_backtest for publishing. It also frames when the grid archetype applies ('earn from oscillation inside a range, not from trend') and warns that range choice is part of the hypothesis.

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?

No annotations exist, so the description carries the full burden and does: it declares the call asynchronous and that the response contains only a job_id, describes polling and estimated_seconds, tier-dependent pair caps and per-day quotas, and the persistence caveat that results live only in api_jobs.result and are not written to backtest_runs.

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 highest-value facts (async, job_id only, must poll) before drilling into benchmark-window nuance. The passages on beats_bh_count vs beats_bh_count_requested_window and the window-offset caveats are somewhat repetitive, but each sentence carries actionable 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?

Despite having no output schema, it fully covers the async contract, how to obtain results, quotas, tier limits, and result persistence, including which sibling tools will NOT surface the results later. Nothing an agent needs to invoke and consume this call 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%, so the baseline is 3, but the description adds real meaning beyond the schema: tiers gate the effective pair cap vs the schema's 250 hard limit, and it frames universe_id vs pairs[] as mutually exclusive sources.

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 concrete question and states the exact operation: run the strategy against every pair in the universe. It is clearly distinguishable from arena_run_backtest (single pair) and arena_run_grid_backtest (parameter sweep) without opening a 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 routing: provide either universe_id (via arena_list_universes) or explicit pairs[], plus the mandate to poll arena_get_job_status until 'completed'. It also prescribes pairing with bnh_fixed/dca_reference_v2 over the same universe and interval, which is genuine when-to-use guidance.

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?

With no annotations provided, the description carries the full burden of disclosure. It clearly states that the tool returns auth status, tier, server version, time, and rate-limit state, and explicitly notes that it does not consume extra quota beyond the call itself. This covers the key behavioral traits an agent needs to know for a status probe. It does not explicitly say it never modifies anything, but the read-only nature is strongly implied by the diagnostic framing and the listed outputs, so the slight gap is minor.

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 description is about 90 words and is well-structured: it opens with the core question, then lists outputs, then gives usage guidance and the quota note. Every sentence contributes new information, and the most important guidance ('call this first when other tools fail') is front-loaded near the middle rather than buried at the end. It is slightly longer than strictly necessary, but the density of actionable detail justifies the length.

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?

Given that the tool has no parameters, no output schema, and no annotations, the description needs to fully explain what the agent will get and when to use it. It does exactly that: it enumerates all the returned data categories, explains how to interpret them for troubleshooting, and explicitly promises no extra quota consumption. The sibling set is large and all getter-like, so this description successfully carves out a unique diagnostic role. Nothing essential 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?

The tool has zero parameters, so schema coverage is trivially 100%. The description goes beyond the empty schema by explaining what the returned fields mean (key kind, tier, time, rate-limit state) and how they map to troubleshooting actions. With no parameters to document, a baseline of 4 is appropriate; the description adds semantic value about the output context even though it cannot describe input semantics.

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 opens with a customer-facing question ('Am I connected, and what can this key do?') and then enumerates exactly what it returns: auth status (key kind and tier), server version, current UTC time, and rate-limit state. This is a specific verb+resource with no ambiguity. It also distinguishes itself from the many sibling getter tools by positioning itself as the diagnostic endpoint to call when other tools fail, which clearly sets it apart from the rest of the arena_* family.

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 explicit, actionable guidance: 'Call this first when other tools fail' and then tells the agent how to interpret results by separating auth problems (reconnect), tier problems (upgrade), and rate limits (wait) from real outages. It also states that the call itself does not consume extra quota, which is a practical constraint. This is textbook when-to-use and when-not-to-use guidance.

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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It fully discloses the return format (EVIDENCE verdict plus metrics, flags, caveats), the checks performed (look-ahead-aware, net of cost, out-of-sample split, 30-round-trip gate), and explicitly states it is NOT a recommendation. It also mentions the 'API Pro tier' access constraint, which is not covered elsewhere. This is exceptional transparency that goes well beyond a typical description.

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 description is compact yet comprehensive, covering purpose, inputs, checks, output, and access in about 150 words. It is front-loaded with the core question and key details, with every sentence adding value. While the density might benefit from bullet points, it is well-structured and appropriately sized for the tool's complexity.

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 schema is thorough (100% coverage), and the description explains the tool's behavior, returns an EVIDENCE verdict, and lists the checks performed. It does not provide an output schema, but it names the possible verdict values. It also mentions the Pro tier. For a tool with nested objects and multiple input types, this description, combined with the detailed schema, is complete enough for an agent to know when and how to call it correctly.

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 each parameter is already well documented. The description adds context about the input types (rules, signal_list, trade_list) and the overall purpose, but does not add detailed parameter-specific guidance beyond what the schema provides. The 'API Pro tier' note is access-related, not parameter semantics. Given the high schema coverage, a baseline of 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 opens with a clear question and states the tool's function: 'Backtest a trading strategy honestly' with a specific methodology (Deflated-Sharpe-Ratio / multiple-testing correction). It lists the three input types (rules, signal_list, trade_list), returns an EVIDENCE verdict, and explicitly states it is NOT a buy/sell recommendation. It also distinguishes itself from generic backtest tools, making its purpose unambiguous and well differentiated among the many arena_* siblings.

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?

The description advises 'Call this before acting on a strategy or signal list' and notes it is 'not reproducible via generic backtest tools that ignore overfitting,' giving clear when-to-use context. However, it does not explicitly name sibling tools such as arena_run_backtest or arena_get_backtest, nor does it specify when not to use it (e.g., if you only need a simple backtest). This leaves some ambiguity but still provides strong usage context.

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