backtesting-arena

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

Since annotations are absent, the description fully carries the burden. It discloses idempotency, that cancelling an already-cancelled subscription is a no-op, that undelivered updates are not removed, and that it returns the deactivated subscription. 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 three sentences, each serving a distinct purpose: action/effect, idempotency note, and source of ids/additional info. It is front-loaded with the core purpose, and every sentence earns its place 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?

Given the tool's simplicity, no output schema, and moderate parameter count, the description covers all essential behavioral aspects: cancellation effect, idempotency, side effects (queued updates not removed), source of ids, and tier restriction. It is complete for its complexity.

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

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

Schema coverage is 100% with descriptions for both parameters. The description adds marginal value: it tells where to get subscription_id (from arena_list_subscriptions). The context parameter is already explained in the schema. Baseline 3 is appropriate.

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

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

The description clearly states the action ('Deactivates one subscription by id'), the resource (subscription), and the effects ('stops firing and frees a slot'). It distinguishes itself from sibling tools like arena_list_subscriptions and arena_check_subscription_updates by focusing on cancellation.

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 guidance on when to use: when you need to cancel a subscription. It mentions that ids can be obtained from arena_list_subscriptions, and notes idempotency. However, it does not explicitly state when not to use or list alternatives, which is a minor gap.

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?

Discloses key side effect: marks updates as delivered after returning. Also mentions payload contents. With no annotations, this is above average but doesn't detail rate limits or destructive potential.

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 plus two short notes, all essential and front-loaded. 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 polling tool with schema describing the only parameter, the description provides comprehensive context including behavior, usage cadence, payload, and tier restriction.

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 has 100% coverage with a detailed description for the 'context' parameter. The tool description adds no further parameter meaning, baseline 3 is appropriate.

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

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

The description clearly states the tool returns undelivered updates and marks them delivered, with specific verb+resource. It distinguishes from sibling subscription tools that handle subscribing or canceling.

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 advises to 'Call regularly to consume the polling queue', providing when-to-use guidance. However, it does not mention when not to use it or alternatives, but the context is clear given 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 burden and excels: it discloses sequential execution, an expected runtime of 10–50s, per-day quota limits (Pro=20, Power=200), and API tier requirement. It also surfaces a subtle behavioral trait of the output—the winner is upward-biased under multiple testing—which is exactly the kind of context an agent needs to interpret results correctly.

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 dense but well-organized paragraph: purpose first, then use case/alternative, then caveat, then performance/quota. Every sentence adds unique value and no words are wasted. It is front-loaded with the core action and output, making it easy for an agent to grasp 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 absence of an output schema, the description adequately describes the return value (per-strategy metrics plus a comparison summary naming the specific best/worst categories). It also provides execution context (sequential, quota, tier) and statistical interpretation guidance. This covers the essential information an agent needs to invoke the tool and interpret its results.

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

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

Schema description coverage is 100%, so the baseline is 3. The description reinforces the core parameters (pair, interval, date range, strategies) but does not add new semantic details beyond what the schema already provides; it only restates the 'same pair, interval and date range' constraint. This meets the baseline without exceeding it.

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 ('Run') with a precise resource ('2–5 strategies against the SAME pair, interval and date range') and the expected output ('per-strategy metrics plus a comparison summary (best by CAGR, best by win-rate, worst by drawdown)'). It clearly distinguishes itself from sibling tools like arena_run_backtest and arena_run_universe_backtest by emphasizing the controlled comparison.

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

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

The description explicitly tells when to use the tool ('Use this when the user asks which of several strategies fits a market') and explains why it is preferable to calling arena_run_backtest multiple times. It also points to an alternative tool for a different use case ('For one strategy across many pairs use arena_run_universe_backtest instead').

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 transparently states that returns are scenario numbers and which option wins, explicitly denies being a buy/sell recommendation, and clarifies it uses user assumptions. It does not mention side effects, but the tool appears to be a pure computation with no destructive actions.

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 concise, covering key points in a few sentences. It front-loads the purpose and mode explanations. Some redundancy exists (mentioning modes twice), but overall it is efficient and informative.

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, nested objects, many parameters), the description provides sufficient context: what it does, what it returns, and what it does NOT do. The pointer to the full interactive version adds completeness. No output schema, but the description notes returns are scenario numbers, which is acceptable.

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 each parameter. The description adds value by explaining that prices are multiples of today in 'compare' mode and absolute in 'allocate' mode, and by mentioning Kelly/risk-aversion gamma. This enhances understanding 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 clearly states the tool's purpose: 'Buy now or wait for the dip? Decision-math over the user's OWN assumptions.' It distinguishes between two modes (compare and allocate) and explicitly states what it does not do (NOT a buy/sell recommendation). This differentiates it from sibling tools, which are mostly data retrieval or backtesting 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 clear usage context: it is for comparing buy-now vs wait based on user assumptions. It explains the two modes and advises to ask the user for missing inputs. However, it does not explicitly state when not to use it or compare it to alternatives among siblings, though the uniqueness of the tool makes this less critical.

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 provided, so description carries full burden. It clearly states the tool is descriptive only and never a buy/sell signal. It mentions it composes historical-analog + key-levels tools and requires an invalidation point. It does not disclose any destructive actions or auth requirements, which is acceptable for a query 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 well-structured, starting with the main purpose and then detailing outputs and requirements. It is slightly verbose but each sentence adds value. Front-loading is present with 'Frame a dip/accumulation thesis WITHOUT a recommendation'. The structure could be slightly more concise, but it is effective.

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 complexity (7 parameters, no output schema), the description covers all aspects: inputs, outputs (ladder, base rate, tradeoff), and context (structural framing, MCP-only, related tool). It distinguishes from siblings and explains when to use. The description is complete for an AI agent to understand and invoke 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%, but the description adds significant value beyond the schema. For example, it explains that BTX uses support clusters while ETH/SOL use 200-week MA; preset enum includes a note on price-derived presets for ETH/SOL; invalidation is mandatory and explicitly described; risk_aversion explains ladder tilt meaning. This goes well beyond a 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 the tool frames a dip/accumulation thesis without a recommendation. It specifies the outputs: tranche ladder anchored to structural marks, historical base rate from analog engine, and lump-sum-vs-tranche tradeoff. It distinguishes from sibling arena_dip_decision by noting different method (structural framing vs EV/Kelly) and references an interactive tool at a URL.

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: for dip/accumulation thesis framing, not a buy/sell signal. It differentiates from an interactive tool at https://tradingstrategies.work/analyse/dip-decision. However, it does not explicitly state conditions when not to use or mention alternatives among 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?

No annotations are provided, so the description carries the full burden. It discloses the methodology (v7 Native-Filter) and that it is daily and free tier. However, it does not explicitly state that it is read-only, describe any potential side effects, or mention rate limits or authentication requirements. The term 'snapshot' implies no destructive actions, but this is implicit.

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 concise (two sentences, one with a list) and front-loaded with the main purpose. It efficiently covers purpose and return data. However, the list of components could be formatted more cleanly; it is dense but still readable.

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 description explains what the tool returns (list of indicators) and mentions the free tier, which is helpful. However, since there is no output schema, the description could provide more detail on the format or possible values (e.g., what the color values look like). The parameter is well-documented. Overall, it is fairly complete for a simple data retrieval 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 only parameter 'context' has a detailed description that explains its purpose (analytics/intent tracking), provides word count guidelines (15-25 words), specifies third-person perspective, and warns against sensitive information. This adds significant value beyond the schema, which only defines type and required status.

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 daily Altcoin-Season indicator with specific components (BTC-Dominance, Alt-Dominance, Layer-1 signals, color, Top-50 snapshot). It uses a specific methodology ('v7 Native-Filter methodology') and distinguishes from siblings like 'arena_get_altcoin_season_history' by implying this is a current snapshot.

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 mentions 'Daily' and '[Free tier]', hinting at usage context (regular daily checks, accessible to free users). However, it does not explicitly state when to use this tool versus alternatives (e.g., arena_get_altcoin_season_history for historical data), nor does it provide any when-not-to-use guidance.

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

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

No annotations, so description must disclose behavior fully. It describes output format, daily resolution, and tier capping. It does not explicitly state read-only or mention rate limits, but the context as a 'get' tool implies no destructive side effects. Good but not exhaustive.

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

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

Two sentences: first defines output, second gives use case and alternative. No redundant information, front-loaded with key 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 the tool's simplicity and lack of output schema, the description covers all needed information: what it returns, how to use it, and tier limits. It distinguishes from a key sibling, making it complete for agent selection.

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 parameters described). Description adds value by explaining that 'days' is auto-clamped by tier and 'context' requires an explanation with an example, going 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 clearly states the tool returns a time series with daily data including specific fields (overall_color, BTC/alt/stablecoin dominance, BTC price). It distinguishes from the sibling 'arena_get_altcoin_season' which returns only today's state.

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

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

