Backtesting Arena

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

Since no annotations are provided, the description carries full burden for behavioral traits. It clearly discloses that the tool is idempotent, deactivates a subscription, frees a slot, and returns the deactivated subscription. It also notes that queued undelivered updates persist, which is a key behavioral trait beyond the basic mutation action.

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

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

The description is very concise at 3 sentences, with the main action front-loaded ('Stop this alert? Deactivates...'). Every sentence adds unique value: clarifies effect, provides idempotency info, links to related tools, and notes queue behavior. There is zero wasted 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?

Given the tool's moderate complexity (2 required params, no output schema, no nested objects), the description is nearly complete. It explains the action, return value, idempotency, queued updates behavior, and how to get IDs. It does not explicitly state whether cancellation is reversible or that the tool mutates state, but the description implies mutation (deactivates), which is 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 description coverage is 100%, so baseline is 3. The description adds value by explaining the purpose of 'subscription_id' (needed to identify the subscription, obtained from 'arena_list_subscriptions') and noting it is a UUID format returned by 'arena_subscribe_*'. It does not elaborate on 'context' but that parameter's schema already provides detailed usage instructions and examples.

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 'deactivates' and resource 'subscription by id', explaining the effect of stopping alerts and freeing a slot. It is distinguishable from siblings like 'arena_list_subscriptions' and 'arena_subscribe_*' tools, though the purpose could be more directly stated upfront alongside the initial question.

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 (deactivate a subscription by id) and how to get ids via 'arena_list_subscriptions'. It also provides an important exclusion: 'Undelivered updates already queued are not removed', and notes idempotence to avoid errors for already-cancelled ones. This fully guides the agent on usage 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?

No annotations are provided, so the description must carry the full burden. It clearly discloses that the tool has a destructive polling behavior: 'then marks them as delivered.' This tells the agent the tool is not idempotent and consuming updates will deplete the queue, which is critical behavioral transparency for a polling endpoint. It also describes the return payload structure: 'Updates contain payload with subscription_type, current value, previous value, and trigger context.' This provides actionable behavioral detail beyond just the function signature.

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, each earning its place: the first frames the user intent, the second defines the tool's core action and side effect, and the third describes the output format. No wasted words. The last sentence '[API Pro tier]' adds a concise licensing note. Front-loaded with the most critical information.

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

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

Given the tool has 1 required parameter (with 100% schema coverage), no output schema, and no annotations, the description is complete. It explains the polling semantics, the destructive read (mark as delivered), the input expectation (implicit from schema), and the return payload structure. The sibling tools include subscription-creation tools and list_subscriptions, making the polling-consumption tool's role clear. No information gaps remain for correct agent invocation.

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

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

Schema coverage is 100% with one parameter (context). The schema describes the parameter's purpose and formatting rules thoroughly. The tool description does not repeat or add to the parameter details in the description itself, but since coverage is at 100% and the parameter is a mandated analytics field with extensive documentation in the schema, the baseline is 3. The description earns a 4 because the context parameter is a special meta-parameter (communication to the system, not data input), and the description's overall context (the polling behavior) helps the agent understand why they are calling it, which indirectly supports the context 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 starts with the user-query framing 'Has anything I subscribed to fired?' then clearly states this tool 'Returns all undelivered updates for the API key, then marks them as delivered.' The verb 'returns' and resource 'undelivered updates' are specific, and the 'marks them as delivered' clarifies a side effect. This clearly distinguishes it from the sibling tools like arena_subscribe_* (which create subscriptions) and arena_list_subscriptions (which lists them).

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

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

The description explicitly tells when to use: 'Call regularly to consume the polling queue.' This serves as clear usage guidance. It does not explicitly list when NOT to use it or name specific alternatives, but the context signals indicate it's a polling consumer, and the sibling set includes subscription-related tools for setup, so a 4 is appropriate for clear but slightly implicit exclusions.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It discloses that the tool holds pair/interval/date range fixed, does NOT equalize evaluation windows, produces per-strategy metrics and a comparison summary, warns about multiple testing bias, states execution is sequential with estimated time, and lists quota limits. It also mentions the API Pro tier requirement. This is unusually thorough and leaves no ambiguous behavior unaddressed.

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: a leading question, clear purpose, usage guidance, caveats, and performance notes. Every sentence adds value. It is slightly lengthy (several sentences) but no word is wasted. The front-loading of purpose is excellent. Minor compression could be possible, but it remains 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 (9 parameters, 6 required, nested objects, no output schema), the description covers purpose, usage, behavioral caveats, performance, quota, and tier. It does not explicitly describe the output structure beyond mentioning per-strategy metrics and a comparison summary with specific fields (best by CAGR, win-rate, worst by drawdown), which is adequate. The absence of an output schema is partially compensated by this description. A slightly more explicit output schema reference would raise this to 5.

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

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

Schema coverage is 100%, so baseline is 3. The description does not add much parameter-level meaning beyond what the schema already provides; it repeats the idea of 'same pair, interval and date range' but does not elaborate on individual parameters like 'filters' or 'context' beyond what is in the schema. The caveats about evaluation window and multiple testing are global, not parameter-specific. The description meets the baseline but does not exceed 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 begins with a clear question 'Which of these strategies performed best on the same data?' and immediately states the action: 'Run 2–5 strategies against the SAME pair, interval and date range and return per-strategy metrics plus a comparison summary.' It distinguishes itself from siblings by explicitly naming alternatives: 'For one strategy across many pairs use arena_run_universe_backtest instead' and highlighting that it holds the pair/interval/date range fixed, unlike separate arena_run_backtest calls. This makes the purpose unmistakable and well-differentiated.

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

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

The description gives explicit guidance on when to use ('Use this when the user asks which of several strategies fits a market') and when not to use ('For one strategy across many pairs use arena_run_universe_backtest instead'). It also includes important caveats about the evaluation window not being equalized, multiple testing bias, and suggests a complementary tool (arena_get_robustness_field). Performance expectations (sequential, 10–50s) and per-day quota limits are provided. This is exemplary usage 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. 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?

With no annotations provided, the description carries the full burden. It discloses that the tool does NOT make a recommendation, is not a price forecast, and explains the tradeoff (lower timing variance, not higher expected value). It warns about small-n and notes asset-specific limitations (BTC-only support clusters). It could mention authentication or rate limits, but the behavioral traits are well-covered.

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

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

The description is relatively long but every sentence adds value. It is front-loaded with a clear question, then expands into numbered output points. The structure is logical and easy to follow. Minor redundancy (e.g., 'structural framing is MCP-only') is justified by context.

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 (7 parameter tool with no output schema), the description covers input requirements, output structure, constraints, and alternatives. It lacks explicit mention of error cases or tier access requirements (though '[API Pro tier]' hints at it), but overall provides sufficient context for the agent to 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 description coverage is 100%, so baseline is 3. The description adds meaning beyond the schema for key parameters: for 'asset' it explains structural mark differences, for 'preset' it notes ETH/SOL limitations, and for 'invalidation' it provides guidance on what constitutes a valid input. This extra context justifies a score above baseline.

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

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

The description clearly states the tool's purpose: framing a dip/accumulation thesis without a recommendation, returning a tranche ladder, historical base rate, and tradeoff. It uses specific verbs ('returns', 'composes') and explicitly distinguishes itself from related tools (calendar-DCA, price forecast, and the interactive tool at the 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 gives explicit when-to-use guidance ('Where would I add on a dip?'), mandates the invalidation parameter, and contrasts with the EV/Kelly interactive tool. It also notes that this is MCP-only and combines historical-analog + key-levels tools, helping the agent choose between alternatives.

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

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

With no annotations, the description must carry the full burden. It mentions the methodology ('v7 Native-Filter methodology') and that it is a 'Daily' indicator, hinting at update frequency. The '[Free tier]' suggests access limitations. However, it does not disclose whether the call is read-only, what happens on failure, or any performance implications. The behavioral transparency is 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?

