AI Backtester

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

Annotations already declare readOnlyHint=true and openWorldHint=false, and the description adds genuinely new behavioral context: no cost, no market-data access, and concrete failure classes it detects (impossible thresholds, strategies with no exit). It does not describe the shape or granularity of the verdict returned.

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

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

Three short sentences, front-loaded with the core action, then cost/safety, then concrete examples of what it catches. No filler.

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

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

For a simple one-parameter, read-only tool with no output schema, the description covers purpose, cost profile, and detection scope, and annotations carry the safety profile. The only real gap is that the return value/verdict format is not described.

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

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

Schema description coverage is 100% for the single 'spec' parameter, which points the agent at get_strategy_spec_rules. The description adds no further meaning about the spec object's expected structure, so the baseline of 3 applies.

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

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

States a specific verb (validate) and resource (a strategy spec) plus the exact scope of the check: proving whether rules can ever fire. The phrase 'without running it' and 'touches no market data' implicitly separates it from run_backtest, the main alternative an agent might confuse it with.

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

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

The description gives clear context for use ('costs nothing', static analysis) that signals this is a cheap pre-flight check before incurring backtest cost, but it never explicitly names run_backtest as the alternative or states when this tool should be skipped.

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 and openWorldHint=false, and the description adds real value: it discloses which metrics come back and the important caveat that runs over different markets/periods are flagged as non-comparable. That comparability handling is genuinely useful behavioral context beyond the annotations.

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

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

Two dense sentences, no filler, metrics and cardinality listed up front and the comparability caveat placed last. Every clause earns its place.

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

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

No output schema exists, and the description compensates by naming the returned fields (return, buy & hold, drawdown, Sharpe, trades, win rate) and the mixed-period behavior. Complete enough to call correctly, though it says nothing about ordering or error cases (e.g., an unknown run id).

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 one parameter and 0% schema description coverage, the description carries the burden and does: it states the 2-6 range and that runIds may be the caller's own or public runs, adding access-scope meaning the schema does not express (the schema only encodes min/maxItems).

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 (compare) plus resource (saved runs/backtests), with the returned metrics enumerated and a 2-6 cardinality constraint. It is clearly distinct from single-run readers like get_run, though it never names a sibling explicitly to sharpen the contrast.

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

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

Usage is implied by the framing (side-by-side comparison of multiple runs) and the 2-6 constraint, but there is no explicit when-to-use vs when-not, nor a pointer to get_run for single-run inspection.

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 it is a non-destructive write (readOnlyHint=false, destructiveHint=false, openWorldHint=false). The description adds real context beyond that: cost behavior, a Pro tier requirement, and a preview of the returned analytics (equity, drawdown, Sharpe, contribution, correlation). It does not disclose persistence/auth details beyond the tier gate.

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

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

A single, front-loaded sentence that leads with the action, then the output, then cost/tier. Dense and informative with em-dash framing, and no filler. Slightly run-on but every clause carries value.

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 previews return contents and adds cost/tier context. It is nearly complete for a create tool; minor gaps are the lack of linkage to downstream tools (e.g., run_portfolio) and behavior on name collisions.

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?

Top-level schema description coverage is 0%, so the description carries weight. It clarifies the 'weight' concept via 'each with a share of the capital' (the nested items do document id and weight with a default of 1). But the required 'name' parameter is never addressed, so the compensation is only partial.

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: 'Put several of your saved strategies together as a portfolio.' This is clearly the creation operation, distinguishable from get_portfolio (fetch), run_portfolio (execute), and update_portfolio (modify). The scope of the tool is unambiguous.

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

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

Provides a cost guideline ('Combining saved backtests costs nothing') and a tier gate ('Pro'), which are useful usage signals. However, it names no alternative tools and gives no explicit when-to-use/when-not-to-use guidance relative to update_portfolio or run_portfolio, leaving the agent to infer.

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

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

Annotations already declare destructiveHint=true and readOnlyHint=false, but the description adds non-obvious consequence detail beyond them: strategies and their results are retained, and the operation requires an explicit confirm gate plus user confirmation. This is exactly the kind of blast-radius context 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?

