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?

With no annotations provided, the description carries full responsibility for behavioral disclosure. It covers: the side effect of freeing a slot, return value ('Returns the deactivated subscription'), idempotence, and the nuance that undelivered queued updates are not removed. It also mentions the API tier requirement. This is a thorough disclosure of behavior beyond the basic action.

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 moderately wordy but information-dense. The opening question 'Stop this alert?' is slightly informal and could be omitted, but it frames the intent well. Each subsequent sentence adds distinct value (action, slot implication, return, idempotence, id source, queued updates, tier). It is front-loaded with the core action before the details. A 4 reflects minor redundancy, not a significant flaw.

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 single-parameter tool with no output schema, this description is exceptionally complete. It explains the return type, idempotence, side effects (slot freeing), the non-removal of queued updates, and the tier requirement. It also points to the correct sibling for id retrieval. An agent has all the information needed to call the tool correctly and interpret the result.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema already describes subscription_id as 'Subscription id returned by arena_subscribe_*', and the description adds a more practical retrieval source: 'Get ids from arena_list_subscriptions'. This is valuable because list_subscriptions is the natural place to get existing subscriptions to cancel, whereas arena_subscribe_* returns ids only at creation time. The description enhances the parameter's 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 description opens with a user-oriented question 'Stop this alert?' and then states the core action: 'Deactivates one subscription by id, so it stops firing'. This clearly identifies the verb (deactivate) and resource (subscription by id), and it explicitly mentions freeing a slot against the per-tier limit, distinguishing it from getter siblings like arena_list_subscriptions or arena_check_subscription_updates. No ambiguity remains 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?

The description gives direct guidance: 'Get ids from arena_list_subscriptions' tells the agent exactly where to obtain the subscription_id parameter. It also explains the idempotent behavior ('cancelling an already-cancelled one is a no-op'), which informs when it is safe to call repeatedly, and notes that queued updates are not removed, setting expectations. Alternatives are implicitly clear since this is the only cancellation tool among the 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, the description carries full responsibility for behavioral disclosure. It clearly states the destructive side effect (marks updates as delivered), the return payload structure (subscription_type, current value, previous value, trigger context), and the polling cadence. This is strong transparency for a tool with zero annotations, though it doesn't mention error cases or empty-queue 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?

Four short sentences pack the purpose, side effect, polling advice, and payload details with zero redundancy. The opening question sets immediate context, and each sentence earns its place. This is an exemplary model of concise, front-loaded tool descriptions.

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 contract with no parameters and no output schema, the description covers the essential points: what it returns, the side effect, usage cadence, and payload shape. It lacks explicit handling for the empty case, but that is reasonable to infer. The tier restriction is also disclosed. This is nearly complete for an agent 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?

The tool has zero parameters, so the description cannot add parameter-level detail. It correctly infers the API key is passed via header/context rather than a parameter. With nothing to document, this receives the baseline score of 4.

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 immediately answers 'Has anything I subscribed to fired?' and specifies exactly what the tool does: returns undelivered updates for the API key and marks them delivered. It clearly distinguishes from siblings like arena_list_subscriptions (which lists active subscriptions) and the many data-retrieval getters, making its unique role as the subscription-update poller unmistakable.

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 says 'Call regularly to consume the polling queue,' giving clear usage context. It doesn't explicitly state alternatives or exclusions, but since no sibling tool performs this function, the guidance is sufficient. The 'API Pro tier' note also warns about access constraints.

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, the description carries the full burden and does so thoroughly. It discloses that the tool does NOT give a recommendation, anchors to structural marks (not calendar-DCA), states the mandatory invalidation point, explains the tradeoff (laddering buys lower timing variance, NOT higher expected value), notes asset-specific behavior (support-cluster rungs are BTC-only; ETH/SOL use 200-week MA), and flags small-n warnings. It also mentions the 'API Pro tier' constraint. These behavioral traits are valuable and not repeated by any structured field.

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 fairly long but front-loaded with the core question and purpose. It organizes returns into numbered items, then states the mandatory requirement, composition, and alternative. Every sentence adds information; there is no filler. It could be slightly streamlined, but it is well-structured and readable, earning a 4 over 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?

Given the tool's complexity (six parameters, composed from two other tools, no output schema), the description does a strong job of explaining the expected return values: tranche ladder, base rate with episodes_matched and small-n warnings, and the tradeoff explanation. It also covers the mandatory invalidation and asset-specific differences. However, it does not describe the exact output format or potential error conditions, and relies on the schema for parameter details. On balance, it is sufficiently complete for an agent to call it correctly, but not exhaustive, so a 4.

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 does not add meaning beyond the schema: it repeats the mandatory invalidation requirement and mentions asset/preset/horizon generically, but the schema already enumerates enums and provides detailed descriptions for each parameter. No extra semantic value is provided, so a 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 states a specific verb-resource pair ('Frame a dip/accumulation thesis') and explicitly scopes what it returns (tranche ladder anchored to structural marks, historical base rate, lump-sum-vs-tranche tradeoff). It distinguishes itself from siblings by naming the composed tools (historical-analog + key-levels) and clarifies it is NOT a recommendation, not calendar-DCA, and not a price forecast. This gives an agent a precise, differentiated purpose.

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 a clear use case ('Where would I add on a dip?') and states the tool returns a structural thesis without a recommendation. It points to a related, different-method tool (EV/Kelly) via URL, implying when to seek that alternative. However, it does not explicitly name sibling arena_dip_decision or give explicit when-not conditions for it, leaving some inference to the agent. Overall clear context but not fully 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 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 bears the full responsibility for behavioral disclosure. It goes beyond a generic 'get' by revealing the tier-based range cap (Free 30d / Pro 365d / Power unlimited) and the chronological ordering. It does not mention error handling or response format details, but these are less critical for a read-only historical query; the disclosed constraints are significant enough to warrant a high score.

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 with zero waste. The purpose and data content are front-loaded in the first sentence, and the usage guidance and alternative are compactly provided in the second. 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?