Explicitly says to use this tool for seeing capital rotation over time and to use the sibling for today's state alone. Also mentions tier-based range limits, guiding when to call.

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 adds important context: access control, API Pro tier requirement, and that it returns aggregate metrics. It doesn't mention rate limits or idempotency, but covers key aspects 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 concise with no wasted words, front-loading the core function. It efficiently links to sibling tools and states return contents in a single, well-structured sentence.

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

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

For a simple retrieval tool with no output schema, the description fully covers what it does, returns, constraints, and related tools. No gaps remain.

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 explaining the context parameter's detailed requirements (15-25 words, third-person, no sensitive info) and listing return fields that clarify the id parameter's purpose.

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 full record of ONE backtest run by id' and lists the specific fields. It distinguishes from siblings like arena_get_backtest_trades and arena_list_backtests.

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 tells when to use it, how to get ids from arena_list_backtests, for trades use arena_get_backtest_trades, and for new runs use arena_run_backtest. Also mentions access restriction: 'Only your own runs (admins may read others).'

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?

Discloses that only closed round-trips are returned (open positions excluded). Mentions API Pro tier requirement. No annotations provided, so description carries full burden; could mention pagination or data limits, but overall good.

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

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

Front-loaded with purpose, each sentence adds value. No redundant language. Efficiently covers purpose, usage, and limitations in two sentences plus a short note.

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 simple parameters and no output schema, description fully covers what the tool returns, how to use it, and prerequisites. No gaps identified.

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

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

Schema covers both parameters with descriptions. Description adds context: 'id' is a run_id from arena_list_backtests, and 'context' parameter has detailed usage instructions (word count, third-person perspective). Adds 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?

Description clearly states it returns individual round-trips of a backtest run, specifying exact fields (entry/exit dates, prices, P&L, equity curve). Distinguishes from sibling arena_get_backtest which provides aggregates only.

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 tells when to use this tool ('when aggregate metrics are not enough') and when not ('for aggregates alone use arena_get_backtest'). Also specifies prerequisite (run_id from arena_list_backtests).

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

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

No annotations provided; the description discloses the pre-aggregated weekly nature and historical focus, but lacks details on side effects, authentication, rate limits, or data freshness. Some transparency exists but not comprehensive.

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?

Description is a single paragraph that efficiently lists components and return fields without excessive detail. Could benefit from structured formatting (e.g., bullet points) but remains concise 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?

Despite no output schema, the description covers the return structure (quadrant_performance, component_correlations, asset_correlations, current_quadrant) and lists included components. Lacks detailed explanation of each field's interpretation, but sufficient for a data-retrieval 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 only parameter 'context' has a description covering 100% of schema, but it is a meta-parameter about intent tracking, not about data selection. The description adds value beyond schema by explaining the tool's output, but the parameter itself does not affect the correlation data.

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 tool name, title, and description clearly indicate it provides pre-aggregated weekly correlations between Bitcoin and 13 macro components plus 4 asset classes. The description lists specific components and return structure, distinguishing it from numerous 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?

The description states 'Historical analysis only — not investment advice' but does not explicitly mention when to use or avoid this tool, nor provide alternatives. Usage is implied by the specific data it returns.

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 discloses behavioral traits: it explains the base rate calculation caveat ('a fresh same-day flip is the least reliable observation... NOT a forecast'), states it is educational, and lists all returned fields. This provides comprehensive transparency about the tool's 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 a dense single paragraph that covers many details but lacks structural formatting like bullet points or clear sections. While it is not overly long, readability could be improved with better organization. It is adequate but not exemplary.

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

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

Given the complexity of the tool with multiple output fields and no output schema, the description provides thorough detail on all return values and the base rate interpretation. It also notes the free tier. The description is complete enough for an agent to understand what the tool does and what to expect.

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 is only one parameter (context) with 100% schema coverage, and the description does not add any additional meaning for parameters beyond the schema. Baseline 3 is appropriate since the schema already documents the parameter adequately.

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 daily Bitcoin market structure from a specific indicator (Phantomflow adaptation) and lists specific outputs like current_trend, wave counts, fractals, and trend context. It is specific and detailed, but does not explicitly differentiate from sibling tools like arena_get_btc_macro_correlations or arena_get_bullmarket_ampel.

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 mentions 'Educational analysis of price action — no signal, no recommendation' implying it's for educational use, but it does not specify when to use this tool versus alternatives or provide any exclusions or prerequisites. No guidance on context such as market conditions or user goals.

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 that the tool is free-tier and returns specific fields (active_count, stage_history, stage breakdown), but does not mention side effects, authentication needs, rate limits, or caching. The transparency is adequate but lacks depth.

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 concise with two sentences. The first sentence states the core function; the second adds output details and a behavioral note. It is front-loaded and efficient, though the first sentence could be grammatically smoother.

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 many sibling tools, the description is incomplete. It names return fields but lacks structure, types, or examples. It does not explain what the stages represent or how this tool relates to similar ones. Agents may struggle to interpret results or choose this 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?

Schema description coverage is 100% (one required 'context' parameter with a detailed description). The tool description does not reference this parameter, adding no meaning beyond the schema. Baseline 3 is appropriate because the schema already provides full documentation for the parameter.

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

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

The description clearly states the tool returns the current state of a specific indicator ('Bullmarket-Ampel') with a numeric stage count and mentions return fields. The verb 'Get' matches the name. It is distinct from sibling tools because it targets a unique indicator, but the description does not explicitly differentiate it from other data retrieval tools like arena_get_cycle.

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

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

The description provides no guidance on when to use this tool versus alternatives. It only notes '[Free tier]' implying cost, but does not specify conditions, prerequisites, or compare to sibling tools. Agents are left to infer the tool's role without context for selection.

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?

The description fully discloses behavioral traits: it explains point-in-time scoring, how ETH/SOL return not_applicable for BTC-native indicators, the output structure (raw + Z-Score, signal enum, percentiles block, highlights, price_context), and that the tool is not reconstructable from a generic price API. No annotations are provided, but the description carries the entire burden and does so excellently.

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 but well-structured. It front-loads the core purpose, then details the indicators, asset-specific behavior, and output. Each sentence adds value. Minor room for tightening (e.g., '[Free tier]' could be separate), but overall efficient.

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 (multiple indicators, asset differentiation, no output schema), the description is thorough. It explains the output structure (raw, Z-score, signal enum, percentiles, highlights, price_context) and limitations. It does not elaborate on interpreting the signal enum or percentiles, but these are likely domain-knowledge. The 'Free tier' mention is brief but acceptable. Overall, quite 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% (both parameters described). The description adds significant meaning beyond the schema for the 'asset' parameter, explaining that ETH/SOL return a price-derived cycle with not_applicable fields. The 'context' parameter description is standard and sufficient. Overall, the description 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 clearly states the tool's purpose: 'Crypto cycle position — where are we in the cycle?' It specifies the default asset (BTC), lists the comprehensive set of indicators aggregated, and differentiates behavior for ETH/SOL. This is a specific and informative statement.

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 when to use this tool vs. alternatives: 'Note for volatility questions: this tool carries the regime context around a volatility reading (Funding, Mayer, Pi-Cycle) but not the volatility series itself — that is arena_get_volatility_history.' It also lists related tools (arena_get_historical_analog, arena_get_bullmarket_ampel, arena_get_pulse), providing clear guidance.

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

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

With no annotations, the description carries full burden. It discloses point-in-time behavior (look-ahead-free analysis) and tier caps. However, it does not explicitly state that it is a read-only operation or mention authentication needs, but these are implied by the nature of the tool and available free tier.

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 front-load the key information: what it returns and its behavior. No fluff; every sentence serves a 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?

Given no output schema, the description fully explains the return format (columns, ordering) and constraints (tier-based limits). It also covers use cases and alternatives, making it self-contained for the agent.

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 3. The description adds value by explaining the output structure (adj_score and z_adj_score) and clarifying that 'days' is auto-clamped by tier, which goes beyond the schema's 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 the tool returns a 'BTC-Cycle TIME SERIES' with specific columns (adj_score and z_adj_score) and ordering (ascending by date). It explicitly distinguishes from sibling tools like arena_get_cycle and arena_get_historical_analog.

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 when-to-use (time series for look-ahead-free analysis) and when-not-to-use alternatives: 'For the current cycle reading alone call arena_get_cycle; for what similar historical readings were followed by, call arena_get_historical_analog.' Also mentions tier-based range limits.

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?

Despite no annotations, the description discloses the output (mean, max, outlier counts) and window parameter. It does not mention rate limits, auth needs, or whether it's read-only, but the details provided are adequate for a read-like operation.

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?