Three short sentences, front-loaded with the action and its scope, then the safety prerequisite. 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, so return values need not be explained, and annotations cover the safety profile. The description covers destruction scope and the confirmation requirement; only the `id` parameter's expected form and whether the deletion is reversible are left unaddressed.

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

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

Schema description coverage is 0%, so the schema documents neither parameter. The description clarifies `confirm` (must be true, ask the user first), which is the less obvious of the two, but leaves `id` entirely undocumented in both places. With only half the parameters covered, this lands at baseline.

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

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

States a specific verb (delete) and resource (portfolio), and immediately scopes the effect by noting strategies and their results are kept, which distinguishes it from the sibling delete_strategy. An agent can tell exactly what this removes and what survives without opening the schema.

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

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

Gives one firm precondition ('confirm' must be true: ask the user first) which is real guidance, but never names an alternative tool or a when-not-to-use condition. Usage is implied by the confirm gate rather than by explicit routing against siblings like delete_strategy.

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

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

Annotations already declare destructiveHint=true, but the description goes further by enumerating the concrete consequences: removal from strategies/Browse/profile, the forward test stopping, results becoming private, and irreversibility. This is exactly the behavioral context an agent needs before a destructive 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?

Two tight sentences, front-loaded with the action and consequences before the safety instruction. Every clause earns its place, with no repetition of the title or name.

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 destructive tool with no output schema, the description covers consequences, irreversibility, and the confirmation gate. Nothing an agent needs to invoke it safely is missing.

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

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

Schema description coverage is 100%, so both `id` and `confirm` are already documented in the schema, anchoring the baseline at 3. The description reiterates the confirm requirement but adds no format or sourcing detail for `id` beyond what the schema provides.

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 (delete) plus resource (strategy) in the first sentence, and the scope is scoped to the caller's own strategies. It is cleanly distinguishable from adjacent siblings like demote_strategy or delete_portfolio.

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

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

It gives concrete preconditions: 'confirm must be true' and 'ask the user first', which tells the agent when it may proceed. It does not name alternatives (e.g. demote_strategy for a softer outcome) or state explicit when-not-to-use cases, 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?

Annotations already declare destructiveHint=true, but the description goes further by naming exactly what is destroyed (the forward record) and why the operation is irreversible ('a forward test cannot be paused and resumed'), which is critical context an agent cannot derive from the schema or annotations.

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

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

Two sentences, front-loaded with the destructive action and consequence, followed by the rationale. Every sentence carries information and none is redundant.

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

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

For a destructive single-parameter mutation with no output schema, the description supplies the key missing context: irreversibility and the reset-to-zero consequence of a subsequent promote. The only gap is the undocumented 'id' parameter, which is minor given the tool'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 description never mentions the single required 'id' parameter, so it does not explain what the id identifies or what format it takes. The phrase 'the forward record' indirectly hints at the target, but the compensation is weak; a 3 reflects minimal viable coverage for a one-parameter tool.

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 ('Stop forward testing') plus the material consequence ('DISCARD the forward record'). It also differentiates itself from the sibling promote_strategy by explaining what promoting again does, so an agent can distinguish the two without opening either schema.

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

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

The description makes the use case clear (ending a forward test) and explains the alternative path's behavior ('Promoting again starts from zero at the new date'), which implicitly routes the agent between demote and promote. It never states an explicit 'when to use this vs X' rule or prerequisites, so it falls short of a 5.

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

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

Annotations only declare it is not read-only/destructive/open-world, but the description adds real context beyond them: it consumes one backtest credit, requires a Pro plan, and produces a run result. It omits idempotency/repeat-fork behavior and error cases, but the added cost and gating details are substantive.

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 effect, and the sourcing instruction follows logically. The standalone 'Pro.' fragment is abrupt though effective; overall it earns its place with no filler.

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

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

For a single-param tool with no output schema, it covers what the tool does, its side effects, the plan requirement, and how to obtain the argument. What is returned (e.g., how the new strategy is identified) is left implicit, a minor gap.

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

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

