MarketHeist Backtest

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

Beyond the readOnly/idempotent/openWorld annotations, it discloses that template and strategy ids are answered from precomputed data (instant, not rate-limited) while custom assets and overlays are computed live, and that results carry provenance, caveats, and a reproduce-me hash. It also instructs the agent to surface caveats when reporting.

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

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

Front-loads purpose then usage, and every sentence carries real information for a 6-param nested tool. It is dense as a single run-on paragraph, and the long output enumeration could be tightened, but nothing is wasted.

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

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

For a complex tool with nested objects and no output schema, the description covers inputs, computation provenance, returned metrics, validity/cite blocks, and usage routing. An agent has everything needed to call it correctly and interpret 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 coverage is 100% (baseline 3), but the description adds meaning the schema does not enforce: the mutual exclusivity of template/strategy/assets, the definition of an 'independent bet' (correlation ≥ 0.5 groups), and the practical effect of the overlay. It reinforces rather than repeats 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?

Opens with a specific verb+resource ('Analyze an asset-allocation portfolio') and enumerates the exact metrics returned (CAGR, max drawdown, volatility, Sharpe, Sortino, Ulcer index, etc.), so an agent knows precisely what it produces. It also distinguishes itself from siblings like compare_portfolios, portfolio_returns, and portfolio_risk by 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?

Gives concrete triggering examples ('how did 60/40 / All Weather / Golden Butterfly perform' or a custom mix) and explicitly routes other needs to alternatives: seasonality/calendar years to portfolio_returns, drawdown/diversification to portfolio_risk, comparisons to compare_portfolios. It also states the exactly-one-of input contract.

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

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

Annotations already declare readOnlyHint/idempotent/non-destructive, so 'Read-only' is largely redundant. However the description adds real behavioral context beyond the structured fields: ids are precomputed from a monthly refresh while `assets` entries are computed live, and there is a hard limit of 2 custom entries and 24 distinct tickers per call. It stops short of noting any latency or cost differences between the precomputed and live paths.

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

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

The content is largely on-point and front-loads the purpose, but it is one dense wall of text with clause-heavy sentences and no visual breaks, making it harder to scan than an equivalent set of shorter lines. The side commentary ('the only fair comparison', the gold/Ivy dates) adds color but lengthens an already long block.

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?

Although there is no output schema, the description enumerates the returned metrics precisely (CAGR, volatility, max drawdown, Sharpe, Sortino, Ulcer, best/worst year, longest time underwater, per-portfolio full-window figures, pairwise correlations, calendar table) plus the alignment model. Nothing material is missing for a comparison tool of this complexity.

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

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

Schema coverage is 100% so the baseline is 3, but the description adds meaning the schema does not: the 'exactly one of template or strategy or assets' invariant per item, the source of ids (list_portfolios), and the live-vs-precomputed distinction with its 2-entry/24-ticker caps. These constraints go beyond the raw property descriptions.

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 ('Compare 2 to 4 portfolios ... side by side') and immediately scopes the operation to the COMMON window. Crucially it also names the siblings this is not for ('For one portfolio's detail use analyze_portfolio, portfolio_returns or portfolio_risk'), so an agent can separate it from the other portfolio tools 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?

It provides explicit trigger phrases ('All Weather vs Golden Butterfly vs 60/40', 'which of these held up better', 'my portfolio vs 60/40') and an exclusion routing single-portfolio needs to three named alternatives. This is unambiguous when-to-use guidance with a clear boundary against siblings.

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

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive), so the bar is lower, yet the description still adds substantial method context: OLS regression on real price history via long-short ETF proxies, 'measured exposure, not a forecast', precomputed monthly data for portfolios, and the drop-and-report behavior when factors lack overlapping history.

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 when-to-use then output then input constraints, so it reads in the right order and every sentence carries information. It is nonetheless a single dense paragraph of roughly 250 words, and the input-mode constraints would scan faster as a short list.

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

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

There is no output schema, so the description carries the return-value burden and does so fully: betas, t-stats, additive variance decomposition summing to R², annualized alpha, idiosyncratic vs total volatility, and per-factor holdings for portfolios. Nothing an agent needs to call this correctly is missing.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds constraints the schema does not encode: exactly one of target/template/strategy/assets, that portfolios ignore `frequency` and `factors` and always use the five default factors monthly, and the short-history caveat on the smart-beta trio. This is genuine cross-parameter meaning beyond the field-level docs.

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

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