Three sentences precisely cover purpose, output, and usage context with no wasted words. The tier mention is appropriate and concise.

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 two well-documented parameters, the description provides sufficient context: output structure, window usage, and specific review cadence. Minor gap: no explicit mention of read-only nature.

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 both parameters comprehensively. The description adds minimal parameter context beyond implying 'days' controls the window. Baseline 3 is appropriate.

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

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

The description clearly states the tool's purpose: comparing bgeometrics vs BRK pilot metric pairs and returning drift metrics. It distinguishes itself from many similar 'arena_get_*' siblings by specifying the unique function and usage context.

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 specifies the tool is used for BRK-migration review every 4 weeks, providing clear usage context. However, it does not explicitly mention when not to use it or alternatives among the many sibling 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 provided, so description carries full burden. Discloses verdict criteria (Δ>+1pp, ≥30 runs), that filters are evaluated in isolation, and caveat about gross vs net CAGR. Fully transparent about 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?

Description is informative but somewhat lengthy. Front-loaded with main purpose. Each sentence adds value, but could be slightly more concise while maintaining completeness.

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

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

No output schema, but description thoroughly explains return values (baseline/filtered CAGR, verdict) and criteria. Complete understanding of tool's output and behavior.

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. Description adds context parameter semantics (word count, third-person, analytics) but other parameters are adequately covered by schema descriptions. Minimal added 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?

Description clearly states it provides aggregated analysis of how Pro+ entry filters affect strategy CAGR, with specific verb (get/reports) and resource (filter effect reports). Distinguishes from siblings by focusing on platform-wide filter evaluation.

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?

Describes when to use for evaluating filter effects, mentions isolation and baseline comparison, but does not explicitly contrast with related sibling tools like arena_get_filter_insights or arena_get_strategy_filter_effect.

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 provided, so description carries full burden. States it's descriptive only, not a signal, and sources from SoSoValue. Mentions '[Free tier]' indicating no additional cost or restrictions. 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?

Description is a single paragraph with clear structure: purpose, differentiation, output details, then parameter options. Front-loaded with the main verb. Could be slightly more concise, but no wasted sentences.

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

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

No output schema, but description enumerates key outputs: 30d/90d net flow, acceleration, direction label, cumulative time series. Also notes default behavior and free tier. For a data retrieval tool, this 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%, but description adds valuable context: default values for 'days' (365) and 'asset' (BTC), and explains the meaning of outputs tied to parameters. The 'context' parameter is standard but explanation is sufficient.

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 clearly states it retrieves Spot-ETF net flows (USD millions) for BTC/ETH/SOL with trend analysis, distinguishing from a point-in-time summary. Verb 'get' plus resource 'etf_flows' is specific. Differentiates from siblings by focusing on ETF flow trends.

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 compares to summary tool ('The summary only gives point-in-time deltas; this exposes the trend'), indicating when to use this over alternatives. Default and asset options are clear. No explicit 'when not to use' but context is adequate.

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

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

With no annotations provided, the description carries full burden. It discloses the return values (value, classification, history, cache) and notes it is from a free tier, hinting at rate limits. However, it does not explicitly state if it is read-only or any side effects, leaving room for ambiguity.

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, front-loaded sentence that efficiently communicates the tool's output and data source without unnecessary words. Every phrase 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 no output schema, the description adequately explains the return values (current value, classification, recent history, cache) and mentions the free tier limitation. It is sufficient for a simple index retrieval tool, though could note pagination or format.

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 only parameter 'context' has 100% schema coverage. The description does not add meaning beyond the schema, which already explains its purpose and provides an example. Baseline score of 3 applies as schema does the heavy lifting.

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

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

The description clearly states the tool returns the Crypto Fear & Greed Index with current value (0-100), classification, recent history, and cache info. It specifies the source and differentiates from siblings by mentioning 'arena-specific cadence cache for change-detection'.

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 obtaining fear/greed data with historical context, but does not explicitly state when to use this tool versus alternatives (e.g., other sentiment tools) or when not to use it. No exclusions or alternatives are mentioned.

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 must carry full behavioral disclosure. It does not mention read-only nature, authentication needs, rate limits, or side effects. The mention of API tier is minimal context.

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

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

The description is a single, information-dense sentence that captures the tool's core purpose and key filters. No fluff or redundant phrases.

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 no output schema, the description explains input (context) and output concept (lift analysis metrics). It is complete for a tool with one parameter and a straightforward analytic goal.

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 only parameter (context) has a detailed description in the schema (100% coverage). The tool description adds no additional meaning beyond what the schema provides, so baseline 3 applies.

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

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

The description clearly states the tool provides lift analysis of entry filters (200WMA, Altcoin-Season, ATR-Volatility, Bullmarket-Stage) per strategy combo, comparing baseline vs filtered CAGR/win-rate/drawdown. It distinguishes from sibling tools by specifying a unique analytic 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 implies usage via 'API Pro tier' but does not explicitly state when to use this tool vs alternatives like arena_get_strategy_insights or arena_get_strategy_performance. No direct comparison or exclusions are provided.

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 the data source (Binance), the metrics returned, and the interpretation of positive/negative values. It also notes the free tier. Missing details like rate limits or required permissions, but sufficient for a simple read-only data retrieval.

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 concise: two sentences plus a brief interpretation note. It front-loads the essential purpose and outputs, with no unnecessary verbiage.

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 simple nature of the tool (single snapshot retrieval) and that no output schema is provided, the description adequately explains what is returned (value, 30d MA, Z-score) and their interpretation. No critical information 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 only parameter is a meta-parameter 'context' for analytics, which is fully described in the schema (100% coverage). The tool description adds no additional meaning for this parameter, but that is acceptable as it is not a core functional parameter. Baseline for zero functional parameters is 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 clearly states it provides the latest aggregate Binance Perpetual Funding Rate with an 8-hour cadence, and lists the returned metrics (value, 30d MA, Z-Score). It distinguishes from similar tools like arena_get_funding_rate_history by specifying 'latest aggregate'.

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 use for current rate snapshot ('latest') and mentions the cadence, but does not explicitly state when not to use it or note alternatives (e.g., history tool for past data). However, the context is clear enough.

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 description carries the burden. It explains the aggregation cadence, ascending order, tier-based range cap, and meaning of funding values. Lacks details on rate limits or authentication, but covers key behavioral traits.

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 well-structured sentences, front-loaded with the main action. No unnecessary words or 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?

Given no output schema, the description is mostly complete. It could specify the output format more precisely, but the behavior and tier constraints are well-covered.

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

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

Schema coverage is 100%, so baseline is 3. Description adds context like tier clamping and interpretation, but does not provide additional parameter-specific details beyond what the schema already gives.

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 clearly states it returns the funding-rate time series for Binance perpetuals, aggregated at 8-hour cadence, ascending by date. It distinguishes from sibling arena_get_funding_rate by directing users to that tool for the latest single value.

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: when to use this tool vs arena_get_funding_rate. Also explains interpretation of sustained extremes vs single prints. However, does not explicitly state when not to use it beyond the sibling comparison.

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 the score is relative and not a price forecast or buy signal, which is valuable. However, it lacks details on rate limits, authentication, or the exact scope of data returned for free vs. Pro+ users beyond a brief '[Free tier]' mention.

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 purpose is front-loaded, followed by usage guidance and a disclaimer. Every sentence adds necessary information 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 no output schema, the description provides a thorough overview of the return value (composite score, group breakdown, raw factor values for Pro+). It also includes a usage caveat (disclaimer about price forecast) and free tier note. The sibling context is addressed via clear disambiguation.

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

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

Schema covers 100% of parameters, each with descriptions. The description adds meaning by explaining the coingecko_id is for one coin and that the context parameter is for analytics. It also elaborates on the return value (composite, group breakdown, raw factors) which is not in the schema since output schema is absent.

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 'Returns the Altcoin-Screener score for ONE coin' with a specific verb and resource. It clearly distinguishes from siblings by mentioning the plural variant and validation tool, ensuring no 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?

Directly states when to use this tool ('once a candidate is known') and when to use alternatives ('rank or filter the whole screened universe use arena_get_gem_scores' and 'how the score behaved out-of-sample use arena_get_gem_validation'). Provides explicit context for 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, the description must fully disclose behavior. It states daily refresh and tier gating, which are key behavioral traits. It does not explicitly state it is read-only, but for a data retrieval tool, this is acceptable. Minor omission of side effects.

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 concise: two sentences front-loaded with purpose and key details. No wasted words; 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?

