Strategy Arena

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered by structured data. The description adds only the returned metric set (PnL %, trades, win rate) and the 'limit max 30' cap, both of which are marginal given the presence of an output schema and the schema's maximum. No auth, refresh/rate-limit or staleness behavior is described.

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 tight, front-loaded sentences: the resource and default asset come first, then the limit constraint, then the sibling routing hint. Nothing is padded, though the description is in French while the surrounding tool surface (siblings, schema titles) is English, which is a minor friction cost for an agent reading the toolset.

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 full annotations, an output schema and a single optional parameter, the definition covers what the agent needs to call it correctly: what it returns, the default asset, the limit cap, and where to go for multi-asset comparisons. Missing only a hint of when it beats near-neighbors like arena_snapshot or community_arena_rankings.

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 0% for the single 'limit' parameter, so the description carries the burden, yet 'limit max 30' merely restates the schema's maximum/default rather than explaining that it caps the number of ranked strategies returned. It gives a hint of the parameter's role but adds no real meaning beyond the structured field.

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

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

States a specific resource and scope: a live arena leaderboard of the best AI strategies, defaulting to BTC, showing PnL %, trades and win rate. It also differentiates itself from siblings by naming compare_arenas and list_arena_strategies for the multi-asset case, so an agent can route without opening either schema.

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

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

Explicitly names the alternative tools ('compare_arenas ou list_arena_strategies') and the condition that selects them (multi-assets), which is genuine when-to-use guidance. It does not state when this tool should be preferred over arena_snapshot or community_arena_rankings, so the routing picture is incomplete but clearly useful.

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?

While the annotations cover safety, the description adds behavioral context regarding the workflow, specifying that the final 'sealed verdict' occurs in the local Lab, pointing to the next operational step for the agent.

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 text is highly dense and avoids fluff. It packs the tool's entire conceptual mandate—protocol, safety, and workflow—into a few efficient sentences.

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

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

As a reference tool with no inputs, its completeness lies in providing the conceptual framework. The description successfully delivers the necessary protocol guidance for the agent to understand its context before proceeding to generation.

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?

Since the tool has zero input parameters, the description cannot add semantic value to any input. Following the rule for 0 parameters, it receives the baseline score of 4.

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

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

The description defines the tool as a 'short reference' for the ArenaScript protocol, making it distinct from sibling tools like 'generate_arenascript_strategy' or 'validate_arenascript.' It establishes its role as a foundational guide.

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

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

It provides explicit usage guidance, instructing the AI to call it 'before generating a strategy.' It outlines the precise workflow (generate → validate → backtest → Monte Carlo).

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds the compact/lightweight scope and enumerates returned content, but with an output schema present it need not explain returns; the added behavioral value is modest.

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

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

A single front-loaded sentence that leads with the resource and purpose. The parenthetical schema reference is slightly cluttering but the sentence still earns its place without padding.

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 1-parameter, read-only tool with a full output schema and complete annotations, the description covers purpose, content scope, and a light usage cue. It is nearly sufficient, with only explicit sibling routing missing.

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

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

There is a single 'asset' parameter with 100% schema description coverage ('Actif, ex. BTC, ETH, SOL, BNB.'). The description adds no additional meaning about the parameter, so the baseline of 3 applies when the schema does the work.

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

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

