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 readOnlyHint, idempotentHint, non-destructive, and closed-world. Beyond that, the description discloses behavior the annotations don't: the outcome shape (ok or a refusal naming the measurement), that a named preset returns that preset's measured record, and that it 'Runs no market, so it answers at once' — a latency/no-side-effect guarantee. Useful added context.

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

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

Four sentences, front-loaded with the core purpose before the usage triggers and return behavior. Dense but each sentence carries substantive information; the enumeration of trigger conditions is long but earns its space as routing guidance.

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

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

Output schema exists, so return values needn't be fully specified, and the description still summarizes them (ok/refusal/measured record). Given the tool's complexity around presets and certified ranges, the description supplies enough for correct invocation, though it could say more about how partial refusals across multiple flagged dimensions combine.

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 does the heavy lifting and baseline is 3. The description goes slightly further by tying the parameters to decision triggers (e.g., a horizon 'longer than a year' against the 252-day certified range, leaning on statistics or effect size), which helps an agent map its situation onto the arguments rather than just reading field types.

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 ('Check whether a question falls inside the range the simulator's realism was measured for') and frames it as a pre-flight gate ('BEFORE running it'), which cleanly separates it from execution siblings like run_stress_scenario and evaluate_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?

It gives concrete trigger conditions ('horizon longer than a year', 'particular statistics', 'sector-concentrated roster', 'size of a scenario's effect', 'a preset other than the default'), which is strong when-to-use guidance. It does not name a specific alternative tool to prefer or an explicit when-not-to-use case, so it falls short of the top band.

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 largely pre-covered; the description nonetheless reinforces this with 'Changes nothing, so it is safe to poll'. It additionally discloses the result-form equivalence ('the full result in the same form the direct tool returns'), which is useful context an agent cannot get from annotations. No auth or rate-limit detail 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?

Three short sentences, each load-bearing: purpose, return behavior, fallback mode, and safety. The most important facts (what it checks, safe to poll) are front-loaded 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?

For a single-optional-parameter read tool with an output schema, nothing essential is missing. It covers the create/check relationship, the empty-argument behavior, and the safety profile, and it correctly avoids re-specifying return values at length.

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 already documents omission behavior, so the baseline is 3. The description adds provenance the schema does not ('an id exactly as start_job returned it') and restates the list-all fallback, giving slightly more than the structured field alone.

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') with explicit lineage to the sibling tool that creates the job ('started by start_job'). It also states what is returned (status, then full result) so an agent can distinguish it from start_job or the synchronous tools.

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

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

States both operating modes clearly: pass an id to check one job, omit it to enumerate all held jobs. It also notes it is 'safe to poll', which tells the agent when repeated calls are appropriate. It does not explicitly name a when-not-to-use condition or a competing alternative, so it stops short of a 5.

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

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

Annotations already declare destructiveHint=true, idempotentHint=true, and openWorldHint=false, so the safety profile is partly covered. The description adds non-obvious specifics the annotations do not: the session's checkpoints are destroyed along with it, and it 'runs no market,' which meaningfully distinguishes its behavior from the simulation-oriented siblings.

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 dense sentences with the destructive consequence front-loaded and no filler. The clause 'which is what re-runs it from open_session' is slightly convoluted, keeping it just below the ideal.

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

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

Behavior, destruction scope, and side-effect profile are all covered, and an output schema exists so return-value detail is not required. The description nonetheless restates return contents, which is redundant rather than missing, and it never clarifies idempotency semantics for re-closing an already-closed session.

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 session_id parameter with 100% schema description coverage, so the schema already carries the semantics. The description adds nothing about the id's format or origin beyond what the schema states, which is the expected baseline 3 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 (close) and resource (an open session) and spells out the effect: freeing memory, returning final portfolios and orders. It explicitly frames itself against the sibling open_session ('what re-runs it from open_session'), so an agent can place it in the session lifecycle without opening the schema.

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

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

The description makes clear this is the terminal counterpart to open_session and that the returned data is what you feed back into open_session for a re-run, which gives genuine context for when to call it. It stops short of explicit when-not guidance or naming other session siblings (session_fork, session_rewind) as alternatives, so it does not reach 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, closed-world, non-destructive, so the safety profile is covered. The description still adds real value: 'takes no arguments, runs no market and returns the same text on every call' confirms no side effects and deterministic output, which is more than the annotations alone convey. It stops short of noting response size or whether content is versioned, so not 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-loaded with the core purpose and the 'call it first' directive, which is the most decision-relevant sentence. The second sentence is a long comma-run enumeration of return contents that is dense but still scannable; it could be trimmed slightly without losing meaning.

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 technically optional, yet the description still summarizes the payload categories an agent needs to decide whether to call it. With zero params and full annotation coverage, nothing needed for correct invocation 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?

Zero parameters, so the baseline is 4. The description confirms this explicitly ('takes no arguments'), which is the only parameter-level information possible for an empty schema, but adds no further detail beyond that confirmation.

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 (describe the simulator) and enumerates exactly what the response covers: realism checks, limitations, per-tool caps, run duration, presets, certified preset, background-trader populations, and market sessions. This clearly separates it from siblings like explain, list_scenarios, or check_envelope, which return data rather than self-description.

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 ordering rule: 'Call it first, before any other tool.' Combined with the note that it takes no arguments and runs no market, an agent knows precisely when this tool is appropriate versus any other sibling.

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

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

Beyond the annotations (readOnly, idempotent, non-destructive), it discloses determinism ('the same arguments give the same scores'), the direct-call day cap (1-60) versus 252 via start_job, the 8-strategy ceiling, that baseline names are reserved, that populated mode makes strategies no longer share identical markets, and that a null leverage cap triggers a warning. This is unusually rich behavioral context.

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

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

Front-loaded with the core action and scoring outputs, then constraints and routing in descending priority. It is dense and mostly earns its sentences, though a few details (day/roster bounds, preset caveat) duplicate the schema and could be trimmed.

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: determinism, run-size limits, baseline inclusion rationale, and the certification caveat for non-default presets. An agent has everything needed to call 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 description coverage is 100%, so the schema already documents every parameter including presets, populations, roster bounds and reserved baseline names. The description mostly restates those facts (days 1-60, roster 2-120, preset certification caveat) rather than adding new parameter-level meaning, 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?

The description states a precise verb and resource ('Run strategies on one simulated market... and score each one: return, P&L, cost of its own trading in basis points, turnover and errors'), which is far more specific than the title. It also implicitly distinguishes itself from validate_strategy (checks without running) and rank_strategies (orders across seeds).

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

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

It gives explicit sequencing ('Use it first, but it runs one seed, so use rank_strategies before believing an ordering'), names validate_strategy for spec checking, and routes longer horizons to start_job. When-to-use and alternatives are both 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/destructiveHint=false, so the safety profile is covered. The description adds genuinely new behavior: it builds and runs its own market for up to 60 days, every number is measured by re-running the day, and non-default presets return a caveat with that preset's own measured record. It doesn't describe cost or runtime, hence not 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 purpose and the tree shape, then alternatives, then parameter behavior, then operational constraints. Sentences are dense and slightly overpacked (preset caveats, build window, determinism in one clause), but every sentence carries information and 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 values need not be explained, and the description still covers the pieces an agent needs: determinism, read-only nature, the 60-day build, preset certification caveats, and depth's effect on rendered output. Nothing material is missing for a 9-param, zero-required tool.

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

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

Schema coverage is 100%, so baseline is 3, but the description adds real meaning: `depth` governs only the `render` text while `tree` is always whole, `preset` determines which market gets built and whether a caveat appears, and `ticker` omission defaults to first name here vs largest moves in the sibling. That is value beyond the 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?

States a specific verb (trace), resource (one name's price move on one day), and output shape (a tree: log move, factors, draw addresses). It explicitly distinguishes itself from explain_price_move, 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?

Gives an explicit when-to-use split: explain_price_move for which factors moved prices across the roster, this tool for one name when you need to know which draws moved those factors. It also points at describe_simulator for preset records, covering the adjacent decision.

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 redundantly repeats 'read-only'), so the bar is lower. The description nevertheless adds real behavioral context: these contributions are the simulator's own bookkeeping and are NOT the whole price move, `fair_value_shift` removes the news/noise part on the default preset, fair-value moves aren't split up, and it builds/runs its own market for up to 60 days. That is substantial disclosure 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?

Purpose is front-loaded and sentences carry real information, but the prose is dense and slightly meandering ('They are the simulator's own bookkeeping, and they are not the whole price move'), and 'read-only' duplicates the annotation. Mostly earned, minor 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?

An output schema exists so return values need not be explained, and the description covers the concept (mispricing), the exclusion caveat, the top_n fallback, the preset caveat, and the 60-day build limit. For a 9-parameter analytical tool 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 description coverage is 100%, so the schema already documents day, seed, top_n, preset, ticker, and the universe fields in detail, including the preset certification caveat. The description adds only the cross-parameter behavior 'without a ticker it returns the top_n largest moves', which the schema's ticker description already states. 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 first sentence gives a specific verb (break) plus resource (one day's move per name into 12 factor contributions) and even defines the key term 'mispricing' as the log gap between model price and fair value. It explicitly contrasts the scope with the sibling `explain` (whole-cross-section vs. one name down to random draws), 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?

It states the use case directly ('Use it to ask which factors moved prices') and names the alternative tool `explain` with the distinguishing condition (trace one name's move down to the random draws). When-to-use and the alternative are both 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?

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?

Goes well beyond the annotations (readOnlyHint=false, openWorldHint=false, non-idempotent) by disclosing behavior the schema cannot: 'Opening runs no market' (no simulation work until a step), a concurrency cap of 8 sessions, that sessions live only in server memory, and a 30-minute idle TTL. These are exactly the operational traits an agent needs to avoid losing 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?

Front-loaded with purpose, then usage, then parameter glosses, then limits and TTL. It is a dense single paragraph rather than strictly unscannable, and it mostly avoids restating schema text verbatim. Minor redundancy with the already-thorough parameter descriptions keeps it from a 5.

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 description compensates with everything else: purpose, alternatives, companion-tool roles, resource limits, and lifetime semantics. Nothing an agent needs to open and manage a session 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%, so the baseline is 3, but the description still adds meaning: it glosses `agents` (null = one you drive; a spec = self-trading) and ties `preset`/`population` semantics to evaluate_strategies for consistency. It does not add much on cash/seed/steps_per_day beyond what the schema already says, keeping it just above baseline.

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

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

The first sentence gives a specific verb+resource ('Open a simulated market that this server keeps between calls') and states the return value (a session id). It explicitly distinguishes this tool from siblings like evaluate_strategies and rank_strategies, which are for spec-based scoring. An agent can tell exactly what this does without opening the schema.

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

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

Explicit when-to-use: 'Use a session when you want to decide each step yourself and see what happened before the next,' plus a named alternative for the other case ('to score a strategy you can write as a spec, use evaluate_strategies or rank_strategies instead'). It also routes the agent to the companion tools session_step/session_state/session_fork/session_rewind by describing what each is for.

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 read-only/idempotent/non-destructive, and the description adds genuinely new context: cost is roughly one evaluate_strategies call per seed, execution is isolated-only, it refuses population, it is deterministic, and non-certified presets carry a caveat. That is substantial behavioral disclosure beyond the structured fields.

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

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

Front-loaded with purpose and method, then constraints and cost, with no filler sentences. It is dense and slightly repetitive of the schema on seed/day limits, but every sentence carries real 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?

For a complex 11-parameter tool with nested strategy specs, the description covers the key operating envelope: seed count, horizon limits, cost, isolation constraint, determinism, and refusal behavior. An output schema exists, so the brief note on returns is sufficient.

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

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

Schema description coverage is 100%, so the schema already documents all 11 parameters including seeds, days, preset, and the refusal on population. The description adds only marginal meaning, mainly cross-referencing 'preset as evaluate_strategies does', so the baseline of 3 is appropriate.

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

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

States a specific verb and resource (rank strategies) plus the method (paired sign test across many seeds beside baseline agents), which is a distinct operation from evaluate_strategies. An agent can immediately tell this is the multi-seed ranking step, not a single-run evaluation.

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

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

Explicitly says to use it after evaluate_strategies and why (one seed's ordering is often luck), and it names the refused path (population) with the redirect to evaluate_strategies or run_stress_scenario. When-to-use, when-not, and alternatives are all present.

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 read-only/idempotent/non-destructive, and the description adds real behavioral context beyond them: determinism, the refusal of scenarios whose events all fall after the run, the fork_day shared-history mechanism, and populated mode breaking identical-market assumptions. It does not discuss output shape or cost, but with an output schema present and rich annotations this is solid.

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

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

Front-loaded with the core purpose, then constraints and routing. Dense but nearly every sentence carries information; a couple of clauses (scenario form enumeration, days limits) restate what the schema fields already say, which is mild redundancy rather than 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 12-parameter simulation tool with an output schema and full annotation coverage, the description supplies everything an agent needs to call it correctly: valid scenario forms, the length-versus-first-event rule, fork_day applicability, and the certification caveat on non-default presets. Return values are delegated to the output schema appropriately.

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, but the description adds relational semantics the schema does not: fork_day applies only to intervention scenarios (not macro paths or constructors), preset and population must be identical in both markets, and the scenario's three accepted forms. These cross-parameter constraints go beyond the per-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?

States a specific verb and resource (run strategies through a macro stress scenario) plus the defining scope: always beside the same market unshocked, comparing each strategy across the two arms. This distinguishes it from evaluate_strategies, which has no shock arm, and the sibling is named explicitly for parameter parity.

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 clear routing: days 1-60 here versus up to 252 through start_job, and 'Use the result to detect a response, not to forecast its size' sets the interpretation boundary. It also names list_scenarios and build_scenario as sources for the scenario argument. It stops short of an explicit 'use this instead of X when...' rule, so 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 the safety profile (readOnly=false, destructive=false, idempotent=false), and the description adds traits they cannot express: the original is unchanged, the fork counts against the 8-session cap, and it 'runs no market' (no simulation cost). It also asserts determinism — identical steps yield identical prices in both sessions — which is exactly the kind of behavioral guarantee an agent needs when deciding to branch.

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 outcome, then the use case, then the constraints. Four sentences, each carrying information, though the opening sentence is dense enough to be read twice.

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. The description covers state inheritance, side-effect profile, quota impact, and determinism — everything an agent needs to call this correctly and predict the result.

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

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

Only one parameter, and schema coverage is 100% with the schema itself documenting the format ('exactly as open_session or session_fork returned it'). The description adds no further syntax or constraint detail, 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 and resource ('Copy an open session ... into a new session with its own id') and pins the copied state ('at its present state'), which cleanly separates it from open_session and session_rewind in the sibling list.

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 clear motivating scenario — 'try two different actions from the same market and compare them' — which tells the agent when branching is the right move. It stops short of naming the alternatives (session_rewind, open_session) or stating exclusions, so it is strong context rather than full 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?

Goes well beyond the annotations (destructiveHint=true, idempotentHint=true, readOnlyHint=false) by disclosing what is destroyed (every later checkpoint), the checkpoint cadence and 64 cap, and 'Runs no market', all of which an agent needs before committing to an irreversible step.

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 core mutation and its destructive consequence, then checkpoint mechanics, alternative, and return shape – 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?

Covers destruction behavior, checkpoint limits, the fork alternative, and return format ('as session_state does') despite an output schema already existing; 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 both parameters are already documented; the description only echoes the step semantics ('one of the session's checkpoints') without adding format or validation detail beyond the schema.

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

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

States a precise verb and resource ('Put an open session back to a checkpoint... by step, and drop every checkpoint after it') with exact scope, clearly separating it from siblings like session_fork and session_state.

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

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

Explicitly names the alternative and the condition that selects it: 'To keep the later state as well, session_fork first.' It also points to session_state as the way to list checkpoints, leaving nothing 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 readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds genuine value on top: the visibility boundary ('shows what a trader could see and nothing of the simulator's own state') and the fact it runs no market, which is not captured by 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?

Front-loaded with the core action and scope, then the optional ticker behavior, then the session_id branch. The enumeration is dense but every clause conveys distinct content the agent needs, 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?

An output schema exists, so return values need no explanation, yet the description still orients the agent on what the response contains. Combined with full schema coverage and strong annotation coverage, nothing needed to call this tool 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%, so both parameters are already documented. The description restates the tickers detail fields and the omit-session_id behavior rather than adding syntax, format, or edge-case guidance beyond the schema, 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 and resource ('Read an open session without changing it') and enumerates exactly what the read returns: clock, prices, macro figures, news, portfolios, open orders, rewind checkpoints. It also implicitly distinguishes itself from session_step ('Runs no market') and references session_rewind, so an agent can place it among its siblings 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?

Gives clear operating context: read-only, no market advance, and the key branch 'Omit session_id to list the open sessions.' It does not explicitly name the alternative to reach for when you want to mutate state (e.g. session_step/session_fork), but the constraints make the intended use unambiguous.

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 a non-idempotent, non-read-only, non-destructive mutation, and the description goes well beyond them: malformed orders are refused before execution, market-refused orders are listed while the rest trade, hard caps of 360 steps and 504 days, a cost analogy to evaluate_strategies, checkpoint retention at the ending step, and deterministic replay. This is exactly the operational context an agent needs before a mutating 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?

Dense but front-loaded: the core action and its order-sending option come first, followed by limits, cost, and determinism guarantees. Every clause carries information, though the paragraph format makes it a fairly heavy read for a single-sentence-style spec.

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 the description needn't itemize return fields, and it still names the key outputs (fills, portfolios, prices, changes). Combined with caps, error handling, and determinism disclosure, nothing material is missing for a 5-parameter mutating tool.

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

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

Schema description coverage is 100%, so the schema already documents session_id, steps, days, agent, and orders. The description restates the order encoding (signed count, limit object, 'cancel') largely in parallel with the schema rather than adding new per-parameter meaning. Baseline 3 is appropriate given 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 and resource ('Advance an open session by a number of steps or days'), plus the optional order-sending behavior and the return payload. It explicitly positions itself against siblings with 'This is the one session tool that trades,' so an agent can distinguish it from session_state, session_rewind, or close_session without opening another 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 clear triggering context: orders are sent for one agent 'at the first step,' steps or days are mutually exclusive, and it is the only session tool that trades. It stops short of explicitly routing the agent to alternatives (e.g. use session_state to inspect without advancing), so it is strong but not fully 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?

Beyond the annotations (readOnly=false, non-idempotent, non-destructive), it discloses async semantics, capacity limits ('at most 2 jobs run at once'), retention ('last 32 are kept'), ephemerality ('in this server's memory only'), pre-start argument validation, and a runtime estimate in the response. This is unusually rich operational context for a mutation-style tool.

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

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

Front-loaded with purpose, then constraints, then the polling pointer — good ordering. It loses a point for near-duplication: 'The arguments are checked before the job starts' is repeated as 'A preset or population in the arguments is checked before the job starts.'

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 description still covers async behavior, limits, persistence, and validation. Nothing an agent needs to invoke it correctly and then follow up 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 both parameters are documented, so the baseline is 3. The description mostly restates schema content (the 252-day limit, refusal of unknown args/wrong types); the only added nuance is that a 'preset' or 'population' gets validated, which is marginal.

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') plus the exact resources it wraps (evaluate_strategies, rank_strategies, run_stress_scenario) and the immediate return (a job id). This lets an agent distinguish it from the direct sibling calls 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?

Explicit when-to-use: it is 'the ONLY way to run to the certified 252-day horizon', contrasted against the direct call which 'is capped at 60 days so it can answer inside a conversation'. It also names check_job as the polling alternative, so both the use and follow-up path 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 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.