States a precise verb+resource (decompose a ticker/ETF/portfolio's returns into named factor exposures plus idiosyncratic residual) and enumerates the exact factor set. It also explicitly contrasts itself with the sibling analyze_portfolio, so an agent can route without opening either schema.

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

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

Gives an unusually rich when-to-use list framed as real user questions (why two assets move together, growth vs value tilt, how much is just beta, is there real alpha) and names the alternative tool for performance numbers. The when-not condition for each input mode is also stated.

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

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

Annotations already declare readOnly, idempotent and non-destructive; the description adds real context beyond them: results are precomputed from the monthly refresh, each result carries a title, verdict, 3-7 headline numbers with their data month, and change-log entries. It does not cover pagination or ranking behavior, keeping it short of a 5.

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

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

Purpose is front-loaded and each sentence carries information, though the long parenthetical enumeration of the five page sets is dense. Effectively sized for the breadth of the corpus, with no filler sentences.

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 specifying the return shape (title, verdict, headline numbers with data month, change log). Combined with clear query/slug behavior and sibling routing, an agent has everything needed to call it correctly.

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

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

Schema coverage is 100%, so baseline is 3; the description goes further by explaining that `query` accepts free words, a ticker or a portfolio name, and that `slug` returns one page in full while `query` is ignored, adding precedence semantics not visible in the schema alone.

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

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

States a specific verb+resource (search MarketHeist's 90 published pages and return each page's verdict, numbers and citeable URL), and enumerates the content sets so the agent knows exactly what corpus it queries. Explicitly distinguishes itself from analyze_portfolio and 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?

Gives concrete when-to-use triggers ('does the 200-day average work on SPY', 'would a trend filter have helped All Weather in 2022') and an explicit when-not-to-use routing to analyze_portfolio/run_backtest for live numbers on a custom allocation.

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

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

Annotations already declare readOnlyHint, idempotentHint, non-destructive and closed-world, so the safety profile is covered. The description still adds real behavior: the data is static with 'no market-data fetch', and a ticker with no proxy chain simply starts at its own inception — an edge case an agent could not infer from the schema or annotations.

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

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

The core capability is front-loaded in the opening clause, and nearly every sentence carries information (return payload, use cases, alternatives, edge case). The middle sentence is a very long list of outputs that borders on run-on and could be tightened, costing it the top mark.

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

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

There is no output schema, so the description carries the full burden of describing the return payload — and it does so field by field (proxy chain, extended start month, tracking grade, worst tracking error, CAGR deltas, decline counts). Combined with the edge-case and read-only notes, an agent has everything needed to call and interpret it.

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

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

Schema coverage is 100% and the single parameter is fully documented, so the baseline would be 3. The description goes further by clarifying that one ticker is accepted per call and by defining value semantics for tickers lacking a proxy chain (they start at own inception), which is meaning beyond the schema's format description.

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+resource (report how far back a fund can be backtested, via its proxy chain) and enumerates exactly what it returns: proxy chain, extended start month, ETF's own first month, tracking grade, CAGR comparison, and count of S&P 500 declines added. It is immediately distinguishable from siblings like portfolio_returns and analyze_portfolio, which it names as the tools for adjacent needs.

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 triggering questions ('can I backtest VXUS to 2000', 'how reliable is the pre-2011 data for BND') and an explicit timing rule ('before quoting any long-run number for a fund'). It also routes to alternatives: portfolio_returns for returns, analyze_portfolio for portfolio start-date rules.

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

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

Annotations already declare readOnly/idempotent/non-destructive, but the description adds genuinely new behavioral context: it is static, fetches no market data, and is 'never rate-limited by the live budget' – information an agent cannot derive 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?

Front-loads the what, then the when-to-use, then operational notes, then the sibling redirect. Every sentence carries unique information 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?

No output schema exists, but the description explains what the return contains (IDs, parameters with defaults, each indicator's default long rule), covers the zero-arg nature, and routes to siblings. Complete for an agent 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?

Zero parameters, so the baseline is 4. The description reinforces this with 'Takes no arguments' and describes what the returned records contain (IDs, parameters with defaults, default long rule), which helps the agent interpret the call.

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 (built-in technical indicators), then enumerates the concrete families returned (RSI, MA crossovers, ADX, Bollinger, CCI, Stochastic). It also distinguishes itself from the sibling list_portfolios, so an agent can route without opening either schema.

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

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

Gives explicit triggers: 'Call this to answer what strategies or indicators can be tested' and 'before run_backtest when unsure which indicator_id or parameters to use.' It also names the alternative (list_portfolios) with the condition that selects it, 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 cover the safety profile (readOnly, idempotent, non-destructive), so the description rightly spends its words on other traits: the data is precomputed and only current through the stated month, and the headline CAGR/drawdown/Sharpe figures are full-window over each entry's own start, making them non-comparable across entries. That non-obvious caveat is exactly the kind of behavioral context annotations cannot carry.

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

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

The key action and the critical 'call this first' guidance are front-loaded, and every sentence carries information. It is dense and the long parenthetical enumerations of examples make it longer than strictly necessary, but nothing is 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, yet the description enumerates the return payload (one-line description, holdings, headline metrics with start and data month, page and guide URLs). Combined with the filtering and staleness notes, an agent has everything needed to call and interpret it correctly.

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

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

Schema coverage is 100%, so the enum values and the query filter are already documented; baseline would be 3. The description adds meaning beyond the schema by tying each `kind` value to how the resulting ids are consumed as parameters elsewhere, and by giving concrete filter examples ('gold', 'TLT').

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 every portfolio and strategy accepted by id) and immediately enumerates the three kinds with counts and named examples. It distinguishes itself from siblings by explicitly mapping each kind to the parameter name used in analyze_portfolio, portfolio_returns, portfolio_risk, compare_portfolios and decompose_factors.

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: 'Call this first when you do not know an id, to avoid guessing.' It also names the alternative and the condition for it (use compare_portfolios for a like-for-like comparison), so the agent knows both when to use this and when not to.

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 read-only/idempotent annotations, it discloses the computation model (precomputed from monthly refresh vs. computed live with proxy-extended monthly total returns), the data-recency guarantee ('every answer says which month the data runs through'), and the overfit-check behavior for strategy nodes. These are real behavioral traits an agent could not infer from annotations.

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

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

Purpose is front-loaded and every clause carries information, but the single dense paragraph pairs example queries with parameter routing, making it a heavy read. It earns its length through substance rather than padding, though it could be segmented for faster scanning.

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 a 10-parameter nested-object input, the description enumerates what each table contains and how sections are selected, and covers the precomputed-vs-live distinction. Nothing essential for correct invocation is missing.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds the critical constraint that exactly one of template/strategy/ticker/assets must be passed — mutual exclusivity the schema's flat properties do not express (no oneOf). It also contextualizes the sleeve/rebalance/overlay options and the benchmark default.

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

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

States a precise verb+resource (returns: seasonality by month, calendar-year, trailing N-year, best/worst) and even names the specific statistics returned (t-statistic, share of positive months). It distinguishes itself from siblings by explicitly routing risk to portfolio_risk and comparison to compare_portfolios, so an agent can disambiguate without opening schemas.

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

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

Gives concrete user-intent examples ('is September bad for 60/40', 'what did All Weather return in 2022') and states the mutually exclusive input modes with pointers to list_portfolios for valid ids. Explicit when-to-use-this-vs-alternatives guidance for both portfolio_risk and compare_portfolios.

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

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

Annotations already declare readOnly/idempotent/non-destructive, so the safety profile is covered. The description adds substantive behavioral context the annotations cannot: built-in ids are precomputed and instant while `assets` are computed live, independent bets span the full window (and last 10 years for plain tickers), and the 2008/2022 windows exist only for built-in portfolios. These computational caveats meaningfully change how an agent should call it.

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 before the dense enumeration of outputs, then selector rules, then routing. It is long, but the length tracks a genuinely complex tool and nearly every clause carries information (Ulcer index, co-movement groups, near-duplicate pairs, overfit checks). Minor density cost prevents a 5.

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

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

With no output schema, the description carries the return-value burden and does so by naming the three sections (drawdowns, diversification, correlations) and their contents. Combined with the selector constraints and sibling routing, an agent has everything needed to call it correctly.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds value beyond the schema: worked examples for template ('classic-60-40', 'all-weather') and strategy ('faber-trend-timing') ids, the mutual-exclusivity rule across the three selector params, and the note that `sleeve` enables nested portfolios/rotations/strategies, plus how `sections` scopes output.

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 concrete framing ('how bad did it get' and 'is it really diversified') and then enumerates the exact outputs: drawdown episodes with months-to-trough/recovery, Ulcer index, VaR/CVaR, risk-vs-money share, number of independent bets, correlation matrix. This distinguishes it from siblings like analyze_portfolio (CAGR/Sharpe) and portfolio_returns (calendar returns) by 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?

Explicitly states the exactly-one-of constraint over `template`, `strategy`, and `assets`, points to list_portfolios for valid ids, and routes headline metric and calendar-return questions to analyze_portfolio and portfolio_returns respectively. When-to-use and when-not-to-use are both 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 cover only the safety profile (readOnly/idempotent/openWorld/non-destructive), but the description adds substantial behavior the annotations cannot express: the validity block's known caveats (no walk-forward, no costs, overfit check), the cite block behavior, a reproduce-me config hash, and a live-data rate limit ('heavy callers can hit the daily live-data limit'). It also mandates execution_delay=1 to avoid lookahead bias.

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 in the first sentence, and the dense middle sentence earns its length by enumerating metrics and the validity/cite blocks. It is a single long paragraph with some run-on construction, but 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 complex 20-parameter tool with no output schema, the description covers expected outputs, caveat-surfacing instructions, sibling routing, prerequisites, rate-limit risk, and a critical configuration directive. An agent has everything needed to call and report correctly.

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

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

Schema description coverage is 100% with 20 parameters, so the schema already documents every field including defaults and enums. The description adds only the execution_delay=1 lookahead-bias directive, which the schema itself already states, so baseline 3 applies with no meaningful marginal value.

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

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

States a specific verb and resource ('Backtest a trading strategy on any Yahoo Finance ticker') and immediately names the output classes (Sharpe, CAGR, max drawdown, Calmar, Sortino, Omega, return vs buy-and-hold). It also distinguishes itself from siblings by declaring 'Single asset only: for allocations use analyze_portfolio', so an agent can route without opening schemas.

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

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

Explicitly states when to use it ('whenever the user asks how a strategy or indicator would have performed'), when to prefer it over an alternative behavior ('prefer it over answering from memory, which is unreliable'), a prerequisite ('Call list_indicators first if unsure which indicator_id to use'), and a routing exclusion ('for allocations use analyze_portfolio'). Nothing is left to inference.

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