The description is extremely concise: three sentences with no redundancy. It front-loads the key question, states the methodology, enumerates outputs, and notes the tier. Every sentence adds value, and the structure is clear. 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 tool with one parameter and no output schema, the description covers the main return fields but lacks structural details (e.g., how the 'Top-50 CoinGecko snapshot' is structured). It does not explain how to interpret the 'overall color' or what to do with the data. Given the many sibling tools, missing decision-making context limits completeness. Adequate but not comprehensive.

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, which is already thoroughly described in the schema. The tool description adds no additional semantics about the parameter (e.g., how to format the reason or link to the tool's purpose). Baseline is 3 since the schema handles parameter meaning fully.

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

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

The description clearly states the tool's purpose: to determine if it is altcoin season using a daily indicator. It lists the specific return values (BTC-Dominance, Alt-Dominance, etc.) and the overall color. The title includes 'Get Altcoin Season Snapshot', which aligns with the description. However, it does not explicitly differentiate from the sibling tool 'arena_get_altcoin_season_history', which would provide historical data, missing a chance to clarify scope.

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

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

The description provides no guidance on when to use this tool versus the many sibling tools (e.g., arena_get_altcoin_season_history, arena_get_btc_market_structure, etc.). It does not state prerequisites, context, or alternatives. The agent must infer usage purely from the tool name, which is insufficient for confident 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?

With no annotations provided, the description must carry the full burden. It discloses the range is capped by tier (Free 30d / Pro 365d / Power unlimited), which is a key behavioral constraint. It does not mention rate limits, whether the tool is read-only (implied by 'series' but not explicit), or the data volume returned.

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

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

The description is compact, front-loading the key question and output summary in the first two sentences, followed by usage directive and tier information. Every sentence adds value 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 2 parameters, 100% schema coverage, no output schema, and the complexity of the tool (time series data), the description adequately explains the columns, ordering, and tier limits. It could optionally list all columns but the core is covered. Missing output schema may require agents to infer structure, but the description's column list mitigates this.

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 'days' parameter is briefly mentioned in the description as 'auto-clamped by tier', which adds context beyond the schema but does not significantly expand meaning. The 'context' parameter is fully documented in the schema. No additional param nuances are added by the 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 the 'Altcoin-Season TIME SERIES' with specific columns and ordering, distinguishing it from the sibling tool 'arena_get_altcoin_season' which provides 'today's state alone'. The verb 'returns' combined with the resource description makes the purpose highly 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 explicitly tells when to use this tool: 'to see whether capital has been rotating into or out of alts over time', and contrasts it with the sibling tool for today's state. However, it does not mention when NOT to use it or any prerequisites.

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 transparency burden. It states the tool returns data and lists the returned fields, but does not explicitly note whether it is read-only (implied by 'get') or any side effects, rate limits, or authorization details beyond the ownership note. While not misleading, it misses an opportunity to declare non-destructive behavior explicitly.

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 paragraph that flows naturally from a hook to specifics, then usage guidance, then sibling references. It is front-loaded with the core purpose. Every sentence earns its place, though it could be slightly tighter (e.g., abbreviating the metrics list). Still, it is well-structured and not verbose.

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 2 required parameters, no output schema, and no nested objects, the description adequately covers what the tool does and what it returns (listing key metrics). It does not need to explain the return structure further as the description enumerates the fields. A perfect score would require explicit mention of output format or pagination, but for this tool it is 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?

Both parameters (id, context) are fully described in the schema (100% coverage). The description adds marginal value by noting that ids come from arena_list_backtests and that the context parameter is for analytics tracking, but these details do not significantly enhance understanding beyond the schema's existing descriptions. 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 opens with 'What exactly did that backtest do?' and immediately states 'Returns the full record of ONE backtest run by id', specifying the exact resource and verb. It lists what the record includes (strategy, pair, interval, etc.) and differentiates from siblings by directing users to arena_list_backtests for IDs, arena_get_backtest_trades for trades, and arena_run_backtest for creating new runs.

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 clearly tells when to use this tool ('to get full record of one backtest run') and when not to: for individual trades use arena_get_backtest_trades, to create a new run use arena_run_backtest. It also specifies an access restriction ('Only your own runs (admins may read others)'), providing explicit guidance on proper invocation.

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

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

No annotations are provided, so the description bears full responsibility for behavioral disclosure. It clearly states that only closed round-trips are included ('a position still open at the end of the period is not counted'), mentions the API tier requirement ('[API Pro tier]'), and specifies output structure (entry/exit date, price, P&L, running equity). Does not disclose if there is pagination, rate limits, or whether historical backtest results persist. Minor gap given no annotations.

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

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

Three sentences, each earning its place: first sentence states return value, second provides use cases and prerequisites, third adds important limitation. The '[API Pro tier]' tag is tacked on without context and could be integrated. Overall efficient but not perfectly streamlined.

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 what the tool returns (entry/exit dates, prices, P&L, equity curve). Given it is a data-retrieval tool with only 2 params, the description is fairly complete. The missing pagination detail is a minor gap. Sibling tool arena_get_backtest is explicitly mentioned, aiding 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 description coverage is 100%, so baseline is 3. The description does not add further meaning to the 'id' parameter beyond what the schema states (UUID of the backtest run). The 'context' parameter is well-documented in the schema with usage examples and instructions. The description correctly implies the data is aggregated per round-trip but does not elaborate on parameter constraints (e.g., valid ID format or content). Adequate but not exceptional.

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?

A strong verb+resource structure: 'Returns the individual round-trips of one of your backtest runs' followed by explicit data fields (entry/exit date, price, P&L, equity curve). Clearly distinguishes itself from arena_get_backtest by stating 'for the aggregates alone use arena_get_backtest', and additionally differentiates from arena_list_backtests by requiring a run_id.

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

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

Explicit when-to-use guidance: 'Use it when the aggregate metrics are not enough — to see whether a result rests on a handful of outlier trades, how long positions were held, or where the drawdown came from.' Provides a clear prerequisite: 'Needs a run_id from arena_list_backtests.' Names the alternative tool for aggregates. Also warns about closed round-trips only.

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

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

No annotations are provided, so the description must carry the full behavioral disclosure burden. It discloses that asset_correlations include tokenized on-venue proxies (paxg, spyb, qqqb) with tracking noise, that windows not covered are null with a data_start_date explaining why, and that window labels are upper bounds. This is a rich behavioral disclosure for a data tool. It lacks description of auth requirements or rate limits, but for a free tier tool this is acceptable. Score 4 because it goes beyond minimal disclosure without covering every possible behavioral aspect.

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

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

The description is compact given the volume of information (roughly 4 sentences, ~130 words). It front-loads with the core question and quickly enumerates components and data structures. Minor overhead: 'proxies carry tracking noise...' could be slightly tightened, but overall every sentence serves a purpose. Not a 5 because there is some parenthetical overload.

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

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

Given one parameter with full schema coverage and no output schema, the description effectively conveys what the tool returns (quadrant_performance, component_correlations, asset_correlations with caveats, current_quadrant). It explains data quality (windows fill over time, tracking noise, window labels vs actual basis). This is sufficiently complete for a data retrieval tool without output schema. A higher score would require specifying return format or pagination.

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 context parameter is fully documented in the schema). The description does not add meaning to the context parameter beyond what the schema provides, which is already detailed (explain why, word count, perspective, no sensitive info). With perfect coverage, baseline is 3, but the description adds value by explaining what data the tool returns (quadrant_performance, component_correlations, asset_correlations, current_quadrant), which helps the agent craft a meaningful context string. This pushes it to 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 starts with a strong verb phrase 'Get BTC × Macro Correlations' and immediately clarifies the resource ('pre-aggregated weekly correlations between Bitcoin and 13 macro components'). It lists specific components (Fed Net Liquidity, VIX, DXY, etc.) and distinguishes the tool from its many sibling tools that target different metrics (e.g., arena_get_spot_price, arena_get_macro_regime). The purpose is precise 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 the tool's function ('What does Bitcoin actually move with?') and context ('weekly correlations'). It does not explicitly state when to avoid this tool or name alternatives, but the sibling list contains many similarly named tools, and the description's specificity about macro correlations implicitly guides an agent to use it when the user asks about BTC-macro relationships rather than, say, market structure or spot price. A clear exclusion of alternatives would push this to 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?

Given no annotations, the description carries the full burden and excels by detailing data source ('1000-bar Phantomflow adaptation'), constraints (only BTCUSDT 1d), return fields (trend, timestamps, wave/fractal counts), and caveats (fresh flip reliability, base rate not forecast). It also notes 'Educational analysis of price action' and 'Free tier', providing complete behavioral context.

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

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

The description is front-loaded with the key question ('Is the trend up or down...') and delivers substantial value in about 75 words. While thorough, it could be slightly more concise by tightening the base rate explanation, but its structured output enumeration is clear.

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 one parameter, the description fully explains what the tool returns (trend, flip details, fractal counts, context) and its limitations (not a forecast). This is complete for a single-parameter, attribution-level tool with clear educational intent.

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 only parameter 'context' is fully described in the schema with detailed instructions, and the tool description adds no extra parameter info, which is acceptable since schema coverage is complete.

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

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

The description uses specific verbs and nouns ('Returns current_trend...', 'Educational analysis of price action.'), clearly defining this as a Bitcoin market structure indicator tool that distinguishes itself from siblings like arena_get_altcoin_season or arena_get_onchain_latest by being exclusively focused on BTCUSDT daily market structure and providing outputs like trend direction, flip timing, and fractal counts.

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 the tool's scope ('Daily Bitcoin market structure', '1d timeframe'), explains what it does and does not do (e.g., base rates are NOT forecasts), and separates it from other arena tools listed as siblings (e.g., arena_get_sentiment or arena_get_volatility_insights). However, it lacks explicit guidance on when not to use this tool or alternatives.

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

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

With no annotations, the description must carry the behavioral burden, and it does: it discloses output fields, the semantics of `since` when null, the 30-day history window, the meaning of higher counts, and the weekly 20W/50W-MA evaluation. It lacks auth/precision caveats, but this is sufficient for a read-only snapshot.

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

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

The description is dense but organized: it front-loads the core use case, lists return components, explains meaning, and ends with a useful free-tier note. Every clause adds value, though the paragraph is a bit packed.

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 explains return values and edge cases (null `since` before 400-day lookup, 30-day history). Combined with the well-documented context parameter, this is complete enough for an agent to call and interpret 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?

The only parameter, context, is fully documented in the input schema (100% coverage), so the description adds no additional parameter semantics. Baseline 3 applies because the schema already covers parameter meaning and requirements.

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 identifies a specific resource (Bitcoin Bullmarket-Ampel) and states exactly what it produces: current state 0-5 active stages, active_count, stages[] breakdown, and stage_history. This clearly differentiates it from sibling tools like get_btc_market_structure or subscribe_bullmarket_stage.

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

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

The opening question 'Is this still a bull market?' implies the tool answers bull-market status queries, but there is no explicit when-to-use versus alternatives or exclusion guidance. Usage context is only implied, not stated.

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

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

With no annotations, the description carries the full burden and does so thoroughly. It discloses the cointime-weighting caveat, that active + vaulted can exceed circulating supply, that `total_counted` is not a supply number, that all values come from one snapshot, and that the tool is descriptive with no price-direction statement. This is exemplary behavioral disclosure.

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

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

The description is long but every sentence earns its place: purpose, key output, caveats, source, and related tool. It front-loads the core question and answer, then layers in warnings and context. No filler 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?

Despite having no output schema and no annotations, the description provides enough context for an agent to understand what the tool returns, what the fields mean, and what pitfalls exist. It also names the data source and related tool, making the operational context complete.

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

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

The schema has only one parameter (`context`) with 100% description coverage, so the schema already fully explains the parameter. The tool description does not add parameter-specific semantics, but none are needed given the schema's completeness. 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 identifies the tool's function: comparing three BTC cost-basis measures against spot and flagging sign conflicts. It names the specific measures (Realized Price, True Market Mean, Vaulted Price) and the key output (`sign_conflict`), making it distinguishable from related tools like the full cost-basis ladder.

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 explains when this tool is valuable: when the market's profit/loss state depends on which cost basis is used, and when sign conflicts are invisible from realized price alone. It also points to the related `arena_get_knowledge(type="onchain_cost_basis_ladder")` for the full ladder, giving an explicit alternative. It stops short of saying precisely when not to use this tool, but the guidance is clear.

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

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

With no annotations, the description fully discloses behavior: point-in-time scoring, indicator exclusions and weight renormalization, the fixed score-band signal enum (cautioning against misinterpreting mid-band labels), the ath block, highlights and price_context with drift, and the not_applicable handling for ETH/SOL. This is thorough and goes beyond the schema.

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

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

The description is long and dense, but every sentence adds critical context. It is well-structured, front-loaded with the primary purpose, and uses clear separations for asset specifics and related tools. While not concise in length, it avoids redundancy and effectively organizes complex 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 tool's complexity and lack of output schema or annotations, the description is remarkably complete. It covers what is returned, how signals are computed, interpretation cautions, data provenance, and pointer to related tools. No critical gaps for effective tool selection and 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%, so baseline is 3. The description adds meaningful value beyond the schema: it details that weights are renormalized for ETH/SOL, lists which indicators are excluded as not_applicable, and explains the context parameter indirectly (by example in the schema). This enriches the parameter meaning, warranting a 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 the tool's purpose: providing a crypto cycle snapshot with aggregated indicators. It distinguishes itself from siblings by explicitly mentioning related tools like arena_get_volatility_history and arena_get_historical_analog, and clarifies that it carries regime context but not the volatility series.

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 includes explicit when-to-use guidance, e.g., 'Note for volatility questions: this tool carries the regime context around a volatility reading but not the volatility series itself — that is arena_get_volatility_history.' It also lists related tools and explains asset-specific usage (BTC default, ETH/SOL per-coin read).

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

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

With no annotations, the description carries the full burden and does so excellently. It reveals look-ahead-free construction, reconstructed versus walk-forward data, revised versus unrevised inputs, and the warm-up period where z_adj_score actually contains raw scores.

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

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

The description is long but every major sentence adds an essential nuance for correct usage. It is front-loaded with the core behavior then layers in caveats and sibling routing. The warm-up explanation has a small amount of redundant phrasing, keeping it from a perfect conciseness 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?

With no output schema present, the description compensates well by naming the row frequency, output fields, ordering, and critical data-construction caveats. It also covers the tier limit and sibling alternatives. The description is complete enough for an agent to invoke the tool safely and interpret its response.

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

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

Schema description coverage is 100%, and both parameters (days and context) are already documented in the schema. The description adds a tier limit statement, but mostly repeats the auto-clamping semantics already present in the input schema, so no significant new parameter meaning is provided.

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 outcome: returns the BTC-Cycle time series with one row per day, sorted ascending, and names the output fields. It also explicitly differentiates from arena_get_cycle and arena_get_historical_analog, making the tool's 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?

