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?

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered. The description adds what the reference contains (canonical grammar, guardrails, the generate→validate→backtest→CUDA/Monte Carlo→Arena Verified loop), which is useful content context but not deep behavioral disclosure.

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

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

Two sentences, front-loaded with what the tool is followed by when to use it and what it returns. No filler; every clause earns its place.

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

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

With an output schema present and annotations covering the safety profile, the description only needs to establish purpose and timing, which it does. It gives purpose, invocation timing, and content scope, leaving little an agent would need to infer.

Complex tools with many parameters or behaviors need more documentation. 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 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 resource (a short reference of the ArenaScript protocol) and audience (external AIs), which clearly separates it from action siblings like generate_arenascript_strategy, validate_arenascript, and backtest_arenascript. It does not explicitly name those siblings, but the reference-vs-action distinction is unambiguous.

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

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

Gives explicit timing guidance: 'À appeler avant de générer une stratégie' (call before generating a strategy), which routes the agent to use this before the generation workflow. No when-not conditions or named alternatives, but the context is clear.

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

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

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 the safety profile (readOnly=false, destructive=false, idempotent=false, openWorld=false), so the description is free to add real context — and it does: in-sample only, no holdout, and 'Renvoie les mêmes métriques, limites et quota' sets expectations about results and quota consumption. The lack of any warning about in-sample overfitting risk is a minor gap.

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

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

Three short sentences, front-loaded with the alias relationship and then the execution scope, followed by the submission caveat. Dense but every clause carries information; 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?

With an output schema present, the return values need not be enumerated, and the description still gestures at them (mêmes métriques, limites, quota layer). Safety and privacy constraints are covered. The only thing an agent might still want is explicit guidance on choosing this over backtest_strategy.

Complex tools with many parameters or behaviors need more documentation. 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 the schema already carries its meaning and the 20,000-char limit. The description adds a submission constraint (public scripts only) but no syntax or format detail beyond the schema, so the baseline 3 holds.

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

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

Specifies the verb/resource (backtest, an ArenaScript) and immediately pins the relationship to a sibling: 'Alias de backtest_strategy'. It then scopes the execution precisely (moteur Rust du Lab, bougies OHLCV du serveur, timeframe déclaré, échantillon, sans holdout), which is enough to tell it apart from invent_and_backtest and the other backtest-adjacent siblings.

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

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

The alias statement tells the agent this is interchangeable with backtest_strategy, and 'Le script public peut être conservé; ne pas soumettre de stratégie privée' gives a concrete do/don't for submission. It does not, however, state when to prefer this over backtest_strategy or invent_and_backtest, so the routing is implied rather than explicit.

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

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

Provides rich context beyond annotations: execution model (10 bps per side, close execution, no slippage), sample vs. holdout distinction, explicit failure behavior, daily quota of 60, and a privacy warning that the server may retain the submitted script. This is exactly the kind of behavioral detail an agent needs.

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

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

The description is dense but front-loaded with the core purpose. It is a single long sentence with multiple clauses; a bullet list would improve readability, but every clause earns its place.

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

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