States a specific resource ('snapshot compact de l'arène') and enumerates its contents (capital, leaders, méta). It also implicitly distinguishes itself from the sibling arena_leaderboard by positioning itself as the lightweight alternative ('sans télécharger tout le leaderboard'), which an agent can act on.

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?

'utile pour un briefing agent' hints at when to use it, and the contrast with downloading the full leaderboard implies arena_leaderboard is the heavier alternative. However, it never explicitly states when to prefer this over arena_leaderboard, explore_arena, or community_arena_rankings, leaving selection to inference.

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

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

Annotations declare readOnlyHint=false, destructiveHint=false, idempotentHint=false, openWorldHint=false, so the safety profile is partly covered. The description adds valuable context: it is a paper preview, in-sample with no holdout, consumes quota, and warns against submitting private strategies. However, what mutation occurs is not fully spelled out.

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 short and front-loaded with 'PAPER PREVIEW', but the cryptic flags (sealed:false, is_keep:false, paper:true) and bilingual phrasing add noise rather than clarity. Every sentence does not fully earn its place due to undefined jargon.

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 a single-parameter backtest tool with an output schema, the description covers the key call-time context: it is a paper preview, in-sample without holdout, consumes quota, and has privacy restrictions. The only minor gap is the unexplained flag terms, but overall an agent has enough to 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?

Schema coverage is 100%, with the single parameter 'arenascript' already documented as a script up to 20,000 characters. The description does not add syntax or format details beyond the schema, so the baseline of 3 applies.

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

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

States it is a paper preview backtest of an ArenaScript, an alias of backtest_strategy, running the Lab's Rust engine on server OHLCV candles at the declared timeframe, in-sample without holdout. The core verb+resource are clear, though the cryptic flags (sealed:false, is_keep:false, paper:true) and bilingual text slightly obscure the message.

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 'Not a verdict; for a verdict use get_lab_desktop_handoff', naming the alternative and the condition that selects it. Also advises that public scripts may be kept and private strategies should not be submitted, giving clear 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?

Goes well beyond the annotations: discloses engine rules (10 bps per side, close execution, no slippage model, unsupported syntax rejected), the rate limit of 60 backtests/day/client with a quota field, that failures are explicit when the engine refuses, and crucially that the server may retain the submitted script so private strategies should not be sent. That retention notice also explains the non-read-only, non-idempotent annotation profile rather than contradicting it.

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

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

Every clause carries real information, but the opening 'PAPER PREVIEW (sealed:false, is_keep:false, paper:true)' is raw internal field syntax that forces the reader to decode jargon before reaching the actual purpose, and the bilingual prose adds friction. The lead should be the verb+resource, not the flag tuple.

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

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

An output schema exists so return values need no explanation, and the description still covers scope, cost model, quota, retention risk, and failure behavior. The remaining gap is sibling disambiguation against `backtest_arenascript`, which is the most likely mis-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?

Only one parameter and schema description coverage is 100%, so the schema already documents the 20,000-character ArenaScript field. The description adds engine-level constraints on what the script may contain ('syntaxe non supportée refusée') but nothing about format or content 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?

States a specific verb+resource: backtesting an ArenaScript strategy through the Lab's Rust engine on server OHLCV candles resampled to the declared timeframe. However, it never distinguishes itself from the near-identical sibling `backtest_arenascript`, which an agent will immediately be torn between.

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 scopes itself as a paper preview and names the alternative for a real verdict: 'Not a verdict; for a verdict use get_lab_desktop_handoff.' It still gives no guidance on when to pick this over `backtest_arenascript`, `invent_and_backtest`, or `engine_robustness_check`, so a key routing decision is left open.

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

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

Annotations already cover readOnly, idempotent, non-destructive, closed-world. The description adds essentially nothing beyond 'discovery' framing – no mention of what is ranked, ordering, or how results differ from arena_leaderboard.

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

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

Single short sentence, front-loaded with the tool's subject. Efficient, though under-specified rather than over-long.

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?

Output schema exists, so return values needn't be explained, but with a 0%-documented parameter and many overlapping arena siblings, the description leaves the agent unable to distinguish this tool or understand its limit 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 coverage is 0% and the only parameter (limit, default 10, max 30) is never mentioned in the description. The description should compensate for the bare schema but doesn't address the parameter at all.

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

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

States it's a community-arena ranking, but the parenthetical 'stratégies soumises par humains' and 'idées hors vault IA' are vague marketing phrasing rather than a precise verb+resource. It doesn't clearly distinguish from sibling arena_leaderboard or explore_arena.

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 when/when-not guidance. With siblings like arena_leaderboard, explore_arena, and community_arena_stats, the agent gets no way to know when this rankings tool is preferred over those 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?

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and closed-world, so the safety profile is fully covered. The description adds scope information (what is aggregated: submissions, live, authors) but nothing further about freshness, caching, or rate limits; with annotations carrying the behavioral load, this is an adequate 3.

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

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

A single, front-loaded sentence with no filler. It is appropriately sized for a zero-argument stats tool, though it packs little beyond the bare scope.

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

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

An output schema exists, so return values need not be described, and there are no parameters to explain. However, among ~45 sibling tools the description gives no signal about when this stats endpoint is the right pick versus rankings or leaderboard tools, leaving a routing gap.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate; the baseline for a no-parameter tool is 4.

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

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

States a specific verb-like purpose (aggregated stats) and resource (community-arena) and names the dimensions aggregated (submissions, live, authors). The word 'agrégées' implicitly distinguishes it from the sibling community_arena_rankings, but no sibling is named explicitly, so differentiation is left to inference.

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

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

There is no when-to-use guidance, no prerequisites, and no mention of alternatives such as community_arena_rankings or arena_leaderboard. The agent must infer context solely from the phrase 'stats agrégées'.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds the default asset scope and input format, but says nothing about rate limits, auth, or comparison behavior beyond what annotations and the output schema already imply.

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 compact sentences, purpose front-loaded before the parameter note, with no filler. Efficient, though terse enough that the missing top_n explanation is a structure gap rather than excess.

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

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

An output schema exists, so return values need not be explained, and annotations cover safety. For a 2-parameter tool it is nearly complete, but the undocumented top_n and absent when-to-use guidance leave meaningful gaps.

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

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

Schema description coverage is 0%, so the description carries the full burden. It documents 'assets' as a comma-separated list with a default (though the default is already in the schema), but 'top_n' is never mentioned, leaving half the parameters undocumented in both schema and 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?

States a specific verb (compare) and resource (tops of BTC/ETH/SOL/BNB arenas) with a clear goal (cross-asset pattern hunting). An agent can distinguish it from leaderboard-style siblings by the cross-asset comparison angle, but no sibling is explicitly named or contrasted.

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 rationale 'pour chasser des patterns cross-asset' implies when the tool is useful, giving more than pure silence. However, it names no alternatives and no when-not-to-use conditions (e.g., vs arena_leaderboard or arena_snapshot), leaving routing to inference.

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

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

Annotations only declare the safety profile (readOnlyHint=false, non-idempotent, non-destructive, closed-world); the description adds substantive behavior: each idea is generated AND backtested, the result is a paper preview rather than a KEEP, identical-script inputs are rejected, and payment cannot alter the verdict. The cryptic header '(sealed:false, is_keep:false, paper:true)' and 'Payment never changes a verdict' imply billing without explaining cost/quotas, keeping it just under a 5.

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

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

Dense and front-loaded: purpose and the verdict-alternative come first, then refusal condition and billing caveat. Minor waste from the unexplained '(sealed:false, is_keep:false, paper:true)' token and 'Not a KEEP' repeating the is_keep flag, but no sentence is filler.

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

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

With an output schema present, return-shape explanation is not required, and the description covers purpose, refusal, and the verdict alternative. However, for a 5-parameter tool it leaves asset and style_a/style_b semantically unexplained, and the dollar/payment reference is introduced without saying what it costs - a gap an agent deciding whether to invoke would trip on.

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 60% - idea_a/idea_b and asset are documented in the schema, while style_a/style_b have no descriptions at all. The description clarifies only that the two ideas are free-text strategy descriptions to be generated and backtested; it says nothing about the asset param or the style defaults (mean_reversion / trend), so it does not compensate for the uncovered half.

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

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

States a specific verb and scope: 'Pit two public ideas against each other: generate + backtest each, return a compact comparison.' It also flags the output class (PAPER PREVIEW) and explicitly differentiates itself from get_lab_desktop_handoff, so an agent can tell verdict-seeking apart from 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?

Names an alternative for the verdict case ('for a verdict use get_lab_desktop_handoff') and gives a hard precondition for refusal ('Refuses two ideas that produce the same script'). It stops short of routing to the other adjacent siblings such as backtest_arenascript or invent_and_backtest, so routing coverage is partial rather than exhaustive.

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

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

Annotations already declare readOnly/idempotent/non-destructive, but the description adds real behavioral context: no Stripe session is created, checkout is false, and the sealed audit dataset stays server-side (i.e., no data exposure). Those are concrete traits the agent cannot infer from the annotations alone.

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

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

Four short, front-loaded sentences with no filler; the handoff purpose and the no-payment/no-data-leak guarantees lead. The telegraphic fragments ('checkout=false') are terse but each 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?

An output schema exists, so return values need not be described, and the description still states the key output (the /audit URL). For a zero-required-parameter handoff tool it covers the essentials; only the parameter detail and explicit usage routing are thin.

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 0% for the single optional parameter, so the description has to carry the load. It does explain that 'pine' is optional and functions only as a query hint that never touches the server-side dataset, which is meaningful. It is still loose ('pine' vs 'pine_hint') and says nothing about format or the 5500-char limit.

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

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

States a specific action and artifact: 'Human-only Survival Audit handoff' that 'Returns the /audit URL.' The verb+resource+return value are all present, and 'human-only' telegraphs it apart from the automated backtest/arena siblings. It doesn't name a sibling directly, which keeps it from a 5.

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

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

'Human-only' and 'checkout=false' imply the usage context (route a person to an audit page, no in-band purchase), and 'MCP never creates a Stripe session' clarifies the boundary. But there is no explicit when-to-use versus a sibling or when-not-to-use, so the guidance stays implicit.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=false, so safety is covered. The description still adds real behavioral facts beyond them: that first-account partner status is restricted to Lab desktop, that existing accounts get a neutral review, and that the MCP never emits an aff_id (an important disclosure for anyone advising a signup).

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

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

A single sentence, front-loaded with the purpose and then the three sub-topics it covers, closed by the invocation trigger. Every clause carries information; nothing is redundant or padding.

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

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

With an output schema present, the description need not explain return values, and for a zero-parameter informational tool it adequately states both scope and when to call it. It is complete enough to invoke correctly, though it could name related tools to route the agent more sharply.

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

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

The tool takes zero parameters, so the baseline is 4; there is nothing for the description to clarify beyond the empty schema. Parameter semantics are not a source of ambiguity here.

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

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

The description states a specific verb ("Explique" / explain) and a specific resource: the post-proof TradingView partner journey, including first-account partner status (Lab desktop only), neutral review of existing accounts, and why the MCP never emits aff_id. This is clearly distinct from action siblings like export_to_tradingview or get_lab_desktop_handoff, but no sibling is named explicitly, so the differentiation is implied rather than stated.

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?

"À appeler avant de conseiller une inscription TradingView" gives an explicit trigger condition for invoking the tool. It does not list when-not-to-use cases or name alternative tools, but the usage context is concrete and unambiguous for an informational 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?

Annotations already disclose readOnlyHint=false, destructiveHint=false, idempotentHint=false and openWorldHint=false, so the safety profile is covered structurally. The description adds genuinely useful behavioral detail beyond that: 10 bps fees per side, deterministic Monte Carlo with a seed derived from the trade fingerprint, resampling to the declared timeframe, and a separate public quota pool of 8 per day per client. It also states explicit failure when the engine refuses or is unavailable. However, the meaning of 'sealed:false, is_keep:false, paper:true' is never explained, so part of the behavioral framing remains opaque.

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 most decision-relevant sentence ('Not a verdict; for a verdict use get_lab_desktop_handoff') is buried behind an unexplained jargon prefix, so it is not well front-loaded. The body is information-dense with little filler, but the French/English mixing and the parenthetical key:value fragments make it harder to parse than its length warrants.

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 compute-heavy tool with an output schema, annotations, and a quota, the description covers cost (8/day quota), determinism, failure behavior, and the data source. An agent can decide and call correctly. The unexplained 'sealed/is_keep/paper' flags and the lack of any hint about runtime or input script constraints are the remaining gaps.

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

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

Schema coverage is only 50%, but the description compensates: it explains that holdout_percent accepts 10 to 40, or 0 for no holdout, and what 0 implies (Monte Carlo becomes identical to monte_carlo). That is real semantic content missing from the schema. The arenascript parameter is only implicitly characterized (a script executed by the Rust engine), relying on the schema's own description for the 20,000-character limit.

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 concretely states what is computed: a backtest, a chronological holdout, and a Monte Carlo run executed by the Lab's Rust engine on server OHLCV candles. It also explicitly distinguishes itself from the verdict tool (get_lab_desktop_handoff) and from a KEEP decision. The opening string 'PAPER PREVIEW (sealed:false, is_keep:false, paper:true)' is internal jargon that obscures rather than clarifies 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?

It gives an explicit routing rule: 'Not a verdict; for a verdict use get_lab_desktop_handoff', and reiterates 'Descriptif, pas un KEEP'. That names the alternative and the condition that selects it. It does not cover when to prefer monte_carlo or backtest_arenascript, which are the closest siblings for the individual components.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so safety is covered. The description adds useful behavioral context beyond annotations: the data is paper-trading and 'not a verdict,' which warns the agent about its epistemic status. It does not detail return shape, but an 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 compact and front-loads the core purpose before listing contents and sequencing. The list is dense but each item conveys scope; nothing is obviously wasteful, though the phrasing is closer to a checklist than a polished explanation.

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 output schema, annotations, and single well-documented parameter, the description supplies enough context for an agent to know what the tool aggregates, when to call it, and that its data is paper-trading. It could be more explicit about the asset parameter's effect, but overall it is complete enough for correct invocation.

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

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

Schema description coverage is 100%, and the single asset parameter is documented in the schema with its default and examples. The description does not add meaning about how asset affects the orientation output, so the baseline 3 is appropriate.

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

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

The description clearly identifies this as a one-shot arena orientation and enumerates the domains it covers: live status, multi-asset tops, regime, monsters, community pulse, templates count, and play recipes. It distinguishes its aggregate scope from prerequisite tools like get_product_contract and get_public_proofs, though it does not explicitly contrast with sibling tools such as market_regime or arena_leaderboard.

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

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

It gives explicit sequencing: call after get_product_contract and get_public_proofs, and before inventing strategies. That is strong when-to-use guidance. It does not state when not to use it or name alternative tools for specific sub-tasks.

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 annotations present (readOnly false, destructive false, idempotent false), the description adds real context: conversion can be EXACT or PARTIAL with unconverted lines listed, no TradingView aff_id is emitted, and job_id is server-side re-verified via verification_status. It does not cover rate limits or auth, but the behavioral profile is well disclosed.

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

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

The when-not/alternative routing is front-loaded, which is good, but the opening 'PAPER PREVIEW (sealed:false, is_keep:false, paper:true)' is opaque key:value noise, and the mid-sentence shift between English and French makes it denser than necessary.

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

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

An output schema exists so return values needn't be re-explained, yet the description still summarizes them (Pine code, EXACT/PARTIAL status, setup/review URLs). For a 2-param export tool with annotations, this is essentially complete; only alternative-tool routing for the converter siblings is missing.

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

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

Schema coverage is 50%: arenascript is documented (20,000 char max) but job_id is not in the schema. The description compensates by explaining job_id in depth — optional, the header cites the CUDA job only when the job script matches the exported script, and it is an optimization result, not a validation.

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 core sentence states a specific verb and resource: exports an ArenaScript strategy into Pine Script v5, with engine semantics (fees 0.1%/side, no slippage) spelled out. However, the opening 'PAPER PREVIEW (sealed:false, is_keep:false, paper:true)' is cryptic internal jargon that delays the actual 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?

Explicitly says 'Not a verdict; for a verdict use get_lab_desktop_handoff', which is a clear when-not + named alternative. It doesn't address when to prefer this over inspect_pine_export_capability or get_pine_converter_contract, both in the sibling list, so it's strong but not exhaustive.

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

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), so the bar is lower. The description adds genuine behavioral context beyond that: it declares the generation is deterministic, that recognized signals drive entry conditions, that short/sell maps to short_entry, and that asset/timeframe are whitelist-restricted.

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

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