Explicit routing guidance is present: call arena_get_cycle for a current snapshot, arena_get_historical_analog for analogous historical readings, and this tool for the historical series. The tier-based range limit is also given, so an agent can determine when this tool fits.

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

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

No annotations are provided, so the description must carry the full burden of behavioral disclosure. The description states it returns specific statistics (mean, max, outlier counts) and uses a daily drift log, but it doesn't disclose the return format (e.g., structure of the data), whether it's read-only (likely, but not explicit), or any authentication/rate-limit notes. The '[API Pro tier]' hint adds useful context about access requirements. With no annotations, a 3 is appropriate—adequate but leaving notable gaps.

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—three short sentences. It opens with a clear question, immediately states the core function, lists key output metrics, and context. Every sentence adds unique value: the question sets the scene, the jargon notes the data sources, the metrics describe output, and the usage frequency ties to business context. 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?

Given the tool has only 2 parameters with 100% schema coverage and no output schema, the description is reasonably complete. It explains the purpose, the specific metrics, and the usage context. However, without an output schema, some information about the return structure would be helpful, and the description doesn't mention pagination or data volume, but for this narrow domain tool, the completeness is good.

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 documents both parameters (days, context). The description adds value by implying the 'days' parameter controls the window size (aligned with the schema), and the 'context' parameter's purpose is fully explained in the schema. However, the description does not specifically elaborate on parameter meaning beyond what the schema provides, but the baseline of 3 is elevated to 4 because the schema already covers the meanings well and the description's focus on the tool's purpose provides indirect clarity.

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 two data sources (bgeometrics legacy vs BRK canonical-soon) for daily drift, with specific metrics (mean, max, outlier counts) and window. It distinguishes itself from siblings by specifying the exact data-quality/ drift focus, which is unique among the listed sibling tools (none of which mention drift or data-quality 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 provides explicit context for when to use this tool: 'BRK-migration review (every 4 weeks)' and the question 'Do the two data sources still agree?' implies this is for checking data consistency before migration. However, it doesn't explicitly say when NOT to use it or name direct alternatives among siblings, though the unique drift focus makes alternatives less relevant.

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 discloses significant behavioral traits beyond annotations: it explains how delta_cagr is computed differently from raw differences, the use of paired-bootstrap intervals for verdicts, and the gating logic with null fields. It also mentions grouping, pagination, and that filters are evaluated in isolation. No annotations are provided, so the description carries the burden, and it does so comprehensively.

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

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

The description is information-dense and uses technical jargon appropriately for the domain, but it is quite long and runs-on in a single paragraph. While every sentence adds value, a more structured layout (e.g., bullet points for verdicts, gating, pagination) would improve readability. It is not overly verbose given the complexity, but it could be better organized.

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

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

Given the tool's complexity (6 parameters, no output schema, no annotations), the description is remarkably complete. It covers the response structure (grouped by strategy, envelope fields, null handling), the verdict calculus, gating conditions, and pagination. The absence of an output schema makes this description essential, and it leaves no major gaps for an agent to understand the tool's 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 the schema already documents all parameters, but the description adds depth to the 'verdict' parameter by explaining the difference between insufficient_evidence and insufficient_data, which is not fully clear in the schema enums. It also clarifies the meaning of 'strategy' with an example and notes the default behavior for limit/offset. This adds value beyond the schema.

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

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

The description clearly states it analyzes entry filters' effect on CAGR across strategies, and despite the different name, it is distinct from arena_get_filter_insights by focusing on edge detection with paired-bootstrap verdicts. The verb 'Get' and resource 'Edge Reports' are specific, and the detailed content distinguishes it 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 explains when to use this tool (to see which filters carry a real edge) and implies when not (e.g., for individual filter insights use arena_get_filter_insights, though not explicitly stated). It provides explicit guidance on pagination and filtering (limit/offset, verdict, strategy), which is helpful for usage. It lacks explicit exclusions for alternatives, but 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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It describes the output fields (30d/90d net flow, direction label, cumulative time series, impulse with four states) and explains the behavior of `acceleration_usd_m` and `accelerating` fields, including the 'reversal' case. It also notes the data source and free tier. This is comprehensive and exceeds typical 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?

The description is fairly long but every sentence serves a purpose: explaining the tool's value over a summary, describing the output fields, warning about confusing fields, and specifying defaults. The structure is front-loaded with the main purpose. It could be slightly more concise, but the density of useful information justifies the length.

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

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

There is no output schema, so the description must explain return values. It does so by describing the cumulative time series, direction label, `impulse` field, and the behavior of `acceleration_usd_m` and `accelerating`. It also mentions the source and free tier. For a tool with 3 parameters, this is quite complete, though it could optionally specify the format of the time series (e.g., daily data points).

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% (all three parameters have descriptions). The description adds only minimal value: it repeats the default asset behavior and explains the `impulse` field, but does not add new meaning to any parameter beyond what the schema already provides. The baseline of 3 is appropriate given full schema coverage.

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

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

The description uses a specific verb ('Get') and clearly identifies the resource ('Spot-ETF Net-Flow Trend'). It explicitly distinguishes itself from a summary that only gives point-in-time deltas, stating it exposes the trend with 30d/90d net flow, direction label, and cumulative time series. Among the many sibling tools, none target ETF flows, so it is well-differentiated.

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

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

The description provides clear usage context: it explains the default asset (BTC), how to pass alternative assets (ETH, SOL), and warns about confusion between `acceleration_usd_m` and `accelerating` fields, recommending `impulse` as the field to quote. It also mentions the data source (SoSoValue) and free tier. However, it does not explicitly state when to use this tool versus 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 of behavioral disclosure. It thoroughly explains the returned fields (value, classification, history, range, cadence, tempo), notes tier differences (blocks null on Free), and explains the significance of the range block ('a short series here is a window, not a young index'). It also warns the index is not a timing signal, covering potential misuse. This is exemplary transparency.

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

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

The description is lengthy but every sentence earns its place: it front-loads the core function, then adds critical nuances (contrarian nature, range block, tier effects), and ends with pointer to alternatives. It could be trimmed slightly, but the density of useful information justifies the length. 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 complexity (multiple output components, tier restrictions, relationship with other tools) and the absence of an output schema, the description is remarkably complete. It explains all return components, their meaning, tier differences, and even the rationale for the history cap. It leaves no major aspect unexplained.

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

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

Schema descriptions already cover both parameters at 100% coverage, so the baseline is 3. The description adds value by explaining the `days` parameter's effect via the `range` block (granted/available days and reasoning) and by clarifying that the full history is deliberately not offered. However, it doesn't elaborate on the `context` parameter beyond the schema's detailed description, so it doesn't reach a 5.

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

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

The description explicitly states the tool returns the Crypto Fear & Greed Index with value, classification, and history, and clearly distinguishes it from siblings like arena_get_cycle and arena_get_historical_analog by naming them as alternatives for different purposes. The verb 'get' combined with the resource and scope makes 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?

Provides explicit when-to-use guidance: describes the index as a contrarian-read sentiment gauge (not a timing signal) and points to specific alternative tools for regime context and historical analogies. It also clarifies the meaning of short history windows, preventing misinterpretation. This is above and beyond typical usage notes.

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 fully carry behavioral disclosure. While it mentions the scope of analysis (filters, metrics, per strategy combo), it does not state if the tool is read-only, idempotent, expensive to call, or requires specific authorization beyond the noted '[API Pro tier]'. There is no mention of side effects, data freshness, or result size. The description is functional but leaves key behavioral traits unspecified.

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 exceptionally concise: two sentences that front-load the core question and then specify the exact filters, metrics, and comparison. No filler words, no redundancy. Every sentence adds unique value. This is a model of efficient tool documentation.

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 should hint at return format or how to interpret results, but it doesn't. It also lacks prerequisites (e.g., requires strategies to exist) or guidance on using the output alongside sibling tools. However, the core functionality is fully explained for a simple analysis tool. The lack of usage guidance and behavioral details reduces completeness, but the description is not insufficient for its narrow scope.

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 (the single 'context' parameter is fully described with clear instructions). The tool description adds no additional semantic value for the parameter beyond what the schema already provides. Baseline is 3 because schema coverage is high, and the description does not 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 the tool's purpose: it analyzes whether entry filters help and which ones, specifically performing lift analysis on listed filters (200WMA, Altcoin-Season, ATR-Volatility, Bullmarket-Stage) per strategy combo, comparing baseline vs filtered CAGR/win-rate/drawdown. The verb 'get' plus 'filter insights' combined with the detailed specification makes the purpose unambiguous and distinct from siblings like arena_get_strategy_filter_effect or arena_get_strategy_insights.

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 provide any guidance on when to use this tool versus alternatives. With over 70 sibling tools, including closely related ones like arena_get_strategy_filter_effect and arena_get_strategy_performance, the lack of explicit context (e.g., 'Use this when you want to compare filter benefits across multiple strategies, not just a single filter effect') makes it difficult for an AI agent to select appropriately. No when-not-to-use or alternative references are given.

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

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

Since no annotations were provided, the description fully bears the burden of behavioral disclosure. It explicitly states the tool is on a free tier, implies it retrieves live data by mentioning the 'latest' rate, and details the internal logic (averaging across up to three exchanges). This provides significant transparency into the tool's behavior.

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

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

The description is extremely concise at about 75 words. It front-loads the core question and purpose, provides immediate interpretability guidance, and delivers a critical behavioral caveat in the last sentence. Every sentence serves a distinct purpose 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 the tool's simplicity (1 parameter, no output schema, no nested objects), the description is nearly complete. It explains the tool's purpose, output semantics (value, MA, Z-score), and key caveats. The only minor gap is the lack of explicit mention of the return values' format (e.g., 'returns a JSON object with fields...'), but the text description compensates for this effectively.

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

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

Schema description coverage is 100%, so the baseline is 3. The description does not add any new meaning to the single `context` parameter, as the schema already explains what it is for. The description adds no parameter-specific value beyond what the schema provides.

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

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

The description starts with a specific question ('Are longs or shorts paying right now?') and clearly states the tool returns the latest BTC perpetual funding rate averaged across up to three exchanges, with a defined settlement cadence. This differentiates it from its siblings, such as `arena_get_funding_rate_history` which would return historical 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?

The description implicitly guides usage by explaining how to interpret the output (positive/negative values, the meaning of the `coverage` field). It also provides a clear caveat about comparing values across dates due to changing exchange composition. However, it does not explicitly state when NOT to use this tool and suggests no specific alternative for historical data.

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 comprehensively discloses behavior: aggregation across venues, segmentation by venue composition, 8h cadence, ascending order, interpretation of funding rate signs, and cautions about computing statistics across segments.

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 thorough at ~150 words, covering all necessary points without redundancy. A slightly tighter structure could improve readability, but it is well-organized and front-loaded with the core purpose.

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

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

With no output schema, the description fully explains the response structure (segments, composition_breaks, stable flag, rows) and provides interpretation guidance. It anticipates user needs and addresses edge cases like venue changes.

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 context about tier clamping for 'days' and detailed instructions for 'context', enhancing parameter understanding 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 clearly states that this tool returns a BTC perpetual funding-rate time series, aggregated across venues, and distinguishes it from the sibling tool 'arena_get_funding_rate' which provides only the latest 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?

The description opens with a question that frames when to use the tool ('How has leverage positioning shifted over time?'), explicitly directs users to an alternative for latest values, and notes 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?

No annotations are provided, so the description carries full burden. It discloses return contents and includes an important disclaimer ('not a price forecast or a buy signal'). However, it omits any mention of the required 'context' parameter, which has specific formatting and intent-tracking requirements described only in the schema. The agent may not know to provide a meaningful context string, a notable behavioral gap.

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

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

The description is extremely concise—two sentences front-loading purpose, with semicolons structuring the output details. Every sentence earns its place: purpose, outputs, usage guidance, disclaimer, and tier hint. 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 moderate complexity, no output schema, and 100% schema coverage, the description covers return types, usage context, and a disclaimer. However, it fails to explain the required 'context' parameter and its specific formatting rules, leaving a significant gap for the agent to use the tool correctly. The sibling references help, but the missing parameter disclosure reduces completeness.

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. The description adds no additional meaning beyond schema for 'coingecko_id' (simply names it) and does not mention 'context' at all. With full schema coverage, baseline is 3, and the description fails to add value over 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 the Altcoin-Screener score for ONE coin by CoinGecko ID, listing specific outputs (composite score, group breakdown, Pro+ raw factor values). It distinguishes itself from sibling tools arena_get_gem_scores (plural/ranking) and arena_get_gem_validation (out-of-sample), making the scope 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 'Use it once a candidate is known' and provides two clear alternatives: use arena_get_gem_scores for ranking/filtering the universe and arena_get_gem_validation for out-of-sample behavior. Also notes '[Free tier]' indicating availability, which further guides when to use.

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

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

With no annotations, 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 provided, the description carries the full behavioral burden and exceeds expectations. It explains the snapshot/precomputation behavior ('curves are precomputed weekly'), the internal rung ladder with values, the snapping semantics, and even the response field names (`top_n` for actual, `top_n_requested` echoing request, `basis_note` declaring snaps). It also flags the free tier limitation, which is critical behavioral context the agent needs to set 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 sentences, front-loaded with a concrete question, then the key mechanics. The em-dash construction is a bit dense for parsing (long sentence with nested dashes), but every clause earns its place—the rung values, snapping behavior, and field names are all necessary. Minor deduction for the dash-heavy middle section being a wall of text, though it packs maximum information 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?

For a simple 2-param tool with no output schema, the description fully specifies input semantics (optional top_n with rung snapping), the computation model (precomputed weekly), and the return fields. The snapshot/ladder disclosure is the kind of deterministic behavior an agent needs to correctly reason about results. The lack of an output schema raises the burden slightly, but the description covers what matters: what gets validated, how it's computed, and how responses differ from requests. The only minor gap is no explicit mention of the response shape, but the naming convention (`top_n`/`top_n_requested`) is self-documenting.

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 only `top_n` (optional, default 10, range 1-200) and `context` (required). The description adds essential parameter semantics by explaining the rung snapping behavior: `top_n: 100` would actually produce a run with top_n=100 but a request of 75 would snap to the nearest rung. The description explains that `top_n` in the response may differ from the request, showing the lifecycle of the parameter. The `context` parameter itself has extensive inline documentation. Slight deduction because the description doesn't explicitly re-document each parameter, but it doesn't need to given the schema's completeness.

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 this tool validates whether screener picks beat BTC using a bi-weekly equal-weight basket backtest, with specific metrics (CAGR, max drawdown, win-rate). It distinguishes itself from the 80+ sibling tools by starting with a concrete question and specifying the basket/backtest approach, making it immediately distinguishable from similar backtest and strategy tools.

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

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

The description explicitly explains the backtest methodology (bi-weekly, equal-weight), reveals that curves are precomputed weekly with an N ladder of specific rungs (10/25/50/100/200), and discloses the snapping behavior when a requested N doesn't match a rung. It also clearly states the free tier limitation. This tells the agent when to use this vs. the many other backtest tools (run_backtest, list_backtests, go_backtest, run_universe_backtest).

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 carries behavioral transparency. It discloses that prices and days-to-peak are computed from their own series, not hand-copied, addresses the 547-549 day convention by specifying cycle 4, clarifies the date convention per entry (e.g., 2024-04-20 vs 2024-04-19), and marks the current cycle's peak as provisional. It also explicitly states no next-halving estimate is published. This is exceptional transparency.

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

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

The description is dense and informative but slightly verbose. It front-loads the core payload, then adds provenance, date convention, and related tools. Every sentence adds value, but some could be tightened (e.g., the E33 note and parenthetical examples). Still, it's structured logically and packs a lot into a short space.

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 annotations or output schema, the description goes far beyond minimum: it explains data source, computation method, date convention discrepancies, provisional status, excluded content (no next-halving date), and related tools. For a simple list tool with one metadata param, this is exceptionally complete.

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

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

The only parameter is `context`, which the schema fully describes with requirements and an example (100% coverage). The description adds nothing about the parameter itself, but that's acceptable given the schema is thorough. Baseline 3 for high schema coverage.

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

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

The description clearly states the tool returns Bitcoin halving data: date, block height, reward change, price at halving, and cycle peak with days to peak. It distinguishes itself from related tools like arena_get_cycle by naming them and explaining what this tool adds (chain-event-to-price linkage). The verb 'get' and resource 'halvings' are 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?

It explicitly notes that no next-halving date is published)Skip that exclusion, and mentions related tools (arena_get_cycle) for additional context. However, it does not explicitly state when to choose this tool over others, though the unique features (linking prices to halvings, computed values) imply the use case. Slight deduction for lack of explicit when-to-use guidance.

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

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