For a tool with a single parameter fully described in the schema and no output schema, the description fills the gap by specifying exactly what the returned time series contains (fields and ordering). It also clarifies the relationship to the sibling, making the tool self-sufficient 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 schema already documents the single 'days' parameter exhaustively, including tier-based clamping (schema description coverage is 100%). The description only restates 'Range capped by tier,' which adds no new meaning beyond what the schema provides. With such high coverage, 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 states a specific verb ('Returns') with a clear resource ('Altcoin-Season TIME SERIES') and enumerates the exact data fields (overall_color, BTC/alt/stablecoin dominance, BTC price). It also explicitly contrasts with the sibling tool arena_get_altcoin_season, making the distinction 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 an explicit use case ('see whether capital has been rotating into or out of alts over time') and directs the agent to the sibling tool for the current-day snapshot ('for today's state alone call arena_get_altcoin_season'). This leaves no ambiguity about when to use this tool versus the alternative.

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 provided, the description carries the full behavioral disclosure burden and does it well. It discloses that open positions are not counted, explains that raw trades are only persisted for web-UI runs and that API/MCP-created runs return an empty list with an empty_reason, and notes the API Pro tier requirement.

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: the output fields, use cases, prerequisites, the alternative tool, and caveats. It is front-loaded with an immediately understandable question, making it easy for an agent to grasp the tool's purpose 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?

There is no output schema, so the description correctly enumerates the returned fields and explains edge-case behavior such as empty results. It also covers the run_id provenance, closed-trade limitation, and tier restriction, making the description sufficient for correct invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The single id parameter is already fully documented in the schema with 100% coverage. The description adds practical value by telling the agent the id comes from arena_list_backtests, clarifying the expected provenance. This raises it slightly above the baseline.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool returns individual round-trip trades from a backtest run, listing entry/exit dates and prices, per-trade P&L, and running equity. It also distinguishes itself from the sibling arena_get_backtest by noting that that tool provides aggregate metrics alone.

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 says when to use this tool ('when aggregate metrics are not enough') and names the alternative for aggregates ('use arena_get_backtest'). It also specifies the required prerequisite, a run_id from arena_list_backtests, and clarifies that only closed round-trips are included.

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 is highly transparent: explains proxy tracking noise for ETFs, null windows due to listing dates and how they fill in, and clarifies that window labels are upper bounds with data_start_date carrying the actual basis. It also indicates 'Free tier' status. It could mention read-only nature explicitly, but since it's a 'get' tool, the absence is not a major gap.

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 typical but each sentence contributes meaning: it front-loads the purpose, then enumerates the return components, and covers caveats about proxies and window validity. It is well-structured and not verbose for the complexity it handles. The information is dense yet organized.

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 tool with no output schema and no annotations, the description is exceptionally complete. It explains all return structures, data provenance, proxy tracking noise, null-handling logic, and window-label semantics. An agent has everything needed to know what to expect and how to interpret results, making it self-sufficient.

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, triggering the baseline of 4. The description does not need to explain parameters, and it adds value by detailing the output structures and their semantics, which is beyond parameter coverage. Since there are no parameters, it cannot add parameter-specific meaning, but the baseline 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 clearly states the tool's purpose: pre-aggregated weekly correlations between Bitcoin and 13 macro components, listing examples and detailing the returned structures (quadrant_performance, component_correlations, asset_correlations, current_quadrant). This is a specific verb+resource combination that distinguishes it from other arena_* tools, which cover different analyses (e.g., sentiment, cycles, volatility).

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 provides clear context about what the tool does, but does not explicitly state when to use it versus alternatives. It implies usage for understanding Bitcoin's macro correlations, but there are no exclusions or references to sibling tools. Since it's a specialized tool with a clear domain, the implied guidance is adequate but not explicit.

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 transparently discloses the nature of the tool as 'educational analysis of price action', explicitly warns that the base rate is NOT a forecast, and mentions '[Free tier]' indicating potential limitations. This goes beyond a typical description and manages user expectations well.

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 densely informative. It front-loads the core question 'Is the trend up or down, and how fresh is the flip?' and then lists the returned fields in a structured way. Some redundancy exists (e.g., repeating 'last trend change timestamp' and then later 'flip_age_days' but these are distinct), but overall it is well-organized and every sentence adds 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 there is no output schema, the description fully explains the return payload: current_trend, timestamp, counts, fractals, and trend_context with detailed breakdown. It also clarifies the meaning of the base rate and its limitations. An agent can understand exactly what data to expect 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?

The tool has zero parameters, so baseline is 4. The description does not need to explain parameters, and it doesn't. It effectively uses the space to describe the output instead, 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 clearly states it returns Bitcoin market structure indicators (trend, flip freshness, fractals, trend context). The verb 'get' and specific resource 'BTC market structure' are explicit, and the mention of 'Phantomflow adaptation' distinguishes it from generic indicators. It is unmistakable 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 provides clear context: it is for daily Bitcoin market structure analysis. It implies when to use it (when you need trend direction and flip context) but does not explicitly mention alternatives or when not to use it. Since there are many related 'arena_get_*' tools, a brief pointer to alternatives would help, but the context is sufficient for a basic understanding.

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?

Annotations are absent, so the description carries full burden. It discloses the chart inherits the data tool's freedom, shows exactly the same points for the tier, has a tier cap for the days window, includes n, date range, gap count, warning line, attribution, and watermark in the image, and explicitly states it is never a signal. No contradictions with annotations since none 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 longer than a typical one-liner, but each sentence adds meaningful context: purpose, tier inheritance, image contents, connection to data tools, and the 'never a signal' disclaimer. It is front-loaded with the purpose and well-structured, though it could be slightly leaner 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?

For a 2-param tool with no output schema, the description is comprehensive: it explains the return format, the content of the image, the tier behavior, and how to get underlying numbers. It even gives an example mapping. Nothing critical is missing for an agent to correctly invoke and interpret this 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 schema already provides 100% coverage of both parameters. The description adds the tier-cap behavior for days and clarifies that series semantics are given by the matching data tool. It also notes the image names any cap, which is extra context beyond the schema, but the core parameter meaning is 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?

The description clearly states the tool renders a platform series as a PNG line chart and returns it as an MCP image content block plus a JSON meta block. It distinguishes this from data tools by explicitly naming the matching data tool for underlying numbers, so an agent can tell it apart from siblings like arena_get_kimchi_premium.

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 the agent when to use this tool (when a chart is needed) versus the matching data tool (when underlying numbers are needed). It also clarifies that the chart is descriptive, never a signal, and notes the tier cap behavior, which informs decision-making.

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 it thoroughly: it discloses the cointime-weighted nature of supply figures, the non-balance interpretation of total_counted, single-snapshot consistency, the data source, and the inherent lack of forward-looking statements. These are exactly the nuances an agent must know to avoid misinterpreting outputs.

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 every sentence earns its place: the core concept (sign conflict) is front-loaded, followed by the critical supply-figure caveat, then the source and sibling routing. No fluff, and the structure moves from what it is to what to watch out for to where to go next.

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 and no annotations, this description is exceptionally complete. It explains the output fields (sign_conflict, total_counted, supply split), warns about measurement units, names the source, and points to the related tool. An agent can call it correctly and interpret results correctly with zero 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 tool has zero parameters, so the baseline for parameter semantics is 4. The description adds no param-specific details (none exist), but it explains the meaning of the key output field (sign_conflict) which is the closest thing to parameter-like semantics 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?

States a precise verb ('puts ... side by side') and the exact resource (three BTC cost-basis measures with spot), and distinguishes itself from the related ladder tool by naming it. The sign-conflict flag is clearly defined, making it distinct from any single cost-basis tool.

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 names the alternative (arena_get_knowledge with type='onchain_cost_basis_ladder') and provides the selection rationale (full ladder, STH/Active rungs, MVRV percentile). Also warns that the sign-conflict state is invisible when querying realized price alone, and clarifies that it makes no price-direction claims, covering both when-to-use and when-not-to-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 of behavioral disclosure, and it does so thoroughly. It states that scoring is point-in-time and not reconstructable from a generic price API, explains that components without input are excluded and weights renormalized (with indicator_coverage), details the ath block calculations, clarifies the signal enum is a fixed score-band label rather than an independent phase detection, and discloses BTC-specific highlights and price_context. It also transparently mentions that BTC-native indicators are returned as not_applicable for ETH/SOL rather than faked. This level of detail precisely informs an agent about side effects and limitations.

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 information-dense, with every sentence contributing to behavioral understanding. It is front-loaded with the core purpose and then progressively details variants and caveats. While it could be trimmed slightly without losing essential meaning, the length is justified given the tool's complexity and the need to disclose multiple behaviors (indicator handling, signal label semantics, asset-specific differences). The structure is logical, moving from core functionality to edge cases.

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 and one optional parameter, the description covers all necessary aspects an agent needs to call it correctly: what the tool returns (indicator_scores, ath block, percentiles, signal enum, highlights, price_context), how it handles different assets, how scoring works (point-in-time, renormalization), and its relationship to sibling tools. It even explains the signal enum's semantics to prevent misinterpretation. Nothing critical is missing for the agent to make an informed call.

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 single parameter `asset` is fully documented in the schema (100% coverage), so the baseline is 3. The description adds significant meaning beyond the schema by elaborating on what each asset value does: ETH/SOL return a price-derived cycle read built from transferable indicators with renormalized weights, and BTC-native indicators are returned as not_applicable. It also explains the indicator composition for BTC and how weights are handled, which is not in the schema. This adds real interpretative value beyond the enum 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 clearly states a specific purpose: providing a crypto cycle snapshot with a point-in-time 9-indicator aggregation for BTC and a per-coin price-derived read for ETH/SOL. It differentiates from siblings by naming related tools (arena_get_volatility_history, arena_get_historical_analog, etc.) and stating what this tool specifically does differently, such as carrying regime context around the volatility series. The verb 'get' plus the resource 'cycle snapshot' is unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides context on when to use this tool by explaining its scope (cycle position snapshot) and mentioning related tools for alternative use cases (e.g., arena_get_historical_analog for what followed similar states, arena_get_volatility_history for the volatility series). However, it does not explicitly state scenarios where this tool should not be used or give a clear conditional like 'use this when you need X, otherwise use Y'. The guidance is implicit rather than explicit, so it misses the top score.

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 it delivers exceptional detail. It discloses look-ahead-free construction, which inputs are revision-safe (price, calendar, chain) vs. third-party-revisable (fear_greed, btc_dominance), the walk-forward vs. reconstructed data split (since 2026-04-17), and the critical warm-up caveat that early rows carry raw scores under the same field name. This is far beyond what annotations would typically supply.

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 information density is high and every sentence earns its place — the conceptual question is front-loaded, and the warm-up and data-provenance caveats are genuinely necessary for correct interpretation. However, it is one dense wall of text; paragraph breaks would materially improve scannability for an agent parsing the description. Slightly over-long but never wasteful.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Despite having no output schema, the description fully specifies the return shape (time series, one row per day, fields adj_score and z_adj_score, ascending by date) and pre-empts the two biggest misinterpretation risks: the z-score warm-up semantics and the reconstructed-vs-observed data split. For a single-parameter timeseries tool, nothing an agent needs to call it correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the sole 'days' parameter is already documented as 'Number of days back from today (auto-clamped by tier)'. The description adds the concrete tier values (30/365/3650) and reinforces the clamping behavior, which is marginal value. Baseline 3 is correct since the schema does most of the work and the description adds only light amplification.

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 ('How has the cycle score moved over time?') and names the exact resource (BTC-Cycle TIME SERIES with adj_score and z_adj_score, one row per day, ascending by date). It explicitly differentiates from the sibling tools by naming arena_get_cycle for the current single reading and arena_get_historical_analog for historical analog comparisons, so an agent can distinguish it without opening other schemas.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Routing guidance is explicit and actionable: 'For the current cycle reading alone call arena_get_cycle; for what similar historical readings were followed by, call arena_get_historical_analog.' It also states the tier-based range cap (Free 30d / Pro 365d / Power unlimited), which sets expectations for what the days parameter will return. This leaves nothing about when-to-use 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 provided, the description carries full behavioral burden and does so excellently. It discloses the comparison source change with exact dates, warns that rows from different sources must not be averaged, states that drift never auto-switches source, and notes the API tier requirement. This is rich, non-obvious behavior an agent needs to know.

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: purpose, source-change caveat, active/retired pairs, passive behavior, and access tier. Important warnings are front-loaded near the purpose statement, and there is no redundant or filler text.

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 single-parameter tool with no output schema, the description gives sufficient detail for correct invocation: what is returned, which metrics are currently active, which are historical, and the critical source-averaging constraint. An agent can select and call this tool correctly without further information.

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 only parameter, days, is already documented with default and max. The description's mention of the 'requested window' adds no new semantic detail beyond what the schema provides. This is the appropriate baseline for high schema coverage.

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: comparing BRK against a second provider to detect data-quality drift, with mean/max/outlier counts. It uniquely identifies the resource (drift log) and distinguishes it from the many other indicator tools in the sibling list. The active and retired metric pairs add further specificity.

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 about what the tool covers — daily drift, specific metric pairs, and historical queryability — so an agent can infer when to use it. However, it does not explicitly state when to prefer this tool over alternatives like arena_get_onchain_history or arena_get_onchain_latest, and it names no 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 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 provided, the description carries the full burden of behavioral disclosure, and it excels. It thoroughly explains the interpretation of key fields, warns about the confusing difference between `acceleration_usd_m` and `accelerating`, details the four states of `impulse`, and clarifies how to read reversal metrics. This is rich behavioral context that prevents misinterpretation.

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 notably long but deliberately structured: it front-loads the purpose, then systematically explains `impulse`, the confusion between `acceleration_usd_m` and `accelerating`, and the reversal fields. Each sentence serves a purpose—no filler—but the length is above typical and could be tightened. It earns a 4 for being information-dense without 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 there is no output schema, the description must explain return fields and semantics, and it does so comprehensively. It covers the `impulse` states, the acceleration metrics, reversal recovery, defaults, and source. An agent has everything needed to call the tool and interpret results correctly, including edge cases like the apparent contradiction.

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 both parameters with defaults and enums (days: clamp 90-1095, asset: BTC/ETH/SOL). The description merely echoes these defaults ('Default BTC; pass asset=ETH or asset=SOL') without adding new semantic meaning. With 100% schema coverage, baseline 3 applies; no supplementary value beyond 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 precise statement of what the tool does: 'Spot-ETF net flows (USD millions) — is the flow impulse turning or accelerating?' and clarifies it exposes the trend rather than a point-in-time delta. This clearly identifies the resource (ETF flows) and the specific value it adds, making it easily distinguishable 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 provides implied usage guidance by contrasting with a 'summary' that only gives point-in-time deltas, suggesting this tool is for trend analysis. However, it does not explicitly name alternative tools or state when NOT to use this tool. The guidance is contextual but lacks explicit exclusions or sibling 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?

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 must disclose behavioral nuances, but it only states that it is a 'lift analysis' comparing baseline vs filtered metrics. It does not clarify how strategy combos are specified, data coverage, default time periods, or how results are aggregated. This is a significant gap for a read-only analysis 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 two sentences and starts with an engaging question that conveys the core purpose. It lists the relevant filters and metrics without excessive verbosity. However, the filter list could be slightly trimmed, but overall it is appropriately sized.

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 parameters and no output schema, the description covers the essential context: what it does, which filters are analyzed, which metrics are compared, and the API tier prerequisite. It does not explain how results are structured or whether strategy combos need prior configuration, but for a no-parameter tool this is reasonably 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?

The tool has no parameters, so the schema is empty. Per the rules, a baseline of 4 is appropriate since there is nothing to explain; the description adds no parameter details because none 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 clearly states it performs a lift analysis of entry filters, listing the specific filters (200WMA, Altcoin-Season, etc.) and the metrics compared (CAGR, win-rate, drawdown). It distinguishes itself from generic strategy tools by focusing on filter effectiveness per strategy combo, but does not explicitly name siblings to avoid confusion, so it's clear but not maximally 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?

There is no explicit guidance on when to use this tool versus alternatives like arena_get_strategy_filter_effect or arena_get_strategy_insights. The phrase 'per strategy combo' implies a use case, but no exclusions or conditions are given, leaving the agent to infer when this is the right choice.

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 of behavioral disclosure. It explains aggregation across up to three exchanges, settlement cadence, the meaning of positive and negative values, and a key caveat about day-over-day composition changes via coverage and venue fields. It also signals the report is free-tier accessible.

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 efficient: it front-loads the purpose, then explains output semantics, interpretation, and caveats without wasted words. Every sentence serves a distinct purpose.

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 fully compensates by enumerating the returned values (value, 30d moving average, Z-Score), coverage fields, and venue naming. Since the tool takes no parameters, there are no missing invocation details, and the caveats make the data interpretation 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?

The tool has zero parameters, so there is no ambiguity about invocation. The description adds value by explaining the returned fields and their interpretation, which satisfies the baseline for a no-parameter tool.

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 returns the latest BTC perpetual funding rate snapshot, averaged across up to three named exchanges. The rhetorical question 'Are longs or shorts paying right now?' and the word 'Latest' clearly distinguish this from the sibling history tool, arena_get_funding_rate_history.

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 provides clear context for when to use the tool: for the current funding-rate snapshot, as opposed to historical analysis. However, it does not explicitly name the alternative history tool or state when not to use this tool, so some inference is left to the 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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It thoroughly details the segmented response structure, venue composition breaks, causes, and the `composition_stable` flag, and explains the meaning of positive/negative funding. It also discloses tier-based range limits, offering deep transparency about the tool's behavior and output.

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 essential information: core purpose, segmentation details, analytical warning, sibling routing, and tier caps. It is well organized and front-loads the core purpose, with a logical flow that an agent can quickly 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 time-series tool with venue segmentation, the description covers all critical use aspects: what the response contains, how to interpret segments, when it is safe to treat as one series, and how to switch to the latest-value tool. It also addresses tier limits. No output schema exists, but the descriptive detail sufficiently guides correct usage.

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 documents the single parameter ('days') with auto-clamping behavior, so coverage is 100%. The tool description adds context about tier-based caps but does not provide new syntax or format details beyond the schema. Baseline 3 is appropriate since the schema carries the parameter semantics effectively.

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 ('call'), resource ('funding-rate TIME SERIES'), and expands on aggregation across venues, cadence, and ordering. It also names the sibling alternative (arena_get_funding_rate) and clearly differentiates by saying 'For the latest funding value alone call arena_get_funding_rate'.

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 directs users to the sibling tool when they only need the latest value, and warns against computing averages across segments—telling them to compute within a segment or accept the mix knowingly. It also notes tier caps, giving clear when-to-use and when-not-to-use context.

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 the score ranks relative attributes and is not a price forecast or buy signal, and mentions the Pro+ tier for raw factors, giving useful behavioral context. It does not detail error handling or response format, but the core behaviors 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 front-loaded with purpose, then routes to siblings, then adds a caveat. Each sentence serves a function with minimal fluff, though the sibling-routing sentence could be tightened 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?

For a single-parameter read tool with no output schema, the description adequately explains what will be returned, the tier distinction, and the tool's limitations. It does not cover potential errors or edge cases, but for a simple lookup it is sufficiently 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 coverage is 100% for the single parameter coingecko_id, which is already well-documented with an example. The description adds no new meaning beyond referring to it as the identifier, 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 clearly states it returns the Altcoin-Screener score for a single coin identified by CoinGecko id, enumerating the outputs (composite score, group breakdown, Pro+ raw factors). It also distinguishes itself from the plural variant and the validation tool, 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?

Explicitly instructs to use this tool once a candidate is known, and directs to arena_get_gem_scores for whole-universe ranking and arena_get_gem_validation for out-of-sample behavior. This provides clear when-to-use and when-not-to-use guidance with named 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 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, the description carries the full burden, and it does so thoroughly. It discloses cost assumptions (10 bps per side, entry included, one-time BTC benchmark fee, zero slippage), rebalancing cadence, the grid-anchor semantics, the distinction between the one-phase headline and cross-phase `plain` reading, the anecdote threshold, and the nearest-rung snapping 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?

The description is information-dense and nearly every clause is relevant, but it is delivered as one long, parenthetical-heavy paragraph with no front-loaded plain-language summary. It is comprehensive but not concise or easily scannable, so it loses points on structure.

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 compensate for response semantics, and it does: headline fields vs gross fields, `cost_drag_pp`, `plain`, `is_anecdote`, and the `rebalance`, `phase_spread`, `cost_model`, `basis_note`, and `universe` blocks are all explained. For a single-optional-parameter getter, this is remarkably 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?

The schema already documents `top_n` as the basket size with a default, giving 100% coverage and a baseline of 3. The description adds important behavior beyond the schema: the precomputed ladder (10/25/50/100/200), snapping to the nearest rung, the `top_n` vs `top_n_requested` distinction, and how rungs above the priced universe behave.

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 validation question, names the asset (altcoin screener picks), the benchmark (BTC), and the method (equal-weight basket rebalanced every 14 days). It clearly differentiates this tool from generic backtest siblings by focusing specifically on validating the screener's picks against BTC.

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 question "Did the screener picks actually beat BTC?" effectively frames when to use this tool, and the 'precomputed weekly on an N ladder' note signals that this is not an on-demand custom backtest. However, it never explicitly names alternative tools or conditions for when to prefer them, 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?

No annotations are provided, so the description fully discloses behavior: data is computed from own daily-close series, date conventions are declared per entry, the current cycle peak is marked provisional, and no next-halving estimate is published. It even warns about a common data-mixing pitfall. This is comprehensive 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 information-dense. It fronts the core output ('full Bitcoin halving table') and then adds useful clarifications about data provenance and conventions. While it could be tightened, every sentence adds value or prevents misinterpretation.

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 parameters and no output schema, the description is exceptionally complete. It covers what data is returned, how it is computed, the date convention, the provisional status, and a missing feature. An agent would know exactly what to expect and how to interpret results.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With zero parameters, the baseline is 4. The description adds context about the data source and conventions, which is helpful even though no parameter documentation is needed. It does not repeat schema information since there is none.

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 a full Bitcoin halving table with specific fields (date, block height, reward change, price, cycle peak). It explicitly differentiates itself from generic price APIs and references a related tool (arena_get_cycle) to avoid confusion. The verb and resource are 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 implies its use case (when you need halving dates and associated price data) and mentions related tools (arena_get_cycle) as alternatives. It also states a limitation ('No next-halving date estimate is published') which indirectly signals when not to rely on it. However, it lacks explicit when-to-use vs. when-not-to-use 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, the description carries the behavioral disclosure burden. It states that the tool 'Returns' data, implying a read-only operation. It adds the interpretation logic and notes '[Free tier]', hinting at access level. It does not go into potential rate limits or error conditions, but for a zero-parameter read snapshot, the disclosure is adequate and does not contradict any annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences plus a short bracketed note. It front-loads the user-facing question, then explains the output and its interpretation in a clear, efficient manner. Every word earns its place; there is no redundancy or 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?

Given the tool's low complexity (no parameters, no output schema), the description sufficiently explains what is returned and how to interpret it. It could be slightly more explicit about the asset (e.g., Bitcoin) and the exact output format, but for a snapshot indicator, this is adequate. It covers the core information needed to call 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?

This tool has zero parameters and the schema is empty, so per the baseline rule for 0 params, a score of 4 is appropriate. There are no parameter semantics to add, and the description already covers what the tool returns.

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 'Latest Hash Ribbons indicator' and specifically '30d and 60d hashrate moving averages'. The verb 'Returns' plus the resource (hash ribbons) makes the purpose unambiguous, and it distinguishes itself from sibling indicator tools like arena_get_fear_greed or arena_get_mayer_multiple by naming a unique indicator.

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 opening question 'Are miners capitulating?' implies the intended use case: assessing miner capitulation and recovery. It explains the signal interpretation (30d > 60d after capitulation = bullish), which gives clear context for when to apply the tool. However, it does not explicitly name alternative tools or state when not to use it, so it falls short of the explicit when/when-not guidance required for 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 provided, the description carries full burden, and it does so thoroughly. It discloses normalization choices (ATR as % of price, OBV as 30-bar slope), behavior on small samples (percentile null with reason), study verdict inclusion conditions, and even a data provenance note (rsi_14_weekly identical to arena_get_cycle for BTCUSDT). It does not cover rate limits or explicit read-only status, but the behavioral details are extensive for a snapshot 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 a single, lengthy paragraph with several complex clauses (e.g., the Bollinger squeeze explanation). While information-dense, it is not tightly structured; it could be split into shorter sentences or bullets for better readability. It front-loads the core purpose well, but the verbosity around edge cases and related tools makes it less concise than ideal.

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 only 2 optional parameters and no output schema, the description covers the essential call context thoroughly: indicator set, percentile rank approach, edge-case handling, extra field on 1d, state field, and related tools. It does not describe the exact response structure, but that is not required without an output schema. It is sufficiently complete for an agent to call it correctly and interpret results.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so parameters are documented, but the description adds meaningful nuance beyond the schema. For 'interval', it explains the effect on output (e.g., weekly RSI extra field only on 1d) and clarifies the choice. For 'pair', it provides examples and context but no additional semantics. The description adds interpretive value for the interval parameter, earning a 4 rather than a baseline 3.

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, specific question: 'What do the classic indicators read right now?' and enumerates exact indicators (RSI(14), MACD(12/26/9), Bollinger(20,2), ATR(14), OBV) with percentile ranks. It explicitly distinguishes itself from siblings by naming related tools and their purposes (trend channels, historical analog, volatility history), making it unambiguous what this tool does and how it differs.

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 provides clear context for when to use the tool and explicitly lists alternative tools with their purposes in the 'Related:' clause. It gives direct usage instructions like 'Set interval to '1w' for the weekly view' and explains when percentile is null due to insufficient data. It does not explicitly state when not to use it, but the related tool explanations largely cover that.

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 burden. It discloses that the series is forward-only and cannot be backfilled, that early data may be sparse ('says so'), and that both legs come from the same source for internal consistency. It explains the sign convention (positive=premium, negative=discount) and mentions the `range` block in the response. This is solid disclosure, though it omits exact response structure/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 compact yet information-dense. It front-loads the core question, then covers data source, cadence, interpretation, limitations, and parameter behavior in a logical order. No sentence is wasted, though it could be slightly trimmed 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?

For a single-parameter tool with no output schema, the description provides everything an agent needs to call it correctly: definition, timezone, frequency, source consistency, sign semantics, forward-only constraint, tier caps, and the response's `range` block. 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 documents `days` with 100% coverage, including auto-clamping and tier boundaries. The description adds concrete tier limits (Free=30, Pro=365, Power=3650) and clarifies the 'capped by tier' behavior, plus the forward-only note about n_days being small early on. This goes beyond the schema and meaningfully helps the agent set expectations.

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 precise question ('Is Korean spot trading BTC at a premium?') and defines the exact metric: Upbit BTC/KRW (USD-converted) versus global BTC/USD in percent. It names the resource (Kimchi premium), the source (CoinGecko), and the data cadence (daily snapshots), making it unmistakable and clearly distinct from any sibling get_* tool.

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 it (when you need Korean BTC premium) and gives operational constraints: forward-only data since 2026-08, cannot be backfilled, and the `days` window is capped by tier with explicit tier limits (Free=30/Pro=365/Power=3650). It doesn't name an alternative tool to switch to, but given the unique metric, the guidance is essentially complete.

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 provided, the description fully carries the burden of behavioral disclosure, and it does so excellently. It discloses data sourcing (FRED), the derived nature of `vix_score` (not the raw VIX level) and `broad_dollar_index` (DTWEXBGS, not DXY), including specific caveats like normal readings near 120. It also details freshness quantifications (stale_components_detail) and includes a deprecation history, which is far beyond the minimum.

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 well-structured: it starts with the purpose, then enumerates output fields, and dedicates specific attention to two potentially misleading keys. Every sentence adds value—there is no filler. The length is justified by the complexity of the output and the caveats, and important warnings are explicitly flagged ('read them carefully').

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, the description takes on the responsibility of explaining all return values, which it does in detail: composite_score, regime_label, cycle_phase_label, matrix_quadrant, tier_scores, components, and stale_components_detail. It also covers edge cases (deprecated keys, discontinued series) and provides concrete examples (vix_score value mapping). The '[Free tier]' note adds practical context. Nothing an agent needs to correctly interpret the response 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 the baseline per the rubric is 4. The description adds no parameter-related detail (there is nothing to add) but does not need to. It focuses instead on output semantics, which is appropriate. The schema coverage is 100% for parameters (none), so no discrepancy exists.

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 ('What is the macro backdrop doing?') and immediately states it is a 'Daily Macro Regime snapshot' built from a defined set of components and tiers. The verb (get) and resource (macro regime) are explicit, and the detailed composition (18 components, 6 tiers with percentages) clearly differentiates it from sibling tools like arena_get_btc_macro_correlations or arena_get_cycle, 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 thoroughly explains what the tool returns but provides no explicit guidance on when to use it versus alternatives. It does not state conditions like 'use when you need a broad macro overview' or contrast it with other read-only indicators. The absence of any when/when-not or alternative naming leaves the agent to infer usage from the content.

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?

Since no annotations are provided, the description carries the full burden of behavioral disclosure. It thoroughly documents return semantics (distance_pct, two percentile ranks with rank_n and null below 500 obs), warm-up rules (null before full window, never averaging over fewer days), data source (pre-Binance closes for BTCUSDT), tier-based range capping, granularity coarsening with explicit note, and explicitly states what the numbers are NOT (absolute price/MA levels). This level of transparency is exceptional.

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 purpose in the first sentence, then layers details in logical order (MA list, rank types, warm-up, data source, range, granularity, what-not-included, alternatives). No redundancy: each clause adds new information. The length is justified by 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?

With no output schema, the description must explain what the caller receives, and it does so comprehensively: it mentions the returned fields (distance_pct, two percentile ranks, rank_n, coverage block with first valid dates), edge cases (null before warm-up, tier caps, coarsening), and the specific meaning of each value. It also covers the pair-specific start dates. For a tool with this many parameters and behavioral nuances, the description leaves nothing essential unclear.

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 coverage is 100%, the description adds substantial meaning beyond the schema: it explains the ISO-week close definition for weekly MAs, the distinction between expanding and rolling ranks, the meaning of 'rank_n' null condition, the clamping behavior of 'from' to tier window, and the coarsening behavior for granularity. Each parameter's semantics is enriched, not just restated.

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 precise verb-resource statement ('How far above or below its moving averages did price stand back then?') and clearly distinguishes itself from siblings by naming arena_get_key_levels and arena_get_cycle with specific use cases. The title adds 'measured, not estimated' which further clarifies its unique role. This is exactly what an agent needs to quickly identify when to call this tool.

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 states when to use this tool vs alternatives: 'For today's absolute MA levels as named marks use arena_get_key_levels; for the cycle-scored 200-week distance use arena_get_cycle.' It also clarifies the context (measured time series vs estimates) and warns about the warm-up discipline. This gives the agent clear decision criteria without having to open other tools' definitions.

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 is exceptional: it explains settlement-time semantics, signed hours_to_settlement, null behavior, observation-time differences between open_interest_contracts and total_contracts, the recomputation of pre-2026-08-31 rows, the dealer-sign assumption for GEX, and the cron collection schedule. It also discloses that expiry flags are calendar-derived and that total_notional_usd never changes while open_notional_usd moves with spot.

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 — there is no filler and the content is highly informative. However, it is delivered as one dense, comma-heavy wall of text with nested parentheticals and no section breaks, which makes it harder to parse than a structured layout would be. It is appropriately rich but could be better organized.

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 covers all major call-critical aspects: return contents, field semantics, null and signed-value distinctions, venue behavior, GEX assumptions, data provenance, collection cadence, and related tools. An agent has enough information to invoke the tool correctly and interpret ambiguous timing/OI 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?

Schema coverage is 100%, so each parameter is already documented in the schema. The description adds meaningful beyond-schema context: market switches venue with DERIBIT_BTC default, include_gex is DERIBIT_BTC-only with both dealer-sign conventions, and include_strike_ladder includes a day-over-day delta and a recomputed max-pain cross-check. It does not fully restate every schema detail, but the added operational semantics justify a score above the baseline.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a concrete question — 'What happened at the last Deribit expiry?' — and enumerates exactly what the tool returns: max_pain_strike, spot_at_expiry, put_call_ratio, plus up to 10 upcoming expiries with live max-pain levels. It clearly names the resource (Deribit BTC max pain, latest + upcoming) and distinguishes itself from siblings by explicitly naming arena_get_max_pain_history and arena_get_iv_snapshot as related alternatives.

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 provides clear context for when the tool is relevant (latest and upcoming max pain, settlement comparison) and names related tools — arena_get_max_pain_history for base rates and daily snapshots, arena_get_iv_snapshot for implied vol on the same expiries. It does not give explicit 'use this when / use that when' exclusions, but the distinctions are inferable from the stated contents of each.

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 and does so thoroughly: it explains the output structure (rows plus per-class base_rates), the pooling pitfall it separates, that base_rates are computed BEFORE filtering, the open_snapshots limitations (not backfillable, starts 2026-05-28, thin depth), tier capping, and that max-pain levels are the tool's own aggregation (chain not redistributed). It also discloses the data source.

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?

Though long, the description is densely packed with non-redundant information. It front-loads the core purpose, then flows from rows to base_rates, then to filters, then to open_snapshots caveats, tier caps, and source/related tools. Every sentence adds a distinct piece of guidance; there is no fluff or repetition of schema details.

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, the description must explain return values and does so concretely (row fields, base_rates stats, open_snapshots structure). It also covers critical constraints (tier caps, data availability, backfill limits) and trade-offs (pooled median vs per-class). For a tool with this many parameters and caveats, nothing an agent needs 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%, so baseline is 3. The description adds real value beyond the schema: it explains why open_snapshots filtering with snapshot_expiry_date only matters when include_open_snapshots=true, advises using the filter parameters instead of post-processing, and clarifies that expiry_type filter does not affect precomputed base_rates. This contextual advice enhances parameter understanding.

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 precise research question ('Does max pain actually pull price to the strike?') and clearly states the tool returns settled Deribit BTC options expiries with computed max-pain levels. It enumerates the row fields and distinguishes from siblings (arena_get_max_pain for current/upcoming, arena_get_iv_snapshot). Verb+resource+scope are all specific, and it tells the agent exactly what analytical question this data serves.

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: it is for measuring the convergence question, contrasting with current/upcoming data. It instructs to filter with expiry_type / min_contracts / snapshot_expiry_date instead of post-processing the full row set, and warns that open_snapshots are thin and non-backfillable, so coverage must be checked first. It also notes tier-based day caps and names related 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?

With no annotations provided, the description bears the full duty of behavioral disclosure. It comprehensively reveals what is returned (spelled-out fields plus a deprecated raw row shape with removal date), semantics of the bands, and clarifies that this is a single ratio, not a regime call. The free-tier mention further sets expectations. This is thorough transparency 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 front-loaded with the core purpose, followed by field details, deprecation note, and reasoning for alternatives. Every sentence earns its place—no fluff. Although it's longer than average, the density of useful information justifies its length, and the structure (question → answer → caveats → alternatives) is logical.

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 input parameters and no output schema, the description must fully describe both the request and the response. It does: it lists return fields with provenance, explains the deprecated shape, defines the interpretation bands, clarifies the scope (single ratio), and points to sibling tools for related needs. Nothing an agent needs to correctly invoke and interpret this tool 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 the baseline is 4. But the description goes beyond by explaining the meaning of the output fields: sma_200d_source provenance, the exact definition of the Mayer Multiple, and the enumeration of band thresholds with their labels. This adds semantic value that no schema could provide, making it a 5.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with the exact question the tool answers ('Is BTC stretched against its 200-day average?') and then precisely states the product: the Mayer Multiple with its formula and return fields. It explicitly differentiates from siblings (arena_get_cycle for multi-indicator regime, arena_get_mayer_multiple_history for the series), so an agent can instantly identify this tool's unique role among a large 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?

The description gives explicit selection guidance: use this for the single current ratio, use arena_get_cycle for broader cycle context, and arena_get_mayer_multiple_history for the underlying series. It also adds a caution about not treating bands as trade thresholds, preventing misuse. This unambiguously tells the agent when to invoke it 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 provided, the description carries the full burden, and it does a strong job: it discloses the tier-capped range ([Free 30d / Pro 365d / Power unlimited]), the data granularity and ordering, and explicitly states the series is descriptive rather than a trigger. It stops just short of describing the exact response object shape or the auto-clamping behavior on exceeding the limit, which would make it fully 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?

One tight paragraph (~80 words) where every sentence earns its place: formula, granularity, interpretation, semantic caution, sibling routing, and tier cap. The hook question front-loads the subject matter clearly. Slightly dense with the interpretation clause and tier footnote packed after the core function, but the logical flow is sound and there is 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 single-parameter historical series tool with no output schema and zero annotations, the description covers nearly everything an agent needs: what is returned (formula, per-day rows, ascending order), how to interpret values (around 1 = at 200d average), the distinguishing sibling, and the tier range limit. The only gap is the precise response field names/shape, which is minor given the established series concept.

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 schema already fully documents 'days' (number of days back, auto-clamped by tier — Free=30, Pro=365, Power=3650). The description merely echoes the tier cap without adding new meaning beyond what the schema provides, so it neither improves nor detracts from the schema's coverage.

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 and resource ('Returns the Mayer-Multiple TIME SERIES'), gives the exact formula (BTC price ÷ 200-day SMA), granularity (one row per day), and sort order (ascending by date). It explicitly names the sibling arena_get_mayer_multiple, so an agent can distinguish the history variant from the single-value variant 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?

Provides explicit routing: 'For the current value alone call arena_get_mayer_multiple,' which tells the agent when to choose the sibling over this one. Also clarifies the semantic role — 'a descriptive ratio, not a trigger' — so the agent knows it is for context/analysis rather than signal generation. The tier-cap note further sets expectations about what this tool will deliver.

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?

With no annotations provided, the description carries full behavioral disclosure responsibility. It does add useful context by noting the '[Free tier]' and listing the exact fields returned, which implies a read-only operation. However, it does not disclose potential failure modes (e.g., unknown term), response format details, or any rate limits. The behavior is partially transparent but lacks depth, so a 3 is fair.

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 long and logically structured: opening purpose question, return list, and usage context plus free-tier note. The opening question is stylistically engaging but not strictly necessary; still, every sentence earns its place. It is concise and front-loaded with the core purpose.

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 read tool with two parameters and no output schema, the description covers the essential aspects: what it does, what it returns (listing fields), and when to use it (for onto: references). It lacks error handling and explicit read-only confirmation, but those are minor given the tool's simplicity. It is sufficiently complete for an agent 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 the schema already documents both parameters. The description adds value by providing an example term ('regime') and clarifying that version refers to the ontology reference format 'onto:<term>@<version>'. This enriches understanding of how the parameters map to the intended use case, exceeding the baseline of 3.

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 a specific verb ('resolve') and resource ('knowledge-platform term to its canonical definition'), with a concrete example ('term=\'regime\''). It enumerates what is returned (label, definition EN/DE, calculation, unit, source, version, related terms) and explicitly distinguishes its use case from all sibling tools, none of which handle ontology term resolution. The purpose is unambiguous and well 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?

The description gives explicit context for when to use the tool: 'Use this to resolve the onto:<term>@<version> references inside Knowledge Objects.' This is clear and actionable. It does not mention alternatives or when not to use it, but the context alone is sufficient given no sibling tool serves the same function, so a 4 is appropriate.

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 full burden. It discloses a meaningful behavioral caveat — counts include own bulk/admin snapshot runs, so it is coverage-weighted attention, NOT a clean crowd signal — and warns never to present it as 'traders are bullish on X'. It also discloses response sizes (~2 KB vs ~53 KB) and fixed-window behavior for dailyActivity, weeklyTrend, and profitTrend. This is genuinely 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 dense and information-rich, but it is longer than strictly necessary. Every sentence earns its place: scope, field windows, honesty caveat, alternatives, deprecated alias, detail recommendation, response sizes. Slight redundancy between the schema description and the description text (e.g., ~2 KB/full blocks) is minor. Front-loading is good: the core question 'what is being backtested' comes first.

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 2 optional enum params and no output schema, the description covers everything an agent needs: what aggregates exist, which windows apply, how to choose detail level, expected response sizes, a behavioral caveat, and sibling tools for sentiment. The presence of the deprecated alias and its removal date is an added bonus. Nothing material is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3. The description adds value by explaining how `period` affects only some fields while three fields have FIXED windows, and by elaborating on the `detail` values and their size/truncation trade-offs. This enriches the parameter semantics 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 states a specific verb ('Get platform activity dashboard') and resource ('Backtesting Arena platform activity'), and immediately distinguishes it from market sentiment. It names the key output blocks (hotAssets, hotStrategies, etc.) and explicitly says it is NOT market sentiment, which differentiates it from many arena_get_* sentiment 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 gives explicit when-to-use guidance: 'For actual market sentiment use arena_get_fear_greed, arena_get_funding_rate, arena_get_altcoin_season or arena_get_pulse.' It also explains fixed vs. period-controlled windows, recommends detail:'summary' unless the full blocks are needed, and notes the deprecated alias arena_get_sentiment. This is exemplary routing 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?

No annotations are provided, so the description carries the full burden. It discloses what the tool returns in detail: score, band label, color, 7d/30d delta, verdict, components breakdown, and score_percentile with an example interpretation. It also notes the free tier, which is an operational constraint. This is a read-only operation with no destructive side effects implied. The description transparently explains output semantics without contradiction.

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 well-structured and front-loaded with the core purpose (0-100 heat score). Each sentence adds value: the component list, return fields, percentile explanation, and free tier note. There is no fluff or redundancy. It is concise enough while providing necessary detail, achieving an appropriate length for the complexity it describes.

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 zero parameters and no output schema, the description must fully explain what the agent should expect as output. It does so comprehensively, listing all return fields and even explaining the percentile ranking. The free tier note adds operational context. There are no missing elements that would prevent a correct call 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?

The tool has zero parameters, so the schema covers all inputs trivially (schema coverage 100%). With no parameters to document, the baseline is 4. The description focuses on output rather than input, which is appropriate since there is no input, and it does not add any input-related meaning beyond what the schema already provides (which is nothing). No further compensation 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 clearly states the tool retrieves a daily 0-100 heat score for the Bitcoin market, a composite indicator aggregating 8 named components. It distinguishes itself from sibling indicator tools (e.g., arena_get_fear_greed) by framing itself as an overall pulse summary, and lists specific output fields, 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?

The description implies a use case: to get a single composite market heat score and its percentile ranking. It does not explicitly state when to use this tool versus sibling tools that retrieve individual components (e.g., arena_get_fear_greed, arena_get_cycle). However, the mention of '8 components' and the composite nature suggest it's a top-level summary, so an agent can infer when it's appropriate, but explicit guidance is missing.

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, and it does so thoroughly. It states the return format (one row per day, date/score/band, ascending), the optional component expansion (8 component readings with key, rawValue, earnedPoints, maxPoints), the window cap of 365 days when include_components=true, the ~8× payload multiplier, and the tier-dependent range cap. It also discloses a caveat about comparing component values across dates.

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 appropriately sized for a tool with two parameters, component-expansion complexity, and usage distinctions. Each sentence earns its place: the opening question frames the use case, the return format is stated immediately, the sibling alternative is mentioned early, and the component mode/tier caps are explained without 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?

Given no output schema and no annotations, the description supplies everything an agent needs to invoke the tool correctly: exact row structure, optional component fields, window/range caps, the component_epochs prerequisite, and guidance on when to use the simpler sibling. 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?

Schema description coverage is 100%, so the baseline is 3. The description adds value beyond the schema by explaining the purpose of include_components ('answers WHICH component moved the score') and the component_epochs caveat. However, it partially repeats schema information about the 365-day cap and tier clamping, which limits the additional semantic lift.

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 framing question and then states a specific verb+resource: 'Returns the Arena-Pulse TIME SERIES: one row per day with date, 0–100 score and band, in ascending date order.' It explicitly distinguishes itself from its sibling arena_get_pulse (today's value alone), so an agent can tell exactly what this tool does and how it differs.

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 context: 'Use it for trend, turning points and "how did we get here"; for today's value alone call arena_get_pulse (cheaper, one row).' It also provides a prerequisite warning ('check component_epochs before comparing component values across dates') and documents tier-based range caps. No ambiguity remains about selecting this tool over 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 full behavioral burden. It discloses the lifecycle states, returned fields (progress_pct, counts, urls), and a tier requirement ('API Pro tier'). This is good but does not mention read-only nature implicitly, nor rate limits or authentication, so not perfect.

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 concise sentence with a leading rhetorical question, followed by lifecycle, return fields, and tier. It front-loads the purpose and every sentence adds value without waste.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a single-parameter tool with no output schema, the description fully explains what the tool does, the lifecycle, and what the return values are (progress_pct, counts, pdf_url/xlsx_url). It also notes the API tier requirement, making it complete for an agent to correctly invoke and interpret results.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% for the single parameter (job_id), and the schema already states 'Job UUID returned by checkout.' The description does not add additional 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 clearly states the action ('Poll the status of a Custom-Report job') and the resource, with a lifecycle and return values. It is specific enough to distinguish from generic status tools, though it does not explicitly name a sibling, which would earn a 5.

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 after starting a report job ('Is my report ready?') and identifies the resource type, but it does not explicitly state when not to use it or mention alternatives such as the sibling arena_get_job_status. Context is clear but exclusions are absent.

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 provided, the description carries the full burden, and it delivers: it discloses deprecated status, the renaming reason, the removal date, that it's an alias with the same payload plus deprecation fields, and the free tier limitation. This is exceptionally transparent about the tool's behavior and lifecycle.

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: deprecation notice, correction of misnomer, migration instruction, alternatives, and free-tier caveat. It is front-loaded with the most critical information (deprecation and rename) and structured logically without 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?

For a deprecated alias, the description is complete: it explains the new name, why the old name was misleading, when the alias will be removed, and how to find the right tool for actual sentiment. The lack of an output schema is acceptable because the alias inherits the replacement's response structure, and the description notes the added deprecation 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?

Schema coverage is 100% for the single period parameter, including an enum and default value. The description adds no parameter-specific detail beyond 'Same payload plus deprecation fields', which refers to output rather than the input. Baseline 3 is appropriate since the schema handles parameter semantics fully.

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 is a deprecated alias measuring PLATFORM ACTIVITY, not market sentiment, and immediately names the replacement tool. It goes beyond a simple verb+resource by clarifying the misnomer and the actual semantics, fully distinguishing it from the many sibling 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?

It explicitly instructs to use arena_get_platform_activity instead, and lists specific alternative tools for actual market sentiment (arena_get_fear_greed, arena_get_funding_rate, arena_get_altcoin_season, arena_get_pulse). This gives both when-to-use and when-not-to-use guidance with concrete 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?

No annotations are provided, so the description carries the full burden. It discloses access requirements (no ownership, no Pro tier needed), describes the return shape (same as arena_get_backtest: config plus aggregate metrics), and subtly implies read-only via 'Fetches'. This is substantial behavioral context beyond 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?

Two sentences with no filler. The core question is posed first, then the answer, sourcing, and differentiation. 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?

For a single-parameter tool with no output schema, the description covers everything an agent needs: what it does, when to use it, access requirements, and return shape. No critical gaps.

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 parameter is already documented. The description adds context that share_id comes from a /shared/backtests URL, which is helpful but not essential beyond the schema. Meets the baseline for high coverage.

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 fetches a publicly shared backtest via a share_id, and explicitly contrasts it with the sibling arena_get_backtest for the user's own runs. It uses a specific verb and resource, 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?

Explicitly states when to use this tool ('when a user pastes a /shared/backtests URL') and when to use the alternative ('Use arena_get_backtest instead for the user's own runs'). This gives clear routing guidance with no ambiguity.

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 zero annotations, the description carries the full burden and delivers: events are RECONSTRUCTIONS from today's stored series, not live observations and not forecasts; occurred_at carries look-ahead; confirmation requires min_dwell days; drawdown uses the ATH up to that day and never a later one; the window is size-capped but position-free; silent rules are included. This is exemplary disclosure of behavioral traits that prevent misuse.

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 every sentence earns its place — signal list, event fields, dual-date semantics, window mechanics, reconstruction caveat, filter, tier note — and the opening question front-loads the purpose. It is a long single paragraph, but the length is justified by the tool's nuance; a bit more structural segmentation would improve scannability.

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 and no annotations, the description covers event contents (from/to state, dates, threshold params, btc_close, drawdown), the signal set, window behavior, and the critical reconstruction/look-ahead caveats. The only gap is the response envelope structure, but the essential semantics for correct invocation and interpretation are 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 coverage is 100%, so baseline is 3, but the description adds real value: it enumerates the 13 valid signal keys and explains end_date's window-positioning semantics ('capped in SIZE but free in POSITION') beyond the schema's generic 'last day of the window'. The occurred_at vs event_date distinction further clarifies output semantics relative to the requested window.

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: an 'event log of discrete transitions across 13 declared signals', with all signal keys enumerated. The transitions/event-log framing clearly separates it from siblings like arena_get_signal_status (current state) and arena_get_signal_context, 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?

Provides substantive guidance: use event_date for any forward evaluation because occurred_at carries look-ahead, filter with `signal`, and the schema example shows how end_date positions the window at the October 2025 top. Lacks explicit when-not-to-use or named alternatives, but the context is clear enough to route correctly.

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 disclosure burden. It discloses that the data is backed by a daily cron (implying freshness limits) and that at least one active Ampel is required, which are non-obvious operational constraints. However, it does not mention whether the operation is read-only, what happens on missing data or invalid combinations, or any error conditions. These gaps are significant for a tool with zero annotation coverage, though the disclosed constraints do add value.

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 and front-loads the core purpose with a direct question. The cron dependency and active-Ampel requirement are included compactly, and the [Free tier] tag is a briefnote. It is efficient and well-structured, though the question format is slightly informal; it still earns a 4.

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 read-only tool with three required parameters and no output schema, the description covers the core concept and key dependencies. However, it omits expected return format (e.g., a color string, structured object) and behavior when no signal is available or when the combination is invalid. Given the lack of an output schema, these details would be valuable for correct invocation. The description is adequate but not 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%, so each parameter (pair, interval, strategy) already has a description, including a detailed explanation of interval alignment and its impact on CAGR. The tool description adds the signal color concept (green/yellow/red) but does not elaborate on parameter formats or constraints beyond what the schema provides. The baseline 3 applies because the schema does the heavy lifting; the description provides marginal additional insight.

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 ('signalling buy or sell') and a well-defined resource ('signal-status (green/yellow/red) for a strategy on a pair+interval'). It clearly differentiates from sibling tools like arena_get_signal_context (which implies broader context) and arena_get_bullmarket_ampel (which targets a different signal type) by focusing on the current per-strategy signal state. The phrase 'Is this strategy signalling buy or sell right now?' is an immediate, unambiguous statement of purpose.

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 no guidance on when to use this tool versus alternatives. It mentions the cron dependency and the need for an active Ampel, but these are prerequisites, not usage directions. It does not state, for example, 'use this for a quick status check, use arena_get_signal_context for detailed explanations' — leaving the agent to infer appropriate invocation context from the sibling names alone.

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 provided, the description fully carries the behavioral burden. It explains the output structure in detail: current supply, 30d/90d change in USD and %, a compact time series, the `impulse` four-state enum, and the precise semantics of `acceleration_usd` versus the boolean `accelerating`, including how a reversal looks in the data. This goes far beyond a simple 'returns supply' and gives the agent a mental model of the tool's 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?

The description is dense but efficient: it front-loads the core purpose, then unpacks the richer trend data, then explains the nuanced field interactions, and finishes with source and tier. Every sentence contributes new information—no fluff, no repetition. The structure flows logically from high-level purpose to detailed field semantics.

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, the description must convey what the tool returns, and it does comprehensively. It lists the exact fields (current supply, 30d/90d change, time series, impulse, acceleration_usd, accelerating) and explains their meaning. It also notes the data source and free-tier context. For a parameterless read tool, 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 takes zero parameters, and the schema confirms this (empty object, 100% coverage). Per the rubric baseline for 0 parameters, a score of 4 is appropriate. Since there are no parameters, the description cannot add parameter semantics, and it correctly omits any mention.

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 verb and resource (`Aggregate stablecoin supply`) and immediately establishes its role as a crypto-liquidity proxy. It explicitly distinguishes itself from the sibling `arena_get_macro_regime` by pointing out that macro_regime only provides a 30d delta, whereas this tool exposes the trend with current supply, changes, and a time series. The purpose is unmistakable and clearly 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?

The description directly names the alternative (`macro_regime`) and explains its limitation (only the 30d delta), implicitly instructing agents to use this tool when they need trend direction/speed rather than a single delta. It also clarifies what each field (`impulse`, `acceleration_usd`, `accelerating`) means, giving clear context for when this data is relevant. The note about the free tier and source further aids usage decisions.

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 explains the construction of the bands (rolling 730-day window, sigma calculation), discloses that the bands are descriptive geometry not probability statements, provides measured coverage statistics, and explicitly notes the output is descriptive context, not a signal. This is exceptionally transparent for an on-chain data 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 dense but each sentence adds value: it defines the metric, explains derived measures, gives the band formula, warns about interpretation, and mentions the free tier. It is front-loaded with the core question, but the length is justified given the complexity. A little over-packed, but no unnecessary 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?

Without an output schema, the description fully specifies all output fields (cost basis, STH-MVRV, in_loss flag, band values, band_zone, percentile) and explains the rolling window, sigma method, and interpretation caveats. It also mentions the free tier and gives historical coverage context, so an agent knows exactly what to expect and how to interpret the result.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has zero parameters, so the schema provides complete coverage trivially. The description adds context about sigma_method/sigma_window_days traveling in the payload, but since they are not in the schema, they do not affect parameter understanding. The baseline for 0 params is 4, and the description does not need to explain any 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 description clearly states the tool provides the latest BTC short-term-holder cost basis, along with derived metrics (STH-MVRV, in_loss flag, sigma bands, band_zone, sth_mvrv_percentile). It distinguishes itself from siblings by noting 'own convention — not a rebuild' and explicitly referencing a specific on-chain series (brk_sth_realized_price), making the resource unmistakable.

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 tool's purpose and provides a caveat ('not a buy/sell signal'), but does not explicitly state when to use this tool versus alternatives like arena_get_cost_basis_spread or arena_get_btc_market_structure. Usage context is implied by the detailed metric set, but no direct exclusions or recommendations are given.

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 burden. It discloses the exact output components, explains CAGR time-normalization and its consequence for comparing different windows, warns that interval alignment alone can move CAGR by 6.66 pp, and clarifies that results come from real backtest aggregations rather than theoretical permutations. This is exceptionally transparent about behavior and limitations.

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 well-organized: it opens with the core purpose, then lists return fields, explains a caveat, and ends with the use case and tier note. Every sentence adds critical context (outputs, normalization, ambiguity thresholds). While it is longer than typical, the density is justified and front-loaded with the main answer.

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 and no annotations, the description covers all essential operational details: what is returned (baseline, variants, deltas, best pick, not_applicable_filters), how to interpret CAGR, the statistical noise floor, and the exact input constraints. Combined with the 100% schema coverage, nothing needed 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?

Schema coverage is 100%, so baseline is 3. The description adds meaningful value beyond the schema: it explains the interval alignment sensitivity with quantitative thresholds, notes that 1d/2d/3d behave as one block, and references arena_get_strategies for strategy keys. This goes beyond the schema's basic parameter descriptions, enhancing the agent's ability to choose safe 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 description states a specific verb and resource: 'per-(strategy, asset, interval) filter-effect analysis' and directly answers the use case 'Which filters would improve my backtest for X on Y?'. It clearly differentiates from theoretical permutations and lists concrete outputs (baseline stats, deltas, best pick), so an agent knows exactly what it returns and how it differs from generic strategy 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 explicitly says 'Use this to answer...' and specifies the scope (per strategy, asset, interval). It also provides a calibration rule for interpreting interval differences (6.66 pp threshold). However, it does not name alternative sibling tools or state when not to use it, though the uniqueness of the filter-effect focus makes alternatives less 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 provided, the description carries the full burden of behavioral disclosure, and it does so thoroughly. It discloses mode switching, the `plan_capped: true` flag plus `plan_cap_note` to prevent misreading a short matrix, the 403-on-Pro-only-detail behavior, and the interval-alignment caveat with quantified CAGR impact. These details go well beyond a generic 'returns data' 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: core purpose, mode conditions, free-tier cap, error behavior, and interval alignment caveat. It front-loads the primary purpose and then layers constraints in a logical order. The bracketed plan summary at the end is a compact reinforcement rather than redundant repetition.

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 moderately complex tool with two modes, six optional parameters, no output schema, and no annotations, this description covers the essential context needed to call it correctly. It explains what the response looks like in both modes, what failures look like, how plan limitations affect data, and a statistical caveat about interval alignment. Nothing critical for correct invocation is left unexplained.

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 top-level description adds meaningful interaction semantics beyond the individual parameter docs. It clarifies that `strategy` and `interval` jointly trigger detail mode, what detail mode contains, and how free-tier limits affect the results. This added context justifies a score above baseline, though it does not need to explain every parameter since the schema already does.

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 core question: 'Which strategy and interval combinations actually performed?', then precisely defines the resource as aggregated backtest performance per (strategy × interval) cell. It clearly distinguishes the two output modes: detail when both `strategy` and `interval` are provided, otherwise the matrix. This is specific enough to separate it from the many sibling `get_*` 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 explicit conditions for when to get the matrix versus the detail view, including the required combination of `strategy` and `interval`. It also warns about free-tier strategy restrictions and the 403 behavior for Pro-only strategies. It does not name alternative sibling tools or explain when to prefer this over related tools like arena_get_strategy_performance, so it stops short of full alternative 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 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 provided, the description carries the full behavioral disclosure burden, and it does so thoroughly: it explains that no verdict is returned by design, defines each metric (avg_pnl_pct as per-trade not annualized, reward_risk_ratio as mean/stddev not Sharpe), details share_of_time_pct calculation to avoid cadence skew, and explains the benchmark's role. It also discloses the interval-alignment pitfall with quantitative evidence (6.66 pp CAGR swing). 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 substantive information—regime classes, metric definitions, design rationale, composition guidance, and even a free-tier note. It is front-loaded with the core purpose and scopes the single combination clearly. While it could be trimmed (e.g., the free-tier tag feels extraneous), the density of valuable content justifies the length. It is structured as a coherent paragraph with logical flow.

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 fully explains the response structure: regime buckets with trades, trades_per_config, win_rate, avg_pnl_pct, reward_risk_ratio, share_of_time_pct, rating, plus the benchmark block and current live regime. It also clarifies the metric definitions and the rationale for including the benchmark. Nothing an agent needs to correctly interpret the output 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 schema already documents all four parameters well. The description adds value beyond the schema by clarifying the semantic meaning of interval alignment (epoch anchoring and its measured impact) and by stating that trades pool ALL parameter-variant configs. It doesn't repeat basic param definitions but supplements with nuanced context that affects interpretation. This is strong value-add.

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 ('In which macro regime has this strategy worked?') and states the exact scope: historical backtest performance for ONE (strategy, asset, interval) combination split by macro regime. It distinguishes itself from arena_get_strategy_performance (which presumably gives aggregate performance) and names the regime classes explicitly. This is a specific verb+resource with clear differentiation from 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 explicitly tells the agent when to use this tool and when to compose it with others: 'For a decision-grade view compose with arena_get_strategy_filter_effect and arena_is_distinguishable.' It also reasons about the benchmark block anchoring excess returns, and warns that a pooled-trade verdict was removed to avoid pool instability, indicating why this tool should not be used for verdicts. This exceeds minimal usage guidance.

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