Without an output schema, the description does not detail the return structure (e.g., fields per coin). While the input is well-described, the agent may need to infer output format. Given the tool's simplicity, it is minimally adequate but not fully 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 all three parameters. The description adds little beyond schema for 'limit' and 'from_rank', though the tier context for 'limit' is implied. The 'context' parameter is well-documented in the schema. Overall, the description does not significantly enhance 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 clearly states what the tool does: it provides an altcoin screener ranking based on three factor groups. It distinguishes itself from siblings (e.g., arena_get_gem_score) by specifying it ranks the top 200 coins from CoinGecko.

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 mentions tier limitations (Free top-10, Pro top-50, Power top-200) and notes it is backtest-validated, not a hype list. However, it does not explicitly state when not to use this tool or provide alternatives, leaving some 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 provides some behavioral context: backtest frequency (bi-weekly), weighting (equal-weight), and output metrics. However, it omits rate limits, data freshness, destructive potential, and authentication details beyond tier hints.

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 extremely concise: two sentences and a tier hint. Every sentence adds value, front-loads the primary purpose, and avoids repetition of schema data.

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

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

No output schema exists; the description mentions three metrics (CAGR, max drawdown, win-rate) but does not specify return format, data range, or default period. For a moderately complex tool with many siblings, this 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 coverage is 100% with parameter descriptions. The tool description adds tier information (default 10, Pro+ up to 200) which matches schema notes but does not significantly expand on parameter meaning beyond what is already documented.

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 runs a bi-weekly equal-weight basket backtest for Top-N screener picks vs BTC and market average, listing output metrics. However, it does not explicitly differentiate from sibling tools like arena_get_backtest, leaving some ambiguity for an agent.

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?

No explicit guidance on when to use this tool versus alternatives. The description mentions free and Pro+ tiers but does not indicate prerequisites or scenarios where other tools (e.g., full backtest) are more 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 provided; description adds context about free tier and the interpretation of results but does not explicitly state that the tool is read-only, disclose error conditions, or mention rate limits. Adequate but not thorough.

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?

Extremely concise: one sentence covering purpose, output, and interpretation, plus a note on free tier. Every word 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?

Describes the output (two moving averages and their interpretation) sufficiently for a simple indicator tool with no output schema. Lacks explicit mention of data format but overall 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 has 100% coverage for the single context parameter, so baseline is 3. Description does not add any additional meaning or guidance beyond the schema 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?

Clearly states it returns the Hash Ribbons indicator with specific details (30d and 60d hashrate moving averages) and the bullish signal interpretation. Differentiates from siblings by naming the specific indicator and creator.

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?

Implies usage for checking miner recovery signals, but no explicit guidance on when to use this tool versus related indicators like arena_get_cycle or arena_get_fear_greed. No alternatives or exclusions mentioned.

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?

Discloses that it is a distribution, not a recommendation; warns about NULL 'study_finding' fields; explains how to interpret 'vs_unconditional_drift'; mentions point-in-time integrity, small-n warnings, and API Pro tier. No annotations provided, so description carries full burden and does so thoroughly.

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 structured with a clear first sentence stating purpose, followed by output details, warnings, asset-specific notes, and related tools. Every sentence adds value; no 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?

Despite no output schema and no annotations, the description covers all aspects: purpose, parameter nuances, behavioral caveats, interpretation of results, limitations, and related tools. It fully equips the agent to use 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?

Schema coverage is 100%, but description adds significant context: explains presets in detail, mentions default horizon behavior for quiet_volatility, and clarifies asset eligibility per preset. This goes beyond the schema descriptions.

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

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

The description states 'Conditional forward-return distribution for a named preset cycle state' with specific outputs (median/IQR/positive-share forward returns over horizons) and explicitly distinguishes itself from related tools like arena_get_volatility_history and arena_get_cycle.

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

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

Provides explicit guidance: when to use vs alternatives ('not obtainable from web search...'), asset-specific restrictions (BTC-only for fear-greed/volatility presets), and which sibling tools to use for related analyses (e.g., arena_get_cycle for current state).

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 must disclose behavioral traits. It implies a read-only operation by stating 'Latest Deribit volatility snapshot', and mentions backfill dates and free tier. However, it does not explicitly state safety (e.g., no destructive side effects) or any authentication or rate limit requirements. The return value list adds some transparency but not fully comprehensive.

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, front-loaded with purpose and key outputs. Every sentence adds value: purpose, return fields, use cases, and backfill details. It is efficient but could be slightly more condensed.

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 compensates by listing the specific return fields (DVOL, ATM implied vol, realized vol, vol risk premium). It also includes backfill dates and a free tier note. For a simple data retrieval tool, this provides sufficient context for the agent to understand the tool's output and limitations.

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 the two parameters sufficiently. The description does not add extra meaning beyond the schema for parameters; it focuses on outputs. Given high schema coverage, a baseline score 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 it fetches the latest Deribit volatility snapshot for BTC or ETH, listing specific return fields. This distinguishes it from sibling tools like arena_get_volatility_insights or arena_get_volatility_history, which likely serve different purposes.

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

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

The description mentions it is useful for position sizing, options strategies, and market regime assessment, providing clear context for when to use it. However, it lacks explicit guidance on when not to use it or naming alternative tools, which would elevate the 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?

No annotations are provided, so the description must cover behavioral traits. It describes the return fields (status, progress_pct, pairs_completed, full result) and notes '[Free tier]', but lacks details on rate limits, error behavior, or side-effect info. It does not contradict annotations (none present).

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 well-structured sentences. First sentence states purpose and prerequisite; second lists return content and free tier note. No wasted words; front-loaded with key information.

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

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

Given no output schema and no annotations, the description covers the core behavior: polling mechanism, return fields, and relationship to another tool. It omits polling frequency advice and error handling, but is generally complete for a simple status-check tool.

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

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

Schema description coverage is 100%, with both parameters (job_id, context) documented. The description adds minimal value beyond the schema, only referencing job_id. Baseline 3 is appropriate.

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

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

The description clearly states the tool polls an async job by job_id, created via arena_run_universe_backtest. It explicitly mentions the source tool and what it returns, differentiating it from other get_ tools that are not job-related.

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 indicates this tool should be used after launching a backtest with arena_run_universe_backtest, providing clear context. However, it does not specify when not to use it or offer alternatives among the many sibling 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. It discloses that the tool is descriptive and not predictive, and mentions output structure, but does not cover rate limits, authentication needs, or cost implications beyond noting '[Free tier]'.

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 detailed but not overly verbose, front-loading the core purpose and output structure efficiently.

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 explains key output elements (touch-count, band, last-touch date, signed distance) and ordering, but does not explicitly state that the tool is for Bitcoin only (implied by title and description).

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 explains the context parameter elaborately. The description adds no further parameter-specific detail, so baseline score 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 it provides reproducible Bitcoin support/resistance zones from swing pivot clustering, distinguishing it from other arena tools by focusing on level generation rather than predictions or signals.

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 says it is descriptive only and not a prediction or signal, but it does not explicitly compare to sibling tools like arena_get_btc_market_structure or provide when-not-to-use guidance.

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

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

With no annotations provided, the description carries full behavioral burden. It discloses that the tool returns the 'current published envelope' and details the components (payload, explanation, provenance, etc.). It also explains the optional graph traversal behavior and notes access gating via 'min_tier' and a free tier. No contradictions present. Lacks explicit mention of rate limits or authentication, but the detail is strong for an unannotated 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 moderately sized but well-structured, front-loading the core purpose and return structure. It uses bullet-like formatting (colons and commas) and includes a parenthetical note about free tier. Every sentence adds value; no redundancy. Could be slightly more concise in the graph option explanation, but overall efficient.

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 5 parameters, no output schema, and no annotations, the description provides a comprehensive picture: it explains what the tool does, what it returns (payload, explanation, provenance, ontology binding, compute version), how the optional graph works, and access constraints (free tier, min_tier gating). This is sufficient for an agent to understand the tool's capabilities and invoke 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?

All 5 parameters are documented in the input schema (100% coverage), so the baseline is 3. The description adds minimal extra meaning beyond the schema: it summarizes the required pattern (type+subject), mentions as_of as optional, and explains include_graph's effect consistently with its schema description. The context parameter description in schema is already very detailed. No significant enrichment 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 clearly states the tool fetches a 'versioned, explainable Knowledge Object by type + subject' and specifies what is returned (payload, explanation, provenance, ontology, compute version). It explicitly says 'ONE tool covers ALL knowledge types', distinguishing it from potential sibling tools that might be more specific. The verb 'fetch' and the structured return list make the 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 usage for retrieving a knowledge object by type+subject, but does not explicitly state when to use this tool versus siblings like 'arena_list_knowledge' or other get_* tools. It mentions the include_graph option and free tier/gating, but lacks direct guidance on alternatives or when not to use this tool. The context is implied 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?