No annotations are provided, so the description carries full burden. It discloses the tool returns two moving averages and signals recovery while noting it is a free tier tool (implying potential rate limits or reduced data). It does not mention if data is cached, how often it updates, or if any authentication is needed, but the core behavioral impact is clear.

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

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

Description is three sentences, front-loaded with the key question ('Are miners capitulating?'), then naming indicator and what it returns, then the bullish signal. Every sentence adds essential context with zero 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 moderate complexity (two moving averages, a signal interpretation) and no output schema, the description adequately explains what the tool returns and how to interpret it. It could mention the return format (e.g., JSON numbers for each MA) or data recency, but is sufficient for an agent to 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 the baseline is 3. The description adds value by explaining the indicator's meaning and output beyond the schema's single 'context' parameter. The parameter is meta-contextual (explaining why tool is called), and the description gives guidelines for filling it, which is helpful but schema already provides detailed instructions.

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 the tool retrieves the Hash Ribbons indicator, specifying it returns 30d and 60d hashrate moving averages. It distinguishes itself from 90+ sibling tools by naming a unique, specific indicator tied to a creator (Charles Edwards), making its 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?

Description provides clear context for when to use (when assessing miner capitulation/recovery) and implicit signal interpretation (30d > 60d after capitulation is bullish). It does not explicitly list alternatives or when not to use, but among many 'get_' tools, the unique indicator name suffices for selection guidance.

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

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

With no annotations, the description carries the full safety/behavior burden and exceeds it: discloses point-in-time integrity, look-ahead-free matching, small-n warnings, the evidence block, study_finding NULL cases, the non-obvious vs_unconditional_drift adjustment, and parameter behaviors that alter findings (vol_rank_threshold, condition_on_direction).

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

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

The description is long but front-loaded with the purpose and structured into purpose, caveats, preset details, and related tools. Some sentences are wordy (e.g., 'A distribution with its sample size') and the em-dash-heavy style adds noise, yet most sentences earn their place given the tool's complexity.

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

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

For a tool with no output schema and 7 parameters, the description compensates thoroughly: it explains response components, key caveats, defaults changes, cross-asset behavior, and related tools, leaving minimal gaps for an agent to select 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?

Despite 100% schema coverage, the description adds semantic depth: explains the preset meanings, the effect of vol_rank_threshold on the studied definition, the interaction of condition_on_direction with direction_window_days (horizon suppression), and asset-specific presets limitations.

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 clarifying question then states the exact function: computing conditional forward-return distributions for named preset cycle states, with specific output components (median/IQR, horizons, sample sizes). It names all preset values and explicitly distinguishes from related tools by stating it cannot be reproduced via web search or public APIs.

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: warns to read preset_definition/current_state_matches before applying, to prioritize study_finding and vs_unconditional_drift over raw medians, and specifies asset/preset compatibility. Names related tools (arena_get_volatility_history, arena_get_cycle, arena_dip_scenario) with their roles.

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

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

With no annotations provided, the description fully carries the transparency burden. It explains in detail what each indicator returns (e.g., ATR as percentage of price, OBV as normalized slope), how percentile ranks are computed, when percentiles are null with a reason, the inclusion of study verdicts, and the meaning of labels like 'state'. This is exhaustive and leaves no 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 very long and dense, covering many details. While every sentence is informative, it could be more concise by grouping related concepts or using bullet points. The structure is front-loaded with the core purpose, but the sheer length may overwhelm an agent looking for a quick summary.

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 (five indicators, percentiles, study verdicts, null conditions, weekly RSI, labels), the description covers most aspects comprehensively. It mentions payload contents like study verdicts and weekly RSI, but does not provide a full JSON structure outline. Nonetheless, it is complete enough for an agent to understand the tool's behavior and outputs.

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 each parameter. The description adds value by reinforcing the use of `interval` ('Set `interval` to '1w' for the weekly view') and clarifying the `pair` parameter with an example (BTCUSDT). It also explains the null percentile conditions tied to `interval` and bar count, which goes beyond the schema.

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

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

The description opens with a clear question 'What do the classic indicators read right now?' and immediately lists the specific indicators (RSI, MACD, Bollinger, ATR, OBV) with percentile ranks. It distinguishes the tool from siblings by naming related tools like arena_get_trend_channels, arena_get_historical_analog, and arena_get_volatility_history, making 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 provides explicit guidance on when to use the tool (for classic indicators with percentile ranks), how to use the `interval` parameter, and explains edge cases (null percentiles below bar thresholds). It also lists related tools for alternative but similar needs. However, it does not explicitly state when NOT to use this tool, which would push it to a 5.

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

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

The description thoroughly details the output: the trailing vol risk premium, the optional forward premium via include_implied, the caveat about the most recent 30 days, and the warning that it is not a trading signal. This goes well beyond a simple return type and discloses important behavioral nuances.

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

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

The description is excessively verbose and repetitive. It repeats the explanation of the trailing and forward premiums multiple times, includes statistical trivia about correlation, and uses redundant phrasing (e.g., 'The forward field is spelled out...' repeated). The structure is clear but wordy, making it inefficient.

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 all essential aspects of the tool's output: metrics, optional flag, caveats, source, and history. It is comprehensive, but the redundancy and extraneous statistics do not add completeness. It lacks explicit mention of the context parameter in the description, though the schema covers it, so it remains mostly complete.

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

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

The schema provides descriptions for all three parameters: currency (enum BTC/ETH), include_implied (optional boolean with clear effect), and context (explaining its purpose as user intent). The tool description adds detail on the metrics but does not further elaborate on parameters. Since schema coverage is 100% and descriptions are adequate, this scores above 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 identifies the tool as 'Latest Deribit volatility snapshot for BTC or ETH' and lists the specific metrics returned (DVOL, ATM implied vol, realized vol, and vol risk premium). The verb 'Get' and resource 'Deribit IV Snapshot' are explicit and distinguish it from related tools like volatility history or insights.

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 explains what the tool returns and the meaning of the metrics, but it does not explicitly contrast it with sibling tools or state when to prefer this over alternatives. Usage is implied rather than explicitly stated, so it lacks clear 'when to use vs. not 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?

