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

Annotations already declare readOnly/idempotent/non-destructive, and 'Runs no market' reinforces that this is a pure build step. It adds real behavioral context beyond annotations: the returned artifacts (resolved document, fingerprint, warnings) and the day-counting rule that can cause a scenario to be refused.

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

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

Three sentences, front-loaded with purpose then the two input modes then the day-count caveat and the no-market disclaimer. Dense but every clause carries information; slightly packed for a single paragraph.

Shorter descriptions cost fewer tokens and are easier for agents to parse. 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 detailed, yet the description still notes what comes back. Combined with the day-count caveat and sibling routing, an agent has what it needs to invoke this correctly.

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

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

Schema coverage is 100%, so baseline is 3, but the description adds meaning beyond the schema: the day-0 offset rule ('an event at day 50 needs at least 51 days') and the purpose of the steps/shocks/transmission split. This compensates usefully for what the schema alone 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 ('Author a custom scenario') plus the distinctive capability of previewing the resolution before running it. It explicitly distinguishes itself from run_stress_scenario by naming it as the downstream consumer.

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

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

Explains the two authoring modes (steps as a macro PATH, or shocks/transmission as INTERVENTIONS) and that the returned document is passed to run_stress_scenario. It does not explicitly say when to prefer steps over shocks, 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 cover the safety profile (readOnly, idempotent, non-destructive, closed-world), and the description adds meaningful context beyond them: 'Runs no market,' the returned `universe` document contract that every run tool consumes, the roster fingerprint, the envelope warning, and the fact that sector concentration is a 'named envelope gap' reported in the result.

Agents need to know what a tool does to the 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 construction modes, then the return contract and the 'no market' caveat. No filler sentences; every clause carries information an agent needs.

Shorter descriptions cost fewer tokens and are easier for agents to parse. 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 correctly avoids detailing return values while still pointing to the `universe` key and the fingerprint/warning fields. Usage, behavior, and the downstream contract are all covered for a 5-parameter builder tool.

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

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

Schema description coverage is 100% and each parameter is richly documented in the schema itself, including the mutual-exclusion rule ('When given, size, seed and sectors are ignored'). The description only restates the same two-mode grouping at a high level, 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 and resource ('Build a roster of companies and preview it') and immediately names the two construction modes: generated from size/seed (optionally sector-concentrated) or from explicit instruments. This distinguishes it from the neighboring build_scenario / run_stress_scenario tools, which consume a universe rather than construct one.

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

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

Gives an explicit trigger: 'Use it when the default random roster will not do, for example to test one sector or your own companies.' It also clarifies the tool runs no market, so an agent knows not to expect simulation output. It stops short of naming a sibling alternative, so it earns 4 rather than 5.

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

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

Annotations already declare readOnly/idempotent/non-destructive/no open world, so safety is covered. The description adds non-structured facts: it returns ok or a refusal naming the measurement behind it, and that it runs no market so it answers immediately — latency and outcome shape the annotations do not convey.

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

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

Three sentences, front-loaded with the action and the temporal constraint (BEFORE running it), then the trigger conditions, then the return/latency payoff. 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, return values need not be spelled out, yet the description still summarizes the outcome. Purpose, timing, triggers and latency are all covered, leaving nothing an agent needs before calling.

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

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

Schema coverage is 100%, so baseline is 3. The description nonetheless ties parameters to decision conditions — horizon longer than a year, particular statistics, sector-concentrated roster, effect size — which adds interpretive meaning over the field-by-field schema 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?