Front-loaded with the core action, then the determinism rule and recognized signals, then output/style sourcing, ending with the style list. Dense but nearly every clause carries distinct information; the signal enumeration is slightly list-heavy but purposeful.

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

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

An output schema exists, so return-value explanation is unnecessary, and the description still notes idea_used as a useful output. It covers determinism, the style set, and the whitelist constraints, though the asset whitelist itself is not enumerated, leaving a minor gap for a 4-parameter 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?

With 75% schema coverage, the baseline is 3, but the description adds real value: it enumerates the valid style values (balanced, trend, breakout, momentum, mean_reversion, scalping), which the schema leaves as a bare string with no enum, and clarifies that asset/timeframe are constrained to whitelists.

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

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

States a specific verb and resource: 'Génère un ArenaScript canonique et éditable à partir d'une idée.' It further distinguishes itself from siblings by detailing exactly what the generator does (named signals become entry conditions, idea_used reports recognition), separating it clearly from repair_arenascript, validate_arenascript, and backtest_arenascript.

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 use case is implied (turn an idea into an editable strategy) and prerequisites like whitelisted asset/timeframe and style-driven outputs are stated. However, there is no explicit when-to-use vs when-not guidance, nor any pointing to alternatives such as repair_arenascript or invent_and_backtest, so the agent must infer routing.

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

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

Annotations already declare readOnly, idempotent, non-destructive, closed-world. The description adds substantive context beyond that: reads public evidence only, cannot authenticate an owner/pay/publish, and explicitly disclaims that server-checked publication is not independent reproduction or a future-performance guarantee. This is meaningful behavioral framing.

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

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

Front-loaded with READ-ONLY and the core action, then exclusions, then disclaimer. Dense but every clause carries information; the disclaimer is slightly verbose but justified for a trust-sensitive tool.

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

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

For a single read tool with an output schema and full annotation coverage, the description covers input identity, what it does and does not do, and trust boundaries. Output schema handles returns, so remaining gaps are 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?

The schema documents the parameter shape and regex only (0% description coverage); the description compensates by clarifying the semantic identity of the ID — canonical APUB publication ID — and what it must not be conflated with. It stops short of explaining the APUB format itself, but the schema's pattern covers format.

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

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

States a specific verb+resource: retrieves a single already-public Arena Passport by canonical APUB publication ID. Distinguishes from the many sibling tools (leaderboard, snapshot, arena facts) by scope: one passport, keyed by publication 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?