The description mentions polling behavior and return fields, but no annotations exist. It discloses the [Free tier] limitation, which is helpful. However, it does not describe rate limits, whether multiple calls are allowed, or what happens on job failure (e.g., retry vs. error). Without annotations, this is moderately transparent but has gaps.

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

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

The description is two sentences plus a note about free tier. It is front-loaded with the key question and clearly structured. The context parameter rule is verbose but necessary for the strict format. Could be slightly tighter but is 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 no output schema, the description does explain return fields (status, progress_pct, pairs_completed, result). This is good, but it lacks details on output structure for completed result (summary + per-pair). The complexity is moderate, and with 2 well-described params, the description is adequate but could be more complete for a polling tool expecting a result object.

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 tool description complements this by clarifying job_id is from a specific sibling tool, and context has a detailed usage rule. This adds meaningful value beyond the raw schema, earning a 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 the tool polls an async job by job_id, links it to a specific sibling (arena_run_universe_backtest), and enumerates return fields. This is specific and distinguishes it from the many sibling tools, most of which are get_* for 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?

The description explicitly ties usage to the result of arena_run_universe_backtest, implying this is for polling that specific job. However, it does not mention when not to use it (e.g., if the job might be handled synchronously or if another status tool is redundant) or 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 full burden. It explicitly states the tool is read-only (reproducible structural levels), describes key behavioral traits (nearest-first ordering, separate classes, what each level type means), and clarifies these are price clusters not defended levels. This is thorough disclosure for a data retrieval 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 long but well-structured with clear sections for each class, bullet-like formatting, and important usage notes. Every sentence adds value, but the description could be slightly tighter without losing the useful detail about the difference between pivot and indicator levels.

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 a single non-functional context parameter, the description does an excellent job explaining the tool's output and semantics. It defines both classes of levels, how they're calculated, and how they differ. A complete example of a typical response would improve it further, but overall it's very helpful.

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% but the context parameter's description is about analytics tracking, not tool functionality. The tool description itself provides rich detail about what the agent should expect from the key levels output, compensating for the context parameter being non-functional. The description adds meaning beyond the schema by explaining the output structure.

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

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

The description clearly states the tool retrieves Bitcoin key levels including resistance/support pivot clusters and indicator levels, specifying that it covers both sides of spot and two distinct provenance classes. This distinctly differentiates it from siblings like arena_get_btc_market_structure or arena_get_indicator_snapshot by explicitly naming exactly what it provides.

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 explains what the tool outputs and clearly separates the two classes of levels (pivots vs indicator levels) with their distinct meanings. While it doesn't explicitly say when NOT to use it or name alternatives, the free tier note and precise scope give sufficient guidance for an AI agent to decide when to use this tool.

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

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

Since no annotations are provided, the description carries the full burden of behavioral disclosure. It clearly states the tool is read-only (fetch) and describes the return envelope components (payload, explanation, provenance, ontology binding, compute version). It also explains the optional graph attachment behavior. It mentions versioning and explainability. No side effects or destructive actions are implied. The free tier and per-object access gate are disclosed. It does not mention what happens when no object matches (empty result) or any rate limits, but overall provides good transparency for a get 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?

The description is about four sentences long, each carrying clear information. It front-loads the purpose with a question and immediately gives a concrete example. It uses parenthetical lists to detail return fields and graph options. The note about free tier is appended without clutter. It is efficient and well-structured, though the opening question could be slightly more direct. Still, earns a 4 for good craftsmanship.

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 compensates by explicitly listing the return envelope components and explaining the graph extension. The 5 parameters (3 required) are covered by schema descriptions, and the description adds context for type/subject with an example. It addresses the graph traversal edge case. It does not cover behavior for missing objects or the exact response format details (but output schema is absent, so less burden). The sibling tool set includes many get_* tools, and the description's 'ONE tool covers ALL knowledge types' helps disambiguate. Adequate completeness for the tool's 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 description coverage is 100%, so baseline is 3. The description adds minimal parameter-level detail: it provides an example for 'type' and 'subject' (market_regime, GLOBAL) and explains the effect of 'include_graph'. It does not elaborate on 'as_of' (date pattern), 'context' (required analytics parameter with specific formatting rules from schema), or 'subject' beyond 'subject ref'. The added value is moderate but not sufficient to raise the score above 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 starts with a clear question and then uses the verb 'Fetch' to indicate action on a 'versioned, explainable Knowledge Object'. It specifies the resource type and arguments (type + subject) with a concrete example. It explicitly states 'ONE tool covers ALL knowledge types', which differentiates this from more specific sibling tools like arena_get_macro_regime or arena_get_ontology_term, and from arena_list_knowledge (list vs get).

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 frames the use case ('What does the platform know about this subject?') and explicitly states this is the single tool for all knowledge types, guiding the agent away from using other specific endpoints. It mentions the optional graph traversal feature. However, it does not explicitly state when NOT to use this tool (e.g., when a list operation is needed) or name alternatives like arena_get_ontology_term. The note about free tier and min_tier gating provides some 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?

With no annotations, the description carries the full burden. It explains the output structure in detail, including caveats about vix_score and broad_dollar_index, and deprecated fields. It also mentions stale_components_detail for freshness. However, it does not disclose operational aspects like rate limits, caching, or whether the data is real-time or delayed. The 'Free tier' hint is vague.

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

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

The description is front-loaded with the purpose and then details the components and return fields. It is fairly long but every sentence adds value, especially the caveats. It could be slightly more concise by omitting the full component listing, but it remains structured 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 absence of an output schema, the description compensates exceptionally well by detailing the return structure, scores, labels, and caveats. It explains the meaning of vix_score and broad_dollar_index. The only missing piece is the handling of the context parameter, but the schema covers that. Overall, it is very complete for agent invocation.

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

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

The only parameter (context) is fully described in the schema with 100% coverage. The tool description does not add any additional meaning or context about how this parameter should be used in relation to the macro regime. 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 the tool produces a daily macro regime snapshot from 18 components across 6 tiers with specific weights. It distinguishes itself from sibling tools like arena_get_btc_macro_correlations by its composite nature. The verb 'get' and resource 'macro regime snapshot' 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 does not provide explicit guidance on when to use this tool versus alternatives. It mentions 'Daily' and 'Free tier' but no comparative statements. The agent must infer usage from the description of what it returns, which is insufficient for optimal selection among many similar 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?

Despite no annotations, the description comprehensively discloses behavioral traits: warm-up discipline (null fields before full window), data source specifics (platform's pre-Binance closes for BTCUSDT), range capping by tier, granularity coarsening with explicit note, and explanation of output types (ratios and ranks, not absolute levels). This fully compensates for the missing annotations.

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

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

The description is thorough and well-structured with clear sections, but it is quite long. While every sentence adds value, it could be slightly more concise by condensing some of the warm-up discipline details into a shorter note. It is not verbose, but not maximally terse.

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 key completeness aspects: data history, null handling, granularity, cap behavior, and related tools. It does not explicitly describe the output format (e.g., JSON structure) since there is no output schema, but the text mentions the returned fields (distance_pct, percentile ranks, rank_n, coverage block) which compensates. A 4 acknowledges the thoroughness without being fully exhaustive.

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 meaning of the output per parameter (e.g., percentile ranks expanding vs rolling) and clarifying that 'from' is clamped to the tier window. It also names the six MAs explicitly, which is already in the schema's enum, so a 4 is appropriate for the supplementary context.

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 measured time series of how far above or below its moving averages a price stood, covering six specific MAs (50/100/200-day and 50/100/200-week). It explicitly distinguishes this from similar sibling tools like arena_get_cycle and arena_get_key_levels by specifying what metrics it provides (distance_pct plus percentile ranks) and that it is measured (not estimated).

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

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

The description provides clear context on when to use this tool versus siblings: it names arena_get_key_levels for today's absolute MA levels and arena_get_cycle for the cycle-scored 200-week distance. However, it does not explicitly state when NOT to use this tool or list other alternatives beyond those two, so a slight deduction.

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 thoroughly discloses behavioral details: clamping of days_to_expiry, signed hours_to_settlement, OI availability, settlement time specifics, field naming conventions, and data source (Deribit Public API). This provides deep transparency.

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

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

The description is extremely long and dense, packing many edge cases and caveats in a single paragraph. While the first sentence effectively summarizes the tool's outputs, the lack of structure (e.g., bullet points) and excessive detail reduce conciseness.

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 compensates by detailing all returned fields, their meanings, edge cases, and derivation logic. It covers data freshness, naming conventions, and potential pitfalls, making the tool's behavior well-understood for correct invocation.

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

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

Schema coverage is 100%, so the description adds marginal value over the schema itself for parameters. The tool has only two parameters, both well-documented in the schema. The description provides no additional parameter-level details beyond what the schema already offers.

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 gets Deribit BTC max pain data for the last expiry and upcoming expiries, listing the fields returned. It distinguishes from sibling tools like arena_get_max_pain_history and arena_get_iv_snapshot by mentioning them as related, establishing its specific role.

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 or when not to use it. While it mentions related tools, it lacks direct guidance on selection criteria, leaving the agent to infer usage from 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?

No annotations are provided, so the description carries the full burden. It discloses key behaviors: the base_rates block is mandatory for interpretation, open_snapshots are not backfillable and have thin depth, days are auto-capped by tier, and max-pain levels are proprietary aggregations (chain not redistributed). It also mentions the data source (Deribit). It doesn't explicitly state that this is a read-only operation, but the context implies it. Slight gap: no mention of rate limits or auth requirements, but the description is quite transparent for a data retrieval tool.

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

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

The description is dense but well-structured: it opens with the core question, then explains the output structure, provides critical interpretation guidance, and ends with related tools and tier info. It's longer than ideal but every sentence adds value. The front-loading is good (the convergence question is stated first). Minor deduction for length and some redundancy (e.g., 'read it before quoting any pinning narrative' is a bit verbose).

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 (7 params, no output schema, no annotations), the description is remarkably complete. It explains the output structure (each row fields), the base_rates block's role, the open_snapshots series limitations, tier caps, and data source. It also provides usage warnings (pooled median hides tiny dailies, monthly group can be n=3 with outlier). The only missing piece is explicit return format details, but since there's no output schema, the description covers the key fields. This is a well-rounded description for a complex analytical 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 schema already documents all 7 parameters. The description adds value by explaining the purpose of filters (e.g., expiry_type filters both expiries and open_snapshots, base_rates computed before filter; min_contracts drops unknown contracts; snapshot_expiry_date only meaningful with include_open_snapshots=true). It also explains the open_snapshots series start date and coverage check. This goes beyond the schema's basic descriptions, though it doesn't detail every parameter's syntax (e.g., date format is 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 the tool's purpose: it retrieves settled Deribit BTC options expiries with computed max-pain levels to measure whether spot price converges to the max-pain strike. It specifies the resource (Deribit BTC options expiries) and the analytical question (does spot drift toward max-pain). It also distinguishes from siblings by naming related tools (arena_get_max_pain for current/upcoming, arena_get_iv_snapshot) and highlighting the historical/backtest nature.

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 guidance on when to use this tool: for measuring convergence of spot to max-pain over settled expiries, and warns against misinterpreting pooled data (read base_rates before quoting pinning narrative). It also gives filtering advice (use expiry_type/min_contracts/snapshot_expiry_date instead of post-processing) and notes the open_snapshots series limitations. It names alternatives (arena_get_max_pain for current/upcoming) and specifies tier-based day caps.

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

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

No annotations are provided, so the description carries the burden. It discloses the deprecated field shape and the historical nature of bands, but does not detail output structure beyond field names, nor any access or rate limits beyond [Free tier] tag.

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 covering all key aspects efficiently, but could be slightly more structured (e.g., separating output fields from usage notes). It 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?

Given the tool's simplicity (one parameter, no output schema), the description fully covers the metric's formula, field names, provenance, band interpretation, deprecation note, and alternatives, making it complete for an 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% for the single context parameter, which is self-explanatory. The description adds no parameter-specific semantics, but the schema already documents the requirement; 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 it returns the Mayer Multiple, a specific BTC metric, with explicit fields and distinguishes it from the history tool and the cycle tool among many arena_get_* siblings.

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

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

It explicitly says 'One ratio, not a regime call' and directs users to arena_get_cycle for multi-indicator reads and arena_get_mayer_multiple_history for the series, providing clear when-to-use guidance.

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

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

Since no annotations are provided, the description carries the full burden. It explains that the ratio is descriptive ('not a trigger'), shows how to interpret values (around 1 = price at SMA, high near tops, low near bottoms), and notes the return format (time series, ascending by date). It does not mention rate limits or destructive side effects, but for a read-only historical query this is acceptable.

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 very concise: a rhetorical question, a clear action statement, interpretation context, a sibling reference, and a tier note. No unnecessary words. Each sentence serves a purpose. It is well front-loaded and easy to scan.

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

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

Given that there is no output schema, the description adequately explains the return value (time series, daily rows, ascending, ratio interpretation). It also covers the tool's purpose, alternative, and constraints. For a simple historical data endpoint, this is 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 description coverage is 100%, so the baseline is 3. The description does not add new semantic information about the two parameters beyond what the schema provides. It implicitly reinforces the 'days' parameter by mentioning tier limits, but the schema already states 'auto-clamped by tier'. The description adds no additional meaning for parameter usage.

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 divided by its 200-day SMA) with daily granularity. It uses a specific verb ('Returns'), identifies the resource (BTC, historical Mayer-Multiple), and distinguishes itself from the sibling 'arena_get_mayer_multiple' which returns only the current 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?