No annotations are provided, so the description carries the full burden. It details the output structure, including composite_score, regime_label, and stale_components_detail, and warns about component name semantics (e.g., vix_score vs VIX level). This provides good transparency beyond basic 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 relatively long but packed with necessary details. It front-loads the core purpose but includes extended notes on component semantics and deprecation. While informative, it could be more concise without losing key information.

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

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

Given the absence of an output schema, the description thoroughly explains return values: composite_score, regime_label, cycle_phase_label, matrix_quadrant, tier_scores, components, and stale_components_detail. It also clarifies caveats about component names and deprecated fields, making it complete for agent understanding.

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 covers the single 'context' parameter with 100% description coverage. The description adds no extra meaning beyond what the schema already provides, so baseline score 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 it returns a 'Daily Macro Regime snapshot' with specific components and scores. It distinguishes itself from sibling tools by its unique focus on macro regime data, 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 does not explicitly state when to use this tool versus alternatives. While it mentions 'Daily' frequency, it lacks guidance on when to prefer this over other macro or data tools, leaving the agent to infer 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 provided, the description carries the full burden of behavioral disclosure and does so admirably. It reveals important behaviors such as the days_to_expiry clamp to 0, signed hours_to_settlement semantics, null handling for unverified settlement times, the subtle distinction between total_notional_usd and open_notional_usd, and the nesting of expiry type booleans. It also discloses the cron collection time and 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?

The description is a single dense paragraph that is verbose and could be better structured with bullets or headings. However, every sentence provides useful technical detail, and it is front-loaded with the core purpose. While not concise, it avoids redundancy, so it earns a middle score rather than a lower one.

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

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

There is no output schema, so the description must explain return values and field semantics, which it does thoroughly. It covers field meanings, edge cases, data provenance, nesting logic, and related tools, making the tool fully operable for an agent without additional documentation. The absence of an output schema is fully compensated by the detailed field walkthrough.

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

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

Schema description coverage is 100%, with both market and context parameters already well-described (enum for market, word-count and style requirements for context). The description adds some market-specific context (e.g., DERIBIT_BTC settlement time of 08:00:00Z) but does not significantly augment the parameter semantics beyond the schema, 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?

The description clearly states the tool returns the last finalized Deribit BTC options expiry (max_pain_strike, spot_at_expiry, %-diff, put_call_ratio, notional) plus up to 10 upcoming expiries with live max-pain levels. This specific verb+resource+scope distinguishes it from related tools like arena_get_max_pain_history, which is explicitly mentioned as covering base rates and daily snapshots.

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?

While the description does not explicitly say 'use this when you need current max pain and not history,' it provides extensive guidance on interpreting fields (e.g., when to use settles_at vs days_to_expiry, distinguishing live vs settled states) and mentions related tools at the end. This gives clear context for using the tool correctly, though it lacks explicit when-not statements.

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 discloses behavior: it returns complete base rates, the open_snapshots series starting date (2026-05-28), its non-backfillable nature, thin depth, and tier-based day caps. 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 comprehensive but slightly verbose. However, every sentence adds value, and important information is 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 4 parameters, full schema coverage, and no output schema, the description is complete. It explains output fields, snapshot limitations, tier caps, and sibling tools.

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

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

Schema covers 100% of parameters with descriptions. The description adds meaning beyond schema by explaining the purpose of include_open_snapshots, the implications of its use, and the tier caps on days.

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 historical Deribit BTC options expiry data, listing the fields in each row. It distinguishes itself from siblings by mentioning 'Related: arena_get_max_pain (current + upcoming), arena_get_iv_snapshot.'

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 for when to use this tool, including the open_snapshots feature and its limitations. It references sibling tools for current data. However, it lacks explicit 'when not to use' guidance.

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

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

Discloses outputs (ratio, price, SMA) and mentions the Trace Mayer bands. Notes it's a single ratio, not a regime call, and indicates '[Free tier]'. Lacks mention of rate limits or specific auth requirements, but these are generally implicit for read operations.

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 sentences, each purposeful. Front-loaded with core purpose, then usage guidance, and behavioral caveats. No redundant words; highly efficient.

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 get tool with no output schema, the description covers what it returns (ratio, price, SMA), usage context, and alternatives. No gaps identified.

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

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

Schema coverage is 100% with a detailed description of the 'context' parameter. The tool description adds no further meaning to this parameter, so value is 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 it returns the Mayer Multiple (BTC price / 200-day SMA) and includes underlying values. It distinguishes from siblings like arena_get_cycle and arena_get_mayer_multiple_history, making the tool's specific 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 says when to use (current Mayer Multiple) and when not to (not a regime call). Provides alternatives: arena_get_cycle for multi-indicator cycle, arena_get_mayer_multiple_history for historical series. Warns bands are descriptive, not trading thresholds.

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 describes the calculation and interpretation, but does not explicitly state that this is a read-only, non-destructive operation. It implies read-only by 'returns' but could be more transparent about safety.

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 concise (a few sentences) and front-loaded with core purpose, then adds interpretation and tier limits. Every sentence adds value. Could be slightly more streamlined, but effective.

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

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

Given the complexity (time series, tier limits, interpretation hints), the description covers the essentials. It explains output format (rows per day, ascending date) and provides historical context. No output schema, but description compensates adequately.

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 no additional meaning beyond what the schema provides for either parameter. The days parameter's tier clamping is mentioned in the schema already. No improvement.

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 Mayer-Multiple time series (BTC price / 200-day SMA) as rows per day ascending by date. It distinguishes from sibling arena_get_mayer_multiple by noting that tool returns the current value. The verb 'returns' and resource 'time series' are specific.

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 contrasts this tool with arena_get_mayer_multiple, indicating when to use each. It also provides interpretive context (descriptive ratio, not a trigger, cycle top/bottom clues). However, it does not explicitly state when not to use this tool or mention alternative 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 provided, so description carries full burden. It discloses that values are as-reported and can be revised retroactively, not point-in-time. Also mentions tier caps. Does not explicitly state read-only behavior but implies it. Slight room to mention no side effects.

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?

Single paragraph that front-loads purpose, then usage guidelines, behavioral note, and tier info. Every sentence adds value; no wasted words. Well-structured 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?

No output schema, but description explains return format (date/value pairs ascending) and history depth. Covers behavioral nuance (revisions), tier limits, and sibling tool differentiation. Missing output format details, but adequate for agent to select and use 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. Description reinforces tier clamping on days and adds historical context back to 2009, but does not add entirely new meaning beyond schema. The 'context' parameter is not discussed, but schema covers it adequately.

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 full time series of an on-chain metric with date/value pairs. It distinguishes from sibling tools by explicitly comparing to arena_get_onchain_latest (single reading) and arena_list_onchain_series (discovery of valid ids).

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?

Description explicitly states when to use this tool ('trend and percentile work') and when to use alternatives ('for single current reading call arena_get_onchain_latest, to discover valid series_ids call arena_list_onchain_series'). Also includes tier-based range caps as usage 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 provided, so the description carries full burden. It discloses the output format and warns about lack of context, but does not explicitly state it is read-only or mention any side effects. However, the read-only behavior is implied and the warning about context adds 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 concise, front-loads the purpose, then provides usage guidance and warnings. Every sentence adds meaningful information without 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?

Although there is no output schema, the description specifies the output fields. It also mentions free tier and provides necessary cautions. Given the tool's simplicity and rich sibling context, the description 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 coverage is 100% with both parameters described. The description adds value by providing example series IDs and hinting that valid IDs can be found via arena_list_onchain_series. The context parameter is already well-documented 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 that the tool returns the most recent value of one on-chain series, specifies the output fields, and distinguishes from siblings by mentioning arena_list_onchain_series for discovery and arena_get_onchain_history for history. The phrase 'cheapest way' further clarifies its unique value.

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

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

Explicitly says when to use: 'cheapest way to answer what is X right now' and when not to use alone: 'pair it with the series percentile before calling any level high or low.' It names alternative tools for discovery and history, providing clear guidance on tool selection.

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?

Provides a clear list of return fields (label, definition, calculation, etc.) and mentions pricing tier. Lacks explicit idempotency and auth requirements, but given no annotations, the description covers key behavioral aspects.

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?

Three concise sentences: first states purpose, second lists outputs, third gives usage hint and pricing. Every sentence earns its place, front-loaded with key information.

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

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

Given no output schema, the description adequately lists return fields and covers main behavior. Could mention read-only nature, but overall complete for a simple lookup 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?

Adds value beyond the 100% schema coverage by explaining the resolution format (onto:<term>@<version>) and providing an example for the term parameter. The context parameter is already well-documented.

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

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