Explicitly states what the ID must be (canonical APUB publication ID) and what it never accepts (private audit identifiers, local Run IDs), which steers the agent away from wrong inputs. Doesn't name a specific sibling alternative, but the exclusions do most of the routing work.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false. The description adds valuable behavioral context beyond annotations: access is restricted to Operator accounts, public MCP returns not_available_on_public_mcp, and a CUDA result is not a Lab engine verification.

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 short but poorly structured: it opens with cryptic flags like 'PAPER PREVIEW (sealed:false, is_keep:false, paper:true)' and mixes English and French. The useful routing information is not 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?

An output schema exists, so return values need not be explained, and annotations cover the safety profile. The description adds access restrictions and a caveat, but leaves the job_id source/format and the meaning of the 'PAPER PREVIEW' flags 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?

There is one required parameter, job_id, with 0% schema description coverage. The description implies it identifies an ArenaScript CUDA job but gives no format, source, or constraints, so it does not compensate for the missing schema documentation.

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 that the tool returns the status of an ArenaScript CUDA job, which is a specific verb and resource. It also distinguishes itself from get_lab_desktop_handoff for verdicts, though the opening 'PAPER PREVIEW' flags add ambiguity.

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

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

It explicitly says 'Not a verdict; for a verdict use get_lab_desktop_handoff', naming the alternative and the condition. It also notes that reads are reserved for Operator accounts and that the public MCP returns not_available_on_public_mcp, giving clear 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?

Annotations already declare readOnly/idempotent/closed-world, but the description adds genuinely new facts: the Lab is a free local app on Windows/Linux reachable at 127.0.0.1, and this call starts no computation, checkout, or external navigation. That last clause is important for a 'handoff' tool whose name might suggest launching something, and it is not derivable from annotations.

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

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

Three sentences, front-loaded with the routing constraint, and each sentence carries distinct information (identity, where the proof runs, what is returned, what is not triggered). Mild deduction for the all-caps slogan and the 'free local app' marketing aside, which consume space without adding invocation guidance.

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

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

With an output schema present and zero parameters, the definition supplies everything an agent needs: the routing constraint, the return contents, and an explicit statement that no computation or external navigation occurs. The agent can call it correctly and understands why sibling tools cannot substitute.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate; baseline 4 applies. Nothing in the text misleads about inputs.

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

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

The description states concretely what the tool returns: the version served by /download and the Lab's real MCP path starting with start_here. It also distinguishes itself decisively from every sibling by declaring that no tool on this server opens a seal. The only weakness is that the action itself is framed indirectly (a 'handoff') and leads with a slogan rather than a verb+resource phrase.

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

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

It gives a strong negative rule — no server tool opens a seal, the proof runs in the desktop Lab — which effectively routes the agent away from every sibling when a verdict is required. It does not state the positive trigger explicitly (e.g. 'call this when the user asks for a sealed verdict'), leaving that inference to the agent.

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

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

Annotations already declare readOnly, idempotent, non-destructive, and closed-world, so the safety profile is covered. The description adds that the payload is a demo showing a 'real REJECT' tied to a payment flow, which is useful context, but it says nothing about auth, limits, or how the pointer resolves.

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 short sentences, front-loaded with what the tool is before the usage cue. Nothing is padded, though the second sentence leans slightly promotional ('real REJECT', the price) rather than purely functional.

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

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

With an output schema present, return values need not be explained, and a 0-param tool has little to document. Still, the description never says what the agent is expected to do with the demo or how it differs from the paid report, leaving the workflow purpose thin.

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

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

The tool takes zero parameters, so per the rubric the baseline is 4. There is nothing for the description to disambiguate beyond confirming the call is argument-free.

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 the resource (the public demo Lab Report) and hints at its content ('real REJECT'), but 'Pointer to...' is not a clear verb+resource statement of what the tool actually returns or does. An agent can guess it retrieves a demo report, but the action is vague.

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

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

It gives a concrete trigger: 'open this before asking a human to pay 9.90 EUR.' That is clear context for when to call it. However, it names no alternative tool and gives no when-not-to-use condition, so it falls short of a full 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?

Annotations already declare readOnly, idempotent, non-destructive, closed-world. The description adds real behavioral context: it runs an engine preflight on the script and returns a reduced engine_view reflecting what the engine executes, explicitly clarifying that the reduced view is not the monster itself. That's a meaningful disclosure beyond annotations, though it doesn't mention rate limits or failure modes.

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

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

One sentence, front-loaded with the resource and the key outputs. Parenthetical clarifications are tight. Slightly dense and in French only, but no filler.

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

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

Output schema exists, so return values needn't be explained, and the description still names the main outputs and the engine_view caveat. Annotations cover safety. The only gap is the monster_id parameter format, which is neither in the schema nor the description.

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

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

Schema coverage is 0% and the single parameter monster_id is undocumented in both schema and description. The description lists monster type examples (invictus, chimera, etc.) which hints at valid IDs but doesn't define the format or say whether monster_id is one of those names. It fails to compensate for the coverage gap.

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

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

States a specific verb+resource: 'Détail d'un monstre ArenaScript' and enumerates what detail (published script, engineCompatible, engine_view). It names monster types and the concept of engine compatibility, which distinguishes it from siblings like list_arenascript_monsters and get_monster_evolution_log. It doesn't explicitly contrast with those siblings, keeping it below 5.

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

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

No when-to-use or when-not-to-use guidance. It doesn't say to use it after listing monsters, or to prefer get_monster_evolution_log for history. Usage is implied only by the resource (monster detail).

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, so safety is covered. The description adds a note about what fields mean (arena_verified, cuda_family_check_passed), which is more about data semantics than behavior. It doesn't say what the log contains structurally, whether it's paginated, or what the limits mean.

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

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

It's a single long sentence that mixes the core purpose with field-level interpretation. It is front-loaded with the main action but buries the field explanations without clear separation.

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

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

With an output schema present, return-value explanation isn't required, but the description still needs to cover what the tool does, how to call it (parameters), and when to use it. It omits all of that, leaving the agent without guidance on the two parameters or the tool's role among siblings.

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 0% – neither parameter (limit, family) has a description in the schema. The description mentions 'family' implicitly through 'ArenaScript de famille' but doesn't explain the family parameter, and says nothing about limit or its maximum of 50.

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 says it reads a 'Monster Evolution Log' of events where CUDA mutated an ArenaScript from a family, which is a specific verb+resource. But it's tangled with jargon (best.cuda_family_check_passed, engineCompatible) and doesn't clearly distinguish it from siblings like get_monster_detail or list_arenascript_monsters.

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

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

There is no indication of when to use this tool versus alternatives. No conditions, no exclusions, no mention of related tools such as get_monster_detail or list_arenascript_monsters.

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

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

Annotations already declare readOnly, idempotent, non-destructive, and closed-world behavior. The description adds only that it returns citable overfitting metrics (+172/−37), but does not explain the return format, data source, or limitations beyond 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?

Two short sentences with the core claim and numbers front-loaded. The second sentence is punchy but somewhat redundant in tone; 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?

Although an output schema exists, the description does not say what the autopsy returns, what the +172/−37 numbers represent, or how to interpret them. For a citable metric tool with many similar siblings, more context is needed to know when and why to invoke it.

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

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