Given no output schema is mentioned in the context (it says has output schema, but description needn't explain return values extensively), the description covers execution rules, quota, privacy, and failure modes. It is complete enough for an agent to call correctly.

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

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

Schema coverage is 100% and the single parameter is fully described there. The description adds no further syntax details, so 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?

States a specific verb (backtest) and resource (ArenaScript strategy via Rust Lab engine), and distinguishes itself from siblings like backtest_arenascript by naming the exact engine and rules. The scope is unambiguous.

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

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

Clearly says when the engine refuses or is unavailable it fails explicitly, and warns not to submit private strategies. However, it does not explicitly name alternatives or say when to use this vs. backtest_arenascript or invent_and_backtest.

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

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

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 generic readOnly/openWorld/idempotent/destructive flags, so the description adds real value: the duplicate-script refusal, the generate+backtest pipeline, and the integrity guarantee that payment cannot alter a verdict. It omits cost, latency, and whether generated scripts persist, which a non-readonly compute tool should ideally state.

Agents need to know what a tool does to the 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 statements with no filler; behavior and constraints come before caveats. The fragments 'Not a KEEP' and 'Payment never changes a verdict' are terse to the point of being jargon, which costs a little clarity.

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

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

An output schema exists, so return values need not be described, and the pipeline, refusal case, and integrity stance are covered. The gap is parameter-level guidance for a 5-parameter tool with a third of its schema undescribed.

Complex tools with many parameters or behaviors need more documentation. 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%, and the parameters that are undocumented (style_a, style_b) get no explanation in the description either. 'Two public ideas' loosely maps to idea_a/idea_b, but nothing clarifies what a 'style' is, what asset defaults mean, or the relationship between style and idea text.

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

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

Clear verb+resource (compare two public ideas) plus the core mechanism: generate and backtest each, return a compact comparison. It does not name the obvious sibling compare_arenas or explain how 'public ideas' differ from arenas, 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?

It gives one useful exclusion ('refuses two ideas that produce the same script') and a trust caveat, but never says when to pick this over compare_arenas, backtest_strategy, or invent_and_backtest. Usage context is implied rather than 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 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 are present but sparse (all false), so the description carries substantial extra value: it discloses the fee model, deterministic seeding, the return payload (script/plan/data fingerprints), a query quota (8 per day per client, separate public pool), and explicit failure behavior when the engine is unavailable. This meaningfully exceeds what the annotations convey, though it does not explain runtime or latency expectations.

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

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

It is a single dense paragraph that front-loads the core operations before parenthetical detail, and every sentence carries information. The heavy nesting of parentheticals and mixed concerns (engine, fees, quota, output, failure) make it slightly harder to scan, but there is little pure filler.

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

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

For a 2-parameter tool with an output schema, the description covers the engine, determinism, fees, quota, and failure modes, so an agent has most of what it needs to invoke it correctly. The absence of explicit contrast with the closest sibling tools (backtest_arenascript, monte_carlo) is the main remaining 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 coverage is only 50% (holdout_percent has no schema description), and the description compensates by defining its bounds and the special case of 0 (no holdout, Monte Carlo degrades to monte_carlo). The only schema-ignored param is holdout_percent itself, so the description adds real meaning beyond the structured fields.

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

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

The description names the specific composite operation (backtest + chronological holdout + Monte Carlo) and the exact engine that performs it, with concrete execution details (same Rust binary, 10 bps per side, deterministic seed from trade fingerprint). It partially distinguishes itself from siblings by referencing monte_carlo, but does not explicitly contrast with backtest_arenascript or backtest_strategy, leaving the agent to infer the difference.

Agents choose between tools based on descriptions. A clear purpose with a specific verb 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 holdout_percent semantics (10-40, or 0 meaning Monte Carlo becomes equivalent to monte_carlo) hint at when the tool is appropriate, but there is no explicit 'use this instead of X when...' routing against the many related backtest/monte_carlo siblings. The closing 'Descriptif, pas un KEEP' is context-specific and not a genuine usage guideline.

Agents often have multiple tools that could apply. Explicit usage 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, so safety is fully covered. The description adds that it is a one-shot aggregate returning many sections, which is useful context beyond the annotations, but it does not describe size/cost or what the output schema returns. Moderate added 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 compact sentences, front-loaded with the 'START HERE' directive. The feature list is dense but every element is informative; slight looseness from the long noun pile.

Shorter descriptions cost fewer tokens and are easier for agents to parse. 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 does not need to explain return values; it still tells the agent this is a broad orientation call to be used before strategy work. Missing only explicit mention of which sibling to use for deeper drill-down.

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

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

Schema coverage is 100% with a default of BTC and an example list of assets; the description does not add syntax, but the schema fully documents the single optional parameter. Baseline 3 plus the implicit guidance that the asset scopes the orientation view.

Input schemas describe structure but not intent. Descriptions should explain 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 is a bundle of nouns (status, tops, regime, monsters, recipes) rather than a clear verb+resource statement. It conveys that this is an orientation/overview tool but the scope is a list of features rather than a single purpose, making it hard to distinguish from arena_snapshot or get_world_arena_facts by purpose alone.

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

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

Explicitly says 'START HERE for agents' and 'Call this before inventing strategies', which is a clear ordering directive. It does not name an alternative or exclusion, but the sequencing instruction is unusually strong for this dimension.

Agents often have multiple tools that could apply. Explicit usage 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 give a generic safety profile (readOnly=false, destructive=false, idempotent=false, openWorld=false). The description goes well beyond that: it discloses engine semantics (Lab engine, 0.1%/side fees, no slippage), that conversion may be partial with unconverted lines listed, the partner-attribution policy (never emits a TradingView aff_id), and the meaning of verification_status. It stops short of stating any server-side side effects of the call.

Agents need to know what a tool does to the 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 and deliverable, and most sentences carry useful content. It is dense and mixes French and English, and the aff_id policy sentence is somewhat tangential, but nothing is pure 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 two-parameter conversion tool with an output schema (which itself covers return values), the description supplies the engine assumptions, conversion-fidelity caveat, and the optional job_id semantics needed to call it correctly. Only explicit sibling/alternative routing 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% (only arenascript is described), but the description compensates by explaining job_id in depth: it is optional, only cited in the header if the job's script matches the exported script, and is an optimization result rather than a validation. This adds real meaning beyond the bare string/maxLength 64 schema entry.

Input schemas describe structure but not intent. Descriptions should explain 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 (export an ArenaScript strategy to Pine Script v5 ready to paste into TradingView) plus the exact deliverable (code, EXACT/PARTIAL conversion status, setup/review URLs). The purpose is unambiguous, though it never names a sibling such as inspect_pine_export_capability or get_pine_converter_contract to differentiate itself.

Agents choose between tools based on descriptions. A clear purpose with a specific verb 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 implied by the purpose (call it when you want a Pine export), but there is no explicit when-to-use, when-not-to-use, or prerequisite guidance (e.g., whether to check export capability first). The job_id conditional is a parameter rule, not tool-selection guidance.

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

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

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 cover the read-only, idempotent, non-destructive profile. The description adds real behavioral context beyond that: an authorization constraint (Operator accounts only), the exact sentinel response on the public MCP, and a caveat that a CUDA result is not Lab-engine verification. This is meaningful disclosure the structured fields 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?

Two compact sentences with the core purpose front-loaded and the caveat last. The parenthetical access note is dense but earns its place; nothing is wasted.

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

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

An output schema exists, so return values need not be explained, and the description still flags the one non-obvious response value. Access restrictions and the CUDA-vs-Lab caveat are covered; only the job_id acquisition path 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?

Schema description coverage is 0% and the single job_id parameter is undocumented in the schema. The description implies the parameter identifies an ArenaScript CUDA job but adds no format, length, or provenance details (e.g., where a job_id comes from), so it only partially compensates 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 and resource: it returns the status of an ArenaScript CUDA job, matching the tool name exactly. It does not explicitly differentiate itself from siblings like list_arenascript_monsters or backtest_arenascript, but the resource scope is unambiguous.

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

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

The description discloses who may use it (Operator accounts) and what happens on the public MCP (not_available_on_public_mcp), which is access guidance rather than when-to-use guidance. It never names an alternative tool or specifies the conditions under which an agent should call this instead of another status/backtest 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 declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds genuinely useful context beyond that: it clarifies the tool initiates no computation/checkout/navigation (consistent with openWorldHint=false) and notes the pricing nuance ('Download is free; new supervised execution is not a free begin'). It does not, however, describe what the handoff returns, which matters given the output schema.

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

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

The leading sentence is appropriately front-loaded, but the middle 'Diagnostics, capabilities, predeclared design, lock, Operator-gated execution, proof verification, then local Passport' sequence reads as an internal jargon dump that consumes space without conveying actionable meaning. The final sentence is tight and earns its place.

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

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

With an output schema present, return values need not be explained, and the 0-param signature is trivial. The description covers what the tool is and explicitly what it does not do, but it omits any usage context relative to the large sibling set and leaves the enumerated workflow opaque. Adequate but with clear 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 schema coverage is 100%, so there is nothing for the description to compensate for. Baseline 4 applies; no parameter claims are made or needed.

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

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

The first sentence names a specific resource (the Lab desktop download) and frames the tool as a 'handoff', which does distinguish it from the arena/strategy siblings. However, the middle sentence ('Diagnostics, capabilities, predeclared design, lock, Operator-gated execution, proof verification, then local Passport') is an opaque jargon list that obscures what the tool actually returns or does. An agent gets the general domain but not a crisp statement of purpose.

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

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

The description gives no when-to-use or when-not-to-use guidance and names no alternative sibling. It only asserts a negative ('starts no computation, checkout or external navigation'), which implies a safe read but does not tell the agent when this tool is the right choice over get_product_contract, get_lab_report_demo, 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 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 establish read-only, idempotent, non-destructive behavior, and the description adds genuinely new context: MCP never starts checkout and payment never changes a verdict, which bounds what this tool can do. It also advertises that unsold items are enumerated, a useful behavioral trait beyond 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?

"START HERE" is front-loaded and the pricing list is compact, with each clause carrying information. The telegraphic price fragments are slightly dense, but nothing is redundant.

Shorter descriptions cost fewer tokens and are easier for agents to parse. 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 details are not required in the description. Coverage of pricing, sold/unsold scope, and the no-checkout guarantee is sufficient for a zero-parameter read tool, with only the sibling routing 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?

The tool takes no parameters, so the schema has nothing to document and the baseline of 4 applies. The description correctly adds no parameter detail because none is needed.

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

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

The description concretely states it returns the exact sold catalogue, the scientific contract, and pricing tiers, and it explicitly notes it lists what is NOT sold. That is specific content an agent can identify, though it stops short of naming siblings like get_pine_converter_contract or describe_survival_audit as distinct alternatives.

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

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

"START HERE" gives a clear sequencing instruction that tells the agent to call this before other catalogue-related tools. It does not spell out exclusions or name a sibling to use instead for narrower questions, so it falls short of full when/when-not guidance.

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

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

Annotations already declare read-only, idempotent, non-destructive, and closed-world behavior. The description adds no behavioral traits beyond that—it does not say what the proofs look like, whether they are citations or content, or how citation should be performed. Its added value is mostly usage preference, not behavioral disclosure.

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

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

Two sentences: the first front-loads the purpose and enumerates the proofs, the second states a preference. Dense but not bloated, and no sentence is wasted. The list is somewhat run-on, but it is appropriately sized for a zero-parameter reference 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?

With rich annotations, no parameters, and an output schema, the description need not explain return values. It lists the canonical proofs and gives a preference over spectacle pages, which is enough for an agent to select the tool. The only gap is that it does not clarify how this aggregate relates to the sibling tools that fetch individual proofs.

Complex tools with many parameters or behaviors need more documentation. 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 parameter semantics baseline is 4 per the rubric. The description lists artifacts but has no parameters to annotate, and the empty schema already covers the input shape.

Input schemas describe structure but not intent. Descriptions should explain 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—'Public proofs'—and enumerates concrete artifacts (demo REJECT, autopsy, World Arena facts JSON, Strategy Hospital, Pine converter, APUB passports). It says what the tool is for, but does not explicitly state a verb like 'retrieves' or clarify how it relates to the individual sibling tools that expose the same artifacts. Distinguishing from those siblings is left implicit.

Agents choose between tools based on descriptions. A clear purpose with a specific verb 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 only usage guidance is 'Prefer these over spectacle pages,' which gives a relative preference but no explicit conditions for choosing this tool over the many sibling tools that return the same proofs (e.g., get_strategy_hospital, get_world_arena_facts). The implied context—'agents must cite'—is present, but when and when-not guidance is thin.

Agents often have multiple tools that could apply. Explicit usage 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?

Annotations only give the coarse safety profile (readOnlyHint=false, non-idempotent, non-destructive); the description supplies the crucial specifics: the generated script may be stored/persisted and no sealed Rust proof is created. It also states the return payload. It does not mention latency, cost, or limits, so it is useful but not exhaustive.

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

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

Four tight sentences, front-loaded with the pipeline and outcome, each carrying distinct information (operation, persistence caveat, proof limitation, style values). Slightly telegraphic phrasing ('script + validation + metrics') 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?

For a 4-parameter one-shot pipeline whose output schema exists, the description covers the operation, side effects, and the style vocabulary an agent needs. Remaining gaps are operational (runtime, rate limits, whether re-running overwrites a stored script), which are minor against the available structured data.

Complex tools with many parameters or behaviors need more documentation. 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% and the 'style' parameter has no enum and no schema description; the description supplies the full accepted set (balanced|trend|breakout|momentum|mean_reversion|scalping), which is genuine added value. It adds nothing for idea/asset/timeframe, but those already carry schema descriptions.

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

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

Names a specific compound operation (generate ArenaScript, validate, then backtest on server OHLCV) and its scope as 'ONE-SHOT public exploration'. It doesn't explicitly name the sibling pipeline tools (generate_arenascript_strategy, validate_arenascript, backtest_arenascript) that it collapses, but the 'ONE-SHOT' framing lets an agent infer it is the fused alternative.

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

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

'so an AI can discover quickly' implies this is the fast exploratory path versus the individual step tools, and 'public' implies a non-production context. However, no explicit when-to-use/when-not comparison to the sibling backtest or generate tools is stated, leaving the choice largely 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 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?

Goes well beyond the annotations: discloses a deterministic seed derived from the trade fingerprint, a minimum of 10 trades, the returned artifacts (equity percentiles, input_scope, quota), a public rate limit of 8/day per client shared with play_public_round, and an explicit epistemic caveat that historical win frequency is not predictive. This quota-consumption context also explains why readOnlyHint=false despite the operation being a simulation.

Agents need to know what a tool does to the 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 dense sentences that front-load the core operation (block bootstrap resampling) before secondary details like quota and the sibling equivalence. Every sentence carries substantive information, though the phrasing is packed and could be slightly easier to parse.

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

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

An output schema exists, so return-value explanation is not strictly required, yet the description still names the percentiles/input_scope/quota returned. Combined with the trade-count precondition, determinism note, rate limit, and sibling equivalence, nothing an agent needs to call it correctly is missing.

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

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

Schema coverage is 100% for the single arenascript parameter, so the schema already carries the definition (20000-char limit). The description adds the 'minimum 10 trades' precondition, which is useful, but no format or syntax detail beyond the schema. Baseline 3 is appropriate when the schema does the heavy lifting.

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

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

States a specific verb+resource: block bootstrap resampling of net-of-fee trades from a full backtest. It names the exact engine (Lab Rust engine), the minimum trade count, and explicitly equates itself to a named sibling (engine_robustness_check with holdout_percent=0), so an agent can distinguish it without opening any schema.

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

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

It gives clear context for use (post-backtest resampling of an ArenaScript strategy) and names an alternative, engine_robustness_check(holdout_percent=0), stating the two produce exactly the same Monte Carlo. However, it never states when to prefer this tool over that sibling or when not to use it, leaving the choice 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 cover the safety profile (readOnlyHint=false, destructiveHint=false, idempotentHint=false), and the description adds real context beyond them: it 'may store the generated script', 'reports failed/skipped steps', runs on server OHLCV in-sample, and consumes the shared public Monte Carlo pool with quota implications. These are meaningful behavioral traits 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?

Dense but front-loaded: the pipeline and the minimum-trades gate come early, and the alternative routing sentence closes it cleanly. The opening 'THE PUBLIC PLAY BUTTON' is the one non-earning phrase.

Shorter descriptions cost fewer tokens and are easier for agents to parse. 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; the description still covers execution context, the engine, and partial-failure behavior. Given a 4-param, no-nested-object tool, it is close to complete, with only parameter nuance left unaddressed.

Complex tools with many parameters or behaviors need more documentation. 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 idea, asset and timeframe. The description adds no parameter-level meaning (defaults, formats, style semantics), so it does not compensate for the partially undocumented 'style' parameter. 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 concrete pipeline (generate ArenaScript, validate, backtest, run Monte Carlo) and marks its scope as 'public' vs the sealed-holdout path, so an agent can tell it apart from get_lab_desktop_handoff. It is less sharply differentiated from close siblings like invent_and_backtest or the standalone generate/backtest/monte_carlo tools, and the 'THE PUBLIC PLAY BUTTON' framing is marketing rather than descriptive.

Agents choose between tools based on descriptions. A clear purpose with a specific verb 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 precondition ('when there are at least ten trades') and an explicit when-not with a named alternative ('For sealed holdout science, use get_lab_desktop_handoff'). It stops short of routing between this all-in-one pipeline and the individual generate/backtest/Monte Carlo 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, 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.