The description clearly states the verb 'resolve' and the resource 'knowledge-platform term', and provides an example. It distinguishes the tool from siblings by focusing on ontology terms, unlike other arena_get_* tools that handle different data.

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: to resolve onto:<term>@<version> references inside Knowledge Objects. Does not mention alternatives or when not to use, but the context is clear and specific.

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 discloses output details: score, band label, color, deltas, verdict, components breakdown, and percentile ranking interpretation. It also notes 'Free tier', suggesting usage constraints.

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 in one paragraph, listing components and output fields. It is informative without being overly verbose, though slightly dense.

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

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

Given no output schema, the description adequately covers return values (score, bands, deltas, components, percentile). It provides enough context for an agent to understand the tool's full output.

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 'context' has 100% schema coverage explaining its purpose. The description adds no additional parameter semantics beyond what the schema provides, warranting the baseline score.

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 'Daily 0-100 heat score for the Bitcoin market' aggregated from 8 named components, distinguishing it from numerous sibling tools like arena_get_fear_greed or arena_get_cycle.

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

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

No explicit guidance on when to use this versus alternatives like arena_get_btc_market_structure or arena_get_sentiment. The description implies usage for market heat assessment but does not contrast with 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?

No annotations are provided, so the description carries full burden. It fully discloses the output structure (time series rows), ordering (ascending date), and tier constraints (Free 30d, Pro 365d, Power unlimited). No destructive or authorization concerns are needed for this read-only 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?

Three concise sentences: first defines the tool's output, second gives usage guidance and alternative, third states tier limits. No redundancy, front-loaded with key information.

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

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

No output schema exists, but the description fully specifies the output format (rows with date, score, band, ascending order). It covers purpose, usage, alternative, and constraints. Complete for a historical data retrieval tool.

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

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

Schema coverage is 100% with detailed parameter descriptions. The tool description adds 'auto-clamped by tier' for the 'days' parameter, but since schema already explains the parameters, the added value is minimal. Baseline 3 is appropriate.

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

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

The description clearly states 'Returns the Arena-Pulse TIME SERIES' with specific output details (one row per day, date, score, band, ascending order). It distinguishes from the sibling tool arena_get_pulse by noting it provides historical data versus a single snapshot.

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

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

Explicit usage guidance: 'Use it for trend, turning points and how did we get here; for today's value alone call arena_get_pulse (cheaper, one row).' Also clearly states tier-based range limits, providing both when to use and 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. It discloses the lifecycle stages, return fields (progress_pct, counts, pdf_url/xlsx_url), and the '[API Pro tier]' prerequisite. This adds substantial behavioral context beyond the schema, though rate limits, idempotency, and error states are not mentioned.

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?

Three sentences that are front-loaded with the primary action ('Poll the status'), followed by lifecycle and return details. Every sentence adds value without redundancies. The structure is efficient and easy 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?

The description covers the essential outputs (progress_pct, counts, URLs) and lifecycle, which is sufficient for a polling tool. However, it omits expected polling intervals, error handling guidance, and whether the tool is read-only. Given no output schema, it provides a decent picture but could be more 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 baseline is 3. The description does not add new parameter-level details beyond what the schema provides. The job_id parameter is already explained as 'Job UUID returned by checkout', and the context parameter has an extensive description in the schema. The description's lifecycle arc adds peripheral context but not parameter 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 verb 'Poll' and the resource 'Custom-Report job status'. It lists the lifecycle states (pending_payment → queued → running → generating → success/failed), which distinguishes it from other status tools by specificity. Given the sibling tools (e.g., arena_get_job_status, arena_get_signal_status), this description makes the tool's unique purpose evident.

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 job checkout via the lifecycle mention, but it does not explicitly state when to use this tool versus alternatives like arena_get_job_status. No 'when not to use' or explicit guidance for handling errors or timeouts. The context is clear but lacks comparative 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 provided, so description carries full burden. Discloses read-only, look-ahead free nature, honest small-n handling, and what the tool does not do (never a recommendation). 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?

Description is slightly long but every sentence adds value. Front-loaded with purpose, then details return structure and edge cases. Could be trimmed slightly but still efficient.

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 no output schema, description fully explains return values (distribution, verdict, DSR threshold) and covers edge cases (insufficient neighbors, optional user_sharpe). Explains both axes comprehensively.

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%; description adds meaning beyond schema by explaining how params define neighborhood, context parameter's purpose, axes meanings, provides examples, and clarifies that user_sharpe is optional for DSR.

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 assesses one backtest result against its neighborhood, returning distribution statistics, a verdict, and a Deflated Sharpe threshold. It distinguishes from siblings by focusing on robustness across assets vs single CAGR cells.

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

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

Explicitly says when to use (to avoid trusting a single CAGR cell) and when not (fewer than 15 neighbors yields 'insufficient'). Distinguishes between cross_asset and parameter axes, noting parameter view is 'always anecdotal'. Includes 'never a recommendation'.

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 honestly discloses that counts include bulk/admin runs, making it a coverage-weighted attention signal rather than a clean crowd signal. This level of self-critique is rare and highly 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 a bold warning, then lists return fields and a honesty note, then alternatives. It is longer than necessary but every sentence adds value. Could be tightened slightly, but well-structured overall.

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 thoroughly explains all return fields and their interpretations. The two parameters are adequately covered, and the tool's limitations are clearly stated. It is complete for the given complexity.

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

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

Schema coverage is 100% with both parameters described. The description mentions the period aggregation windows but does not add substantial meaning beyond the schema. The context parameter is well explained in the schema itself. Therefore, baseline 3 is appropriate.

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

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

The description immediately corrects the misleading name with a bold header, clearly stating it reports platform backtesting activity, not market sentiment. It lists specific data returned (hotAssets, hotStrategies, etc.), making the purpose unmistakable and distinct 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 warns against misrepresenting the data as trader sentiment and provides a list of alternative tools for actual market sentiment (arena_get_fear_greed, arena_get_funding_rate, etc.). It also notes the free tier limitation, giving clear when-to-use and when-not-to-use guidance.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It transparently states that no ownership or Pro tier is required, and that the return shape matches arena_get_backtest. However, it does not mention rate limits, authentication needs, or potential side effects, but for a simple fetch operation, this is nearly complete.

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 extremely concise, consisting of two sentences and a tag. Every sentence serves a purpose: the first defines the action and resource, the second provides usage guidance and references a sibling. No redundant information, perfectly 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 tools' complexity and the lack of an output schema, the description provides a good overview by referencing the return shape of a sibling tool. It covers the distinguishing aspects (public shares, no Pro tier). However, it could be slightly more explicit about the exact fields returned, but the reference to arena_get_backtest compensates.

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 description does not add significant meaning beyond the input schema, which already has 100% coverage. The share_id parameter is explained in both places, but the description mentions the URL pattern, which adds marginal context. The context parameter's description is solely in the schema, so no extra 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 clearly states the verb 'fetches' and the resource 'a backtest that someone published via a share link'. It distinguishes from the sibling arena_get_backtest by specifying that this tool is for shared backtests, not the user's own runs. The URL pattern is also mentioned, making the purpose crystal clear.

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: when a user pastes a /shared/backtests URL. It also provides an exclusion: use arena_get_backtest for the user's own runs. Additionally, it notes the free tier availability, which helps in 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 transparency burden. It discloses that data is "Backed by the daily check-signals cron" (indicating daily caching) and that the tool requires "at least one user with an active Ampel" to return meaningful results. It also labels the endpoint as "[Free tier]", adding cost context. These go beyond the name, though failure modes (e.g., empty result) are not specified.

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-loaded with the core purpose. Each clause adds useful context: status colors, strategy/pair/interval scope, data frequency, prerequisite, and pricing tier. 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?

Despite lacking an output schema, the description conveys the essential return value (green/yellow/red) and necessary preconditions. It also notes the daily cron backing, which helps set expectations about data freshness. For a simple read tool with well-documented parameters, this is adequate; only a detailed response shape is absent.

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

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

Schema description coverage is 100%, with all four required parameters documented (e.g., interval enums with explanation of alignment effects). The tool description adds no additional parameter semantics beyond what the schema provides, placing it at 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 states a specific verb and resource: "Current signal-status (green/yellow/red) for a strategy on a pair+interval." This clearly distinguishes it from sibling tools like arena_get_bullmarket_ampel, which targets market-level signals rather than strategy-specific ones. The scope 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?

Usage context is implied through the prerequisite "needs at least one user with an active Ampel on this combination," which suggests when data will be available. However, it does not explicitly state when to use this tool versus alternatives like arena_get_pulse or arena_get_bullmarket_ampel, nor does it name any exclusions. Guidance is present but implicit.

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

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

No annotations provided. Description discloses data source (Binance), data fields, and free tier. Missing details on potential latency, error states, or authentication needs, but covers core 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-structured with front-loaded purpose, use case, and free tier note. Slightly verbose but every sentence adds value. Could be trimmed by merging the usage note.

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?