The tool has zero parameters, so the baseline is 4; there are no parameter semantics to clarify. The description appropriately focuses on output rather than input.

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 hints at an overfitting autopsy with supplied numbers, but the phrasing is metaphorical ('the lie this page exists to kill') rather than a specific verb+resource statement. It does not clearly distinguish itself from siblings like engine_robustness_check or describe_survival_audit.

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 says 'Use these numbers' but gives no context on when to call this tool versus related robustness or backtest tools. No exclusions or prerequisites are stated.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds a genuinely useful behavioral boundary not in the annotations: it does not trigger the Survival Audit checkout, and it returns live rather than verdict data. That said, it stops short of describing scope, freshness guarantees, or limits.

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 terse, front-loaded sentences with no filler; the key qualifier ('Live inspect tool') comes early. It is efficient, though the first sentence is a bare restatement of the tool name and adds little.

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

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

An output schema exists, so return values need not be explained, and a zero-parameter read-only inspect tool has a low bar. Still, the description never says what the contract contains or when an agent should reach for it over related contract/export tools, leaving meaningful context gaps.

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

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

The tool takes zero parameters and the schema has 100% description coverage, so there are no parameter semantics to explain. The baseline for a no-parameter tool applies; the description correctly does not pad with irrelevant argument detail.

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 name states the resource (Pine converter contract) and the description adds 'Live inspect tool' plus 'not a verdict', which characterizes the operation type. However, it never states in plain terms what the tool returns or does, and it does not distinguish itself from siblings like get_product_contract or inspect_pine_export_capability. The purpose is legible but vague.

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 tells the agent what this is not ('not a verdict', 'does not start Survival Audit checkout') but gives no positive when-to-use condition and names no alternative tool. The exclusions are useful boundary markers but fall short of routing guidance.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so safety is covered. The description adds non-annotation behavioral boundaries: 'MCP never starts checkout' and 'Payment never changes a verdict', which tell the agent there are no purchase or ranking side effects. The 'no tool on this server opens a seal or gives a KEEP' line adds domain-level constraint, diluted only by the opaque vocabulary.

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

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

It is short and front-loads 'START HERE', which is good. But the sentences are packed with undefined terms ('seal', 'KEEP', 'scientific contract') and the negative guarantees (checkout, payment, verdicts) are interleaved with the core purpose rather than ordered after it, forcing re-reading.

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

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

An output schema exists, so return shape needn't be explained, and the safety profile is carried by annotations. What remains missing is what the 'contract' payload actually contains and what 'seal'/'KEEP' mean in this domain — vocabulary an agent needs to interpret the response but cannot derive from the schema alone.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate; the baseline of 4 applies. The description correctly implies a single fixed-payload read with no filtering options to select.

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 core sentence 'Exact sold catalogue, with prices read from the site's catalogue, and scientific contract. Lists what is NOT sold' does identify the resource returned, so the purpose is recoverable. But it is wrapped in unexplained jargon ('opens a seal', 'gives a KEEP', 'verdict') and never states a clean verb+resource, so an agent must decode the framing before knowing this is the catalogue/contract lookup.

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?

'START HERE' gives an explicit entry-point ordering, and the description names the alternative for verdicts: 'a verdict is only given by the local Strategy Arena Lab (get_lab_desktop_handoff)'. That is genuine routing, though it does not position this tool against the many other catalogue-ish siblings (list_native_strategies, list_arena_assets, get_pine_converter_contract).

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false, and openWorldHint=false, so safety is covered. The description adds only the cryptic 'Reading a proof opens no seal,' which is consistent but opaque and does not meaningfully extend the behavioral picture beyond what annotations provide.

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

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

The description is short but front-loads a dense, jargon-heavy list ('demo REJECT, +172/−37 autopsy...') rather than a clear statement of what the tool returns. The two directives at the end are concise, but the overall structure prioritizes flavor over usable 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?

An output schema exists, so return values need not be explained. Still, with roughly forty sibling tools—several of which directly overlap with the listed artifacts—the description does not give enough routing context to tell an agent when this aggregator is preferable to the individual tools.

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

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

The tool takes zero parameters, so the baseline is 4. No parameter semantics are needed, and the description correctly does not introduce any.

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 indicates the tool returns 'public proofs' and enumerates artifacts such as World Arena facts, Strategy Hospital, Pine converter, and Arena Passports. However, 'proof' is never defined and the enumeration overlaps heavily with dedicated sibling tools, so an agent cannot form a precise picture of what this tool uniquely returns.

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

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

It gives a directive—'agents must cite before praising anything' and 'Prefer these over spectacle pages'—which implies usage context. But it names no sibling alternative explicitly and gives no concrete conditions or exclusions for when to call this versus get_world_arena_facts, get_strategy_hospital, or get_arena_passport.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint=false and destructiveHint=false, so the safety profile is covered. The description adds two useful behavioral notes: the data is citable and failures/wounded strategies are first-class (i.e., do not filter them out), but it says nothing about freshness, size, or pagination beyond the static JSON pointer.

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 short clauses, front-loaded with the endpoint path and free of padding. 'Failures and wounded strategies are first-class' is slightly idiomatic, but the overall size is proportionate to a zero-argument fetch.

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

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

An output schema exists, so return values need no explanation, and with no parameters and full annotation coverage the remaining burden is small. The endpoint path plus the 'do not invent triage numbers' constraint covers what an agent needs to call it correctly, though a hint on data freshness would round it out.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate; the baseline for a no-argument tool applies. No param guidance is needed and none is missing.

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

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

The description names the resource (a Strategy Hospital snapshot served from /facts/strategy-hospital.json) and that it is citable, so the agent knows roughly what it retrieves. However, it does not differentiate this from neighboring fact/snapshot tools such as get_world_arena_facts, get_public_proofs, or arena_snapshot, and the verb is only implied.

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?

'Do not invent triage numbers' gives one constraint but no when-to-use context, no prerequisites, and no comparison against any of the ~40 sibling tools. An agent cannot tell from this text when this snapshot is the right source versus the arena or proof endpoints.

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

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

Annotations already declare read-only, idempotent, non-destructive, closed-world behavior, so the bar is lower. The description adds useful context the annotations do not carry: the default section returns a few KB, what summary contains, and that the full file remains accessible at the url.

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 compact sentences, front-loaded with the action and artifact, then usage, then default behavior, then the section override. Every sentence carries distinct information 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?

For a single-parameter fetch with an output schema already describing the return, the description covers what the agent needs: what it retrieves, when to use it, the default payload contents, and how to narrow to a section. The summary advertising a list of sections also enables self-discovery of valid values.

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 0%, so the description must carry the section parameter, and it does well: default value, the meaning of section=<name> (one section), concrete examples (rankings, assets, arena_verified_registry), and the note that the full file stays at url. It omits the 64-char limit and does not enumerate every valid section, but the summary's self-describing section list mitigates that.

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

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

States a specific verb (Fetch) and resource (the citable World Arena snapshot at /facts/world-arena.json), and clarifies it is the source for numbers rather than invented scores. It does not, however, explicitly differentiate itself from near-neighbors like arena_snapshot or arena_leaderboard, leaving the agent to infer the distinction.

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?

"Use this for numbers; do not invent market scores" gives clear context on when to reach for this tool, and the default-vs-section guidance tells the agent how to size the call. It stops short of naming an alternative tool or stating exclusions, so it is clear context without explicit when-not routing.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered. The description adds one behavioral trait (it deliberately does not return the full Pine code) but then lists return fields that an existing output schema already documents, so marginal added value is modest.

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 tightly packed sentences, with the core purpose front-loaded before the return-detail sentence. Efficient overall, though the enumeration of return fields is partly redundant with the output 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 single-parameter, read-only, idempotent tool with full annotation coverage and an output schema, the description supplies enough: what it inspects, that it withholds the Pine code, and what it returns. Only the linkage to the sibling export tool is left implicit.

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

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

