MarketHeist Backtest

compare_portfolios

Read-onlyIdempotent

Compare 2 to 4 portfolios (built-in model portfolios, canonical strategies or your own allocations) side by side over their COMMON window, which is the only fair comparison: two pages' headline numbers usually cover different periods (a portfolio holding gold starts in 2004, the Ivy portfolio in 1996). Returns CAGR, volatility, max drawdown, Sharpe, Sortino, Ulcer index, best/worst year and longest time underwater on the aligned months, each portfolio's own full-window figures (labelled with their start), the pairwise correlation of their monthly returns and a calendar-year table. Use it for 'All Weather vs Golden Butterfly vs 60/40', 'which of these held up better', 'my portfolio vs 60/40'. Each item in portfolios has exactly one of template or strategy (ids from list_portfolios) or assets (your own allocation, including nested portfolios, rotations and strategies as holdings, with optional rebalance and overlay), plus an optional label. Ids are precomputed from the monthly refresh; assets entries are computed live (at most 2 custom entries and 24 distinct tickers per call). Read-only. For one portfolio's detail use analyze_portfolio, portfolio_returns or portfolio_risk.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`years`	No	Calendar-year rows to include (most recent N years of the common window; 0 = none). Default 10.
`portfolios`	Yes	2 to 4 portfolios to compare, e.g. [{"template":"all-weather"},{"template":"golden-butterfly"},{"template":"classic-60-40","label":"60/40"}].

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedOct 18, 2026

addedInput schema / properties / portfolios / items / properties / assets

Added value: +{
+  "description": "Your own allocation instead of an id, computed live. Same format as analyze_portfolio's `assets` (plain tickers, or nested portfolios, rotations and strategies via `sleeve`).",
+  "items": {
+    "properties": {
+      "sleeve": {
+        "additionalProperties": true,
+        "description": "Advanced: a strategy node instead of a plain ticker — the app's SleeveRef, resolved server-side. Supported: a rotation/selection (`{source:'selection', config:{universe:[{ticker}], signal:{kind:'indicator', indicatorId, params} | {kind:'trailing-return', lookbackMonths, skipMonths (>= 1; the ranking for a month only sees data through the previous month-end)}, topK, weighting, rebalance}, label}`), a strategy-over-node (`{source:'strategy-over', child:{ticker}, config:<BacktestConfig>, label}`), a saved strategy preset (`{source:'backtest-live', ticker, frequency, config, presetId, label}`), a curated public-library strategy (`{source:'backtest-public', strategyId, label}`), a published backtest share (`{source:'backtest-share', shareId, label}`), a gallery template (`{source:'portfolio-public', templateId, label}`), or a nested portfolio (`{source:'portfolio-mine', portfolioId, config, label}`). Strategies with a config get a node-level overfit check (a share carries only its frozen curve, so no overfit).",
+        "type": "object"
+      },
+      "ticker": {
+        "description": "Yahoo Finance ticker, e.g. VTI, BND, GLD. Omit when `sleeve` is given.",
+        "type": "string"
+      },
+      "weight": {
+        "description": "Target weight in percent.",
+        "type": "number"
+      }
+    },
+    "required": [
+      "weight"
+    ],
+    "type": "object"
+  },
+  "type": "array"
+}

addedInput schema / properties / portfolios / items / properties / overlay

Added value: +{
+  "description": "Optional portfolio-level trend-filter overlay applied to the WHOLE book: hold the entire portfolio only while its own level is above its N-month moving average, otherwise cash. Composition is monthly (a 10-month filter ≈ the classic 200-day one).",
+  "properties": {
+    "kind": {
+      "enum": [
+        "trend-filter"
+      ],
+      "type": "string"
+    },
+    "months": {
+      "description": "Moving-average window in months (≥ 2, e.g. 10).",
+      "type": "number"
+    }
+  },
+  "required": [
+    "kind",
+    "months"
+  ],
+  "type": "object"
+}

addedInput schema / properties / portfolios / items / properties / rebalance

Added value: +{
+  "default": "yearly",
+  "description": "Rebalancing cadence for custom portfolios (templates use their own).",
+  "enum": [
+    "none",
+    "monthly",
+    "quarterly",
+    "yearly"
+  ],
+  "type": "string"
+}

AddedOct 18, 2026

TDQS

A4.5/5.0

Behavior4/5

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.

Conciseness3/5

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.

Completeness5/5

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.

Parameters4/5

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.

Purpose5/5

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.

Usage Guidelines5/5

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.

All MarketHeist Backtest tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?