The description explicitly tells the agent when to use this tool vs the alternative: 'For the current value alone call arena_get_mayer_multiple.' It also mentions the tier-based range cap, which guides usage based on subscription level. It could be slightly stronger by explicitly stating when not to use it, but the guidance is clear and actionable.

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

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

With no annotations provided, the description fully discloses behavioral traits: values are as-reported and subject to retroactive revision (not point-in-time), the range is capped by tier with a 'range' block in the response that indicates clamping, and the tier limits are specified (Free 30d / Pro 365d / Power unlimited). This gives the agent a clear understanding of 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 well-structured, starting with a question, then stating the return format, usage guidance, data caveats, and range behavior. While it is somewhat lengthy, every sentence adds value. Could be slightly more concise (e.g., 'time series' is mentioned twice), but overall it is efficient and front-loaded.

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

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

Given the absence of an output schema, the description adequately explains the response format (date/value pairs, range block with clamping details) and the historical depth (back to 2009 for most series). All three parameters are covered, and the tool's purpose, usage, and behavioral traits are fully described, making it complete for both selection and invocation.

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

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

Schema coverage is 100%, so baseline is 3. The description adds value beyond the schema by providing context for the 'context' parameter (15-25 words, third person, no sensitive info) and explicitly noting that 'days' is clamped by tier. It also gives an example for 'series_id' ('mvrv'). This enriches the parameter understanding beyond the schema definitions.

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

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

The description starts with a clear question ('How has this on-chain metric moved over time?') and explicitly states it returns the full time series of one on-chain metric with date/value pairs in ascending order. It also distinguishes itself from sibling tools by naming arena_get_onchain_latest for single current readings and arena_list_onchain_series for discovering valid series_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?

Provides explicit guidance: 'Use it for trend and percentile work; for the single current reading call arena_get_onchain_latest, and to discover valid series_ids call arena_list_onchain_series.' Also explains the range clamping behavior and tier limits, helping the agent decide when to use this tool versus alternatives.

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

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

With no annotations, the description carries full burden. It discloses the operation is a read (returns latest value), mentions cost efficiency ('cheapest way'), specifies output format ({series_id, metric_name, date, value}), and warns about lack of context. It does not cover error handling or rate limits, but for a simple read tool this is sufficient. Score 4 because it's transparent 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?

The description is a compact paragraph front-loaded with a user-oriented question. Every sentence serves a distinct purpose: stating the function, listing output, noting cost, cross-referencing siblings, and providing usage caution. 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?

The tool is simple with 2 parameters, no output schema, and no nested objects. The description covers the return format, cross-references related tools, and provides a critical usage hint (pair with percentile). It does not describe error behavior or edge cases, but given the tool's simplicity, the information is largely sufficient. Score 4.

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

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

Schema coverage is 100%, so the schema already documents both parameters. The description adds value by giving examples of series_id values (MVRV, SOPR, etc.) and reinforcing the context parameter's purpose. However, it does not significantly extend beyond the schema's descriptions. 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 the most recent value of a single on-chain series, with specific verb ('Returns the most recent value') and resource ('one on-chain series'). It distinguishes from siblings by explicitly mentioning arena_list_onchain_series for discovery and arena_get_onchain_history for history, making the unique 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 provides explicit guidance: it's the 'cheapest way' to answer 'what is X right now', directs users to list_onchain_series for valid IDs, and to get_onchain_history for historical data. It also warns against misinterpreting a single reading by recommending pairing with a percentile. This is comprehensive usage 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?

The description explicitly mentions '[Free tier]', indicating cost implications. No annotations are provided, so the description fully covers behavioral traits. It discloses return format and the resolve-on-reference use case, but could add details about version handling.

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

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

The description is mostly efficient, but the 'context' parameter description is excessively long and includes formatting instructions that may not be necessary, reducing conciseness. The core description is front-loaded with purpose and typical use.

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

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

Given the three parameters and no output schema, the description adequately covers what the tool returns (label, definition, calculation, etc.) and when to use it (resolving references). It does not explain version behavior in depth, but the schema hints via optional parameter.

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 parameters. The description adds the example 'regime' for the term parameter and notes the 'context' parameter's role for analytics and user intent tracking, which adds value beyond the schema. However, the 'context' description is verbose and prescriptive, which may detract.

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 resolves a knowledge-platform term to its canonical definition, specifying the return fields and citing an example. This distinguishes it from sibling tools which retrieve data or perform actions on different entities.

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 suggests using this to resolve 'onto:<term>@<version>' references inside Knowledge Objects, which provides context on when to invoke. However, it does not explicitly state when not to use this tool versus alternatives like arena_list_knowledge or arena_get_knowledge.

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

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

No annotations are provided, so the description must carry the full burden. It discloses that counts include admin/bulk runs (coverage-weighted, not clean crowd signal), explains period-dependent vs. fixed-window fields, and notes that it replaces a deprecated tool. This is rich behavioral context, though it doesn't describe exact output format or pagination, which is acceptable since no output schema exists.

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

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

The description is moderately long but densely informative, front-loading the purpose and then detailing fields and caveats efficiently. Every sentence adds value, though the length could be slightly trimmed without losing meaning. The structure is logical: purpose, aggregates, fixed-window fields, honesty note, alternative tools, deprecation note, tier label.

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 moderate complexity (2 parameters, no nested objects, no output schema), the description comprehensively covers the data returned, the period behavior, important caveats about data sources, alternative tools, and deprecation status. It is fully sufficient for an agent to decide when and why to invoke this tool.

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

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

Schema description coverage is 100%, so baseline is 3. The description adds context about the period parameter ('7d default, 30d or 90d') and explains how it affects the data, but does not add new parameter-level details beyond what the schema provides for the context parameter. The description's value is in explaining the data semantics, not the parameters themselves.

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 shows what is being backtested on the platform, distinguishing it from market sentiment. It lists the specific aggregates (hotAssets, hotStrategies, etc.) and explicitly differentiates from sentiment tools like arena_get_fear_greed. The verb 'get' and resource 'platform activity' are specific 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?

Explicitly states when to use this tool (platform activity) vs. alternatives (arena_get_fear_greed, arena_get_funding_rate, etc. for market sentiment). Also includes a 'honesty note' about not presenting as crowd signal, and notes the deprecated alias and its removal date, providing clear usage boundaries.

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 for behavioral disclosure. It clearly states the tool is read-only (no mutation implied), returns a 0-100 score with various derived fields (band, color, 7d/30d delta, verdict, components, percentile), and mentions a '[Free tier]' constraint. This provides sufficient behavioral context for an agent to understand outcomes and restrictions.

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 one paragraph of ~70 words, efficiently conveying purpose, composition, return fields, and a usage note (free tier). It is front-loaded with the core value proposition. A minor deduction for the long parenthetical list of components which could be summarized, but overall it earns its space.

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

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

Given the tool has no output schema, the description compensates well by detailing return fields (score, band label, color, 7d/30d delta, verdict, components breakdown, score_percentile). It also explains the percentile in plain language. The only gap is no mention of caching or update frequency (e.g., how often the 'daily' score refreshes), but for a relatively simple 1-param tool with no outputs schema, it is nearly complete.

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

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

The only parameter is 'context' with 100% schema description coverage, which explains its purpose (analytics, intent tracking) and provides formatting rules (15-25 words, third-person, no sensitive data). The description adds value by explaining the tool's output structure and the score_percentile field semantics, helping agents understand what the tool returns without needing explicit param details.

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 'Daily 0-100 heat score for the Bitcoin market', uses a specific verb ('get'), names the resource ('Arena Pulse'), and explicitly differentiates from siblings like arena_get_pulse_history or other indicator tools by explaining it's an aggregate of 8 components. The title 'Get Arena Pulse Today' reinforces 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 this is for getting the current pulse of the Bitcoin market. However, it lacks explicit guidance on when to use this versus siblings like arena_get_fear_greed (one component) or arena_get_pulse_history (history). No exclusion criteria or alternatives are mentioned, though the aggregated nature is somewhat differentiating.

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 clearly discloses the mutation behavior ('Returns ... in ascending date order'), the range cap by subscription tier, and the cost/row comparison to the sibling tool. The only missing context is whether it's read-only (implied but not explicit) and if there are any performance considerations.

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

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

The description is two sentences plus a bracketed note—zero waste. The key purpose is front-loaded, followed by usage guidance and constraints. Every sentence earns its place.

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

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

With two simple parameters and no nested objects, the description is nearly complete. It covers purpose, usage guidance, and tier constraints. The only gap is lack of information about error handling or edge cases (e.g., what happens if days exceeds the tier limit), but for a list tool this is minor.

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. The description adds context for the 'days' parameter by tying it to tier limits, but does not add new meaning beyond what the schema provides. 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 states a specific verb ('Returns'), a clear resource ('Arena-Pulse TIME SERIES'), and specifies the output format ('one row per day with date, 0–100 score and band, in ascending date order'). It also distinguishes this historical tool from the sibling 'arena_get_pulse' which returns a single row for today's 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?