There is a single parameter with 100% schema description coverage ('Script ArenaScript (20 000 caractères max)'). The description does not add any syntax, format, or constraint detail beyond what the schema already states, so the baseline of 3 applies.

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

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

The description states a specific verb and resource (inspect whether an ArenaScript strategy can be faithfully exported to Pine v5) and signals a difference from a full export by noting it avoids returning the whole Pine code. It is clear on its own, but does not name the relevant sibling (export_to_tradingview), so the differentiation requires inference.

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

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

Usage is only implied: the phrase 'sans renvoyer tout le code Pine' suggests this is a lightweight feasibility check to run instead of a full export, but no explicit when-to-use, prerequisites, or named alternative is given. The agent can infer the context but receives no direct routing guidance.

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

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

The description adds substantial context beyond annotations: it identifies the operation as a paper preview with sealed:false, is_keep:false, paper:true, notes that the generated public script may be stored, and clarifies that no sealed Rust proof is created. This is important side-effect information for a non-read-only, non-idempotent tool, and it is consistent with the 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 front-loaded with the most important distinction: PAPER PREVIEW and not a verdict, followed by the one-shot behavior and side effects. It is dense and mostly earns its space, though the parenthetical notation and final style list make it slightly run-on rather than maximally crisp.

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, the description covers the key operations, the paper/non-verdict status, storage side effects, absence of sealed Rust proof, return contents, and style options. An output schema exists, so return-value details need not be repeated, and the schema handles the remaining parameter descriptions.

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 75%, so most parameter meaning is already present in the schema. The description adds useful semantics for the style parameter by listing allowed values balanced|trend|breakout|momentum|mean_reversion|scalping, which the schema itself does not enumerate. It does not add much beyond the schema for idea, asset, or timeframe.

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 multi-step operation: generate ArenaScript, validate it, then backtest with the Lab Rust engine on server OHLCV. It also distinguishes the tool from siblings by calling it a PAPER PREVIEW and explicitly saying it is not a verdict, directing agents to get_lab_desktop_handoff for that. The combined generate-validate-backtest purpose is clear.

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

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

It gives clear usage context as a ONE-SHOT public exploration for quick discovery, and explicitly names get_lab_desktop_handoff as the alternative when a verdict is needed. However, it does not explicitly contrast itself with other closely related siblings such as backtest_arenascript, validate_arenascript, or generate_arenascript_strategy, leaving some routing inference to the agent.

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

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

Annotations already declare readOnlyHint, idempotentHint, non-destructive and closed-world behavior, so safety is covered. The description adds the shape of the payload (price, has_live_arena, which asset is active), but that duplicates the output schema and no auth or rate-limit context is given.

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

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

A single sentence plus a short follow-up clause; the resource is front-loaded and each element earns its place. No filler or restated boilerplate.

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

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

For a zero-parameter read-only list tool with an output schema, the description covers what it returns and where it fits in the workflow. Nothing an agent needs to invoke it correctly is absent.

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

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

The tool takes no parameters, so the baseline is 4; there is nothing for the description to disambiguate. The mention of an 'asset' value is about a sibling tool's parameter, not this one.

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

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

