QuanterLab

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

Annotations already declare the mutation profile (readOnlyHint=false, destructiveHint=false, idempotentHint=false), so the description only needs to add context, and it does: it discloses the UI-window side effect, the three-year run horizon as a hard limit, and that the circuit is persisted as the person's project and reopens in the lab as built. It stops short of saying what happens if a window is already open or what the call returns to identify the new circuit.

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

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

Purpose and routing information are front-loaded before the Args block, and each sentence carries real information about behavior or sequencing. It is somewhat long and leans on descriptive imagery ('as the lab's canvas shows it', 'every card lights up in turn') that costs tokens without changing agent behavior.

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-required-parameter tool with no output schema, it covers purpose, prerequisites, follow-on tools (circuit_step, run_circuit), the three-year scope limit, and persistence semantics. What is missing is the handoff detail — how the agent identifies or references the circuit it just created when calling circuit_step, given no return value is documented.

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

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

Schema coverage is 0%, so the description must carry both optional parameters, and it largely does: name is given a usage pattern and a concrete example ('RSI dip on KO, tested forward'), and fresh is given an explicit false/else branch meaning. The only gap is that null is the schema default but the description never states what null does relative to fresh=true.

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 opens with a specific verb and resource — opens a window where a circuit of QuanterLab lab cards is assembled step by step — and describes the visible progression (cards arrive, wires join, cards light up on run). It explicitly distinguishes itself from start_test (ready-made tests), circuit_step (adding cards), and run_circuit (execution), so the agent can place it among siblings without opening another schema.

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

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

It names the conditions for use — a person's own idea that no ready test covers, or a change to a previously built circuit via fresh=false — and names the alternatives explicitly (start_test, circuit_step, run_circuit). The 'a longer test runs in the lab' clause also tells the agent when this tool is NOT the right vehicle.

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

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

Annotations already establish that this is read-only, non-destructive, and closed-world. The description adds important behavior beyond that: it waits a few seconds for the next step and returns incremental steps, the circuit drawing, and run information, which is useful for an agent to know.

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

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

The description is short and includes only relevant details, but the opening sentence is grammatically awkward and obscures the tool's purpose. The Args section is clear enough, but the overall structure is not well front-loaded.

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

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

For a two-parameter read tool with no output schema, the description does explain the parameters and broadly describes return contents and long-poll behavior. It remains incomplete because it does not clarify how this differs from sibling circuit tools or what exactly a 'draft' response 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 description coverage is 0%, so the description carries the burden. It meaningfully explains `window` as the window id from build_circuit and `n` as the last step shown, compensating well for the bare schema, though it omits the meaning of `n`'s default 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?

The description indicates this operates on a circuit window during circuit construction and returns draft/progress information, but it never states a clear verb or resource in plain terms. It also does not distinguish itself from siblings like circuit_progress or circuit_step, leaving the exact purpose somewhat vague.

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

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

It implies usage while the circuit is being built and notes that `window` comes from build_circuit, which gives some context. However, it does not say when to use this instead of circuit_progress, circuit_step, or run_circuit, and offers no explicit exclusions.

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

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

Annotations already establish that this is a read-only, non-destructive operation. The description adds useful behavioral context beyond them: it waits a few seconds for the next card to finish, and when the run finishes it returns report-card text, figures, a growth chart, and next-run offers.

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 is front-loaded and the Args section is useful, but the main sentence is a long, awkward run-on with repeated card metaphor and unclear phrasing. It is informative rather than bloated, but its structure could be much cleaner.

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 polling/progress tool with no output schema, it explains the in-progress view and the finished-run return content. It leaves minor gaps around error behavior or exact polling cadence, but covers what an agent needs 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 0%, so the description carries the full burden. It documents all three parameters: task_id comes from start_test, seen is the count already shown as run, and now is the currently running card. This compensates fully for the schema gap.

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

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

The description states a specific resource and action: progress for the circuit card, showing which circuit cards have run, which is running, and final report details. It is distinguishable from most siblings via the circuit-card and start_test context, though it does not explicitly contrast with run_card_progress or show_report_card.

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

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

It gives clear invocation context: this is for the circuit card, it is called while a ready test runs, and task_id comes from start_test. It does not name alternatives or state when not to use it, so it stops short of 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?

Discloses the non-obvious semantics annotations cannot: steps run in order, a failing step halts the remainder while prior steps persist, each step is validated against catalog/ports/param ranges/plan entitlements, and the response includes unresolved requirements. It also states the forward test caps at three years and the anchor defaults to the last three years ending at the prior month's end.

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

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

Front-loaded with purpose, ordering, and failure behavior before the argument detail; every paragraph carries information the agent needs. It is dense and longer than average, but the length is justified by the seven-op payload and the format example has no filler.

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

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

No output schema exists, and the description still summarizes the return ('each card's id, ports and settings, the wires, and what the circuit still needs'). Combined with the prerequisite, partial-failure, and validation semantics, an agent has everything required to invoke it correctly.

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

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

Schema description coverage is 0% and the single parameter is an untyped object array, so the description carries the entire burden. It enumerates every op (add_card, connect, set_card, remove_card, disconnect, set_anchor, clear), gives literal JSON examples, and documents optional fields like id/after/params defaults, including the Signal Module rule config format.

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

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

States a specific verb+resource ('puts the circuit opened with build_circuit together, one step after another') and ties itself to the sibling that creates the circuit, so an agent can tell it apart from build_circuit and run_circuit. It stops short of explicitly contrasting with circuit_draft, which is the nearest ambiguous alternative.

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

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

Establishes the prerequisite ordering ('the circuit opened with build_circuit') and points to list_primitives as the source of valid card types. There is no explicit when-not-to-use guidance versus circuit_draft or build_circuit, so a small inference remains.

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

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

Annotations already declare read-only, non-destructive, closed-world behavior. The description adds useful behavioral detail by listing the returned workflow fields and the `defaults` concept, though one sentence about how the run starts is somewhat ambiguous for a discovery tool.

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

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

The description is front-loaded with purpose and return details, then usage guidance and parameter examples. It is mostly efficient, but the sentence beginning 'The run starts...' is somewhat ambiguous in the context of a describe-only tool.

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

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

There is no output schema, so the description compensates by explaining what the returned list contains, including workflow metadata and defaults. It does not document edge cases such as no-match behavior, but it is complete enough for an agent to invoke the tool 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?

The schema has 0% description coverage for the only parameter, so the description has to carry the full burden. It does so by explaining that `intent` is free-form user wording and by providing concrete examples such as finding mean-reverting stocks and backtesting an RSI strategy.

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 gives a specific verb and resource: match a natural-language intent string to QuanterLab workflows. It also states the return contents and explicitly distinguishes the tool from the execution tools by saying it is used to pick the right `start_*` tool.

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

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

It states the condition directly: use this when the user describes what they want in their own words, and use it to pick the correct `start_*` tool. This gives both the when-to-use and the alternative execution path without requiring 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=true, openWorldHint=false and destructiveHint=false, so the safety profile is covered. The description adds that the payload ends with suggested next steps (including a start_test pointer), which is useful behavioral context, but it is tangled and never states access limits, whether unpublished ids fail, or how large the returned text is.

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 opening sentence is well front-loaded, but the trailing clause about 'the person's idea first: a version of their own, or the paper's own circuit ... changed by talking' is syntactically broken and unparseable, adding length without adding usable meaning.

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

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

An output schema exists, so enumerating the returned fields (title, byline, sections, URL) is largely redundant, and the description spends its space there while leaving open the id provenance ambiguity and the follow-on start_test relationship. Adequate for a one-parameter read tool, but not tight.

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 single 'id' parameter has 0% schema description coverage, so the description must compensate. It does partially by specifying the id is the one 'search returned', which is genuinely useful provenance, but it never states format, whether it is the paper id or a study id (it hints both), or what happens on an unknown id.

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?

It states a specific verb and resource ('The text of one published paper by the id') and implicitly ties itself to the 'search' sibling by saying the id comes from search results. The second half wanders into a description of the paper's 'next steps' and a suggested start_test call, which blurs the boundary between what fetch does and what other tools do.

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

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

Usage is only implied: 'by the id search returned' suggests search must run first, and start_test is named as a follow-on. There is no explicit statement of when to use this over search, show_report_card, or my_paper_trades, and no exclusions or error conditions.

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

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

Although annotations already declare this as a safe read-only operation, the description adds substantial behavioral detail: the returned fields, the possible status values, the 0-100 progress scale, and extra completion-time fields (`result`, `report_url`). It also explains that the completed summary mirrors `summarize_workflow`, which helps the agent interpret results without opening another schema.

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

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

The description is front-loaded with purpose and then return behavior, and most sentences earn their place. The final sentence on `result` and `report_url` is dense and slightly awkward, but the overall structure remains 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?

For a one-parameter status tool with annotations and no output schema, the description is nearly complete: it explains the return shape, status values, progress range, and completion behavior. The only real gap is explicitly connecting `task_id` to the return value of `start_backtest`.

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

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

Schema coverage is 0%, so the description must compensate for the single required `task_id` parameter. It implies the identifier comes from a backtest started with `start_backtest`, but it never explicitly states that the task ID must be the value returned by that call. That is useful context but incomplete compensation.

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

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

The description names the exact resource (backtest progress) and ties it to the sibling tool that starts the run (`start_backtest`), so an agent can immediately place it among the many other progress tools. It is specific about what is being retrieved rather than merely restating the tool name.

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 clearly establishes the usage context: this is for a backtest started with `start_backtest`. That is stronger than implied usage, but it does not explicitly exclude alternatives such as `list_my_running_tasks` or explain when to prefer a different progress/status 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 the read-only, non-destructive profile, and the description adds genuine lifecycle context: the partial payload during the run, the extra `result`/`report_url` fields only after completion, and where the report surfaces in the chat card.

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

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

Front-loaded with purpose, then the return shape and completion-state differences. Mostly efficient; the trailing clause about the chat card is slightly ornamental but adds UI context.

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 does the work of documenting the response keys and their conditional presence, plus the origin of `task_id`. Only the polling cadence and terminal-status semantics are left implicit.

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

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

One required parameter with 0% schema description coverage; the description only indirectly implies `task_id` is the identifier produced by `start_mr_scan`, without stating the expected format or that it is the task id, not a name.

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 (progress of a mean-reversion scan) and anchors it to the sibling that creates the task, `start_mr_scan`, which cleanly separates it from `get_pairs_scan_progress` and other progress tools.

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

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

The link to `start_mr_scan` plus 'when the scan has finished' implies a polling usage pattern, but the description never explicitly says to call it repeatedly, nor does it state exclusions or alternatives for retrieving results.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so safety is covered. The description adds valuable behavioral detail: the exact return fields (`task_id`, `status`, `progress`, `message`, `dashboard_url`) and that upon completion it also returns `result` with passed pairs and `candidates`, plus `report_url`. This goes beyond what annotations provide.

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

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

The description is front-loaded with purpose, then provides return details in a compact, well-structured manner. Every sentence contributes directly to the agent's understanding.

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

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

Given the annotations cover safety and there is no output schema, the description fully explains the return values, including what appears when the scan finishes. This is complete for a progress-check tool.

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

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

Schema coverage is 0% for the single `task_id` parameter, so the description must compensate. It indirectly implies `task_id` comes from `start_pairs_scan`, but does not explicitly explain the parameter's meaning or format. This is a baseline 3: partial compensation via contextual reference.

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+resource: retrieving progress of a pairs scan. It explicitly ties to the sibling `start_pairs_scan`, making it easy to distinguish from other progress tools for different scans.

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 clearly indicates this is used after starting a pairs scan via `start_pairs_scan`, giving the agent a clear context for when to call it. It doesn't explicitly name alternatives or exclusions, but the link to the start tool provides sufficient guidance.

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

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

Annotations only say read-only/non-destructive/closed-world; the description goes far beyond them by disclosing the exact return shape `{task_id, status, progress, message, dashboard_url}`, the terminal status values, the conditional `result` field on completion, and the `report_url` surface. That is precisely the behavioral context 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 first clause is well front-loaded, but the second paragraph is a long run-on enumerating nested `figures.branches` fields and a parenthetical about `start_test`/`offers` that is tangential to reporting progress. Much of that detail would be better placed on the result/summary tool it duplicates (`summarize_workflow`).

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 correctly spends its budget describing the returned fields, the terminal states, and how the completed payload relates to `summarize_workflow`. An agent can call and interpret it correctly; only the `task_id` provenance and the division of labor with `get_primitives_run_result` are left 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?

With a single parameter at 0% schema description coverage, the description must carry the meaning, and it does only indirectly by tying the run to `start_primitives_run`. It never states that `task_id` is the identifier returned by that start call, nor any format or validation constraints.

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 ('Progress of a lab run') and anchors it to the creating tool `start_primitives_run`. It is clear what the tool does, but it does not explicitly distinguish itself from the very similar sibling `get_primitives_run_result`, which an agent could reasonably confuse it with once status is `done`.

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?

Polling usage is only implied by '`status` reaches `done` or `error`' and by the note that the finished answer carries `result`. There is no explicit 'use this while running, use get_primitives_run_result for the final payload' routing or any guidance on polling cadence, so the agent must infer the workflow.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds useful behavioral context beyond that – a finished run is required, and the response carries the run's anchor plus any look-ahead warning (point-in-time caveat). It says nothing about error behavior for an unfinished/unknown task_id, which is the main remaining gap.

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

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

The text is one long run-on construction with hedging filler ('and the like') and an awkward clause ('The figures ... come with `get_primitives_run_progress` as `result`, and from `summarize_workflow`') that obscures rather than front-loads the key point. The useful content (which tier fields are returned) is buried mid-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 output schema, the description does take on the burden of enumerating return fields, and it lists them reasonably well (tiers, market-state label, dates, beat-holding flag, rounded return, Sharpe, worst drop, trades, anchor, look-ahead warning). But it omits the required task_id entirely and gives no indication of result volume, ordering, or what happens for an unfinished run.

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

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

There is a single required parameter, task_id, and schema description coverage is 0% – the schema gives only a title. The description never mentions task_id or explains that it identifies the run whose result is returned, so it does not compensate for the coverage gap; an agent must guess what the identifier refers to (task vs. project branch).

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 conveys the content of the response (per-circuit tier rows with performance_tier, drawdown_band, trades_tier, skill_band, market-state labels) but never states a verb or says it fetches a result for a given task. Its differentiation from get_primitives_run_progress and summarize_workflow is attempted but muddled – it tells the agent the numeric figures 'come with' those other tools, leaving it unclear exactly what this tool returns on its own.

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

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

'The outcome of a finished lab run' implies a prerequisite (the run must have completed) and implicitly routes in-progress polling to get_primitives_run_progress. However, there is no explicit statement of when to call this versus summarize_workflow or what to do if the run is not finished, so usage must be inferred.

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 readOnlyHint/destructiveHint already declaring a safe read, the description still adds real value: it discloses the exact return keys, the terminal-state behavior ('when the analysis has finished, the answer also carries `result`'), and that `result` mirrors `summarize_workflow` while `report_url` matches the chat card. It does not cover polling cadence, status value semantics, or behavior on a stale/invalid task_id.

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

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

Three tight sentences: purpose and origin first, then the return payload, then the terminal-state additions. No filler, and the most decision-relevant information is front-loaded.

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

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

There is no output schema, so the description must enumerate return values — it does so thoroughly, including the conditional `result` and `report_url`. Combined with annotations covering the safety profile, an agent has what it needs; only error/edge-case behavior 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 0% for the single `task_id` property, so the description carries the burden and does so partially by tying the id to a run created via `start_regime_analysis`. It never says explicitly that `task_id` is that tool's returned identifier, nor what happens if it is unknown, so a little meaning is left implicit.

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 the specific verb and resource ('Progress of a regime analysis or pairs check') and names the originating tool `start_regime_analysis`, which separates it from the many other *_progress siblings. It stops short of explicitly contrasting with sibling progress tools like `get_regime_optimization_progress` or `list_my_running_tasks`, so it lands just under the top mark.

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

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

Clearly frames the usage context: call this after starting a run with `start_regime_analysis` to poll its state. No when-not guidance or alternative routing (e.g., for already-finished runs or for enumerating tasks) is offered, which keeps it from 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 cover read-only/non-destructive/openWorld=false, so the bar is lower, and the description still adds real value: it enumerates the returned fields and explains that `result` and `report_url` appear only once the run has finished. It does not describe the possible `status` values or polling/rate-limit behavior.

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

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

Short and front-loaded: purpose first, then return shape. Minor waste in the odd indented/multi-line quote formatting, but no content is superfluous.

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 documents the return payload and the conditional completion fields, and it cross-references `summarize_workflow` for the result shape. Missing only status enumeration and polling guidance for a progress-checking tool.

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

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

Only one parameter (`task_id`) with 0% schema description coverage, so the description must compensate. It implies the id originates from `start_regime_optimization`, but never states the id format, lifetime, or the error behavior for an unknown/expired id.

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 (progress of a regime optimization) and ties it directly to the sibling that creates the run, `start_regime_optimization`. It does not explicitly distinguish itself from the similarly named `get_regime_analysis_progress`, relying on the reader to map 'optimization' vs 'analysis'.

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?

Implicitly defines when to use it by reference to `start_regime_optimization` (i.e., after starting such a run), but never says whether to poll, how often, or when to prefer `list_my_running_tasks` instead. Usage is inferable rather than stated.

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

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

Annotations already establish that this is a safe, read-only, non-destructive, non-open-world call. The description adds useful behavioral context by saying it starts nothing, answers with an overview and ready-test list, and can render as a card or as plain words for hosts without card support.

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 and usage are front-loaded, but the description is long, clause-heavy, and occasionally meanders into details about downstream tools. The parenthetical capability summary and the 'three years a run' phrase add bulk without clearly helping the caller use get_started itself.

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 onboarding tool with no output schema, the description gives enough context about what the response contains: QuanterLab's capabilities, a list of one-tap tests, and a plain-text alternative. It stops short of describing the exact response structure, but an agent can still 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?

There are zero input parameters and schema coverage is complete, so there is no parameter semantics burden. The description appropriately adds no parameter guidance because none is needed.

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

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

The description clearly states that this is the first-contact/orientation tool that explains what QuanterLab is and what it can do. It distinguishes the tool from action-taking siblings by saying 'It starts nothing' and by routing picked tests to start_test and custom ideas to build_circuit.

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 names the triggering situations: a hello, a question about QuanterLab, a request for help, or someone with no rule in mind yet. It also names the alternatives for next steps, including start_test for a selected test and build_circuit for a user's own idea.

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

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

Annotations already establish that this is a safe read-only operation. The description adds useful behavioral detail by documenting the returned fields and explaining that completed runs include result and report_url, which goes beyond the annotations.

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

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

The description is short and front-loads the return contract. The final clause about the chat card is a little awkward, but overall there is little wasted text.

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 simple progress-polling tool with annotations and no output schema, the description gives a solid return-value overview and terminal-state behavior. It is only missing guidance on task_id provenance and alternative progress tools.

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

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

Schema description coverage is 0% for the single required task_id parameter, and the description does not explain what task_id is or where to obtain it. It relies entirely on the caller inferring that task_id is the stochastic backtest task identifier.

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

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

The description clearly identifies the resource as a stochastic backtest and the operation as checking its progress. It is specific enough to distinguish this from most siblings, but it does not explicitly contrast with get_backtest_progress or start_stochastic_backtest.

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

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

It implies the tool is for checking progress, but gives no explicit when-to-use guidance, no mention of where task_id comes from, and no comparison to the sibling get_backtest_progress.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, so safety is covered. The description adds genuine behavior: progress advances window by window, and on completion the payload gains `result` (same as `summarize_workflow`) and `report_url`. It stops short of enumerating status values or describing error/unknown-task behavior.

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

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

Front-loaded with the key fact, but the trailing clause 'which the run's card in the chat shows' is UI fluff that adds no calling information, and the multi-line prose with backticks is slightly ragged. Nothing else is wasteful.

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 return-value documentation and does so adequately: it lists the base fields and the completion-time additions. The main gap is the absence of status enum values and polling expectations, which an agent needs to decide when to stop 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?

Single `task_id` parameter with 0% schema description coverage. The description indirectly explains it by referencing the run started with `start_walkforward`, so the agent can infer the value comes from that call, but no format or validity constraints are given.

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

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

States a specific verb+resource: retrieves progress of a walk-forward started with `start_walkforward`, explicitly naming the sibling that produces the task. It is clearly distinguishable from most siblings (get_backtest_progress, circuit_progress, etc.) by tying itself to the walk-forward run, though it doesn't contrast itself against the other *_progress tools.

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

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

The link to `start_walkforward` implies when to call it, and the finished-state behavior hints at polling. But there is no explicit polling guidance, no statement of what to do if the task is still running, and no contrast with `list_my_running_tasks` or the sibling progress tools.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=false and destructiveHint=false, so the safety profile is covered. The description adds useful context beyond that: exactly what each entry contains (code, name, blurb, extra parameters) and where the analyzers actually live (the Supplementary Data menu on quanterlab.com), which tells the agent this is a static local catalog and where the underlying capability runs.

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 purpose sentence, then the return shape, then the site/menu context. Slightly verbose in the second paragraph, but every sentence carries information an agent can use.

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 returned fields and clarifies that parameters are per-analyzer rather than for this call. Combined with annotations covering safety, little is missing for a zero-parameter catalog tool; only explicit sibling routing is absent.

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

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

The tool takes no parameters, so the baseline is 4. The description still adds value by explaining that analyzers accept a `ticker` plus additional parameters listed in the returned catalog, which prepares the agent for downstream calls.

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 resource (single-stock fundamental analyzers) with the scope 'available in QuanterLab', which distinguishes it from catalog siblings like list_indicators and list_primitives. It stops short of explicitly contrasting itself with those catalog tools, so it is clear but not fully differentiated.

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

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

The description implies the tool is a discovery/catalog call ('this catalog lists what is there'), but gives no explicit when-to-use guidance or pointers to alternatives such as list_indicators or describe_capability. Usage is inferable but not stated.

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

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

Annotations already cover the safety profile (readOnly, non-destructive, closed-world), and the description adds genuinely useful context beyond them: it enumerates the returned fields (id, display name, category, parameters with defaults and bounds, short usage note) and explicitly disclaims market data or computed values. That prevents a common misinvocation. Pagination/result-size behavior is not mentioned.

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 one-line purpose, then the return contract, then the argument notes. Every line carries information an agent needs; nothing is redundant with the schema.

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

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

With no output schema, the description correctly takes on the job of describing the return shape and its limits, and both optional filters are explained. For a two-parameter read-only catalog tool, 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 0%, so the description carries the full burden and does it: it gives concrete category examples ("momentum", "trend", "volatility", "volume") that stand in for missing enums, and defines search as a case-insensitive substring matched against id and display name. This is meaning the schema cannot supply.

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

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

Specific verb + resource: it lists the technical indicators the platform supports for strategy building, which is unambiguous on its face. It does not, however, contrast itself with the other list_* catalog tools (list_primitives, list_fundamental_analyzers, list_stochastic_methods), so an agent must infer the distinction from the noun alone.

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

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

The description frames the use case (discovering indicators for strategy building) and sets a clear boundary by stating it returns metadata only and no market data or computed values, which steers agents away from using it as a data source. It stops short of naming an explicit alternative tool or a when-not-to-call 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 cover the safety profile (readOnlyHint true, non-destructive, closed-world), but the description adds substantive behavior: newest-first ordering, the exact return fields, the four `performance_tier` enum values, and the persistence prerequisite. It does not explain truncation/paging behavior when results exceed `limit`, which is the main remaining blind spot.

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

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

Front-loads the core purpose and return shape, then args — good ordering with no filler sentences. The paragraph describing where reports live in the quanterlab.com sidebar is user-facing context rather than agent-invocation guidance, so it is mildly expendable.

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 does the return-value work itself: fields, enum values, ordering, and the `report_url` distinction for unsaved runs. Completeness is only slightly undercut by the absence of guidance on how to retrieve results past the limit cap.

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

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

Schema coverage is 0%, so the description carries the full burden and does: `strategy_code` is described as an optional filter with three concrete example codes and explicit all-strategies-when-omitted behavior, and `limit` adds bounds (1-100) and the default (20) that the bare schema does not state.

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?

Opens with a specific verb + resource + ordering ('List the authenticated user's saved backtest results, newest first') and scopes it to the caller's own saved runs, which cleanly separates it from siblings like list_my_running_tasks or get_backtest_progress. The clause that a run appears only after save_workflow_result further pins down what 'saved' means.

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 real usage condition (results from an assistant-started run only surface here after `save_workflow_result`, otherwise use its `report_url`), which steers the agent away from expecting in-flight runs. It stops short of naming an explicit alternative tool for in-progress runs, so it is clear context rather than full when/when-not routing.

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

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

Annotations already cover read-only/non-destructive, and the description adds real value beyond them: results are newest-first, only summary fields are returned (universe size, stocks passed, pass rate), and where the full names can be viewed. It doesn't mention pagination behavior or the default cap, which is a minor gap.

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

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

The core sentences are front-loaded and efficient, but the final sentence about the quanterlab.com sidebar is grammatically broken and of marginal use to an agent. A cautionary note about truncation would have earned that space better.

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 simple single-parameter read tool this is close to adequate, but with no output schema and 0% parameter coverage, an agent still can't tell how many results come back by default or how to page. The return-shape hints help but don't close the loop.

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

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

Schema description coverage is 0% — the single 'limit' parameter has no description, default, or range documented anywhere. The description never mentions limiting, pagination, or what happens when more results exist than requested, so it fails to compensate for the schema gap.

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

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

States a specific verb+resource: list the user's saved scanner / filter results, with scope (own results) and ordering (newest first). It doesn't explicitly separate itself from sibling list tools like list_my_backtests or list_my_projects, but 'scanner / filter results' is distinctive enough.

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

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

Usage is only implied — you call it to see saved scan outputs. There's no statement of when to prefer this over list_my_backtests or get_primitives_run_result, and no prerequisites or exclusions are given.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, so safety is covered structurally. The description adds genuinely new behavior: results are sorted newest first, the circuit/settings/results are not returned here but stay server-side, and the exact rows emitted are enumerated. Pagination or result-count limits are not mentioned.

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

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

Front-loaded with the core action and ordering, followed by a compact row-by-row field list that earns its place because there is no output schema. The final sentence about state staying on QuanterLab is slightly indirect but carries the important 'no circuit payload returned' point.

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 compensates by enumerating returned fields, which makes it largely self-sufficient. However, it omits whether the list is bounded/paginated and how it differs from list_my_projects, leaving a gap for an agent choosing between the two list tools.

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

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

The tool takes zero parameters, so the baseline is 4. The description still explains that returned `id` values are the handles consumed by `start_primitives_run`, giving the key field meaning beyond the empty schema.

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

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

States a specific verb and resource — 'List your saved lab projects (circuits on the canvas)' — and clarifies the domain object (a project wrapping a circuit) versus the raw primitive catalogs in siblings like list_primitives. It does not explicitly distinguish itself from the similarly named list_my_projects, which leaves one ambiguity unresolved.

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?

Provides clear forward routing: projects are opened on the canvas and executed via `start_primitives_run` with the returned `id`, which tells the agent exactly why and when to call this. No explicit when-not-to-use rule or comparison to list_my_projects is given.

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

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

Annotations already establish the safe read-only profile, and the description adds valuable context by enumerating the returned metadata fields and explaining that project items open on quanterlab.com. It does not mention pagination, which is unlikely given zero parameters, or auth requirements, but it meaningfully supplements the annotations.

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

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

The description is front-loaded with the core purpose, then handles disambiguation, return contents, and item access in three short, purposeful sentences. There is minor repetition of item counts between the first sentence and the return-field list, but it does not waste space.

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

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

With no parameters and no output schema, the description carries the burden of explaining what comes back, and it does so by listing name, description, category, item count, and timestamps. Combined with the explicit sibling distinction, it gives an agent everything needed to call and interpret this tool.

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

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

The tool takes no parameters, so the baseline is 4; there is no parameter behavior the description needs to clarify. The description appropriately focuses on return contents and scope 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?

The description states a specific verb and resource (list the user's projects) and immediately distinguishes it from the similarly named sibling `list_my_primitives_projects`, clarifying that these are saved-item/note folders rather than lab circuits. An agent can tell exactly what this tool does and what it does not do without inspecting 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?

It explicitly names the alternative tool for lab circuits and explains the domain distinction, which is strong routing guidance. It does not spell out a usage scenario beyond the implied 'use this to see My Projects folders,' so it falls just short of a full when/when-not guideline.

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

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

Annotations already cover the safety profile (readOnly, non-destructive, closed-world), and the description adds real behavior: the 3-run cap, the meaning of `wedged` (no progress for 15 minutes, released at the next start_* call), the null case for `runs_left_today`, and the data-policy boundary ('No market data, only the person's own runs'). These are traits an agent cannot infer 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 trigger condition is front-loaded and the prose is readable, but the return shape is stated twice: once narratively ('Returns one row per run: its task_id, its kind, the seconds since it last reported progress, and `wedged`') and again verbatim as a structure literal. That duplication is redundant for a tool with no inputs.

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 and no output schema, the description carries the full burden and meets it: it documents the return object's shape, the meaning of its non-obvious fields, the limit, and the data policy. An agent can call this and interpret the result without guessing.

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

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

Zero input parameters, so there is nothing to disambiguate and the baseline is 4. The description instead spends its effort on return-field semantics (task_id, kind, last_progress_age_s, wedged), which is useful but falls outside parameter semantics proper.

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 person's runs that are still counted as running') plus a scope bound ('at most 3 at once'), which cleanly separates it from the get_*_progress siblings that inspect a single completed/ongoing resource and from start_* tools that launch runs.

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

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

Gives an explicit trigger condition: use when a start_* call is refused because 3 runs are already going and it's unclear which, 'most often after a conversation moved on in the middle of one.' It also tells the agent to read it before proposing a run's settings, which is a concrete pre-condition rather than vague guidance.

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

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

Annotations already declare the read-only/non-destructive profile, so the bar is lower, yet the description adds a genuinely non-obvious trait: default rows deliberately omit watchlist fields and opting in is audited/logged. That privacy/audit behavior is not inferable from schema or annotations.

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

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

The core behavior is front-loaded, but the Args block largely restates the include_details explanation already given in prose, including repeating the audit note. It is not wasteful, but the duplication adds length without new 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?

With no output schema, the description must describe return shape, and it does: it names the default row fields (ID, strategy_type, strategy_code, trade_count, tier, performance_tier) and the opt-in fields. Only pagination/ordering behavior is 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 coverage is 0%, so the description must carry the load, and it does: limit gets a range (1-100) and default (20) not present in the schema, and include_details is mapped to specific returned fields. Slight redundancy with the body paragraph keeps it from 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 verb+resource ("List the user's saved trading configs") plus provenance ("exported from strategy builders"), which distinguishes it from siblings like list_my_backtests or list_my_projects. An agent can identify the target with no schema inspection.

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 clearly explains the default-vs-detailed behavior and when to opt in ("Pass include_details=True to opt into the full row"), but gives no guidance on tool selection relative to siblings or any prerequisites. Usage is implied through the parameter semantics rather than a selection rule.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so safety is covered. The description adds value beyond them by detailing the shape of the return (a catalog with type, label, category, input/output ports, settings, description), which tells the agent what it will actually get back.

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 core statement and alternative routing are front-loaded, and the Args block is efficient. A few sentences (the canvas/strategy philosophy and 'three years a run') are atmospheric rather than operational, costing it a perfect score.

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

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

For a read-only, two-optional-parameter list tool with no output schema, the description covers purpose, return shape, filtering, and sibling relationships. Nothing critical is missing, though it could state ordering/pagination behavior of the returned catalog.

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

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

Schema description coverage is 0%, so the description must carry both parameters, and it does: category is described as an optional filter with a concrete example list, and search is described as a case-insensitive substring matched against block type and label. That is more than the schema offers, though it lacks e.g. format constraints or behavior when both are supplied.

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 cards' — and immediately resolves ambiguity by defining a primitive as a card and enumerating what each catalog entry contains (type, label, category, ports, settings, description). It also distinguishes itself from build_circuit (assembles cards) and run_circuit (executes), so an agent can tell the three apart 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?

The description frames this as the discovery step feeding build_circuit ('build_circuit puts these cards together in the chat, step by step') and points to run tools for data/results, giving clear contextual routing. It stops short of an explicit 'call this before build_circuit' instruction or any exclusions, so it is strong but not a full when/when-not statement.

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 this is a non-destructive, read-only, closed-world read, so the safety profile is covered. The description adds substantive context beyond them: it enumerates the exact metadata returned (id, display name, category, parameters with defaults and bounds, short description) and preempts a likely agent misconception by stating no market data or fitted values come back.

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

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

Front-loaded with the core purpose and return contract in the first two sentences, then a scoping exclusion, then a compact Args block. No redundancy with the name or with the annotations.

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

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

No output schema exists, and the description compensates by specifying exactly which fields come back and what does not. Both parameters are documented, and with annotations covering the read-only safety profile there is nothing an agent needs to call this correctly that 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 0%, so the description must carry the parameter burden, and it mostly does: it explains that category is an optional filter with concrete examples ('mean_reversion', 'trend', 'pairs', 'regime') and that search is an optional case-insensitive substring matched against id and name. It does not say whether the two filters combine with AND or how partial matches rank, leaving a small gap.

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

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

Opens with a specific verb+resource ('List the stochastic methods QuanterLab supports') and ties it to the consuming sibling, start_stochastic_backtest, via the exact field it feeds (primary_method.id). An agent can distinguish it from list_indicators, list_primitives, or list_fundamental_analyzers 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 states the use case: 'Use this to discover valid primary_method.id values for `start_stochastic_backtest`', which gives a clear trigger condition. It also carves out a negative boundary ('Does NOT return any market data or fitted parameter values'), though it names no alternative discovery tool for that sub-need.

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, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds real context beyond that: it specifies the comparison baseline used ('its own change since it went live next to simply holding over the same days, in whole percents') and reinforces that no money moves, which is meaningful for a performance-reporting tool.

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

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

The substance is good but it arrives as one long run-on sentence that restates the question three ways ('their strategy, their paper trade or their live test'). The key point about the benchmark comparison is buried mid-sentence rather than front-loaded, and the repetition of the no-money clause costs space.

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 must carry the return-value burden, and it does: it enumerates the fields returned and explains the performance metric and its basis. It stops short of stating ordering, count limits, or what an empty result means, which leaves minor gaps for a list-style read tool.

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

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

The tool takes zero parameters and schema description coverage is 100%, so there is nothing for the description to disambiguate. Per the baseline rule, a no-parameter tool starts at 4, and nothing here misleads about inputs.

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

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

The description clearly establishes the resource (the person's paper-traded strategies) and what is returned (name, go-live date, current state, performance vs. holding), which lets an agent distinguish it from mutation siblings like start_paper_trade. It never uses an explicit verb like 'list' or 'retrieve', relying on 'How ... are doing' to imply a read, which is slightly indirect.

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

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

Usage is only implied — an agent can infer this answers 'how are my paper trades doing', but there is no explicit when-to-use, when-not-to-use, or named alternative. The closing line 'Nothing here places an order or moves money' does steer the agent away from expecting a mutation, but it doesn't contrast with any specific sibling.

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

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

Annotations already declare readOnly/non-destructive/closed-world, so the description only needs to add context, and it does: it discloses the three distinct outcomes (in-progress percentage, the finished card with words/figures/chart/offers, and the connector's stop reason). That state-dependent return behavior is real value beyond the annotations.

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

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

The main content is one rambling, clause-chained sentence riddled with semicolons and asides, so the key fact (this polls a chat-started run's progress) is not front-loaded. The Args block is clean, but the prose is hard to parse and would benefit from restructuring into discrete statements.

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 0% param coverage, the description does cover the return states and both parameter meanings. However, for a polling tool it omits how often to poll, terminate conditions for the loop, and how it relates to the many sibling progress tools, leaving gaps an agent must guess at.

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 0% schema description coverage, the description must carry both parameters, and it does: task_id is tied to 'the task_id the start answered with' and progress is defined as 'How far the card already shows the run, in percent.' This meaningfully compensates for the empty schema, though the optional/nullable status of progress at the API path is left unaddressed.

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 conveys that this polls a run started from the chat and returns the report card, but the phrasing ('For the report card only, which calls it while a run started from the chat goes on') is convoluted and never states a clean verb+resource. It does partially differentiate from siblings by scoping it to the chat-initiated run and the report card, but an agent would have to work to parse that out.

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

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

There is an implied polling usage ('waiting a few seconds for it to move on'), but no explicit statement of when to call this versus the many sibling progress tools (circuit_progress, get_backtest_progress, get_pairs_scan_progress, etc.) or when to stop polling. The exclusion 'For the report card only' hints at a boundary but never names the alternative.

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 behavior beyond the annotations: a daily per-account allowance where a refused call does not count, silent truncation of windows beyond three years with a `held` note, persistence of the run as the person's project, UI cadence while running, and the presence of a result plus report_url. Annotations only cover safety flags, so this is real added value.

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

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

Purpose and constraints are front-loaded, and most sentences carry load-bearing information (cap, quota, progress tool, param meanings). A few narrative asides, such as the window lighting up card by card, are marginal but not distracting.

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 only two optional params, the description does the heavy lifting: it explains the run's lifecycle, the progress-tracking sibling, the terminal result and report_url, and truncation behavior. Remaining ambiguity is around the exact shape of the `held` response, which is only described as 'one line'.

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

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

Schema description coverage is 0%, so the description must carry both optional params, and it does: `name` is the project name in the person's words used only when the circuit lacks one, and `question` is a one-sentence restatement (explicitly not the raw user message) that becomes the report title and is kept only as that. The guidance is semantically rich but slightly indirect in wording.

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 ('runs the circuit built with build_circuit and circuit_step') and names the build-side siblings it depends on, so an agent can distinguish it from build_circuit/circuit_step and from the generic start_* runners. The scope ('on the lab's engine, over three years at most') further pins down what kind of run this is.

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 prerequisite (the circuit must already exist via build_circuit and circuit_step) and routes progress polling to get_primitives_run_progress. It notes the three-year cap and that longer tests run in the lab, but never explicitly contrast it with look-alike siblings such as start_test or start_primitives_run.

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

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

Annotations cover the safety profile (readOnlyHint=false, destructiveHint=false, openWorldHint=false), so the bar is lower; the description still adds real context: it creates a persistent, user-visible artifact in the Trading configs menu, and it explicitly disclaims live tracking and paper-trade side effects. It does not explain what happens when the same config is saved twice, which matters given idempotentHint=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?

Front-loaded with the core action, then scope, then alternatives, then Args – a logical order. Some redundancy: the live-tracking/paper-trade caveat is stated twice in adjacent paragraphs, costing a couple of lines in an already long 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?

For a 2-param mutation with no output schema, the description covers trigger conditions, side effects, supported kinds, and parameter meanings. The remaining gap is the return value – it never says whether the call returns a config id or label, which the agent needs to confirm success or reference the config later via list_my_trading_configs.

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

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

Schema coverage is 0%, so the description must carry the burden; it does define task_id's provenance ('returned by a prior start_* call') and adds a constraint the schema lacks for label ('max 100 chars'). Neither is fully illustrated (no example label, no statement of what happens if task_id refers to an unsupported kind).

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

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

Specific verb + resource ('save the settings a run was started with as a trading config') with an explicit scope limit enumerated in the kinds list (backtest, walkforward, stochastic_backtest, basic_backtest, regime_optimization). It also names the sibling that handles scanners (save_workflow_result), so the agent can distinguish it without opening either schema.

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

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

Gives an explicit when ('AFTER you've validated a config, e.g. walk-forward looked good'), an explicit when-not ('does not track the strategy live, starts no paper trade'), and names the alternative for the excluded case ('start_paper_trade does that'). Scanner kinds are routed to save_workflow_result, which is a genuine exclusion rule, not just a mention.

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

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

Annotations declare a non-read-only, non-destructive, non-idempotent write; the description adds real context beyond that — the refusal behavior for unfinished runs, the 100-character label cap and the fallback naming scheme, and the two return fields (report_url, where). It does not say what happens if the same task is saved twice, which matters given idempotentHint=false, so it is 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?

Purpose is front-loaded in the first sentence, and the bulleted run-type list earns its space by telling the agent what shapes of result are valid. The closing sentence about `where` restates the location a second time and is mildly redundant.

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

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

With no output schema, the description compensates by naming report_url and where and explaining why both exist. Combined with the completion precondition and default-naming rule, an agent has everything needed to invoke this correctly against a 2-parameter mutation.

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

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

Schema coverage is 0%, so the description carries the full burden and does so well: task_id is tied to a prior start_* call, and label is described as optional, capped at 100 characters (a constraint absent from the schema), with the default naming convention spelled out. Minor gap: no format expectation for task_id.

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?

A concrete verb plus resource: it saves a finished run's result into the user's Research Library, and it enumerates exactly what a saved run contains (figures, trades, equity line for a backtest; passing names for a scan). It distinguishes itself from the start_*/get_*_progress siblings by being the terminal persistence step, but it never names a sibling alternative, so it stops short of a 5.

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

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

It gives a clear precondition and a negative case: the run must be finished, and saving a running task is refused with a message telling the user to wait. That is genuine when-to-use/when-not guidance, but there is no explicit routing to or away from any named sibling tool.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so safety is covered. The description adds useful behavioral detail beyond that: a cap of 20 results, the return shape {id, title, url}, and the empty-query behavior that lists newest papers.

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

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

The description is compact and front-loaded: it states what is searched, the result cap and shape, the follow-up action, and the empty-query behavior in just a few sentences. Every sentence adds distinct information without repetition.

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 only one parameter and an existing output schema, the tool is simple, and the description covers the key behavior including empty-query handling and return count. The remaining gap is lack of query-syntax guidance, which is minor given the schema's simplicity.

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

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

Schema description coverage is 0%, and the single `query` parameter has no schema-level documentation, so the description must carry the burden. It does explain that an empty query lists newest papers and that ids are used with `fetch`, but it does not clarify query syntax, matching behavior, or how keywords are interpreted, leaving a clear gap.

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

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

The description names a specific verb and resource ('Search QuanterLab's published research papers') and further scopes it as registered walk-forward studies with trial records. It also implicitly distinguishes itself from the sibling `fetch` by explaining that passing an id to fetch retrieves the paper's text, so an agent can tell them apart without inspecting 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?

It provides clear context for use: searching published research and using an empty query to list the newest papers. It points to `fetch` as the follow-up for full text. However, it doesn't explicitly state when not to use this tool or contrast it with other listing siblings like `list_my_projects`.

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 and non-destructive annotations, the description explains exactly what the card contains, how parameter-grid results are represented, and that the card offers next-step choices that can open the lab project. It also clarifies that one call produces the card without a follow-up call.

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

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

The purpose is front-loaded, but the first sentence is extremely long and heavily nested with parentheticals, making it harder to parse than necessary. The later sentence about one call showing the card repeats information already implied in the first 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?

For a one-parameter UI tool with no output schema, the description is complete enough: it explains what appears in chat, what the parameter accepts, and when the card should or should not be shown. No critical agent-facing behavior appears 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 0%, so the description carries the full burden for report_url. It does so well by identifying the source tools and accepted URL patterns, including /r/, /report/, /backtest-report/, and /filter-report/ links or a pasted report link.

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: showing a QuanterLab report as a chat card. It also differentiates from sibling behavior by saying this is for reports with no existing card, while runs started in the chat already show their own card.

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 names when to use the tool: a report link answered by summarize_workflow or save_workflow_result, or a pasted report link, and when not to use it: when a run was started in the chat and already has its own result card. This directly routes the agent away from redundant calls.

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

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

Goes well beyond the annotations: discloses the 30s–3min runtime, the immediate `{task_id, status, kind, dashboard_url}` return, polling via get_backtest_progress, what the finished answer contains (summary, comparison figures, report_url), and a per-account daily allowance where refused calls don't count. It also explains that the chat card self-updates, which the readOnly/idempotent hints cannot 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-loaded with purpose, defaults, and return shape before the parameter reference, and nearly every sentence carries information. It is long and somewhat scattered, though — the update-card behavior is mentioned twice, and `question`/`report_url` are documented after the worked example rather than with the other Args.

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 19-parameter, nested-object tool with no output schema, this is complete: it covers invocation behavior, async polling, quota failures, return payloads, report generation, and follow-up actions. An agent can call it correctly and handle the result without consulting anything else.

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 0% schema description coverage and 19 params, the description carries the full load and does it: every parameter is explained with units, defaults, and accepted values (duration formats, direction, position_sizing, risk_per_trade semantics, oos_pct behavior, cost defaults). It further specifies the nested condition object grammar, allowed operators, and column-naming conventions, plus a full worked example.

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?

Opens with a specific verb+resource+scope: 'Run a backtest of an indicator rule on one stock or ETF, on daily bars,' and clarifies the timeframe restriction. It differentiates against portfolio/paper-trading tooling for multi-position sizing, but never distinguishes itself from other start_* siblings such as start_walkforward or start_stochastic_backtest, so an agent must infer which starter fits.

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 strong operational guidance: no settings must be settled beforehand, defaults are fine, and changes require a new run ('a change is a new run'). It also tells the agent that a run started here needs no show_report_card and points to save_workflow_result/save_trading_config for persistence. It stops short of explicit exclusions or a direct 'use X instead' for backtest variants.

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

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

Annotations only declare the basic mutation profile (readOnlyHint=false, destructiveHint=false, idempotentHint=false); the description goes far beyond by disclosing the quota model and that refused calls are free, the expected latency, the exact response shape {task_id, status, kind, dashboard_url}, the waiting semantics, and the report_url delivered on completion. It even warns that an unsupported index still consumes a turn but runs nothing, which is a genuine behavioral trap an agent must know to avoid.

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 action, then quota, then return shape, then parameters — a sensible ordering for a tool with no schema documentation. It is long, but the bulk is the filter reference, which is unavoidable at 0% schema coverage; the only fat is a few convoluted clauses such as "The call waits for the run while it is likely to finish inside it" and the run-card sentence, which read awkwardly and could be tightened.

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

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

No output schema exists, so the description explains the immediate return value, the deferred result payload delivered via get_mr_scan_progress (per-filter pass counts, up to ten ranked candidates with statistics), and the post-completion report_url. Combined with quota, latency, and the full filter spec, an agent has everything needed to call this correctly and set user expectations.

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

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

Schema coverage is 0% and the schema has no titles beyond bare names and no enums, so the description carries the full burden — and it does: index values ('sp500', 'nasdaq100', 'dowjones') with out-of-set handling, timeframe ('1d' only), duration ('6m'/'1y'/'3y'), question semantics (one sentence, becomes report title, not the user's message), and steps as an ordered filter chain. The filter catalogue enumerates all eight types with their parameter names, meanings, units, and bracketed defaults, plus the pass-to-next-filter chaining rule.

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?

Opens with a specific verb and resource: "Run QuanterLab's mean-reversion scanner across an index," which is immediately distinguishable from siblings like start_pairs_scan, start_backtest, and start_regime_analysis. The follow-on text clarifies it launches an asynchronous task whose result surfaces through get_mr_scan_progress, so the agent knows exactly what class of operation this is.

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 context: the daily allowance (a refused call does not count and the count is available via get_started and each run's answer), the 30s–3min runtime, and the fact that a run started here needs no show_report_card. It also explains the non-obvious fallback behavior when a user asks for an unsupported index (DAX/FTSE → S&P 500 scan and nothing runs). It does not explicitly contrast against start_pairs_scan or other scan starters, so it falls short of full when/when-not/alternatives coverage.

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 context beyond the annotations: expected 1-5 minute runtime, the daily rate allowance with 'refused calls don't count', the response envelope {task_id, status, kind, dashboard_url}, that progress is polled via get_pairs_scan_progress, and that the row is auto-filled so no show_report_card is needed. The annotations only say it's a non-destructive, non-idempotent mutation; the description supplies the operational behavior an agent actually needs.

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

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

The critical content (purpose, alternative, cost, return shape) is front-loaded and the filter block is scannable. It is somewhat long and the report-card discussion plus the awkward leading indentation and line breaks add mild noise, but little of it is truly redundant.

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

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

With no output schema, the description correctly explains the return envelope, the `candidates` result (up to ten pairs, rounded stats), and `report_url`. What's missing is any mention of `duration`/`timeframe`, which materially affect a backtest-style scan, so an agent must guess those defaults.

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

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

Schema coverage is 0%, so the description carries the load and mostly does: it enumerates the index values and the fallback semantics, defines `question` as a one-sentence restatement used as the report title, and documents the nested `steps` filter shape (min_corr, max_pvalue, min_hl/max_hl, max_cov, window, max_h, min_rank) with defaults even though `steps` is an untyped array. However, `duration` and `timeframe` are never mentioned, leaving two of five parameters undocumented.

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

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

Opens with a specific verb+resource+scope: 'Scan an index for pairs of stocks that move together.' It immediately contrasts with the sibling start_regime_analysis ('For one chosen pair ... start_regime_analysis ... checks that pair directly'), so an agent can distinguish a universe-wide scan from a single-pair check without opening either schema.

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

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

Explicitly names the alternative tool and the condition selecting it (single pair -> start_regime_analysis), states the daily-allowance constraint and that refused calls are free, and warns that an unsupported index (DAX, FTSE 100) triggers a note and a substitution rather than a run. When-to-use, when-not, and cost are all covered.

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 far beyond the annotations: states the first call is a no-op that only returns a question, that an account tracks one strategy at a time and the replace flow stops the old one while keeping its record, that setup is 100k/90 days with a six-month check, that the first update arrives after the next US market close, that a long check falls back to async, and that no order or money movement occurs. This resolves the non-idempotent, non-destructive hints into concrete outcomes.

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

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

Purpose and routing are front-loaded, but the body is long and narrative, with awkward constructions ("It is what 'start it live, follow it...' ask for") and a typo ("goes on on QuanterLab"). Most content earns its place, but the same lifecycle could be stated in noticeably fewer words.

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 7-param, no-output-schema, stateful mutation tool, the description covers the full lifecycle: input sources, confirmation gating, concurrent-strategy conflict, async fallback, error surfacing via `message`, and where to check status afterwards. 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 0%, so the description carries the full burden and does: each of the 7 args is explained, including the mutually exclusive task_id/study/project_id sources with where each id comes from, and non-obvious semantics for live_version, replace, replace_id ("as the answer that asked names it"), and confirm.

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 opening sentence states a specific verb and resource ("Start a strategy live... on live market data, on paper") and explicitly contrasts with the sibling save_trading_config and forward-references my_paper_trades. An agent can immediately tell this apart from the backtest/scan starters and from save_trading_config.

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

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

Explicitly enumerates the user phrasings that should trigger this tool, spells out the two-phase confirm flow (first call returns `ask`, second call with confirm=true), and names the alternative (save_trading_config) that does NOT go live. It also gives the exclusion condition for the replace path and requires a human yes before proceeding.

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

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

Annotations only declare non-readonly, non-destructive, non-idempotent; the description adds real behavior: the project runs exactly as saved at a point-in-time anchor, the `index` override applies for this run only and leaves the saved project untouched, and there is a daily allowance where refused calls don't count. That rate-limit and no-side-effect-on-project detail is exactly what annotations cannot 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?

The core call-routing information is front-loaded, but the middle is bloated with UI narration ('lights each card as it runs', 'next steps as choices') and `report_url` is introduced twice, first as '(report_url, below)' and again in its own paragraph. Several sentences could be cut without losing agent-relevant meaning.

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

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

With no output schema and no schema descriptions, the description nonetheless covers the full lifecycle: how to obtain the id, what the task id is for, what the progress answer will contain (result, per-branch comparison to holding, report_url, lab_url), and the quota constraint. Nothing needed to invoke or follow up is missing.

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

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

Schema coverage is 0%, so the description has to carry all three parameters, and it does: project_id's source, question's purpose (one-sentence restatement, used only as the report title), and index's three allowed values plus the DAX/CAC/FTSE substitution behavior. That is genuinely useful content, but the `index` guidance is buried in a dense run-on sentence rather than crisply enumerating the enum.

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 one of your saved lab projects... return a task id to poll') and pins down the scope: the circuit at its point-in-time anchor, no settings but `index`. It is immediately distinguishable from sibling starters like start_paper_trade and start_backtest.

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

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

Explicitly routes the agent: get `id` from `list_my_primitives_projects`, poll `get_primitives_run_progress`, and notes that a run started here needs no `show_report_card`. It also names the alternative path (start_paper_trade with the run's task_id for live paper tracking).

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 context beyond annotations: async task behavior, 30 seconds to 2 minutes runtime, daily allowance, refused calls not counting, the `{task_id, status, kind, dashboard_url}` return shape, and how `get_regime_analysis_progress` later supplies `result` and `report_url`. It also explains the chat card behavior and that `show_report_card` is unnecessary, with no contradiction of `readOnlyHint=false` or `destructiveHint=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 description is front-loaded with the one-stock versus pair distinction and is organized clearly into result, Args, and async/report behavior. It is still lengthy and repeats some result/report details across paragraphs, so it is comprehensive but not 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?

For a complex async analysis tool with no output schema, it covers inputs, runtime, quota behavior, return shape, progress retrieval, report artifact, and UI behavior. Nothing material needed to invoke it correctly appears to be missing.

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

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

Schema description coverage is 0%, but the description compensates with an Args section covering all six parameters: required `ticker`, optional `ticker_b` pair behavior, `mode='volatility'`, default `years=2`, `params` override examples such as `hmm_enabled` and `mc_simulations`, and `question` as the report title. This gives meaning well beyond the bare schema.

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

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

States a specific action: analyze one stock or check one chosen pair, and enumerates what each path does. It explicitly distinguishes itself from `start_pairs_scan` and `start_regime_optimization`, so an agent can select it without opening sibling 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 routing: use it for a single stock or a specific pair, use `start_pairs_scan` for an index-wide search, and use `start_regime_optimization` for threshold grid-search rather than descriptive analysis. It also names the natural-language prompt it answers: "is X / Y a tradable pair?"

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

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

The description adds substantial behavior beyond the annotations: expected 2-10 minute runtime, the immediate return shape, progress polling via a sibling, daily allowance behavior, refusal handling, the 500-backtest guard, waiting behavior, and report generation. These details are consistent with readOnlyHint=false, idempotentHint=false, and destructiveHint=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 purpose is front-loaded and the length is largely justified by 14 parameters and nested configuration semantics. Some passages about indicator settings and swept columns are convoluted, but the overall structure follows a useful purpose, return, constraint, and Args progression.

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 properly explains the immediate return keys, the progress result, report_url, and runtime expectations. It is nearly complete for calling the tool, though the advanced outer-window parameters are not explained.

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

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

Schema description coverage is 0%, so the description must carry parameter meaning; it documents the required ticker, base_config shape, param_x/param_y structure and accepted names, duration, n_regimes, mode, objective, and question in useful detail. It leaves timeframe, outer_opt_bars, outer_step_bars, and outer_test_bars undocumented, and grid_steps is only referenced indirectly.

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 gives a specific verb and resource: it runs regime-aware threshold optimization via HMM regime detection and per-regime grid search. It clearly identifies the progress sibling used to retrieve completion/result, but it does not explicitly distinguish this tool from start_regime_analysis.

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 explains that the run is long-running, that get_regime_optimization_progress should be used for progress/result, that a completed run carries report_url, and that no show_report_card is needed. It also notes the daily allowance and refusal behavior, but it does not state when to prefer start_regime_analysis versus this optimization 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?

Adds far beyond annotations: the call blocks while the run is likely to finish and otherwise returns a card that self-updates, runtime is ~30s–2min, there is a daily allowance and refused calls don't count, and the returned shape is `{task_id, status, kind, dashboard_url}`. It also explains `oos_pct` semantics (held-back data never tested) and that result detail scales with run length. Consistent with readOnly=false / idempotent=false ('a change is a new run').

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

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

Front-loaded with purpose, then sweep rules, then method ids, then output workflow — a sensible order. It is long but dense with distinct facts; only minor waste (the allowance point is restated in two places, and raw indentation from a docstring leaks through).

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

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

Given a 22-param, no-output-schema tool, the description covers what an agent needs to call it correctly: required fields, the polling successor, the return shape, cost/allowance, and the sweep-vs-single-run decision. The remaining gap is the undocumented tuning parameters, which the description partially excuses by promising defaults surfaced in 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 0% across 22 parameters, so the description carries the burden. It does well on the high-value ones — `sweep` gets a full shape, step bounds and objective choices; `primary_method` gets id/params structure with all four ids and aliases; `question` and `oos_pct` are explained. But roughly sixteen parameters (duration, leverage, direction, timeframe, spread_bps, regime_filter, risk_budget_k, signal_params, stop_loss_pct, take_profit_pct, max_holding_days, position_sizing*, risk_per_trade_pct, commission_per_trade, initial_capital) are undocumented anywhere, relying only on 'sensible defaults'.

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?

Opens with a specific verb and resource ('Run a Stochastic Methods backtest') and names the concrete model families (OU, Kalman), then explicitly contrasts with the sibling `start_backtest` (indicator rules) by stating this engine fits a stochastic model to the price series. An agent can distinguish it from every other start_* sibling 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?

Explicit routing: grids/sweeps/'best setting' must be ONE call with `sweep`, 'never many single runs', with the reason (one task, one run of allowance). It also routes to `list_stochastic_methods()` for valid method ids and to `get_stochastic_backtest_progress` for results, and states a run started here needs no `show_report_card`.

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

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

Beyond annotations, it discloses the daily allowance, that a refused call does not count, and where to check today's count. It explains asynchronous behavior: get_primitives_run_progress follows by task_id, and the final answer includes result, report_url, and offers (e.g., start_paper_trade). It also describes the circuit card drawing and lighting each card as it runs, providing rich behavioral context without contradicting the annotations.

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

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

The description is front-loaded with the core purpose and organized into paragraphs plus a clear Args section. It is lengthy, with some repetitive or parenthetical details (e.g., repeated settings and stop-loss explanations), but the complexity of seven optional parameters and multiple modes justifies most of the length. Minor tightening would improve 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 explains the return shape: result, report_url, and offers each with its exact call. It covers async follow-up via get_primitives_run_progress, daily allowances, special index handling for mvo, and the study path with to_today. This is enough for an agent to call the tool correctly across its modes.

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

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

Schema description coverage is 0%, but the Args section fully compensates: it lists the allowed test values, explains ticker as an optional symbol, details index options and their caveats for mvo, and gives per-test settings ranges plus the universal stop_loss setting. It also explains question, study, and to_today semantics, including how settings change behavior. This is comprehensive parameter documentation well beyond the schema.

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

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

The description states a specific verb and resource: 'Runs one of QuanterLab's ready tests on a stock or fund as a circuit of the lab's cards.' It explicitly lists the ready tests (mean_reversion, trend_following, etc.) and distinguishes them from custom backtests by scoping the tool to 'ready tests' and referencing get_started's card. This gives an agent enough to separate it from sibling start_* tools.

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

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

It gives clear usage context: a test picked from get_started's card or named in words runs as it is, and it explains the study vs. test paths and to_today behavior. It also notes that a ready test needs no show_report_card. However, it never explicitly says when to choose this over sibling tools like start_backtest for custom strategies, leaving that comparison implicit.

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

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

Beyond the annotations, the description discloses the 1–5 minute runtime, daily allowance behavior, refusal semantics, returned fields, progress behavior, report URL, grid-size limits, and fallback `offers` for oversized requests. These are meaningful operational traits not covered by the readOnly/openWorld/idempotent/destructive hints.

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 long but front-loads the core purpose, default behavior, and result flow before moving into the detailed Args section. It is necessarily detailed for a 12-parameter tool, though some phrasing and repeated caveats could be trimmed.

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

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

Given the complexity, nested objects, no output schema, and limited annotations, the description is complete enough for an agent to call the tool correctly. It covers inputs, defaults, limits, async progress behavior, returned fields, and report generation.

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

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

With 0% schema description coverage across 12 parameters, the description fully compensates by documenting every argument, including defaults, minimums, enum values, nested `base_config` shape, `param_x`/`param_y` naming rules, and `grid_steps` limits. This adds substantial meaning beyond the bare schema.

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

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

The description opens with a specific verb and resource: 'Run a walk-forward optimization of an indicator rule.' It also explains the walk-forward mechanic and distinguishes the tool from siblings by naming `get_walkforward_progress` and `show_report_card`.

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

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

The description makes the default-driven usage clear: settings left open run with sensible defaults, and 'a change is a new run.' It names the progress tool and says no `show_report_card` is needed, but it does not explicitly state when to choose this over a plain `start_backtest`.

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

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

Annotations already establish readOnly/non-destructive/non-open-world, and the description adds materially beyond them: conditional fields (`figures` only for runs of a year or longer, `candidates` only for scans), the full verdict enum, and the fact that `report_url` opens without a login. That is exactly the behavioral context an agent cannot get from 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?

Given there is no output schema, the Returns block is justified and the conditional-field notes earn their space. Structure is a bit inverted — the tool's own action is in the last paragraph and the return inventory leads — but there is little filler.

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

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

With no output schema, the description carries the full return-shape burden and discharges it: enumerated keys, which are conditional, the verdict vocabulary, and the access properties of `report_url`. An agent can call this and interpret the response without opening anything else.

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 0% schema description coverage, the description must carry the parameter, and it does: 'task_id: A task id from any earlier `start_*` call' tells the agent where the value comes from and links it to the sibling tools that produce it. It does not say what happens with an unknown or stale id, which prevents 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?

The first line describes the artifact ('the summary of a run: a verdict, a headline, a short narrative and next steps') and the closing line states the action implicitly: 'this tool reads a run again later.' It distinguishes itself from the family of progress tools by positioning itself as the post-hoc read, though the verb is buried at the end rather than front-loaded.

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

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

'The progress tools give the same summary as `result` when a run finishes, so this tool reads a run again later' clearly establishes the when: after completion, to re-fetch. It names the alternative category explicitly. It stops short of an explicit 'do not use while running' rule, though that is strongly implied.

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