Names a specific action (check) against a specific resource (the simulator's realism envelope) and states the scope: whether a question falls inside the range realism was measured for. This is clearly distinguishable from siblings like validate_strategy or describe_simulator.

Agents choose between tools based on descriptions. A clear purpose with a specific verb 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 triggering conditions — horizon longer than a year, particular statistics, sector-concentrated roster, scenario effect size — and the sequencing rule (BEFORE running it). It does not name an alternative tool or state when-not to use it, so it falls short of a full routing instruction.

Agents often have multiple tools that could apply. Explicit usage 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, so 'changes nothing' largely restates structured data; however it converts that into actionable polling advice ('safe to poll') and describes the two-phase return (status first, full result once finished), which is real behavioral context 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?

Three sentences, no filler: origin and return behavior first, listing mode next, safety last. Every sentence earns its place.

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

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

With a full output schema, complete parameter docs, and read-only annotations, the description only needs to cover origin, modes, and polling safety – and it does all three. Nothing an agent needs to invoke this 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 description coverage is 100% and the schema itself already documents the optional job_id and the omit-to-list behavior, so the description's restatement adds little. Baseline 3 applies since the schema carries the parameter semantics.

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

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

Specific verb+resource ('check a background job'), plus the origin relationship to start_job and both operating modes (status by job_id, list-all when omitted). An agent can distinguish this from start_job and the direct tools without opening a 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?

States the triggering context clearly: it is for jobs created by start_job, and omitting job_id switches to the listing mode. It implies the alternative is calling the direct tool, but never says when to poll versus when to call the direct tool, so no explicit exclusion.

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

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

Annotations already declare readOnlyHint/idempotentHint/destructiveHint=false, so safety is covered; the description goes further by disclosing that it "takes no arguments, runs no market and returns the same text on every call," which is genuine behavioral context (deterministic output, no side effects on simulator state). It stops short of saying anything about the size/format of the returned text, which is acceptable given the output schema exists.

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

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

The scope enumeration is front-loaded in the first sentence, followed by the single usage instruction and the no-arguments/determinism caveat. Every clause carries information; nothing is padded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. 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-argument documentation tool with an output schema present, the description covers scope, invocation order, and determinism, which is everything needed to select and call it. Return-value structure is correctly left to the output schema rather than duplicated.

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

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

Zero parameters, so the baseline is 4; the description's statement that it "takes no arguments" is consistent with the empty schema and removes any doubt about needing 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?

States a specific verb (describe) and an enumerated scope: what the simulator is, what its realism checks certify, what it cannot do, tool caps, and run duration. This is unmistakably distinct from every sibling (validate_strategy, run_stress_scenario, etc.), which are action tools rather than meta-documentation.

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

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

"Call it first in a session, before any other tool" is an explicit, unambiguous ordering instruction that tells the agent exactly when this tool applies. No alternative needs to be named because it is a prerequisite orientation call rather than a competing 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 readOnly, idempotent, non-destructive, closed-world, and the description adds substantial behavioral context on top: determinism ('the same arguments give the same scores'), runtime ('a few seconds'), horizon caps and job escalation, the 8-strategy cap, taken baseline names, and the warning that null max_leverage lets trading size alone win.

Agents need to know what a tool does to the 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 first sentence carries the core action and outputs immediately, then alternatives and constraints follow in a logical order. A few facts (days 1-60, roster 2-120, the strategy example) duplicate the schema, which costs a little density.

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

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

With an output schema present the description need not explain return values, and it covers the remaining gaps an agent needs: scope (one seed), determinism, runtime, limits, escalation path, spec format, and when to prefer a sibling. Nothing required for a correct call is missing.

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

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

Schema coverage is 100%, so the schema already documents every parameter; the description's value-add is the concrete strategy-spec example, the enumeration of signal kinds, the note that baseline names are reserved, and the 2-120 roster bound. These mostly reinforce rather than extend schema text, so it sits just above the baseline of 3.

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

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

States a specific verb (run/evaluate) and resource (strategies on one simulated market) plus the exact scoring outputs (return, P&L, cost in bps, turnover, errors). It explicitly says this is one market/one seed and contrasts itself with rank_strategies, so an agent can separate it from siblings 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?

Gives explicit when-to-use ('the right first look'), the reason not to trust the output alone ('ONE seed, so use rank_strategies before believing an ordering'), and the pre-flight alternative ('validate_strategy checks one without running it'). It also routes long horizons to start_job and bounds days to 1-60 for direct calls.

Agents often have multiple tools that could apply. Explicit usage 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=true, idempotent=true, closed-world, so the safety profile is covered; the description nonetheless adds real behavioral context beyond them: it builds and runs its own market capped at 60 days, is deterministic, and every node can be replayed with numbers measured by re-running the day. The 'read-only' restatement is redundant with annotations, which keeps it just short of a 5.

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

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

Front-loads what the tool produces before the routing guidance, and every sentence carries information (output shape, sibling boundary, depth scope, build cost, determinism). Slightly dense in the middle clause, 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?

With an output schema present, return-value documentation is unnecessary, and the description covers the remaining agent-facing concerns: cost of building its own market, the 60-day horizon, determinism, and the tree/render distinction. Only the seed/universe interaction is left entirely to the schema.

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

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

Schema description coverage is 100%, so the parameters are already documented, including ticker's omit-behavior and universe's replacement semantics. The description adds the meaning of depth in terms of the `render` text specifically ('sets how much of the tree the render text shows'), but does not meaningfully elaborate the seed/universe parameters. 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?

Names a specific verb and resource ('Trace one name's price move on one day down to the random draws'), and describes the shape of the answer (a tree: log move, factors, draw addresses). It explicitly distinguishes itself from the sibling explain_price_move, so the 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?

States the alternative and the exact condition that selects it: 'Use explain_price_move to see which factors moved prices across the roster; use this for one name when you need to know which draws moved those factors.' Both the when and the not-when are present, plus the granularity difference (roster vs one 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 read-only, idempotent, non-destructive, closed-world. The description adds genuinely useful context beyond them: the factors are 'the simulator's own bookkeeping,' they are 'not the whole price move,' and on the default preset fair_value_shift removes news/noise from the mispricing. It also notes the 60-day market build. Return format is left to 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?

Front-loads the core purpose in the first sentence, then layers caveats and sibling routing. Dense and mostly earns its length, though the fair-value/mispricing explanation is slightly winding and could be tightened.

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

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

For an 8-parameter factor-decomposition tool with an output schema, the description covers the interpretation caveats, sibling routing, no-ticker behavior, and read-only/self-contained nature. Nothing an agent needs to call it correctly is missing.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds meaning beyond the schema by explaining the ticker/top_n interplay ('Without a ticker it returns the top_n largest moves') and the fair-value decomposition caveat that shapes interpretation of the returned factors.

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

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

States a precise verb and resource: break one day's move into 11 factor contributions that sum to the change in the mispricing. It also names the sibling it is not (explain) and clarifies the scope (mispricing, log gap between model price and fair value). An agent can distinguish it from explain 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 routes: 'use it to ask which factors moved prices; use explain to trace one name's move down to the random draws behind it.' It also documents the no-ticker behavior (returns top_n largest moves) and the fair_value_shift caveat, giving clear selection conditions.

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

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

Annotations already establish readOnly/idempotent/non-destructive, and the description adds real domain context beyond them: it runs no market (no cost/side effects) and warns that four targets have effects too small to observe over a hundred days. These are non-obvious traits an agent would not infer from the schema or 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?

Front-loaded with what it lists, then usage guidance, then the behavioral caveats. Three dense sentences with no filler; each clause carries distinct 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?

Output schema exists, so return format needn't be restated, and the description still summarizes the return content (targets and what each was measured to reach). Nothing an agent needs to invoke it correctly is missing.

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

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

Tool takes zero parameters and schema coverage is 100%, so baseline is 4. The description's 'Takes no arguments' simply confirms the empty schema rather than adding parameter meaning.

Input schemas describe structure but not intent. Descriptions should explain 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 (List) and three concrete resources (shipped stress scenarios, scenario constructors, intervention targets) plus what each target was measured to reach. This clearly distinguishes it from siblings build_scenario and run_stress_scenario, which the description names directly.

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

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

Explicitly instructs to read before build_scenario or run_stress_scenario and gives the reason (first_event_day sets the shortest useful run; four targets have imperceptible effects). Names the alternatives and the condition that selects this tool over them.

Agents often have multiple tools that could apply. Explicit usage 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), so the bar is lower; the description adds genuine extra context: cost ('about one evaluate_strategies call per seed'), the 2-12 seed range, the days cap, and 'Deterministic.' It stops short of describing what happens on a failed entrant or partial-run 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?

Front-loads the action, then the rationale, then the cost and limits. Dense but every clause carries information; the run-on construction of the limits sentence is the only mild inefficiency.

Shorter descriptions cost fewer tokens and are easier for agents to parse. 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 read-only tool with a full output schema and complete parameter docs, the description supplies the missing operational context (cost per seed, seed/day ceilings, determinism, sequencing after evaluate_strategies). Nothing an agent needs to invoke it correctly appears to be missing.

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

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

Schema description coverage is 100%, so the schema already documents every parameter, and the description mostly restates those bounds (seeds default six, days 1-60/252, at most 8 strategies). Baseline 3 is appropriate; it adds little beyond what the schema carries.

Input schemas describe structure but not intent. Descriptions should explain 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 ('Score strategies across MANY seeds ... rank them with a paired sign test') and explicitly positions itself against the baseline agents and the sibling evaluate_strategies. An agent can distinguish it from evaluate_strategies and start_job 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?

Gives an explicit trigger ('Use it after evaluate_strategies, because one seed's ordering is often luck') and names the escalation path for longer horizons ('up to 252 through start_job'). This is when-to-use plus alternatives, not just implied context.

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

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

Annotations already declare readOnly/idempotent/non-destructive, and the description adds real behavioral context beyond them: determinism, the hard refusal rule for out-of-window scenarios, the fork mechanic where both arms trade shared days identically, and the note that a concentrated roster is a named envelope gap surfaced in the result.

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

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

Information-dense and front-loaded with purpose and the two-arm comparison, but it restates material already in the schema (the scenario-source enumeration and the 1-to-60/252 day limits appear in both places), which costs a little efficiency without hurting comprehension.

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

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

With 10 parameters, an output schema, and full schema descriptions, the description supplies exactly the missing operational layer: valid scenario sources, refusal conditions, fork applicability, horizon routing to start_job, and determinism. Nothing an agent needs to call this 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?

Schema coverage is 100%, so the baseline is 3; the description still adds meaning, clarifying that fork_day only applies to intervention-based scenarios (a macro path or constructor pins the macro from day 0), that peak_day is constructor-only, and that days is capped at 60 here versus 252 via start_job.

Input schemas describe structure but not intent. Descriptions should explain 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 ('Run strategies through a macro stress scenario') and immediately pins the distinctive design: every run sits beside an unshocked twin market and the two are compared. This separates it from sibling evaluation tools like evaluate_strategies and rank_strategies, which lack the shock/control contrast.

Agents choose between tools based on descriptions. A clear purpose with a specific verb 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 enumerates the three accepted scenario sources (shipped document via list_scenarios, constructor vix_shock/rate_ramp, or build_scenario output), states the refusal condition when all events fall after the run, explains when to pass fork_day, and routes the 252-day horizon to start_job. It even sets the interpretive frame: 'detect a response, not to forecast its size.'

Agents often have multiple tools that could apply. Explicit usage 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 only the safety profile (non-read-only, non-destructive, non-idempotent, closed-world). The description adds substantial behavior the annotations cannot convey: immediate job-id return, pre-flight argument validation, a run-time estimate in the response, a concurrency cap of 2 simultaneous jobs, retention of only the last 32, and that state lives in server memory only. This is exactly the added value the dimension rewards.

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

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

Four sentences, front-loaded with the primary action and the job-id return, then constraints, then the polling pointer. No filler and nothing repeated from the schema or annotations.

Shorter descriptions cost fewer tokens and are easier for agents to parse. 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 still flags the job id and run-time estimate. For a long-running, resource-limited, in-memory job launcher, the concurrency limit, retention count, and polling instruction cover everything an agent needs to call and follow up correctly.

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

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

Schema coverage is 100%, so the baseline is 3. The description still adds meaning: 'days may go to 252' clarifies the range limit that the schema does not encode, and it confirms validation semantics ('an unknown argument or a wrong type is refused before the job starts') for the pass-through arguments object.

Input schemas describe structure but not intent. Descriptions should explain 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 (start) and resource (a background job running one of three named tools), and enumerates exactly which tools it wraps. An agent can distinguish it from evaluate_strategies/rank_strategies/run_stress_scenario directly 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?

Gives an explicit when-to-use rule ('the ONLY way to run to the certified 252-day horizon') and the reason the direct call is insufficient (capped at 60 days so it can answer inside a conversation). It also names the follow-up tool ('Poll with check_job'), leaving no routing inference to the agent.

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

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

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description goes further by disclosing failure behavior (grammar errors name the offending field) and success behavior (normalised spec plus fingerprint), and it asserts no market is run. Return format is partly carried by the output schema, so 4 rather than 5.

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

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

Front-loads the core action and the 'without running it' constraint in the first clause, then handles alternatives and behavior in two efficient sentences. The inline example is duplicated from the schema, a minor redundancy, but each sentence otherwise earns its place.

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

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

For a single-parameter validation tool with an output schema and rich annotations, the description covers purpose, alternatives, failure and success behavior, and the no-side-effect guarantee. Nothing an agent needs in order 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 description coverage is 100% and the single parameter is fully documented, including the optional spec_version default. The description repeats the example spec that the schema already supplies, adding no format or syntax meaning beyond it, so the baseline 3 applies.

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

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

States a specific verb pair (parse and fingerprint) and resource (one strategy spec), plus the crucial scope qualifier 'WITHOUT running it.' It explicitly differentiates from the sibling tools evaluate_strategies and rank_strategies, so an agent can select 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?

Gives an explicit when-to-use: 'iterate on a spec cheaply before evaluate_strategies or rank_strategies.' It names the alternative tools and the condition (cheap iteration) that selects this one, leaving little to inference.

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