Completes the picture for a simple price tool: states what is returned, source, and usage intent. No output schema, but description adequately sets expectations for return content.

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

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

Schema coverage is 100% with one parameter (context) fully documented. The description adds no additional semantics for the parameter beyond that, so baseline 3 applies.

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

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

The description clearly states the verb 'get' and resource 'spot price', specifying assets (BTC, ETH, SOL) and data fields (last price, 24h change %, high, low). It distinguishes from siblings by focusing on live price anchoring for analytics.

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 to use for anchoring analytics instead of web search, and notes it's context-only not a recommendation. Lacks explicit exclusion of other siblings but gives actionable 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 provided, the description carries the full burden. It discloses that the tool is descriptive (non-signal), sources data from DefiLlama peggedUSD, and implies read-only behavior. It does not mention any destructive or mutation actions, which is consistent with its purpose. The 'Free tier' tag adds transparency about access.

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, dense sentence that front-loads the purpose and includes all essential information. It is concise with no wasted words, though splitting into two sentences could improve readability slightly. Every clause serves a 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?

Despite lacking an output schema, the description adequately explains what the tool returns: current supply, 30d/90d change (USD and %), acceleration, and a compact time series. This is sufficient for an agent to understand the output's nature and structure.

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% (the only parameter 'context' is fully described in the schema). Per the rubric, baseline is 3. The tool description adds no additional parameter details beyond what the schema provides, so no extra value is given.

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 aggregates stablecoin supply as a crypto-liquidity proxy and distinguishes it from sibling macro_regime by offering more detailed trend data including current supply, 30d/90d change, acceleration, and a time series. The verb 'aggregates' and specific resource 'stablecoin supply' make the purpose 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 compares with arena_get_macro_regime, noting that this tool provides more than a single delta. It also states 'Descriptive only, not a signal,' guiding agents away from using it for trading signals. While it doesn't enumerate all alternatives, it gives clear context for when this tool 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?

With no annotations, the description carries full burden. It discloses the derived metrics and the interpretive context of the in_loss flag, but does not mention update frequency, data source, or any potential limitations. Adequate but not comprehensive.

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 concise and front-loaded, conveying the main metric, derived values, and interpretive note in three short sentences. 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?

While the description lists the returned data elements, it lacks details on output format or structure. Since there is no output schema, the description should provide more structural context for programmatic use.

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 'context' parameter. The tool description adds no additional meaning beyond the schema's own documentation, so a baseline score 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 title and description clearly specify the tool returns the latest BTC short-term-holder cost basis, along with derived STH-MVRV and an in_loss flag. The description distinguishes it from generic on-chain tools by focusing on a specific metric with interpretation.

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?

No explicit guidance on when to use this tool versus alternatives like arena_get_onchain_latest or other on-chain metrics. The description states it is descriptive and not a signal, but lacks context for when it is most 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?

With no annotations, the description carries the burden and discloses key behaviors: time-overlap-matched baseline methodology, use of real aggregations, and an example of not_applicable_filters (altcoin_season excluded on BTC-pair). It does not detail output structure or edge cases like empty results, but it offers substantial behavioral context beyond trivial expectations.

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 dense sentences cover purpose, return structure, methodology, use-case, and pricing. Every clause provides distinct information, with no filler or redundancy. The front-loaded purpose allows quick comprehension.

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 enumerates the main return components (baseline, deltas, best pick, not-applicable list) and clarifies the non-exhaustive nature of filter variants. It lacks specifics on the number of variants or error scenarios, but for a filter-analysis tool it is largely complete and decision-ready.

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

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

Schema coverage is 100%, with detailed parameter descriptions (e.g., interval alignment effects). The description merely echoes the strategy/asset/interval scope without adding new parameter-specific semantics or usage nuances. Baseline 3 applies because the schema does the heavy lifting.

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

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

Clearly states it performs per-(strategy, asset, interval) filter-effect analysis, listing specific outputs: baseline stats, filter-variant stats with deltas, best_by_cagr pick, and not_applicable_filters. The use-case sentence ('Which filters would improve my backtest for X on Y?') further anchors its purpose and differentiates it from generic backtest 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?

Provides explicit when-to-use guidance via the phrased question, and clarifies data source ('real backtest aggregations — not theoretical 2^5 permutations'), implying a non-hypothetical scenario. However, it does not explicitly name alternative tools or state when not to use this tool, so it stops short of full exclusion guidance.

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

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

With no annotations, the description carries the transparency burden. It discloses the Free/Pro tier limitation (Top-10 vs full) and the dual-mode behavior. However, it does not mention output structure, error cases, or other limitations; the alignment caveat is present only in the schema, not the main description.

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

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

The description is three tight sentences. It front-loads the core purpose, then explains the conditional modes with clear markers, then provides the tier limitation in a compact bracket. Every sentence earns its place with no fluff.

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

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

The tool has 7 parameters and no output schema, yet the description manages to explain the two primary output types (detail with per-asset breakdown vs full matrix) and the tier constraint. It does not describe the exact matrix format or detail schema, but for a read-only insights tool, this is adequate.

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 linking `strategy` and `interval` to detail mode and implying `min_runs` only applies to matrix mode, providing a crucial interaction not fully captured in the schema. It does not add details about `asset_type` or `assets_mode`, but the schema already covers those.

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 aggregated backtest performance per strategy×interval cell, with detail mode vs matrix mode. It distinguishes the tool's scope ('Free Top-10 / Pro+ full') and the conditional output, but does not explicitly differentiate from sibling tools like arena_get_strategy_performance.

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 conditional guidance: if both `strategy` and `interval` are provided, returns detail; otherwise, returns the full matrix. This tells the agent when to use the two modes, but it does not mention when to prefer this tool over alternatives or when not to use it.

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

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

With no annotations, the description carries the full burden. It discloses the return metrics (run_count, avg_cagr, avg_win_rate, etc.), the aggregation nature, and the '[Free tier]' limitation. It does not mention data freshness or error scenarios, but for a read-only get tool, it provides meaningful behavioral detail.

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: it front-loads the purpose, lists the return fields, and then provides usage guidance and an alternative. Every sentence earns its place with no 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 rich input schema, the description covers the essential return values and usage context. It doesn't explain how to obtain valid strategy keys (though the schema points to arena_get_strategies) or discuss edge cases, but it is sufficiently complete for a get-based snapshot tool.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds a bit of context by emphasizing the 'ONE specific (strategy, asset, interval) combination' and the vs_buy_hold comparison, but the schema already fully documents each parameter.

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

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

The description clearly states it provides aggregated backtest performance for ONE specific (strategy, asset, interval) combination, making the tool's function unambiguous. It also distinguishes itself from the sibling tool by recommending arena_get_strategy_insights for multi-strategy overview.

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 tells the agent when to use this tool ('How does strategy X perform on asset Y?') and points to arena_get_strategy_insights as the alternative for multi-strategy overview, providing clear context and exclusion.

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 burden and does well by disclosing that regimes are classified at trade entry, listing output metrics, and explicitly clarifying that reward_risk_ratio is per-trade mean/stddev, not annualized Sharpe. It could add more on how the recommendation is derived or edge cases, but it is solid.

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 concise, front-loaded with the core function, and every sentence adds value: the regime split, the killer question, the metric list, and the free tier note. No fluff, 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?

Since there is no output schema, the description appropriately lists the return fields and their semantics. It falls short only in not describing the structure of the current-regime recommendation, but it is otherwise complete for an agent to invoke the tool.

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

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

Schema coverage is 100%, so the description needn't repeat parameter details. It does add the constraint that the tool handles ONE combination and mentions interval implicitly, but this is marginal. 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 the tool returns historical backtest performance for one (strategy, asset, interval) combination split by macro regime, plus a current regime recommendation. It distinguishes itself from sibling tools like arena_get_strategy_performance by emphasizing the regime split and the 'killer question' framing.

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 a clear use case: answering 'Should I trade this strategy NOW?' which implies decision-making for the current live regime. It does not explicitly name alternatives or exclusion criteria, but the context is sufficient for most cases, earning a 4 rather than 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 carries the full burden of behavioral disclosure. The description explains that universes reflect current membership and carry survivorship bias, which is a key behavioral trait. It does not explicitly state that the tool is read-only, but 'returns' implies no side effects. It could be improved by mentioning rate limits or that it is free tier, but the current detail is sufficient for safe use.

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 plus a bracketed tag, all front-loaded with the main purpose. Every sentence adds value: the first defines the tool, the second gives usage guidance, and the third adds a critical caveat. 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?