The description explicitly tells when to use this tool ('trend, turning points and "how did we get here"') and when not to ('for today's value alone call arena_get_pulse (cheaper, one row)'). It also notes the range cap by tier, providing concrete constraints.

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

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

No annotations are provided, but the description compensates by detailing the lifecycle states, returned fields (progress_pct, succeeded/failed counts, pdf_url/xlsx_url), and an '[API Pro tier]' note, which implies tier restrictions. It lacks disclosure of rate limits or potential side effects, but for a polling tool the behavior is well-covered.

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

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

The description is concise at three sentences, each serving a clear purpose: TL;DR question, lifecycle overview, and return values plus tier note. It is front-loaded and compact, though the lifecycle list could be slightly more streamlined.

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 2 parameters, 100% schema coverage, and no output schema, the description covers the core purpose, lifecycle, and return fields adequately. It lacks details on error handling or edge cases (e.g., what happens on failure), but is sufficiently complete for a polling tool with a well-documented lifecycle.

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 adds meaning by referencing 'job_id' as from checkout and the 'context' parameter for analytics (including word count and format rules). However, it does not elaborate on parameter types or constraints beyond the schema, so it meets but does not exceed the baseline.

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

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

The description clearly states the tool's purpose: 'Poll the status of a Custom-Report job.' It includes the verb 'Poll' and the resource 'Custom-Report job', and distinguishes itself from sibling tools like arena_get_job_status and arena_get_backtest by specifying it is for a Custom-Report workflow.

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

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

The description provides a lifecycle sequence (pending_payment → queued → running → generating → success/failed) and mentions required input 'job_id' from checkout. However, it does not explicitly state when to use this tool versus alternatives (e.g., arena_get_job_status) or include when-not-to-use guidance, missing a clear directive.

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 bears full responsibility and delivers thoroughly. It declares read-only access ('Read-only over result aggregates, look-ahead free'), describes the return structure (distribution, verdict, DSR threshold), and explains the Deflated Sharpe N-counting logic with its honesty guard ('fewer than 15 neighbors → insufficient'). No contradictions exist since there are no annotations.

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

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

The description is dense with valuable information but is overly long (150+ words) for what could be more tightly structured. While front-loaded with the key question, it could benefit from short paragraphs or bullet points to improve scannability for an AI agent. Every sentence adds value, but the wall of text reduces readability.

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

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

For a complex tool with 9 parameters, nested objects, and no output schema, the description provides comprehensive guidance: it explains the cross-asset vs. parameter axis, the DSR counting detail, the 15-neighbor guard, the return value categories (median, IQR, positive-share, verdict), and the data scope. The only missing piece is some mention of error/edge cases (e.g., missing pairs), but the completeness for the tool's core purpose is strong.

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, but the description still adds immense value beyond the schema labels. It explains how the 'params' object is used to form the neighborhood, clarifies that user_cagr is the 'cell being assessed' (not just a parameter value), and describes the optional user_sharpe's role in the DSR calculation. The axis parameter's effect on analysis is also explained beyond the enum values.

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

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

The description starts with a clear question ('Is this backtest result real, or a lucky cell?') and immediately states the tool's purpose: assessing a result against its neighborhood. It specifies the exact resource (one backtest result's robustness) and differentiates it from siblings like arena_get_backtest_trades (getting details) or arena_compare_strategies (comparing strategies, not robustness).

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 the context for use (assessing robustness of a single result) and explicitly describes when DSR-N is not claimed ('fewer than 15 neighbors'). It mentions the axis parameter for a secondary 'anecdotal' view, which hints at when to avoid using it. However, it does not explicitly say when to prefer siblings like arena_compare_strategies or arena_get_strategy_insights, missing a clear 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 of disclosing behavior. It transparently notes the deprecation, the removal date (2026-11-15), the semantic correction, the 'same payload plus deprecation fields', and the free tier. This is strong coverage, though it does not specify the exact nature of the deprecation fields, which would add completeness.

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 'DEPRECATED' and contains multiple sentences, but each sentence adds value: deprecation reason, alternate tool, market sentiment alternatives, and free tier. It is slightly verbose but well-organized 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 deprecation and simple schema, the description covers the essential context: replacement, timeline, semantic correction, and alternatives. It does not describe the response shape, but the 'same payload plus deprecation fields' gives a reasonable hint. Overall, it is sufficient for an agent to decide whether to use this tool or avoid it.

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

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