Schema coverage is 0% (a bare string with no description), so the description carries the full burden and does so well: it clarifies the param is a run id (not a strategy id), which is subtle given the tool is about strategies, and names two concrete sources for it.

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 (copy/fork) and resource (someone else's public strategy) plus the additional side effect (runs it once to produce a result). It clearly describes creating a private copy, which distinguishes it from siblings like get_strategy or run_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?

Tells the agent exactly what to pass (the id of one of the strategy's public runs) and where to get it (search_strategies or a report link), and flags the 'Pro' requirement. It gives clear context for use but does not state exclusions or contrast with any alternative 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 establish readOnlyHint=true and openWorldHint=false, so safety is covered. The description adds genuine behavioral context by disclosing downsampling and the rationale for the small default, but it says nothing about data granularity, what happens with an invalid/unknown runId, or the shape of returned points.

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

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

Two sentences, front-loaded with the data shape and then the sizing constraint. The second sentence justifies the default rather than stating behavior, but it is short and informative enough to earn its place.

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

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

A read-only two-parameter tool with no output schema, so the description should describe what a curve sample looks like. It covers the sampling cap but leaves the return structure and the runId contract unspecified.

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

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

Schema description coverage is 0%, so the description must carry parameter meaning. It explains maxPoints well (downsampling cap, deliberately small default) but never explains runId, leaving half the parameters undocumented.

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

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

States a specific resource and shape: account equity over time for a run, downsampled to maxPoints. It is clear what the tool returns, but it does not differentiate itself from adjacent read tools like get_trades, get_run, or get_forward_result.

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

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

No guidance on when to use this versus get_trades, get_run, or get_forward_result, and no mention of prerequisites such as needing a completed run. The only usage-adjacent content is about response sizing, not tool selection.

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 and openWorldHint=false, so safety is covered. The description adds useful conceptual context (fitted-to-past vs. genuinely out-of-sample), but says nothing about what happens if the strategy was never promoted or what data window is used.

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

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

Two short sentences, front-loaded on the actual comparison. The closing sentence is partly rhetoric rather than information, but it does convey why the tool exists, so it mostly earns its place.

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

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

With no output schema, the description should have indicated what is returned (which backtest/forward metrics) and any precondition on the strategy's state. It explains the concept well but leaves the operational contract thin for a tool an agent must invoke blind.

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 ('id') with 0% schema description coverage, and the description never states that the id is a strategy identifier or what form it takes. With the schema silent, the description was the only place to compensate and it does not.

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 comparison (backtest vs. forward performance since promotion) over the implied resource (a strategy). It is distinguishable in spirit from compare_backtests, but the description never names that sibling or explicitly says the input is a strategy id, leaving a small ambiguity.

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

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

No when-to-use, when-not-to-use, prerequisites (e.g., the strategy must have been promoted to have forward results), or named alternatives. The line 'This is the number that matters' is persuasive framing, not usage guidance.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered, but the description adds two non-obvious traits the schema cannot express: the cost is 'Free', and there is a fallback resolution path when the portfolio has never run. These genuinely extend 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?

A single front-loaded sentence leading with the verb and resource, with the fallback tucked into a parenthetical. Dense but no filler sentences, and the main action comes first.

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 annotation-derived return info, the description meets its burden by enumerating what comes back (equity numbers, trades, per-strategy parts) and covering the empty-history case. Read-only single-param tool, so little else is needed.

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 'id' parameter, so the description must carry the meaning. 'Show a portfolio' weakly implies the id is a portfolio identifier, but it never states format or how it differs from a strategy id in this sibling-heavy family. Marginal compensation for the coverage gap.

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

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

States a specific verb (Show) and resource (portfolio) and clarifies that it returns the portfolio's latest run — combined equity, trades, and per-strategy breakdown — or the combined saved strategy results if it has never run. This is richer than a bare name restatement and hints at a distinct role versus siblings like get_run or get_strategy, though it does not name those alternatives.

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

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

There is no explicit when-to-use guidance and no routing against the many portfolio siblings (get_run, get_equity_curve, list_portfolios, etc.). The fallback condition (never run → combined saved results) is a behavioral detail, not usage guidance, so an agent still has to infer when this tool is the right pick.

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 and openWorldHint=false, so the safety profile is covered. The description adds genuine context beyond that: access scope (your runs or anyone's public run) and that the response includes a link to the full report.

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

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

Two short sentences, front-loaded with what the tool returns and followed by the sibling routing hint. Every clause earns its place with no filler.

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

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

There is no output schema, and the description compensates by naming what comes back (headline numbers plus a report link). For a single-parameter read tool this is nearly complete, with only the runId format/provenance left implicit.

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

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

Schema coverage is 0% for the single runId parameter, so the schema itself explains nothing. The description does state the run is fetched 'by id', which gives minimal meaning to the parameter, but it never explains the id's format or where the agent obtains it.

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 ('the headline numbers of one saved run by id') and bounds the scope ('yours, or anyone's public one'). It also names the sibling tools that cover a different granularity, so an agent can distinguish it from get_trades and get_equity_curve 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?

It gives explicit routing guidance: this tool for headline numbers, get_trades and get_equity_curve for detail. That is a clear when-to-use-alternative rule, though it does not state exclusions or prerequisites for this tool itself.

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 and openWorldHint=false, so safety and scoping are covered structurally. The description adds that the response includes the strategy plus its 'current spec', which is mildly useful, but says nothing about pagination, permissions, or behavior when the id is unknown.

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

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

One sentence, no filler, with the resource and the lookup key front-loaded. Nothing could be trimmed without losing 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 carries the burden of describing the return value; it only says 'a strategy and its current spec' without indicating what those contain or the failure mode for a bad id. For a simple one-parameter read tool with read-only annotations, this is adequate but incomplete.

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 'id' parameter, so the description must carry the meaning. 'by id' identifies it as a lookup key but adds no format, source, or example detail beyond the parameter 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 (fetch) and resource (a strategy and its current spec) keyed by id, which clearly separates it from list_strategies and hints at the difference from get_strategy_spec_rules. It never explicitly names a sibling to route against, 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?

There is no guidance on when to call this versus the many sibling read tools (get_strategy_spec_rules, list_strategies, search_strategies, get_run). The agent must infer usage from the name alone.

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 and openWorldHint=false, so safety is covered. The description adds substantive context beyond that: it is a static reference payload whose contents (indicator ranges, operators, examples) are enumerated, which tells the agent this is documentation retrieval rather than data lookup. It does not explicitly say the content is static/cacheable, which keeps it short of 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?

Two sentences, both front-loaded: the first states the prerequisite and when it applies, the second enumerates the payload. No filler or restatement of the title.

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

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

No output schema exists, so the description carries the return-value burden and does so by enumerating the four content categories. For a zero-parameter reference tool, an agent has everything it needs to decide when and why to call it.

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

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

The tool takes zero parameters, so per the rubric the baseline is 4. The description correctly does not waste space describing nonexistent 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?

Specific verb and resource: it 'returns the full strategy format' and enumerates exactly what that contains (JSON schema, supported indicators with ranges, condition operators, worked examples). This clearly separates it from siblings like get_strategy or check_strategy, which operate on concrete strategies rather than the format spec.

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

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

Explicit when-to-use: 'REQUIRED reading before calling run_backtest or check_strategy for the first time.' It names the two sibling tools that depend on this knowledge and the trigger condition ('for the first time'), leaving nothing to inference.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is clear. The description adds ordering ('in order') and scope, but omits pagination behavior (limit/offset defaults), return format, and whether 'every trade' is subject to result caps.

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

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

A single, front-loaded sentence with zero waste. Every word contributes to the core meaning without redundancy.

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

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

For a three-parameter, paginated list tool with no output schema and no schema descriptions, the description is too sparse. It omits pagination semantics and makes 'every trade' misleading given the default limit of 100, which may truncate results.

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 compensate but does not. It implies the runId parameter via 'from a saved run' but never explains limit or offset, leaving two of three 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?

Clearly identifies the resource (trades) and scope (from a saved run) with ordering noted. Distinguishes from siblings like get_run and get_equity_curve, though it lacks an explicit verb such as 'List' or 'Retrieve'.

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 provides no guidance on when to use this tool versus alternatives like get_run or get_equity_curve. It simply states what is returned, leaving the agent to infer appropriate usage contexts.

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 and openWorldHint=false, so the safety profile is covered. The description adds genuinely useful output context (that each entry includes a strategy count), which matters because there is no output schema, but it says nothing about ordering, pagination, or whether empty portfolios appear.

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

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

A single front-loaded sentence with zero filler. The verb and resource lead, and the return-content clause is the only added detail.

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 list tool with annotations covering safety and no output schema, the description is nearly complete: it names the resource and the salient field returned. Only minor gaps (ordering, whether the list can be empty) remain.

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

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

The tool takes zero parameters, so the schema has nothing to document and there are no semantics for the description to compensate for. Baseline of 4 applies.

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

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

States a specific verb (List) and resource (your portfolios) and adds a scope detail: each portfolio's strategy count. An agent can distinguish it from get_portfolio (singular) and list_strategies, though the description never names those siblings explicitly.

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

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

No when-to-use guidance and no routing to alternatives. With get_portfolio, list_strategies and search_strategies in the sibling set, an agent gets no signal about when this overview listing is preferable to fetching a single portfolio. Usage is only implied by the name.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds the 'saved to this account' scoping, which is useful but overlaps with openWorldHint=false, and it says nothing about pagination behavior, ordering, or result size despite having pagination params.

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

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

A single front-loaded sentence with no filler or repetition. It is efficient, though its brevity leaves real gaps that the other dimensions penalize.

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 low-complexity read-only list tool with annotations covering safety and no output schema, this is adequate but thin: pagination behavior and the sibling distinction from search_strategies are missing, which an agent would need 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% for both limit and offset, and the description provides no pagination semantics at all. With two undocumented non-trivial parameters, the description 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 and resource ('List strategies') plus a scope qualifier ('saved to this account'), which is enough to identify the operation. It does not distinguish itself from the sibling search_strategies, so an agent must infer the difference between listing and searching.

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 offers no when-to-use guidance, no prerequisites, and no mention of the obvious alternative (search_strategies) for filtered retrieval. Usage is only implied by the verb 'List'.

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 safe read profile (readOnlyHint=true, openWorldHint=false), yet the description adds real operational context: the perp default, Binance's lot-size ticker prefixing (1000PEPEUSDT vs PEPEUSDT on spot), and spot-only coins/quote assets. It omits return shape and pagination/limit behavior, which keeps it from 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?

Two dense sentences, front-loaded with the core action before the ticker caveat. Every clause carries information, though the second sentence is long and would read better as a short list of spot-only quirks.

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 should ideally sketch what comes back (list of symbols/tickers). It conveys scope, defaults, and ticker conventions well enough for correct invocation, leaving only the return shape implicit.

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

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

Schema coverage is 67% (limit is undocumented in the schema). The description compensates meaningfully for the two semantic parameters: it confirms perp as the default market and warns that query strings may need the exchange's prefixed form, which the schema's simple "PEPE" example does not convey.

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 (search) and resource (every market with history in the archive), and explicitly splits the corpus into USD-M perpetual futures (default) and spot. No sibling tool covers symbol lookup, so the scope is unambiguous for an agent.

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?

"Worth calling before writing a strategy" gives a clear when-to-use trigger and explains the failure mode of skipping it (guessing the ticker finds nothing). It stops short of explicit exclusions or naming an alternative, but no sibling alternative exists.

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 flag destructiveHint=true and readOnlyHint=false, and the description usefully qualifies this by stating nothing mutates unless apply is true, plus that the operation is free and re-weights existing run output. It adds real behavioral context beyond the annotation set, though it does not discuss permissions or the exact shape of the comparison output.

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 search-plus-validation action and every clause is substantive, but the conversational, dash-heavy style ("The last 30% is the honest number; say so") is denser and less scannable than an ideal definition.

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

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

For a 4-parameter tool with no output schema, the description covers the mechanics, prerequisites, mutation semantics, objectives, and what the response compares. An agent has everything needed to call it correctly and to explain results to the user.

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

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

Schema coverage is 50% (cap and apply are documented in-schema), and the description adds meaningful semantics for the enum by naming all six objectives and noting that min_drawdown/fast_recovery never fall below the current return. However, the phrase "these two" is ambiguous and `id` is left undocumented.

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

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

States a specific action (search a portfolio's allocations for the best score), scopes it to the first 70% of the last run, and describes what is returned (out-of-sample 30% vs current and equal-weighted allocations). This clearly distinguishes it from optimize_strategy and run_portfolio among the siblings.

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

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

Gives explicit prerequisites ("Needs a run first (run_portfolio)"), cost behavior ("Free: it re-weights the run's results"), and mutation conditions with a directive ("Nothing changes unless `apply` is true — ask the user before applying"). An agent knows exactly when and how to invoke it.

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

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

Discloses substantial behavior beyond the annotations: a 60/20/20 walk-forward split with an untouched holdout, low-trade candidate rejection, score discounting by number of attempts, and a fixed cost of 20 backtests from the quota. It even pre-frames the common 'winner is worthless' outcome. This is exactly the kind of caveat an agent needs, and nothing contradicts the readOnlyHint=false / destructiveHint=false 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?

Four dense sentences, all load-bearing, with the core action front-loaded and the methodology, cost, and expected-outcome caveat following in priority order. No filler or restatement of the title.

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

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

With no output schema, the description carries the return-value burden; it explains the report's purpose (how much of the result the search explains) but not the concrete shape of the response (winner params, scores, rejection counts). For a 5-param sweep tool with search cost, the behavioral picture is otherwise complete.

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

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

Schema coverage is 60% (pointsPerParam and maxCombinations have constraints but no descriptions). The description partially compensates by explaining that scores are 'discounted by the number of attempts' and that it 'uses 20 backtests from the quota', giving the undocumented search-size params practical meaning. It also reinforces minTrades via 'rejects candidates that barely traded'.

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: 'Search a strategy's declared params for the best combination' plus a distinctive second function ('report how much of that result is explained by the search itself'). The scoping to a strategy's declared params implicitly separates it from optimize_portfolio, but no sibling is named explicitly.

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

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

Usage is implied through methodology rather than stated conditions: an agent infers this is for parameter sweeps on an existing strategy. It never names alternatives like optimize_portfolio, propose_optimization_plan, or plain run_backtest, nor says when not to use it. The note that a 'not worth trading' conclusion 'is the tool working, not failing' is useful expectation-setting but not routing guidance.

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

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

Annotations declare readOnlyHint=false, so this is a state-changing operation, but the description doesn't say what state changes or what gets created (a forward test run?). It doesn't mention whether the strategy must be in a particular state, whether the operation is reversible, or what happens to existing forward tests. The philosophical framing crowds out behavioral disclosure.

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

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

Three sentences, two of which are aphoristic filler about backtest vs future tuning. The action is stated last, and the philosophical framing could be cut without losing operational information.

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

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

For a state-changing tool with no output schema, the description should explain what promotion does operationally, prerequisites, and likely follow-ups (get_forward_result, check_strategy). None of that is present; the description is conceptually evocative but operationally incomplete.

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

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

Schema description coverage is 100% and the single id parameter is documented in the schema ('Strategy id, from list_strategies'). The description adds nothing about the id or format, so a baseline 3 is appropriate.

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

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

The description says 'Begin evaluating a saved strategy on candles it has never seen,' which conveys the core action but uses metaphor ('candles it has never seen') rather than the domain term forward testing stated in the title. It never names forward testing explicitly, and it doesn't differentiate from siblings like run_backtest or get_forward_result.

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 contrasts backtesting with forward testing conceptually ('A backtest can be tuned until it looks good; the future cannot') but never states when to call this tool vs run_backtest, check_strategy, or get_forward_result. No trigger conditions 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 and openWorldHint=false, so the safety profile is covered. The description still adds real value by disclosing the return contents and, notably, the clamping behavior when a requested range exceeds what a param can affect, plus the zero-cost guarantee. It does not explain what happens to requests exceeding maxCombinations, leaving one behavioral 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?

One sentence, front-loaded with the core action, then the three outputs, closing with the cost reassurance. No filler and nothing buried.

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 readOnly annotations present and no output schema, the description sensibly describes the return payload itself. It is nearly complete for a preview tool, missing only the interaction between pointsPerParam and maxCombinations and any reference to the caller's strategy/portfolio context.

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 only 33%: spec points at get_strategy_spec_rules, but pointsPerParam and maxCombinations have no schema descriptions and no explanation here either. The description gestures at the concepts ('values per param', 'total combinations') without clarifying their semantics, defaults, bounds, or how maxCombinations truncates the sweep — a real gap for a tool whose whole purpose is predicting combination counts.

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 (show/preview) and resource (a parameter sweep), with an explicit enumeration of what is returned: values per param, total combinations, and clamped ranges. It implicitly distinguishes itself from the executing sibling optimize_strategy via 'before spending anything on it', but never names that alternative, so it falls short of a clean 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?

'before spending anything on it' and 'Costs nothing' make the use case clear: dry-run this prior to committing to an actual sweep. No explicit when-not or named alternative (e.g. optimize_strategy) is given, so an agent must infer the routing from the cost framing.

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 readOnlyHint=false and destructiveHint=false; the description adds real value by disclosing that nothing is persisted or published unless `save` is provided, and that identical previously-saved runs (private or public) are returned from cache instead of re-executed. That caching/dedup behavior is not derivable from annotations or 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?

Three sentences, front-loaded with the core action before the prerequisite and caching caveat. The 'a backtest is a question, not a publication' line is rhetorical but does compactly convey the side-effect-free default.

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 nested-object schema, no output schema, and modest annotations, the description covers the key agent-facing questions: prerequisite call, persistence semantics, and cache-hit behavior. Return values are only characterized as 'performance', which is acceptable without an output schema but leaves result shape unspecified.

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

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

Schema coverage is 100%, so the baseline is 3, and the description goes beyond it by tying `save` to persistence/publication and spelling out the identity key for cache hits (same rules, settings, period, completed months). It doesn't elaborate on `params` overrides or the nested visibility/strategyId fields, which the schema handles.

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 ('Run a strategy against real historical data and return its performance'), which is clearly distinguishable from retrieval siblings like get_run or get_trades. It does not explicitly name the nearest alternative (run_portfolio), so it stops short of full sibling differentiation.

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

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

It gives a concrete prerequisite ('Call get_strategy_spec_rules first if you have not already') and explains the cached-result condition that bypasses execution entirely. There is no explicit 'do not use this when...' routing to run_portfolio or optimize_strategy, but the operational context is clear.

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

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

Annotations declare readOnlyHint=false, destructiveHint=false, openWorldHint=false; the description adds real context beyond that: strategies are not modified, capital/dates are ephemeral ('used for this run and not saved'), one backtest per strategy is consumed, and prior finished-month results are reused. It does not, however, address what the result looks like or any failure conditions.

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 in the first sentence, with mechanics and defaults following. It is dense and long, and the parenthetical clauses about per-trade slicing add some drag, but every sentence carries operational information.

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

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

For a 4-parameter, side-effecting run tool with no output schema and 75% schema coverage, the description covers mutation semantics, ephemerality, cost, and date defaults. The only gap is the shape of the returned 'combined result', which is left vague.

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

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

Schema coverage is 75%. The description adds genuine meaning beyond the schema: capital is the split pool, and start/end default to the first day all markets have data through the start of this month, plus a note that these values are not persisted. That defaulting behavior is not in the schema.

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

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

States a specific verb and resource ('Run every strategy in a portfolio... show the combined result') and defines the scope of the run. This cleanly separates it from run_backtest (single strategy) and optimize_portfolio without requiring the agent to open their 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?

Usage is implied by the mechanics described (running a whole portfolio as a combined simulation), but no sibling is named and there is no explicit when-to-use versus run_backtest, compare_backtests, or optimize_portfolio. The defaults for dates/capital are given, which helps selection but is not routing guidance.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered. The description adds genuinely new behavior: the default Sharpe sort and its rationale (avoids surfacing overfit high-return results), plus the minTrades filtering behavior. Return format and pagination remain unstated.

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 front-loaded sentences with no filler, and the default-sort behavior leads. The explanatory clauses justifying Sharpe ranking and minTrades filtering earn their place by explaining non-obvious defaults.

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 15-parameter search tool with no output schema and near-zero schema coverage, the description covers only two parameters. It omits pagination (limit/offset), return shape, and the meaning of most filters, so it is not fully complete for correct invocation.

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

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

Schema coverage is only 13% across 15 parameters, so most filters (symbol, timeframe, minSharpe, maxDrawdownPct, etc.) are undocumented in both schema and description. The description only adds meaning for minTrades and the sort default, leaving the bulk of the surface unexplained.

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 ("Search public backtest results") and the "public" scope implicitly separates it from the private strategy tools. However, it never names a sibling like list_strategies or compare_backtests, so the agent must infer the boundary itself.

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

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

The description implies the discovery use case and explains the minTrades exclusion rule, which is useful guidance. But it offers no explicit when-to-use / when-not-to-use versus list_strategies or compare_backtests, leaving routing to inference.

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

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

The annotations already flag destructiveHint=true and readOnlyHint=false, so the safety profile is known. The description adds what is destroyed (the previous strategy list is fully overwritten) and implies name changes are benign, which is meaningful context beyond the annotations. It omits auth requirements and error behavior.

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

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

A single front-loaded sentence with the destructive replacement semantics in a parenthetical that directly follows the parameter it modifies. No filler, and the most important constraint is not buried.

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 small three-parameter mutation tool with no output schema, the description covers the two behavioral essentials: renaming and full replacement of strategies. It leaves partial-update behavior (name only) and failure modes unstated, which is a minor gap.

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

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

With 0% schema description coverage on the top-level parameters, the description does the compensating work: it maps 'name' to a rename and 'strategies' to a wholesale replacement list whose entries carry allocation 'shares' (weights). It does not explain the 'id' parameter or the min/max list limits, so not fully exhaustive.

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 specific verbs and resources: rename (name) or replace the strategies/weights of a portfolio. An agent can distinguish this from create_portfolio, delete_portfolio, and get_portfolio. It stops short of explicitly naming a sibling it should be preferred over, so it is clear but not maximally differentiating.

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 one real usage rule: strategies must be the complete list because it replaces the old one, which prevents accidental data loss. It offers no guidance on when to choose this versus create_portfolio or update_strategy, and no note on required permissions, so usage is only partially 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?

Annotations only declare readOnlyHint=false and destructiveHint=false; the description goes further by disclosing the real side effect of visibility changes — making a strategy private removes it and every saved result from Browse and the profile, and public restores them — plus the Pro plan gate. It does not describe idempotency or response behavior, so it falls short of 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?

Three sentences, front-loaded with purpose, then side effects, then the redirect to the correct tool for rule changes. Every sentence earns its place with no filler.

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

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

For a 3-param mutation tool with no output schema and no annotations beyond a title, the description covers the mutation's effects, plan gating, and where to go for rule edits. It does not state that name and visibility are independently optional, which is the only notable gap.

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

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

Schema coverage is only 33% (only 'id' is documented), so the description must carry the load for 'name' and 'visibility'. It does map them to meaning — rename maps to name, public/private maps to visibility with concrete consequences — and 'id' is anchored to list_strategies in the schema, though no constraints like maxLength 120 are echoed.

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 (rename a strategy / change its visibility) and implicitly scopes out the adjacent operation of changing rules. An agent can distinguish it from siblings like delete_strategy, fork_strategy, promote_strategy, or run_backtest without opening schemas.

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

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

The description gives a clear positive use case (rename, change visibility) and, crucially, an explicit alternative for the thing an agent might otherwise attempt here: 'To change its rules, run a backtest with the new spec and save.strategyId.' It lacks only a full when-not/alternative matrix, so 4 rather than 5.

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

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

Annotations only cover read-only and non-open-world; the description adds that the call validates the key and returns plan and weekly quota, which is real behavioral content, especially with no output schema. It stops short of describing failure modes or quota reset semantics, but it discloses what the agent will learn.

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

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

Two tight sentences with zero filler. The core action and its result are front-loaded, followed by the usage rationale.

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 no-parameter, no-output-schema diagnostic tool, the description conveys what it validates and what it returns, which is enough for correct invocation. Minor gaps remain around quota period semantics and error behavior, but nothing blocking.

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 schema has nothing to explain and the baseline is 4. Nothing in the description is needed to compensate for parameter documentation.

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 specific verbs and resources: confirm API key validity and report current plan plus weekly backtest quota. No sibling tool does this, so an agent can distinguish it immediately from the strategy/portfolio/backtest 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?

Explicitly recommends calling it first in a conversation so later failures aren't a surprise, which is clear triggering context. It doesn't state when not to call it or name a comparable alternative, but none of the siblings overlap with this function.

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