Despite lacking an output schema, the description fully explains what the tool returns (id, label, selection rule, complete list of pairs). It also covers when to use it and a crucial data caveat (survivorship bias). For a simple retrieval tool with two parameters and no output schema, this description is complete and sufficient for an AI agent to use 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 100% coverage with descriptions for both parameters (context and universe_id). The description adds context for universe_id by explaining its role in previewing before backtest, but does not provide additional syntax or format details beyond the schema. Baseline 3 is appropriate given the high schema coverage; the description adds modest 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 clearly states the tool returns a full pair universe with specific fields (id, label, selection rule, pairs). It distinguishes from sibling tools like arena_list_universes and arena_run_universe_backtest by explicitly mentioning their roles. The verb 'returns' and resource 'one pair universe' make the purpose specific and 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 explicitly states when to use the tool: before calling arena_run_universe_backtest to preview, or to resolve a universe into explicit pairs. It also directs users to arena_list_universes for the list of available universes. Additionally, it warns about survivorship bias, which is a crucial guideline for proper 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 transparency burden. It discloses data stitching pre-Binance (ATR null before Binance era), the look-ahead-free nature of expansion ranks vs. trailing 2-year rolling ranks, the structural decline caveat, free tier limits, measured payload savings from schema_version '2026-08', and the default flip date. These are behavioral traits beyond what any structured field could convey.

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 and dense, but every sentence carries relevant information. It front-loads the core definition and measurement details. The measured savings percentages across three window lengths are somewhat excessive but still purposeful. It could be more streamlined, yet it avoids fluff and is well-organized, earning a 4 rather than a lower score.

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 convey what the tool returns. It explains the series composition (RV, ATR%, ranks), data coverage (2009, ATR nulls pre-Binance, meta.coverage), field-minimal options, free tier limitations, and related tools. For a complex 8-parameter tool with no output schema, the description covers the full context 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 meaning beyond the schema: it explains the semantic distinction between rank flavors (rvRank vs. rvRankRolling) and advises when each is appropriate. It also adds practical parameter-combination guidance (from/to vs. days, combining granularity/fields for real reduction, schema_version 2026-08 savings). These enrich the parameter understanding beyond the schema's own descriptions.

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

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

The description opens with a specific verb+resource: 'Daily Bitcoin volatility time series' and enumerates exactly what is included (realized volatility 30d/90d annualized, ATR% Wilder EMA-14). It distinguishes itself from siblings by explicitly naming related tools and their scopes: arena_get_volatility_phases (current phase), arena_get_iv_snapshot (implied vs. realized), and arena_get_cycle (regime context).

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 explicit when-to-use guidance: use rvRankRolling/atrPctAnnRankRolling for cross-epoch regime comparisons, use from/to for specific windows, combine granularity/fields for affordability, and pass schema_version '2026-08' for long ranges. It also gives a when-not: 'Descriptive — no forecast, no signal.' Alternatives are listed with their distinct purposes.

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?

Discloses that cells below min_trades are suppressed rather than shown as noise, and indicates the tool is for [API Pro tier]. No annotations provided, so description carries full burden. Could add more on data freshness or limitations but current disclosure is strong.

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?

Three sentences, each meaningful: purpose, sibling differentiation, behavioral note. No wasted words. Front-loaded with the main action.

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?

Covers purpose, usage alternatives, behavioral trait, and access tier. No output schema, but given the complexity, it adequately prepares an agent. Could mention output structure (e.g., table) but not essential.

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 description adds value: explains context parameter purpose, asset_type as filter, and min_trades default (20) with trade-off tone ('buying coverage with noise'). Provides nuance 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?

Description clearly states it breaks down strategy performance by volatility phase, with specific verb 'Breaks...down by...' and resource 'realized strategy performance'. It distinguishes from three sibling tools by naming them explicitly.

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

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

Explicitly says when to use (to see if edge only exists in one volatility regime) and when not (for overall verdict use arena_get_strategy_insights, for macro-regime cut use arena_get_strategy_performance_by_regime, for raw time series use arena_get_volatility_history).

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 provided, so description carries burden. It discloses update frequency and free tier, but lacks details on rate limits, authentication, or how many pairs are tracked. Adequate but not rich.

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

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

Three sentences, front-loaded with key info, no redundant or vague language. Very efficient.

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 simple tool (3 params, no output schema), description covers purpose, update cadence, sibling relationships, and filter usage. Minor gap: could mention output fields or format explicitly.

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%, baseline 3. Description adds marginal value for 'pair' filter advice but no extra context for 'asset_type' or 'context' 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?

Description clearly states it returns 'current ATR-based volatility phase (low/normal/high/expansion) per tracked pair' with update timing. Distinguishes from sibling tools like volatility_history and volatility_recommendations.

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 provides guidance: 'single current state — for time series use arena_get_volatility_history, for strategy implications use arena_get_volatility_recommendations.' Also advises filtering with pair parameter.

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, description carries full burden. It discloses historical nature (not advice), minimum trade requirement, and API tier. Could add rate limits or data freshness but sufficient.

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 concise sentences with front-loaded purpose, constraints, and related tools. No redundant or unnecessary 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?

Adequate for a 3-parameter tool with no output schema: specifies return type (top-3 strategies with win-rate) but omits response format details. Leaves some ambiguity.

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

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

Schema covers all parameters with descriptions (100% coverage). Description adds no extra parameter meaning beyond schema, meeting baseline for this metric.

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 top-3 strategies ranked by historical win-rate for the current volatility phase, and distinguishes from related tools like arena_get_volatility_phases and arena_get_edge_reports.

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: answers a specific question, notes dependency on volatility phases, and lists related tools. Lacks explicit when-not-to-use scenarios.

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 provided; description carries full burden. It discloses public nature, anonymized format, selection bias (upward-biased edge), and free tier. Lacks response structure description but is otherwise clear about 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 sentences, front-loaded with purpose. Every sentence adds value: purpose, bias warning, alternatives, free tier. No 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 simplicity of tool, description covers purpose, return fields, bias, alternatives, and pricing. Adequate for agent to select and invoke 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 3. Description does not add extra meaning for parameters; they are well-documented 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 clearly states it is a public leaderboard of top CAGR backtest results, answering 'what has scored best'. It distinguishes from siblings like arena_list_backtests and validation 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?

Explicitly warns against using as recommendation, suggests alternatives (arena_get_robustness_field, validate_strategy) and directs to arena_list_backtests for user's own runs.

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 ordering ('newest first'), ownership scoping ('belonging to the authenticated user', 'Only your OWN runs'), pagination ('Paginated via limit + offset'), and access tier ('[API Pro tier]'). It also lists output fields. It does not mention error handling or rate limits, but covers the key behavioral traits for a read-only listing 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 three well-structured sentences: purpose/returned fields, usage path, and scope/alternatives. It also integrates pagination and API tier info without redundancy. Every sentence earns its place, and it is 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?

Given no output schema, the description compensates by enumerating returned fields (id, strategy, pair, interval, date range, headline metrics) and specifying ordering. It covers usage, ownership scope, pagination, and tier. It lacks explicit default values or error cases, but for a listing tool with fully documented parameters, it is largely 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?

Schema coverage is 100%, so the schema already documents all 7 parameters thoroughly. The description adds minimal parameter detail beyond mentioning 'limit + offset' and briefly implying filters (pair, strategy, interval). It does not exceed the schema's parameter explanations, so the baseline score 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 it 'Lists the backtest runs belonging to the authenticated user — newest first, with id, strategy, pair, interval, date range and headline metrics per run.' This is a specific verb+resource+scope statement and differentiates from siblings by noting 'Only your OWN runs; for the public cross-user leaderboard use 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?

It provides explicit guidance: 'Use it to find a run_id, then call arena_get_backtest for its detail or arena_get_backtest_trades for the individual trades.' It also distinguishes from alternatives by pointing to arena_get_winners for public leaderboard. This is strong when-to-use vs alternative direction.

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 provided; description discloses that it lists published types/subjects and includes fields like min_tier, api_path, seo_slug, latest as_of. Indicates '[Free tier]' and automatic updates, implying read-only and non-destructive 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?

Two sentences: first states purpose, second provides usage guidance and mentions free tier. Front-loaded with no superfluous content.

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

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

For a simple list tool with a single parameter, the description covers what is listed, returned fields, automatic updates, free tier, and usage ordering. 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% with a detailed description for the 'context' parameter. The tool description adds no additional semantics beyond the schema, meeting 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 the verb 'list' and resource 'knowledge objects', specifying it lists all published types and their subjects with details. It differentiates from sibling 'arena_get_knowledge' by advising to use it beforehand.

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 'Use this BEFORE arena_get_knowledge to learn valid type/subject pairs', providing clear when-to-use guidance. Mentions 'New types appear automatically' but no when-not-to-use or alternatives beyond the sibling.

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