The input schema already describes both parameters (period, context) with 100% coverage, so baseline 3 is appropriate. The description adds 'same payload' referencing the replacement tool, but does not provide additional parameter-specific semantics beyond what the schema already offers.

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 that this endpoint measures PLATFORM ACTIVITY, not market sentiment, correcting the misleading name. It clearly identifies the tool's actual function with a specific verb ('measures') and resource ('platform activity'), and distinguishes it from sentiment tools like arena_get_fear_greed and arena_get_pulse.

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: use arena_get_platform_activity instead, and lists specific alternative tools for actual market sentiment. It clearly states when not to use this tool and directs the agent to the correct replacement, making misuse less likely.

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 the full burden. It discloses access requirements (no ownership, no Pro tier, free tier) and return shape (same as arena_get_backtest). While it doesn't mention rate limits or side effects, for a read operation this is 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 sentences with a parenthetical, front-loaded with a question hook. Every sentence adds value with no unnecessary 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 no output schema, the description compensates by stating the return shape. It covers unique value proposition, usage scenario, and parameter linkage. Completeness is high for a simple fetch tool with only two parameters.

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 each parameter having a description. The description adds 'addressed by its share_id' which reinforces parameter purpose but does not significantly extend beyond what the schema already provides. 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 fetches a backtest published via a share link using its share_id. It distinguishes itself from sibling tool arena_get_backtest by explicitly noting it requires no ownership or Pro tier.

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 ('when a user pastes a /shared/backtests URL') and when not to ('Use arena_get_backtest instead for the user's own runs'), providing a clear alternative.

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

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

With no annotations, the description fully discloses behavior: anticipated is always false before close, edge_vs_benchmark is gated by noise floor, contradictions are reported not resolved, sources can fail independently, and the answer never silently narrows. This is exemplary transparency.

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

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

The description is long but information-dense and well front-loaded with the core question. Every sentence serves a purpose, though some elaborations could be tightened without loss of clarity.

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 return blocks: filters[].blocks_this_entry, edge_vs_benchmark, contradictions, invalidation zones, statement/confidence, and sources_used/sources_unavailable. It covers edge cases and limitations, making it complete for a complex analysis 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 baseline is 3. The description adds meaningful semantic detail beyond the schema, notably for 'interval' (alignment effects on CAGR and indistinguishability) and 'detail' (headline vs full), raising the 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 opens with 'Should I take this entry?' and states it 'Answers it for one (strategy, pair, interval) in ONE call instead of seven.' This clearly identifies the tool's function and distinguishes it from the sibling filter-effect tool by combining historical filter alignment with current signal 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?

The description explains this tool replaces seven calls and references complementary tools: 'Compose further with arena_get_strategy_performance_by_regime (WHEN has this worked) and arena_is_distinguishable.' It does not explicitly state when not to use it, but the context is clear.

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

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

No annotations provided, so the description carries full burden. It fully discloses that it's a read-only check backed by a daily cron job, that it requires active user subscriptions to return meaningful data, and that it has a free tier. All of this is valuable beyond the schema.

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

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

Three concise sentences front-loaded with the core purpose, then dependencies, then tier info. No fluff or wasted words. Each sentence earns its place.

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

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

Given no output schema, the description could hint at the return format but doesn't. However, the tool is simple (green/yellow/red status) and the description is thorough enough for an agent to use correctly. Completeness is good for a non-complex 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 baseline is 3. The description doesn't add parameter-specific meaning beyond what the schema provides (e.g., interval has very detailed enum documentation in the schema itself, the context parameter is fully defined in schema). No additional value from 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 uses a specific verb ('getting') and resource ('signal-status') with clear outcome ('green/yellow/red'), and distinguishes from siblings like arena_get_signal_context which provides broader context rather than current status.

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

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

Clearly states when to use this tool (current signal status) and what prerequisites are needed ('needs at least one user with an active Ampel on this combination'). However, it doesn't explicitly say when NOT to use it or mention 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 must carry the full burden. It describes the output (last price, change %, high/low) and source (Binance), and mentions '[Free tier]'. However, it does not disclose how often the price updates, whether it is cached, or any rate limits or authentication requirements. More behavioral context would be helpful.

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 concise sentences. The first delivers the core purpose and data returned, the second provides usage guidance and a free-tier note. Every word earns its place with no redundancy. It is front-loaded and well-structured.

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

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

For a single-parameter price tool with no output schema, the description adequately covers what is returned (last price, 24h change, high, low) and the source (Binance). It also mentions the free tier and use case. It does not describe the response format or error cases, which would push it to 5, but overall it is sufficient for an agent to understand and 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?

The only parameter is 'context' (required, string). Schema description coverage is 100%, so baseline is 3. The main description does not add meaning beyond what the schema already says. The parameter is for analytics tracking, not for modifying the tool's primary price retrieval behavior. The schema description is adequate but the overall parameter semantics do not add 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 tool fetches the current spot price for BTC, ETH, and SOL, providing last price, 24h change, high, and low from Binance. This is specific and distinguishes it from the many other arena_ data tools (e.g., arena_get_gem_score, arena_get_onchain_latest) which focus on analytics or history.

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

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

The description gives explicit usage guidance: 'Use this to anchor the connector’s own analytics... instead of switching to web search mid-analysis.' This tells the agent when and why to use the tool while steering it away from a common alternative. However, it does not compare to other arena_ sibling tools, which would make it even clearer.

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 adequately discloses that the tool is a read operation, gives context on the source (DefiLlama peggedUSD), acknowledges the free tier limitation, and explains behavioral details like the four impulse states and how reversal is indicated. This is transparent for a data-retrieval tool, though it doesn't mention potential rate limits or data latency.

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

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

The description is compact and front-loaded with the core purpose ('Aggregate stablecoin supply...'), then progressively adds detail about output fields and interpretations. It's slightly wordy in parts (e.g., the example in 'accelerating: false') but each sentence contributes to understanding. Could be trimmed slightly without losing substance.

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 only one parameter, no output schema, and is a data-retrieval tool, the description is quite complete. It explains the output's structure (current supply, 30d/90d change, time series, impulse states), differentiates from a sibling, and notes the data source and tier. A small gap: it doesn't specify whether the output is a single object or an array, but the behavioral hints compensate. For a simple tool, this is well-rounded.

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 only one parameter ('context'). The description adds value beyond the schema by explaining why the tool is called (to expose trend vs single delta) and what output it provides, which helps the agent understand the context parameter's role in tracking intent. The context parameter's description is detailed, but the tool description itself doesn't reiterate parameter specifics (though schema details are covered). Baseline 3 is adjusted upward because the description effectively orients the agent on what the tool yields, making the context parameter more meaningful.

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 identifies the tool as aggregating stablecoin supply as a crypto-liquidity proxy, and it distinguishes its purpose from 'macro_regime' (which only gives a 30d delta) by exposing a broader trend with current supply, 30d/90d change, and a compact time series. The verb 'exposes' and resource 'stablecoin supply trend' are specific, and the mention of 'impulse' states adds further clarity.

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

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

The description provides clear context for when to use this tool: it's for seeing the trend and direction of liquidity impulse, contrasting with 'macro_regime' which only gives a single delta. It also explains the meaning of the 'impulse' field and how it relates to 'acceleration_usd' and 'accelerating', giving guidance on interpreting the output. However, it does not explicitly state when NOT to use this tool or name direct alternatives beyond macro_regime.

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 tool returns three metrics (cost basis, MVRV, in_loss flag) and notes it is descriptive, not a signal, and has a '[Free tier]' label. It does not explicitly state it is read-only or discuss rate limits, but the 'get' verb and context imply safe retrieval. 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?

The description is three sentences long and front-loaded with a clear question. It efficiently conveys the metric and derived values. However, the phrasing is slightly run-on and could be more structured. Still, 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?

For a simple data retrieval tool with one parameter and no output schema, the description explains the returned metrics, their meaning (e.g., in_loss flag), and provides context (descriptive, not a signal, free tier). It lacks specification of the output format, but given the tool's simplicity, it is largely 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%, so the baseline is 3. The description does not add any information about the 'context' parameter beyond what the schema already provides. No extra semantics or usage examples are 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 it returns the BTC short-term-holder cost basis along with derived STH-MVRV and an in_loss flag. The verb 'get' and resource 'STH cost basis' are specific. However, it does not explicitly distinguish itself from the many sibling on-chain tools, though the unique metric makes it identifiable.

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 vs alternatives. The description notes it is 'descriptive on-chain context, not a buy/sell signal' but does not provide when-to-use or when-not-to-use criteria. Among many sibling arena_get_* tools, clear usage context would help agent 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?

No annotations are provided, so the description bears full burden. It discloses key behavioral traits: the tool returns baseline-stats plus variant-specific deltas, includes a not_applicable_filters list, and clarifies that CAGR is time-normalized across different windows. It also warns about multi-day candle alignment and its effect on CAGR variability (6.66 pp). However, it does not explicitly state whether the tool is read-only or destructive, but given the analytic nature, this is a minor gap. The free tier note also gives transparency on pricing 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 a single paragraph of moderate length (around 120 words). It front-loads the core purpose ('What would each entry filter have changed for this strategy?') and then expands with output details and caveats. It is mostly efficient, though some sentences (e.g., about CAGR time-normalization) could be tighter. The use of '—' for parentheticals helps structure. A bullet list might improve readability, but overall it earns its space with valuable 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 complexity (4 parameters, 100% schema coverage, no output schema), the description is highly complete. It explains what each output component means (baseline stats, variant deltas, not_applicable_filters, best_by_cagr pick), clarifies aggregation window and CAGR normalization, and warns about multi-day candle alignment issues. The note about real versus theoretical permutations sets appropriate expectations. No output schema exists, so the description compensates well.

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 adds significant value beyond the schema: it explains that 'context' is for user intent tracking with specific formatting rules (15-25 words, third-person, no sensitive info), details the interval parameter's behavior (multi-day anchor, CAGR variability of 6.66 pp, grouping of 1d/2d/3d), and clarifies that strategy keys come from arena_get_strategies. The description enriches every parameter with practical guidance.

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

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

The description clearly states what the tool does: it provides per-(strategy, asset, interval) filter-effect analysis, showing what each entry filter would have changed for a given strategy. It distinguishes itself from siblings by referencing siblings like arena_get_filter_insights implicitly (by focusing on strategy-specific filter effects) and by specifying the output includes baseline stats, variant stats, and best_by_cagr pick, which is unique among the listed tools.

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

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

The description explicitly states when to use the tool: 'Use this to answer "Which filters would improve my backtest for X on Y?"'. It also provides exclusions by mentioning 'not_applicable_filters list (e.g. altcoin_season excluded on BTC-pair)', and hints at alternatives by contrasting with theoretical permutations ('Not theoretical 2^5 permutations. Based on REAL backtest aggregations'). This makes the usage context clear and actionable.

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

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

No annotations are provided, so the description carries full burden. It discloses free-tier capping (`plan_capped: true`, `plan_cap_note`), 403 behavior for Pro-only strategies in detail mode, and even quantifies interval-alignment uncertainty (6.66 pp CAGR move) to prevent misinterpretation. This is rich behavioral context beyond the schema.

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

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

The description is dense but well-organized: purpose first, then mode behavior, then plan restrictions, then a compact summary. Every sentence adds either actionable guidance or critical caveats. No fluff or repetition of the schema.

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

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

For a 7-param tool with no annotations and no output schema, the description completely covers modes, response contents, error behavior, free-tier constraints, and parameter-interpretation caveats. It leaves no meaningful gaps for the agent to make a wrong call.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds significant value by explaining mode semantics (strategy+interval together trigger detail), free-tier limitations, and interpretation guidance for multi-day candles. It goes beyond what the property descriptions say, such as the alignment affecting CAGR and that differences below that threshold are not distinguishable.

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

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

The description opens with a specific question ('Which strategy and interval combinations actually performed?') and names the resource ('Aggregated backtest performance per (strategy × interval) cell'), then clearly distinguishes matrix vs detail modes. This differentiates it from sibling tools like arena_get_strategy_performance and arena_compare_strategies.

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

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

The description gives explicit mode-selection rules: if both `strategy` and `interval` are provided, detail mode returns per-asset breakdown; otherwise matrix mode returns. It also warns about free-tier limitations and refers users to what happens with Pro-only strategies, effectively guiding when to use and what to expect.

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 details the return values (run_count, avg_cagr, avg_win_rate, etc.) and the evidence block structure, including gate conditions. It does not explicitly state it is read-only or has no side effects, but the context of querying aggregated performance implies a safe read operation. The level of detail is high, earning a 4.

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 front-loaded with a clarifying question. It packs in return field details, alternative tool reference, and a free tier note without wasted words. While it could be slightly more structured (e.g., bullet points for return fields), it is efficiently 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?

The tool has 6 parameters, no output schema, and moderate complexity. The description covers the return structure, the evidence block, and the usage context. It does not discuss error cases (e.g., insufficient runs) or edge cases, but given the single-combination focus, the coverage is mostly complete. A slightly higher score would require explicit error handling notes.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds value beyond the schema by providing extra context for the interval parameter (alignment effects, CAGR differences) and reiterating the third-person requirement for the context parameter. This additional semantic guidance justifies a 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 the tool returns aggregated backtest performance for exactly one (strategy, asset, interval) combination. It uses the verb 'perform' and specifies the resource as 'exact strategy, asset and interval'. It distinguishes itself from the sibling arena_get_strategy_insights by explicitly naming it for multi-strategy overviews.

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 guidance: 'For multi-strategy overview use arena_get_strategy_insights' and 'Use this to answer "How does strategy X perform on asset Y?"'. It also includes a '[Free tier]' tag, implying cost considerations. This clearly tells the agent when to use this tool versus alternatives.

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

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

With no annotations, the description bears full transparency responsibility. It thoroughly explains the output fields (trades, win_rate, avg_pnl_pct, etc.), the interpretation of share_of_time_pct, and the alignment sensitivity of multi-day candles. It also documents the removal of the former recommendation.verdict. Minor omissions: no explicit statement about side effects (read-only) or rate limits, but the detail provided is substantial.

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 verbose and somewhat repetitive, e.g., repeating 'trade counts pool ALL parameter-variant configs' and the note about days until the next observation. While it is logically structured, it could be tightened without losing meaning, making it less efficient than ideal.

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

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

The description covers the tool's purpose, output metrics, interpretation caveats, and relationship to other tools. There is no output schema, but the prose clearly explains what the tool returns, including the benchmark block and the meaning of each metric. It is sufficiently complete for a user to understand the tool's capabilities 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% with descriptions for all 5 parameters. The description adds significant value by explaining the alignment effect for interval and the caution about distinguishing differences, and by reinforcing the required word count and third-person perspective for context. This goes beyond the basic 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 provides historical performance split by macro regime, answering 'WHEN has this strategy worked?' and explicitly contrasts with 'should I trade now' and the removed recommendation feature. It also distinguishes from the sibling tool arena_get_strategy_performance by the regime breakdown.

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 explains when to use it (to assess regime-based performance) and when not to use it (not for trade timing). It also references alternative tools like arena_get_strategy_filter_effect and arena_is_distinguishable for decision-grade views, providing clear 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?

With no annotations, the description fully discloses behavioral traits: the three windows are non-selectable by design to avoid cherry-picking; 'never estimated from fewer bars' with thresholds (500 bars daily, 150 weekly); percentile is null when sample size is insufficient; listing-age pairs return empty channels with data_sufficient: false. It also clarifies that band edges describe past dispersion, not defended levels, preventing misinterpretation. The 'Free tier' indication at the end 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 well-structured: starts with a purpose-question, explains methodology and design rationale, covers limitations and edge cases, and ends with related tools. Each sentence adds value, though some repetition occurs (e.g., window count vs. bar count). It is appropriately detailed given the tool's complexity, but could be slightly tighter without losing clarity.

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 3 parameters and no output schema, the description provides near-complete context. It explains what the tool returns (trend channels, R² percentile, agreement.consistent, windows_unavailable, data_sufficient), covers edge cases (short history, weekly interval, listing-age pairs), and warns about interpretation pitfalls (band edges not support/resistance). The listing of related tools further situates the tool within the broader suite.

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

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

Schema coverage is 100%, so baseline is 3, but the description adds practical value: for 'pair' it gives examples and notes full history is used; for 'interval' it explains that windows are counted in bars and most pairs won't reach 365 weeks on '1w'. The description also explains output semantics (r_squared_percentile, agreement, windows_unavailable) compensating for the missing output schema. However, the 'context' parameter receives no additional explanation beyond its 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?

The description clearly states the tool computes trend channels using log-linear regression over three fixed windows (90/180/365 bars), with R² percentiles to assess robustness. It differentiates itself from siblings by naming related tools (arena_get_key_levels, arena_get_btc_market_structure, arena_get_historical_analog) and explaining its unique design (multiple non-selectable windows prevent p-hacking). The opening question 'Where does price sit inside its trend channel?' further solidifies the 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 provides explicit when-to-use context: analyzing trend channel fit and robustness. It offers alternatives: 'Related: arena_get_key_levels, arena_get_btc_market_structure, arena_get_historical_analog' with brief explanations of their different focuses. It also guides on when results are not an error ('Pairs listed within the last few months... return data_sufficient: false and an empty channel list — that is the answer, not an error') and warns about window length (365 weeks on '1w' interval exceeds most pairs' 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?

The description explicitly warns about survivorship bias: 'Universes reflect the CURRENT membership — they are not point-in-time, so a backtest over them carries survivorship bias for the earlier years.' This is critical behavioral context beyond the tool's basic function. Since no annotations are provided, the description carries the full transparency burden and handles it well, though it could also mention any rate limits or destructive effects, which appear absent.

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 efficient with three sentences covering purpose, use case, behavioral caveat, and sibling reference. The first sentence immediately answers the user's likely question. The '[Free tier]' tag is a minor addition but not essential, and the whole text earns its length.

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

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

Given the moderate complexity (2 parameters, no nested objects, no output schema), the description is complete. It explains what the tool returns, when to use it, how it relates to sibling tools, and a key trade-off (survivorship bias). There is no critical missing information for the AI to make an informed invocation decision.

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

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

Schema description coverage is 100%, so the baseline is 3. The description does not add detail about the 'universe_id' parameter beyond the schema's example, but it does clarify the context parameter's purpose in an example. It does not significantly extend the schema's meaning.

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