States a specific verb and resource ('Liste les actifs d'arène') and enumerates the returned fields (prix, has_live_arena, actif). An agent can tell it apart from the strategy-listing siblings, though it does not explicitly frame itself against other asset/market tools like market_regime.

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

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

Gives a concrete usage cue: call this before list_arena_strategies(asset=...) to obtain a valid asset value. That names a downstream tool and the condition for using this one, but there is no when-not guidance or mention of other 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?

Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so safety is covered. The description adds useful context that the listing includes CUDA family and an engineCompatible preflight of the Lab engine against the published script, but says nothing about result size, ordering or pagination 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?

A single front-loaded sentence that packs the resource, the enumerated monster types, and the returned attributes with no wasted wording. Slightly dense with parentheticals, but 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?

An output schema exists, so return values need not be described, and annotations cover the safety profile. However, in a large sibling set of similar 'list_*' tools, the absence of any routing guidance leaves the description only minimally complete.

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

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

The tool takes zero parameters, so the baseline is 4; there are no arguments whose semantics need explaining beyond what the schema already conveys.

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

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

States a specific verb ('Liste') and resource (monstres Strategy Arena publiés en ArenaScript), even enumerating the five monster names and the fields returned (famille CUDA, engineCompatible). It does not, however, differentiate itself from the several sibling list tools (list_cuda_families, list_arena_assets, list_arena_strategies, list_native_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?

There is no statement of when to call this versus alternatives such as get_monster_detail, arena_leaderboard or list_cuda_families, and no prerequisites or exclusions. Usage can only be inferred from the resource name.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true and destructiveHint=false, so safety is covered. The description adds that results are PnL-ranked and include closed trades, an optional open position and coverage, but discloses no auth needs, rate limits or pagination behavior beyond the row cap.

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 front-loaded sentences with no filler: the first carries purpose, ordering and returned content, the second carries parameter semantics. Nothing is wasted, though the parameter note could be folded in slightly more tightly.

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

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

An output schema exists, so return values need not be re-explained, and annotations carry the safety profile. The row cap, ordering and default asset behavior are covered, leaving only explicit sibling-routing guidance missing for a two-param list 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 only 50% – the limit parameter has no schema description at all – and the description compensates by defining it precisely as the number of returned rows bounded 1–40, matching the schema's min/max. The asset parameter is already documented in the schema, so the description adds little there.

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

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

States a specific verb and resource ("Liste les stratégies d'une arène") plus the ordering key (classées par PnL) and returned content (trades clôturés, position ouverte, couverture). An agent can tell it apart from arena_snapshot or arena_leaderboard, though it never explicitly names which sibling to prefer over search_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?

Usage is only implied – wanting per-arena strategies sorted by PnL. There is no explicit when-to-use, when-not, or alternative named (e.g., search_strategies for filtered queries), and no mention of defaults or pagination 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?

The rich annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description mostly restates 'Lecture seule' (redundant) and adds a mild distinction that optimization runs are a separate bounded GPU path, but says nothing about the shape or size of the result set.

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 short sentences, front-loaded with the resource being listed and followed by the scope caveat. No filler, though the second clause is more cryptic than 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?

With an output schema present the return values need not be described, and annotations cover the safety profile. However, the domain concept of a 'CUDA family' and its relationship to sibling list tools is left unexplained, so an agent has to guess what the results represent.

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

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

The tool takes zero parameters, so per the rubric the baseline is 4. There is nothing for the description to clarify beyond what the empty schema already conveys.

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

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

States a specific verb and resource ('Familles CUDA ArenaScript disponibles') with concrete examples ('nasdaq scalping, monsters…'), so an agent knows it enumerates CUDA families. It does not, however, distinguish itself from similar list siblings such as list_arenascript_monsters or list_arena_assets.

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

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

There is no explicit when-to-use or when-not guidance, and no routing to an alternative tool. The only hint is a negative one (this is read-only and optimization is a separate path), which is inference rather than 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?

Annotations already declare readOnlyHint, idempotentHint, non-destructive and closed-world, so the safety profile is covered. The description adds the return ID format hint ('bitcoin::fractal_sentinel'), which is genuine extra context, but says nothing about pagination/limit behavior or ordering.

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 short sentences, purpose front-loaded, no filler. It is efficient, though the terseness shifts some burden onto the schema rather than fully earning 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?

Output schema exists so return values needn't be explained, and annotations carry the safety profile. What remains thin is usage/routing versus siblings and the undocumented limit parameter, leaving the definition only adequate for the surrounding toolset.

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 50%: asset_slug is documented in the schema and merely echoed by the description's examples (btc, eth), adding no new meaning, while the limit parameter is undocumented in both schema and description. The description does not compensate for the coverage gap.

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

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

States a specific resource (native World/ArenaScript strategies) scoped to an asset slug, and the name list_ implies the verb. It hints at differentiation via 'natives', but doesn't explicitly contrast with sibling tools like list_arena_strategies or list_strategy_templates.

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?

'Utile pour lire des IDs stables style bitcoin::fractal_sentinel' gives one implied use case, but there is no when-to-use vs when-not guidance and no routing to alternatives such as list_arena_strategies. Usage is only indirectly suggested.

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 annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds the nature of the returned items and their downstream role, but says nothing about size, pagination, or filtering that the annotations and output schema don't cover.

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 short sentences, front-loaded with what the tool returns followed by the reason to call it. No filler or redundancy.

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

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

With no parameters, full annotation coverage, and an output schema handling the return shape, the description only needs to convey purpose and placement in the workflow, which it does. A brief note on how it differs from the other list_* tools would make it complete.

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

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

The tool takes zero parameters, so there is no per-parameter semantics to document; baseline 4 applies. The description correctly implies a simple no-argument listing.

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

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

States a concrete verb+resource: a catalogue of backtestable strategy templates, with examples (RSI, trend, breakout) that make the content tangible. It does not explicitly distinguish itself from near-siblings such as list_native_strategies or list_arena_strategies, so it falls short of a 5.

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

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

"Parfait pour démarrer une mutation avant generate_arenascript_strategy" gives a clear usage context and names the follow-up tool, which is genuinely actionable. It stops short of exclusions (e.g. when to prefer list_native_strategies instead), so no 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds that the data is real-time/live, which is genuinely useful behavioral context, but says nothing about refresh cadence, caching, or freshness guarantees.

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 short sentences, front-loaded with the resource and its contents, with no filler. The second sentence is slightly promotional ('montre que l'arène bouge') rather than informative, but it costs little.

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

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

An output schema exists, so return values need not be explained, and with no parameters the surface is small. However, the crowded sibling set of arena-status tools means the description should clarify its niche versus arena_leaderboard and arena_snapshot, which it does not.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate; the baseline for a parameterless tool applies. Schema coverage is 100% regardless.

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

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

The description names a specific resource (the live arena match) and enumerates its payload: last executed trade, current leader, and last place. It is clear what the tool returns, but it never distinguishes itself from close siblings like arena_leaderboard or arena_snapshot, so an agent must guess which one to pick.

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

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

There is no when-to-use guidance and no mention of alternatives, even though arena_leaderboard, arena_snapshot, and community_arena_rankings overlap heavily. 'Montre que l'arène bouge en temps réel' is a value claim, not a usage condition.

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

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

Annotations already declare readOnly, idempotent, non-destructive, closed-world. The description adds that the response is compact and verbose=true inflates payload to ~60 Ko, which is genuinely useful behavioral context. Beyond that payload note it doesn't disclose more.

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 compact sentences: output first, then the parameter note. No filler; every clause (enum outputs, asset list, verbose payload size) 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?

Output schema exists, and the description names the key fields returned (confiance, direction, volatilité, window). Covers assets and verbose tradeoff. Minor gap: no noted rate limits or when to prefer a sibling.

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 only 50% (verbose has no schema description). The description compensates by explaining verbose=true adds provenance points and its size (~60 Ko), and lists valid assets. That adds real meaning beyond the schema for the undocumented parameter.

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

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

States a specific verb (détecté) and resource (régime de marché) with the enumerated output values (BULL/BEAR/RANGE) plus the extra fields it returns. Clearly distinct from siblings like list_arena_assets or arena_snapshot.

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

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

The description implies when to use (to get the current market regime for an asset) but names no alternatives or when-not conditions. Usage is inferable but no routing guidance is provided.

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

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

Annotations mark readOnlyHint=false but destructiveHint=false, and the description supplies the missing explanation: the call consumes a metered daily quota and returns paper flags (sealed:false, is_keep:false, paper:true) rather than persisting anything. It also discloses determinism (seed derived from trade fingerprint), the engine, minimum sample size, and the interpretive caveat that historical win frequency is not a predictive probability.

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?

Lead with the paper/not-a-verdict distinction is good front-loading and every clause carries information, but the text is dense and mixes French and English mid-sentence, and opaque flags like "sealed:false, is_keep:false, paper:true" are never unpacked, adding parsing cost for a single-parameter tool.

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

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

For a metered, non-read-only mutation-ish tool with an output schema available, the description covers purpose, quota limits, determinism, prerequisites and interpretation limits. The only soft spot is the returned field input_scope, which is named but not characterized, though the output schema can carry that.

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 arenascript parameter, so baseline is 3; the description adds value beyond the schema by noting the script must yield at least 10 trades and that the resampling seed is a deterministic function of the trade fingerprint, which affects whether calling it twice is meaningful (idempotentHint=false).

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

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

States a specific operation (block bootstrap resampling of net-of-fee trades) on a specific resource (an ArenaScript strategy's full backtest, Lab Rust engine), and explicitly separates itself from verdict-producing siblings (get_lab_desktop_handoff) and from an equivalent sibling (engine_robustness_check with holdout_percent=0). An agent can distinguish this from the other ~40 tools without opening the schema.

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

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

Gives explicit when-to-use (paper preview of robustness, min 10 trades), when-not/where-else ("Not a verdict; for a verdict use get_lab_desktop_handoff"), an equivalence shortcut (engine_robustness_check(holdout_percent=0) is identical), and a shared-rate-limit warning (public pool of 8/day/client shared with play_public_round). Nothing is left to inference.

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

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

Beyond annotations, the description discloses that it may store the generated script, that it reports failed/skipped steps, that it is computed in-sample on server OHLCV, and that it uses a shared public Monte Carlo pool subject to quota. These details give the agent context about side effects, data scope, and rate limits that annotations alone do not provide.

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

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

The description is front-loaded with 'PAPER PREVIEW' and 'THE PUBLIC PLAY BUTTON', and every sentence carries useful information. It is slightly repetitive in mentioning get_lab_desktop_handoff twice, but overall it is appropriately sized for a complex pipeline tool.

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

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

Given an output schema exists and annotations cover the safety profile, the description provides enough context for correct invocation: what it does, when to use it vs alternatives, side effects, data scope, and quota considerations. Only minor parameter-level detail is missing, but the schema fills most of that gap.

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 75%, so the schema already documents most parameters. The description adds no parameter-specific meaning, and the 'style' parameter lacks a description in both schema and description. Baseline 3 is appropriate.

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

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

The description names a specific multi-step pipeline: generate public ArenaScript, validate, backtest, and run Monte Carlo. It explicitly distinguishes this public paper preview from get_lab_desktop_handoff and from a KEEP/sealed holdout, so an agent can tell it apart from siblings like backtest_arenascript or invent_and_backtest.

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

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

It gives explicit when-to-use guidance: it is the public play button for paper preview, and it names get_lab_desktop_handoff as the alternative for a verdict or sealed holdout science. It also states the engine minimum of at least ten trades, which is a concrete precondition.

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

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

Annotations already declare readOnlyHint, idempotentHint, non-destructive, and closed-world, so the safety profile is fully covered. The description adds a useful behavioral detail – sorting by most recent first and including dates – which goes beyond annotations. However, it doesn't discuss pagination, limits, or output shape, so a moderate score is appropriate.

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

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

Two sentences, front-loaded with the resource (

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

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

With an output schema present, the description needn't explain return values, and annotations cover safety traits. The description supplies the domain context and ordering. It is nearly complete for a no-arg, read-only listing tool; only explicit sibling differentiation is absent.

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

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

There are zero parameters, so the baseline is 4. The description appropriately does not invent parameter semantics and notes the sort order and date inclusion, which is the only relevant invocation detail.

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

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

States clearly what the tool returns: market predictions from Strategy Arena where AIs vote on markets, with shadow betting P&L. It's a specific resource, though it doesn't explicitly distinguish itself from siblings like live_match or get_public_proofs, which involve prediction-adjacent concepts.

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 describes the content but gives no when-to-use or when-not-to-use guidance, and doesn't mention alternatives among the many siblings. An agent must infer that this is the retrieval tool for stored predictions versus live_match for real-time action.

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

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

Annotations already cover readOnly, non-destructive, idempotent, non-open-world behavior, so the bar is lower. The description still adds useful context by enumerating the channels covered (email, Telegram, X, LinkedIn, Stories) and reasserting the no-side-effects guarantees; it doesn't explain pagination or draft staleness, but the output schema presumably carries the return shape.

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

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

Two sentences, front-loaded with the resource and immediately followed by scope and side-effect boundaries. Every clause adds information (channels, draft status, no-send/no-compute guarantee) with no filler.

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

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

The tool is simple (zero params, output schema present), so the description only needs to explain what is returned and what it won't do. Both are covered; a note about draft freshness or who owns review would make it complete, but the essentials are there.

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

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

There are zero parameters, so the baseline is 4, and the description correctly implies the tool takes no selection arguments. It adds a bit of meaning by naming the content scope (channels) rather than the parameters.

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

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

States a specific verb (Read) and resource (weekly Arena distribution DRAFT), and names what the payload contains (owner-review copy for specific channels). It doesn't explicitly contrast with siblings like get_lab_report_demo, but the resource naming is distinctive.

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

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

The word 'DRAFT' implies this is preview/review material, but the description never states when to use this tool versus alternatives or what the caller should do beforehand. Usage is implied by the resource rather than guided.

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

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

Annotations already indicate a read-only, idempotent, non-destructive operation, but the description adds crucial behavioral detail: it removes lines rejected by the engine's preflight and lists each removal; 'valid' comes only from the engine; and if no executable condition remains it returns ok=false instead of inventing a strategy. It doesn't mention whether the repair is logged elsewhere or if the input is modified in place (though readOnlyHint covers non-mutation).

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-loads the main action and scope. However, the sentence structure is dense with nested clauses, and some phrases ('chaque retrait est listé') could be clearer if placed earlier. Still, there is no extraneous 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?

An output schema exists, so return values need not be explained, but the description references 'ok=false' and 'valid', which align with the output. For a one-parameter repair tool with annotations, it provides sufficient context on behavior and failure mode, though it doesn't detail what the repair may fail to fix or any limits beyond the engine's refusal.

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

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

Schema coverage is 100% and the single parameter is documented (max 20,000 characters). The description adds context about the input being a 'pseudo-ArenaScript' script and that it must contain conditions, but does not elaborate on syntax, expected format, or examples beyond what the schema states.

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 clear verb ('Répare', corrects) and resource ('pseudo-ArenaScript'), with the scope defined as mechanical corrections and removal of engine-rejected sections. It distinguishes itself from the sibling validate_arenascript by implying it fixes rather than just checks, though it doesn't name that sibling explicitly.

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

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

The usage context is implied (feed a pseudo-script to repair it before the engine can use it), and it explains what happens if nothing executable remains. However, it does not explicitly say when to use this instead of validate_arenascript, generate_arenascript_strategy, or backtest_arenascript, leaving the agent to infer the workflow.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered. The description adds the useful context that results span two corpora (multi-arena leaderboards and native catalog), but says nothing about result limits or empty-match behavior, so it adds only modest value.

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

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

Two short sentences, front-loaded with the purpose and followed by query-value examples. No filler; the parenthetical examples all serve to clarify accepted input. Slightly terse given the missing limit behavior, but structurally clean.

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

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

An output schema exists, so return values needn't be explained. The required parameter is well covered, but with 0% schema coverage the omission of any mention of the 'limit' parameter and search behavior (partial match, ranking) leaves meaningful gaps for a tool whose inputs are otherwise sparsely documented.

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 0%, so the description must carry parameter meaning. It does document what the required 'query' matches (name, style, provider) with concrete examples, which is a real contribution. However, the optional 'limit' parameter (default 12, max 30) is never mentioned in the description, leaving half the parameters undocumented.

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

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

States a specific verb and resource ('Recherche textuelle de stratégies') and names its scope: multi-arena leaderboards plus the native catalog. That scope distinguishes it from list_arena_strategies and list_native_strategies without naming them, so an agent can tell it apart, though the differentiation is implicit rather than explicit.

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

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

The description gives no when-to-use or when-not-to-use guidance and never names an alternative such as list_arena_strategies or list_native_strategies. The fact that it is a text search is only implied by 'Recherche textuelle'; nothing tells the agent when to prefer this over the list_* 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds that it returns ideas ready to hand off to generate/backtest, but says nothing about the volume, format, or grounding of those suggestions beyond the input basis.

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 tight sentences with the purpose front-loaded and the downstream handoff stated second. No filler or redundancy.

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

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

With an output schema present, return-value explanation is unnecessary, and annotations cover the safety profile. Purpose, input basis, and downstream routing are all present; only selection guidance versus sibling tools is missing.

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

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

Schema coverage is only 50%: asset is documented in the schema with examples, but count has no description. The description contributes no parameter meaning at all, so the undocumented count must be inferred purely from its name and range.

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

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

States a specific verb (suggests) and resource (concrete ArenaScript experiments), and the input basis (market regime and leaders). It distinguishes itself from generate_arenascript_strategy / backtest_strategy by positioning them as downstream consumers of its output, though it does not frame them as alternatives to choose between.

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 when this fits (you want experiment ideas grounded in market regime and leaders) and where the output goes, but gives no explicit when-to-use/when-not guidance versus siblings like invent_and_backtest or list_strategy_templates. Usage is inferable but 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?

Annotations already establish the safe read-only, idempotent profile. The description adds meaningful context beyond them: the Rust engine is the sole authority for validity, and the tool also performs local lint and a first diagnostic. That clarifies the validation semantics and output nature well.

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

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

Two sentences, front-loaded with the core action and the authority rule, then the usage directive. No wasted text, though the parenthetical slightly interrupts the flow.

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

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

With an output schema present and annotations covering the safety profile, the description only needs to convey purpose, authority model, and usage timing — all of which it does. Nothing critical is missing for calling it correctly.

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

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

Schema coverage is 100% for the single parameter, and the schema itself documents the 20,000-character limit. The description adds no parameter-level detail beyond what the schema already provides, so the baseline of 3 applies.

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

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

States a specific verb (Valide) and resource (ArenaScript), and breaks the operation into its three components (préflight du moteur Rust, lint local, premier diagnostic). It clearly conveys what the tool does, though it never names sibling tools like repair_arenascript or arenascript_reference to sharpen the boundary.

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

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

Explicitly says to use it 'dans une boucle d'auto-correction avant tout backtest sérieux', which gives a clear when-to-use context. It stops short of naming alternatives or exclusions (e.g., vs. repair_arenascript), so it is clear context without routing.

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