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

Adds substantial context beyond the annotations: determinism ('no language model', same seed same answer), measured error rates (0.017 FP / 0.000 FN), the four possible synthesis verdicts, the meaning of `floor` and `observations_needed`, minimum input size, and licence/desktop-app requirements. The readOnly/idempotent/non-destructive annotations are consistent with this and the description extends rather than repeats them.

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 blocking constraint (desktop app not installed) before explaining the tool, which is the right priority for an agent that may not be able to call it. Dense but nearly every sentence carries information; minor redundancy in restating the licence requirement at both the opening and the close 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?

There is no output schema, so the description carries the return-value burden and does so: it defines all four synthesis outcomes and the per-control `floor` field. Combined with prerequisites, input minimums and determinism guarantees, nothing an agent needs to invoke and interpret this tool 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 seed, n_boot, n_sims and run_id, including the same-seed-same-answer property. The description only adds the run_id provenance and the sample-size precondition, which is marginal over what the schema already establishes; 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?

Names a concrete verb and resource ('run six controls that try to refute a finished run') and enumerates the six controls plus the positive control, so the agent knows exactly what work is performed. The subject matter is specific enough that it is unmistakable against siblings like red_flag_check or diagnostic_explain even without an explicit contrast sentence.

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

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

Gives explicit timing ('Call it after any promising result') and prerequisites (needs the run's full PnL series with at least 8 points, an unknown run is a named error, Stochastly open with an Atelier or Portfolio licence). It stops short of naming a when-not condition or pointing to an alternative sibling test, so it is clear context but not full routing guidance.

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

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

Annotations already cover read-only/idempotent/non-destructive, and the description adds substantially beyond them: the runtime prerequisite (desktop app installed, licence of a specific tier), the timestamp-intersection semantics of the join, and the named-error refusal for malformed curves. That is exactly the kind of operational context structured fields cannot carry.

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 blocking precondition (app not installed, how to fix), then purpose, then routing, then edge behavior. Dense but each sentence carries information; the install/activation sentence and URL are slightly verbose for a precondition note.

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

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

For a two-parameter, read-only tool this covers prerequisites, routing, input constraints and failure modes well. The one soft spot is that with no output schema the description only says it 'reports the fit' without indicating what that report contains.

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

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

Schema coverage is 100%, so baseline is 3. The description adds meaning beyond the schema by stating the curves are compared on paired increments and that only timestamps present in both curves count, which clarifies the effective input domain rather than restating field names.

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: measure dependence between two supplied equity curves by fitting a copula or mutual information on paired increments. It also names the sibling it is not (portfolio_combine), so an agent can discriminate 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 gives the when ('ask whether two strategies or markets move together before combining them'), the when-not ('to actually build and judge a combined book, use portfolio_combine instead'), and a scope exclusion ('descriptive only, no hypothesis test or 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?

Beyond the readOnly/idempotent annotations it discloses heavy behavioral context: the tool runs inside a desktop app that may not be installed, requires install + licence activation, and needs the app open with a specific licence tier. It also distinguishes the `_engine` sidecar vs in-process execution mode.

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 critical precondition (app not installed) is front-loaded, which is correct prioritization. It is slightly redundant, restating the licence requirement both in the first paragraph ("activate a licence") and the last ("open with an Atelier or Portfolio licence").

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

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

With no output schema, the description carries the full return-value burden and does so thoroughly. Preconditions, licence requirements, and the Routing rationale for calling it first are all present, leaving no gap an agent would need filled.

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

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

The tool takes zero parameters, so the description cannot add parameter meaning; the baseline of 4 applies. The return-field enumeration compensates by describing the output contract instead.

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 ("Report") and resource (the installed Stochastly app) and enumerates exactly what is returned (version, build_edition, platform, license_status, engine_integrity, `_engine`). It is unmistakably distinct from siblings like backtest_status or research_status.

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

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

Explicitly says to "Call it first to check that the app is reachable and which plan is active," and explains the complement: a refusal from any other tool names the plan it needs. It also states the precondition (Stochastly open with an Atelier or Portfolio licence).

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

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

Annotations only say it is a non-read-only, non-idempotent, closed-world call; the description goes much further by disclosing the session-registry side effect, the multiplicity counter, data-source refusal rules, custom-code gating, licensing, and timeout/polling behaviour. No contradiction with the annotations.

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

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

Front-loaded with the hard install/licence gate, then a dense but well-ordered body covering what it does, side effects, data sources, and async pattern. Every sentence carries information, though the opening environment-specific install paragraph is bulky boilerplate relative to the core instruction.

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 9 parameters, no output schema, and a nested plan object, the description supplies the missing context: named return values, session-registry effects, prerequisite sibling calls, async workflow, and failure conditions. An agent has everything needed 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 real meaning: source='folder' sourcing rules, data_root vs registered source, and guidance to use background=true for long runs with timeout_s framed around backtest_status polling. Not a full parameter walkthrough, but above the schema-only 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?

States a specific verb and resource ('Run a strategy graph end to end on your data') and enumerates the concrete stages performed (build configurations, cost-aware backtest with leakage-free splits, overfitting gates). It also names the outputs (verdict, number of survivors, run_id), which distinguishes it clearly from compose_graph (plan validation) and backtest_status (polling).

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 prerequisites and routing: 'Check the plan with compose_graph first', 'Use background=true for long runs, then backtest_status', and licence requirements (Atelier or Portfolio). It also states refusal conditions (unknown source, custom Python without permission), so the agent knows when the call will fail before making it.

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

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

Annotations cover safety hints (destructiveHint=false, idempotentHint=true), but the description adds real behavioral context beyond them: a desktop-app and licence prerequisite, that a finished run is recorded once in the day's session registry, and that an unknown run_id is a named error. The registry-writing note also plausibly explains the otherwise odd readOnlyHint=false.

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 blocking prerequisite about installing the desktop app is front-loaded, which is useful for an agent, and the remaining sentences are tight and each carry information. Slightly more verbose than strictly necessary, but nothing is wasted.

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

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

There is no output schema, and the description compensates by describing return values at each run state, the error behavior for unknown ids, licence requirements, and the registry side effect. 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?

With a single required parameter and 100% schema coverage, the schema already documents run_id as 'returned by backtest_graph,' which the description merely echoes. Baseline 3 is appropriate since the schema does the heavy lifting and no new syntax or format detail is added.

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: 'Get the state of a graph run started by backtest_graph,' and enumerates what is returned at each stage (status/progress/message while running; verdict/survivors/multiplicity when done). It anchors the tool to its producer sibling, backtest_graph, so an agent can place it immediately.

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 triggers: use after backtest_graph with background=true, or when a foreground run hit its timeout. There is no true alternative status tool among the siblings, so nothing needs naming. Clear context with no ambiguity, though no explicit when-not condition.

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

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

Adds substantial detail beyond the readOnly/idempotent/non-destructive annotations: 'Nothing is executed and no data is read,' invalid plans return ok false with the exact offending field, custom-Python plans are flagged via custom_code_nodes/runnable_over_mcp, and it discloses the required app state and license tier (Atelier or Portfolio). This is 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?

Content is front-loaded with the core purpose and the backtest_graph routing. The leading app-install paragraph is somewhat noisy and includes a pricing URL, but the remaining sentences are dense and each earns its place.

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

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

Given no output schema, the description documents the return shape (ok, configs, runnable, strategy, filters, gates, spec), failure behavior, and prerequisites. For a nested-object plan tool this covers everything an agent needs to invoke it correctly.

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

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

With 100% schema coverage the baseline is 3, but the description adds real semantics beyond the schema: params act as single-value locks (omit one to sweep its catalogue values), gates require a threshold with op 'ge'/'le' and specific window values, and cost vs lecture nodes are distinguished. This meaningfully clarifies how to shape the plan.

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: it validates/'checks a strategy graph plan and turns it into a run specification, counting how many parameter configurations it would test.' It also explicitly distinguishes itself from backtest_graph, so an agent can tell the two apart without opening the schema.

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

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

Gives clear sequencing guidance: 'Use it to build and debug a plan before backtest_graph, which takes the same arguments,' and notes backtest_graph's custom-code restriction. It lacks an explicit when-not-to-use condition, but the routing context is strong.

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

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

Annotations already declare readOnlyHint, idempotentHint, non-destructive and closed-world, so safety is covered. The description adds genuinely useful non-schema context: the tool only runs inside the Stochastly desktop app, which must be installed and hold an Atelier or Portfolio licence, and each entry carries an `implemented` flag. It stops short of describing return shape or size, which keeps it at a 4.

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

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

The actual purpose is buried behind a two-sentence installation/licence preamble that precedes it, so the definition is not front-loaded. The remaining sentences are tight and each earns its place, but the ordering forces an agent to read boilerplate before learning what the tool does.

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

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

With no output schema, the description carries the burden of telling the agent what comes back, and it does (strategies plus an `implemented` flag). Prerequisites, sibling routing and return content are all covered; only finer detail such as entry count or pagination is absent, which is minor for a static registry read.

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

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

The tool takes zero parameters, so there is nothing to disambiguate; the baseline for a parameterless tool is 4. The description's field list (timeframes, directions, grids, filters) describes output, not inputs, which is the right place given no arguments exist.

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

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

States a specific verb+resource ('List the cross-sectional crypto strategies') and enumerates the returned fields (timeframes, directions, parameter grids, filters, `implemented` flag). It also explicitly disambiguates from siblings, saying node_catalog is for graph node keys and registries for general strategy families.

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 use case ('see which crypto ranking strategies exist') and names two alternatives with the condition that selects each (node_catalog for graph node keys, registries for general families). Nothing is left to inference about when to reach for this tool.

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

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

Annotations already cover read-only, idempotent, non-destructive, and closed-world behavior. The description adds important behavioral context beyond annotations: the tool requires the Stochastly desktop app to be installed and opened with an Atelier or Portfolio licence, and it describes the output field `sources`.

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

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

The description is appropriately sized and front-loads the critical app/licence prerequisite, then explains output and usage. There is minor redundancy between the opening installation/licence note and the closing licence requirement, but it remains focused overall.

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

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

For a zero-parameter, read-only listing tool with no output schema, the description covers prerequisites, output content (`sources`), and its relationship to `backtest_graph`. Nothing essential for invoking the 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?

This tool has zero parameters, so the schema does not require additional parameter semantics. The description adds no parameter meaning because there are none to explain, which aligns with the baseline for zero-parameter tools.

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: it lists registered data source names, names the output field `sources`, and notes that `folder` is always included. It also distinguishes the tool from `backtest_graph` by positioning it as a prerequisite for choosing that tool's `source` argument.

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

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

It explicitly says to use this before `backtest_graph` to pick its `source` argument, and it states when not to rely on it: if a source is missing, pass `data_root` to `backtest_graph` instead. The prerequisite app/licence context further clarifies when the tool can be used at all.

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 safety (readOnly, idempotent, non-destructive, closed-world), and the description adds substantial context beyond them: the tool runs inside an app that must be installed and licensed, an unknown code returns an error listing known codes, and the explanation explicitly avoids promising that an action will improve the verdict. This is rich, non-obvious behavioral disclosure.

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

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

Content is dense and every sentence carries information, but the opening paragraph is a long environment/licensing preamble before the actual function is stated. It is efficient overall, though the ordering pushes the app-install requirement ahead of the core purpose.

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

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

With no output schema, the description compensates by describing what the returned explanation contains and how errors surface. For a single-parameter read-only tool, 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?

Schema coverage is 100%, so the single 'code' parameter is fully documented, including example values ('OF01', 'OF03', 'CO01'). The description reinforces the provenance (codes from red_flag_check violations) but adds no syntax or format detail beyond the schema, 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 and resource — 'Explain one diagnostic code' — and enumerates exactly what the explanation contains (what the quantity measures, why it matters, which measurement could move the verdict). It also cleanly distinguishes itself from siblings diagnostics_catalog (lists all codes) and red_flag_check (source of codes).

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 on codes returned by red_flag_check and to list every code with diagnostics_catalog, i.e. it names both the trigger source and the alternative tool. It also states the prerequisite (Stochastly desktop app open with an Atelier or Portfolio licence) and the failure behavior for unknown codes.

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, so the safety profile is covered. The description adds genuinely useful non-annotation context: the tool only runs inside the desktop app and needs an Atelier or Portfolio licence, which is exactly the kind of prerequisite disclosure the annotations cannot carry.

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 critical prerequisite is front-loaded before any functional text, which is the right ordering for a tool that cannot run without the app. Some redundancy remains: the licence requirement is stated in the opening sentence and repeated at the end ('Needs Stochastly open with an Atelier or Portfolio licence').

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

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

With no output schema, the description steps in to describe the return structure; with annotations covering safety, it covers the remaining burden of environment and licence prerequisites. An agent has everything needed to decide whether to call it and whether the call can succeed.

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

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

The tool takes zero parameters, so the baseline of 4 applies. The description instead documents the output shape (diagnostics grouped as code/family/page plus severities), which is helpful given no output schema exists, but it adds nothing about inputs because there are none.

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: 'List every diagnostic code the app can raise', and names the returned fields (code, family, page, severities). It is clearly distinguishable from the sibling diagnostic_explain, which it explicitly routes deeper questions to.

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

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

Gives a concrete when-to-use rationale ('know what the checks can hold against a run, and so what they cannot judge yet') and names the alternative for the adjacent task ('explain one code with diagnostic_explain'). No explicit when-not conditions, but the routing to the sibling is 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 already declare destructiveHint=true and idempotentHint=false, so overwrite/non-repeat behavior is signaled structurally. The description adds real value beyond that: the finished-run+verdict precondition, the per-paper error listing on render failure, and the licence requirement. It loses a point only because the desktop-app/licence requirement is stated twice rather than once.

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?

Core function is front-loaded and readable, but the leading app-installation paragraph and the trailing 'Requires an Atelier or Portfolio licence' restate the same availability constraint, and the 'N reports is N trials' aside is tangential. There is noticeable redundancy that dilutes an otherwise tight description.

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

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

With no output schema, the description usefully enumerates the return fields (ok, dir, n, papers, failed) and what a per-paper entry contains, and covers the key preconditions. It is nearly complete; only the duplication and lack of pagination/limit nuance around large run_id batches keep it from a 5.

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

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

Schema description coverage is 100%, and the schema already documents title, layout, out_dir and run_ids including the overwrite note on out_dir. The description repeats the shared-layout/shared-title idea but adds no syntax or format detail, 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+resource with scope: 'Write one research paper PDF per finished run with a shared layout and title.' It explicitly distinguishes itself from the sibling export_paper, which handles a single run, so an agent can route without opening schemas.

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 when-to-use ('report several runs consistently') and names the alternative ('export_paper handles a single run'), plus the precondition that every run must be finished and carry a verdict or nothing is written. Exclusions and prerequisites are 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 cover the safety profile (destructiveHint=true, readOnlyHint=false, idempotentHint=true), and the description adds substantial context beyond them: the tool runs only inside a separately-licensed desktop app, changes require an Atelier/Portfolio licence, sections whose data the run lacks are silently omitted with a note, and an unknown layout id is a hard error. These are meaningful behavioral traits that the structured fields 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?

Front-loads the blocking prerequisite, then purpose, then routing, then edge cases — a sensible order with little waste. The install/pricing preamble is somewhat verbose for a tool description, but it is genuinely necessary given the tool cannot run without it.

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

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

With no output schema, the description carries the return contract itself, listing ok, path, pages, figures, tables, omitted and the layout printed. Combined with licence gating, omission behavior and error semantics, an agent has everything needed to call and interpret 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?

Schema description coverage is 100%, so the schema already documents all six parameters including overwrite behavior, layout ids from paper_sections, and the exploratory labelling of omitted hypothesis. The description reiterates the layout-id error and hypothesis semantics but adds little syntax or format detail beyond the schema, so the baseline of 3 applies.

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

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

States a specific verb (write/export) and resource (multi-page research paper PDF) and enumerates the exact artifacts produced (abstract, numbered equations, tables, robustness section, disclosures box) for a clearly scoped input (one finished backtest run). It explicitly distinguishes itself from siblings export_tearsheet (one-page) and export_atlas (batch), so an agent can route without opening schemas.

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 ('full write-up of one run') and names both alternatives with their differing scope ('export_tearsheet makes a one-page summary and export_atlas a batch of papers'). It also states prerequisites (desktop app installed/activated, Atelier or Portfolio licence), which functions as a when-not-to-use condition.

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

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

Annotations already carry the safety profile (destructiveHint=true, idempotentHint=true, readOnlyHint=false), and the schema documents the overwrite behavior of 'path'. The description adds real context beyond that: it is gated on the desktop app being installed and on an Atelier/Portfolio licence, and it enumerates which run types are refused. It does not, however, say what a refusal looks like to the caller.

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 content is efficient, but the structure is poor: it opens with a machine-specific installation/prerequisite paragraph before stating what the tool does, so the actual purpose is buried in the second paragraph. A caller scanning the first line learns about a missing desktop app rather than the tool's function.

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

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

With no output schema, the description helpfully states the return shape (ok, path, fmt), plus refusal conditions, licence gating and the sibling alternative. It is close to complete for a 3-param export tool; only the failure/refusal response shape is left unspecified.

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 fmt, path and run_id are already fully documented, including the png fallback and the overwrite warning. The description adds no syntax or meaning beyond the schema, so the baseline 3 is correct.

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 — write a one-page tearsheet image/PDF summarising a finished run — and names its return values. It explicitly differentiates itself from the sibling export_paper ('writes the full paper'), so an agent can route correctly 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 when-to-use ('quick shareable summary'), names the alternative (export_paper) and its selection condition, and lists exclusions: research runs, unknown runs and unfinished runs are refused. The licence prerequisite (Atelier or Portfolio) is also 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 cover the safety profile (readOnly, idempotent, non-destructive, closed-world), but the description adds materially beyond them: the hard precondition that the desktop app must be installed, opened, and licensed (Atelier or Portfolio), and the guarantee that secrets are never exposed. Those are exactly the operational facts an agent needs before calling, and they are not derivable from the annotations.

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

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

The blocking app/licence requirement is front-loaded in its own paragraph, then the content, then the usage hint and interpretation. Everything is on-topic, though the app-installation and licence requirements are restated in the opening and closing sentences, 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 no output schema present, the description carries the return-value burden and does so: it lists the reported fields and defines both age_s and present. Combined with the precondition and licence constraints, an agent has everything needed to call this correctly or decide it cannot be called.

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

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

The tool takes zero parameters, which sets a baseline of 4. The description still earns that baseline by documenting the shape of what comes back (age_s as seconds since the state file was written, present as false when the app has never written it), which is useful even though there is nothing to describe on the input side.

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-plus-resource (read the app's last reported state) and enumerates exactly what that state contains: workspace, chart, symbol, timeframe, indicators, graph nodes, current run, active assistant agent. It is clearly distinguished from the write-side sibling set_live_state, so an agent can separate the two 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 concrete usage triggers: 'check the effect of pilot_app or the context of the user's screen', plus an interpretation rule that a large age_s means the app is probably closed. It does not state an explicit when-not or name set_live_state as the write alternative, which keeps it 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 mark this as a safe, read-only, idempotent, local read; the description goes well beyond that by disclosing the hard prerequisite (the Stochastly desktop app must be installed, open, and running with an Atelier or Portfolio licence) and the environment where it will fail. It also explains the in-memory vs engine-reload behavior tied to the force flag.

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 return-value explanation is front-loaded and dense, and the licence prerequisite is stated early. There is mild redundancy between the opening installation instructions and the closing 'Needs Stochastly open with an Atelier or Portfolio licence' sentence, but the size is justified by the non-obvious environment requirement.

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

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

With no output schema, the description carries the return-value burden and does so well: it explains the family grouping, the node categories, the per-node parameter schema, and the exportable flag. The environment prerequisite and downstream usage are also covered, leaving only minor detail unstated.

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 force parameter is fully explained in the schema itself (engine reload after an update). The description adds no additional parameter semantics beyond what the schema already provides, so the baseline of 3 applies.

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

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

States a specific verb and resource (return the graph editor's node catalogue) and describes the return content precisely: grouped by family, covering strategy/filter/gate/cost/reading nodes with parameter schema and an exportable flag. It also distinguishes itself from siblings by naming compose_graph and backtest_graph as its dependents.

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 context: it is the only source of valid node keys and should be called before writing a plan, which implies calling it ahead of compose_graph and backtest_graph. No explicit when-not-to-use case is stated, so it falls just 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 cover read-only/idempotent/non-destructive, and the description adds real context beyond them: an environment/licence prerequisite (desktop app open with Atelier or Portfolio licence) and the downstream behavior that mandatory letterhead/backtest sections are always reinstated. It does not describe pagination or failure modes when the app is missing, 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-loads the prerequisite and then the purpose, which is reasonable, but the app/licence requirement is stated twice (opening paragraph and closing sentence), a redundant repetition that dilutes an otherwise tight three-sentence description.

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 zero parameters and no output schema, the description carries the full burden and mostly does: it specifies the return shape, the licensing prerequisite, and the consumer tools. It leaves out what happens if the licence is absent beyond the install instruction, so slightly short of complete.

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

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

The tool takes no parameters, so per the baseline this scores 4. There is nothing to document, and the description still usefully describes the returned object fields.

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

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

States a specific verb and resource ('List every section a research paper can contain') and even enumerates the returned field shape {id, group, label, mandatory, in_default}. This clearly distinguishes it from export_paper and export_atlas, which consume the ids rather than list them.

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

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

Explicitly routes the agent: 'Use it to choose the `layout` ids for export_paper or export_atlas.' It also explains the downstream consequence that mandatory sections are re-added and that caller order is respected, so the agent knows the sequencing contract.

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

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

Goes well past the annotations (readOnlyHint=false, destructiveHint=false, idempotentHint=false) by disclosing the desktop-app and licence prerequisites, that the command replaces any pending command, that field application order is open/screen/chart/run, that the user sees each step in the status bar and journal, and that the response always carries pilot_enabled. These are exactly the operational facts an agent needs and none are in the schema.

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

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

Front-loaded with the blocking prerequisite before any capability detail, which is the right priority, and each later sentence adds a distinct fact (ordering, when-to-use, caveats, response field). It is slightly long and the install/licence material could be tightened, but no sentence is pure filler.

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

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

For an 8-parameter, zero-required, no-output-schema tool that acts on a GUI, the description covers prerequisites, licensing, mutual exclusions, effect ordering, user-visible feedback, and the pilot_enabled response field. Nothing needed 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?

Schema coverage is 100%, so per-parameter meaning is already carried by the schema, but the description adds cross-parameter semantics the schema cannot: fields combine in one call and apply in a fixed order, and a call replaces any pending command. It restates the run/prompt exclusion rather than adding to it, which keeps it just below a 5.

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

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

States a specific capability set with concrete verbs and objects (open a .stly document, switch screen, show a chart, start a backtest, display a note, send a prompt) and names the sibling it is not (backtest_graph). An agent can distinguish this from backtest_graph or compose_graph 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 selection rule: use this when the user should watch the work in the app, otherwise use backtest_graph to get numbers back directly. It also states the hard preconditions (app open, piloting enabled and off by default, Atelier or Portfolio licence) so the agent can decide not to call it at all.

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

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

Annotations only give the shape (not read-only, not idempotent, not destructive); the description adds the real behavioural load: the book is persisted as a new run consumable by adversarial_check/export_tearsheet, runs from other sessions or in mismatched PnL units are refused rather than converted, a Portfolio licence is required with a named refusal path for Atelier, and the weighting/drawdown timing rules are disclosed.

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

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

Dense and largely waste-free, with prerequisites, purpose, return values, constraints and algorithm timing each getting one sentence. Minor structural weakness: the generic install/licence boilerplate occupies the opening position, pushing the actual purpose into the second 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?

With no output schema, the description correctly enumerates the return values, and it covers side effects (new run id), licensing/auth requirements, session and unit preconditions, and look-ahead/timing semantics. An agent has everything needed to decide and call correctly.

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

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

Schema coverage is 100%, so the schema already documents every parameter and its defaults, and the description's parameter-relevant content is indirect (weights at bar t use only earlier bars; the drawdown cap acts on the previous bar's equity). That adds interpretive context for lookback/dd_cap but no per-parameter syntax beyond what the schema provides, 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 and resource — combining finished runs into a portfolio/book — and enumerates the concrete output (combined series, used weights, correlation matrix, sleeve contributions, deflated Sharpe). It explicitly distinguishes itself from siblings: 'a single graph run covers one strategy, and analyze_dependence only measures two curves you supply.'

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 ('for a multi-strategy or multi-market book'), when-not ('a single graph run covers one strategy'), and names alternatives with the reason they don't fit. Prerequisites (app installed, Portfolio licence, runs finished in the current session) are stated up front.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so safety is covered. The description adds meaningful context the annotations cannot: the tool executes inside a desktop app that may not be installed, and a specific licence tier (Atelier or Portfolio) is required. It does not, however, describe failure modes when the licence is missing or how the data is scoped.

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 blocking prerequisite (app not installed on this machine, install URL, licence activation) is front-loaded, followed by the return contents and the routing note. Everything earns its place, though the licence/installation detail is somewhat dense in a single opening sentence.

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

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

With no input parameters, no output schema and a closed-world read-only annotation set, the description supplies exactly the missing pieces: what it returns (three profiles and named presets), that it is reference data only, the alternative tools, and the environment/licence prerequisite. Nothing an agent needs to invoke or decline the tool is absent.

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

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

The tool takes zero parameters, so there are no arguments whose semantics need explaining; the baseline for a no-param tool is 4. The description correctly adds no parameter discussion, and the returned profiles/presets are described at the value level rather than as inputs.

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

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

The description states a concrete verb (return) and enumerates the exact payload: the three synthetic example profiles (profitable, marginal, overfit) plus the prop-firm rule presets (FTMO Standard/Pro 100k phase 1, The5ers Hyper Growth). It also differentiates itself from siblings by naming red_flag_check and adversarial_check as the tools for real judgments.

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 routing advice — 'Reference data only: to judge a real result use red_flag_check or adversarial_check' — and states prerequisites (Stochastly desktop app open with an Atelier or Portfolio licence). Both when-to-use and when-not-to-use are covered with the alternatives named.

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), and the description adds substantial context beyond them: RED sets deploy_blocked, the returned diagnostics (components, contributions, reasons, violations, missing measures, coverage needed for GREEN), and the fact that missing evidence lowers coverage rather than being imputed. It also discloses a hard environmental prerequisite (Stochastly running with an Atelier or Portfolio licence).

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 deployment verdict and the null-handling rule, and every substantive sentence earns its place. However, the install prerequisite is spread over three sentences up front and then partially repeated at the end ('Needs Stochastly open with an Atelier or Portfolio licence'), a redundancy that costs conciseness.

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

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

There is no output schema, so the description carries the return-value burden, and it does: verdict, score, per-component contributions, reasons, violation codes, missing measures, and GREEN coverage requirements. Combined with the prerequisite and sibling routing, an agent has everything needed to call and interpret it.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds genuine semantics: null is a meaningful 'not measured' value that reduces coverage instead of being guessed, which tells the agent how to populate the five required fields. It does not add units, ranges, or thresholds per measure.

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

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

States a specific verb+resource: combines five overfitting measures into one deployment verdict (GREEN/AMBER/RED) with a 0-100 score. It also enumerates the returned artifacts, so an agent knows exactly what the tool produces 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?

Explicitly says 'Use it to decide whether a configuration or run is fit to deploy' and routes adjacent needs to named siblings: diagnostic_explain for explaining a violation code, adversarial_check for refuting a finished run. The null-for-unmeasured rule gives a clear invocation condition.

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

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

Annotations already declare readOnly/idempotent/non-destructive, but the description adds the crucial behavioral facts they cannot: the tool only runs inside the Stochastly desktop app, that app is not installed on this machine, and a paid licence must be active. This tells the agent the call will fail in the current environment — high-value disclosure beyond 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 the blocking prerequisite, then purpose, then routing — a sensible order with no wasted filler. The installation/pricing sentence is slightly long and marketing-toned, but it carries genuinely decision-relevant information about tool availability.

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

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

For a zero-parameter, no-output-schema tool, the description supplies everything an agent needs: what it returns, which keys, sibling alternatives for adjacent needs, and the environmental/licence prerequisites. Nothing material is left to inference.

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

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

The tool takes zero parameters and the schema is an empty object, so the baseline of 4 applies. The description instead documents the return keys (strategy_families, instrument_groups, timeframes), which is useful but belongs to output semantics rather than parameters.

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

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

States a specific verb ('List') and enumerates the exact resources returned (strategy families, instrument groups, timeframes), plus names the concrete output keys. It also explicitly distinguishes itself from siblings node_catalog and crypto_registry, so an agent can route 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 explicit exclusions and alternatives with their selecting conditions: 'For the node keys you pass to compose_graph or backtest_graph, use node_catalog instead; for the cross-sectional crypto strategies, use crypto_registry.' It also states the prerequisite context (app open, Atelier/Portfolio licence).

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, but the description adds substantial behavioral context beyond them: the journal write cadence (at start, after each turn, at the end), the meaning of `running`, and the `present: false` return when no session exists. It also discloses the environment prerequisite (app not installed on this machine) that annotations cannot express.

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 blocking prerequisite, then the purpose, then the lifecycle routing — a sensible order with no filler. It is somewhat long and the parenthetical about `age_s` leans toward describing output that a return-value reader would infer, but every sentence carries actionable 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?

There is no output schema, so the description must describe the return surface — and it does (status, turns, ideas, evidence, token count, errors, age_s, and the `present: false` case). Combined with the prerequisite and lifecycle guidance, 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% and the `session_id` parameter is already documented in the schema (journal id format, omit for most recent). The description adds no additional meaning about the parameter, 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: 'Read the saved journal of an in-app Research session', and enumerates exactly what the journal contains (status, turns, ideas, evidence, token count, errors, age_s). This is clearly distinguishable from siblings like backtest_status, live_state, and v9_get_run, which cover different subsystems.

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 the agent: start a session with pilot_app(prompt="/research ...") and stop it with pilot_app(prompt="/stop"), and states the hard prerequisite (Stochastly installed, open, with an Atelier or Portfolio licence). It also warns that a `running` status is only a checkpoint, not proof of liveness, which is precisely the kind of caveat that changes how an agent interprets a result.

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 readOnlyHint=false, idempotentHint=true and destructiveHint=false, but the description adds substantial context: environment prerequisites, licence tier requirement, the graceful degradation to dev_only: true when the harness is absent, and the fact that the process tree is killed on timeout. It does not however describe the exact diagnostic line format or the pass/fail payload shape.

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

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

Front-loads the most important gating fact (the desktop app is required / not installed) before describing behavior. There is mild redundancy in restating licence requirements at the end after the checkout prerequisite, but overall it is efficient.

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

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

Given no output schema, the description carries the return contract reasonably well ('pass or fail with the diagnostic line', plus the dev_only fallback). Prerequisites, licence needs and timeout behavior are all covered, leaving only minor gaps about the exact return payload structure.

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 'spec' and 'timeout_s' are already documented in the schema, including defaults and the timeout kill semantics. The description adds nothing parameter-specific, 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 ('start the Playwright smoke test of the app interface') and enumerates the exact scope: visual regression and clean console, headless, mocked data. An agent can immediately distinguish this from sibling tools like diagnostic_explain or tail_app_log.

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

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

Explicitly scopes usage to development ('Development only') and states the prerequisite conditions (source checkout with test harness, Atelier or Portfolio licence) and the when-not case (installed app returns dev_only: true and starts nothing). It does not name alternative diagnostic tools, but the gating conditions are clear enough to route correctly.

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

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

With annotations covering the safety profile, the description goes well beyond them by disclosing that the command replaces any pending one, only takes effect when piloting is enabled, is reported via pilot_enabled in the response, requires a specific licence tier, and that the current app ignores the two fields. These are exactly the operational constraints an agent needs and are not in 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?

The content is front-loaded and each paragraph carries distinct information (install prerequisite, legacy behavior, alternative tool, effect semantics). It is somewhat verbose in the opening install paragraph, but nothing is gratuitous.

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

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

There is no output schema, and the description compensates by describing what the response contains (pilot_enabled, notice that fields were not applied). Prerequisites, enabling conditions, and the alternative tool are all covered, so an agent has enough to call it correctly.

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

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

Schema coverage is 100%, so the schema documents tf and sym, making 3 the baseline. The description adds important meaning the schema cannot: the current app does not apply these two fields and the response says so, which materially affects whether an agent should pass them at all.

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

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

The description states a specific verb and resource: 'queue a command asking the old chart terminal to show another symbol or timeframe.' It also explicitly labels itself 'Legacy' and contrasts with pilot_app, so an agent can distinguish it from siblings. The installation preamble at the top slightly buries the core purpose.

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

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

Explicit routing is given: 'To drive the current app (open a document, switch screen, start a backtest) use pilot_app,' and the legacy/exhausted nature of this tool is stated. It also names prerequisites (desktop app installed, activated, Atelier or Portfolio licence) and the enabling condition (piloting enabled).

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), and the description adds genuinely new behavior: the environment prerequisite that the desktop app must be installed and running with a specific licence tier, the returned fields, and the staleness rule (logs older than one hour are flagged with a caveat about an earlier session). That is exactly the context annotations cannot supply.

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 critical blocker (tool runs in an uninstalled app) is front-loaded, which is the right ordering. However, the licence/app requirement is stated twice (the install block and the closing sentence), and the install URL plus activation instructions add bulk that is only marginally actionable for an agent.

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

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

With no output schema, the description still explains the return fields and the staleness signal, plus prerequisites and sibling routing. An agent has everything needed to decide whether to call it and to interpret 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?

Schema description coverage is 100% for the single 'lines' parameter, so the schema already documents its meaning and default. The description adds nothing about the parameter, which is the expected baseline when the schema does the heavy lifting.

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

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

States a specific verb+resource ('Return the last lines of the app's own log file') and enumerates the shape of what comes back ('present', 'age_s', 'stale: true' with a note). It also distinguishes itself from the log-related siblings v9_tail_log and backtest_status, 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 positive trigger ('Use it to diagnose an app error') and names the two alternatives with the exact conditions that select them ('For a batch scanner run use v9_tail_log; for a graph run use backtest_status'). The prerequisite (app installed, open, Atelier or Portfolio licence) is stated, leaving nothing material to inference.

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

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

Annotations already declare readOnlyHint/idempotentHint/destructiveHint=false, so safety is covered; the description adds valuable non-structured context the annotations cannot express — the Stochastly app must be installed and open, and an Atelier or Portfolio licence is required. The licensing prerequisite is stated twice (opening sentence and closing sentence), which is mildly redundant rather than incorrect.

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 install/licence preamble is a genuine blocker and is reasonably front-loaded, and the middle paragraph is dense with useful content (returned fields, sibling routing, error names). Minor duplication between the first and last sentences keeps it from being maximally tight.

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

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

There is no output schema, so the description carries the burden of describing return content — and it does, listing the verdict file, both robustness counts, PBO, and the log-line window. Combined with the licence prerequisite and sibling routing, an agent has everything needed to call it correctly.

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

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

Schema description coverage is 100% and the single run_id parameter already documents the 'latest' default and its source (v9_list_runs). The description adds no syntax or semantics beyond that, so the baseline 3 applies — it neither compensates nor detracts.

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 one batch scanner run') and enumerates exactly what comes back — verdict file, robustness counts n_total/n_robust_pass, PBO, and last 30 log lines. This distinguishes it cleanly from v9_list_runs (which only finds ids) and v9_tail_log (which streams more log lines).

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 the agent: 'Use v9_list_runs first to find the run_id, and v9_tail_log for more log lines,' naming both alternatives and the condition that selects them. It also names the failure modes ('no_runs', 'run_not_found'), so an agent can anticipate and interpret errors.

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 goes well beyond them: it discloses the app/installation prerequisite, the licence-tier requirement, the newest-first ordering, the exact status vocabulary (running/done/error), and that an empty list is returned when the scanner is absent.

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

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

Front-loaded and organized around purpose/usage/return fields, but the prerequisite is stated redundantly three times (desktop app required, runs inside the app, install/open/activate) and the licence requirement appears twice, once mid-description and again in the closing sentence.

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?

No output schema exists, so the description carries the return shape on its own and does so (run_id, status enum, verdict/n_configs/pbo_cscv/auc/best_config summary). Preconditions, alternatives, and empty-result behavior 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?

Only one optional parameter and schema coverage is 100%, so the schema already documents 'limit' fully. The description's 'newest first' restates the schema's own wording rather than adding ordering semantics or interaction with the limit value.

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

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

States a specific verb and resource ('List the runs of the separate batch strategy scanner') with the run-folder naming convention (V9_*/V95_*) and the per-run fields returned. It also explicitly distinguishes itself from backtest_status (graph-started runs) and positions itself as the feeder for v9_get_run and v9_tail_log.

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 ('Use it to find a run_id for v9_get_run or v9_tail_log'), when-not ('Runs started from a graph are not listed here: use backtest_status'), and the environmental preconditions (desktop app installed, scanner present, Stochastly open with an Atelier or Portfolio licence).

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, non-destructive, idempotent, closed-world), and the description goes well beyond them: it discloses the hard runtime prerequisite (desktop app installed, opened, licence activated), the specific licence tiers accepted, the absence of side effects ('starts nothing'), and the exact failure mode `no_protocol_a_results`. That is the kind of context annotations cannot carry.

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 gating fact (requires the desktop app, output fields, read-only nature) is front-loaded, and every paragraph carries information. The install URL and 'open it and activate a licence' phrasing is slightly more verbose than needed, but it is not padding.

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

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

With no output schema and no parameters, the description compensates fully: it names the returned metrics, the error returned when the source file is missing, and all prerequisites an agent must verify before calling. Nothing needed to invoke or interpret this tool 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?

The tool takes zero parameters, so per the rubric the baseline is 4. There is no argument surface for the description to clarify, and it correctly does not invent one.

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

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

States a specific verb (summarise) and an unambiguous resource (the batch scanner's saved regression check), and enumerates the exact quantities produced (n_total, n_strict, n_soft, n_cumul, pct_cumul, tolerance). It never names a sibling such as v9_get_run or v9_tail_log, so the differentiation is achieved by subject matter rather than explicit 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?

Gives clear operating context: it reads a file computed earlier, 'starts nothing', and needs the Stochastly app open with an Atelier or Portfolio licence. That tells an agent both when this tool is appropriate and when it is not (before the app/licence exists). No alternative tool is named for the same job, which keeps it 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 it safe, read-only, idempotent and non-destructive, so the safety profile needs no restating. The description adds genuine context beyond them: the empty-list behavior ('no run or no log yet') and the environment/licence prerequisite (Stochastly open with Atelier or Portfolio licence).

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 purpose sentence is well-formed, but the definition opens with a three-line installation prerequisite and the licensing requirement is stated twice ('Requires the Stochastly desktop app...' and 'Needs Stochastly open with an Atelier or Portfolio licence'), which is redundant weight.

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

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

With no output schema, the description covers the return value (`lines`) and the empty-result case, and it discloses the runtime prerequisite. Complete enough to invoke correctly; only minor gaps about log size/retention remain.

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% – both `lines` and `run_id` are fully documented in the schema, including the 'latest' default and the >=0 constraint. The description adds no syntax or format detail beyond that, 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 and resource: 'Return the last lines of a batch scanner run's log file, as `lines`.' It explicitly separates itself from sibling v9_get_run ('gives the verdict and robustness counts'), so an agent can distinguish the two 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 clear context: 'Use it to follow a running scan or see why one failed,' and names the alternative (v9_get_run) with the distinct condition that selects it. No explicit when-not guidance or mention of the adjacent tail_app_log sibling, so it falls just short of a full 5.

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