Skip to main content
Glama

Get Backtest Batch Results

get_backtest_batch_results
Read-onlyIdempotent

Fetches every asset's outcome from a submit_backtest_batch call, paginated. By default (waitForCompletion: true) polls internally until every item in the batch is done — a cheap check, not one that pages through everything — so one call returns the finished page. Each item has the same aggregate metrics and recency fields (recentTradeCount/recentAvgPnlR/recentOutcomes) get_backtest_result returns for a single backtest, plus assetPair/status/error, so the single-result and batch-result shapes never drift apart. totalCount/completedCount/failedCount/pendingCount come back on every page, not just the last, so you can tell the batch is done from a single pageSize=1 call.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
pageNo1-based page number. Default 1.
batchIdNoThe batchId returned by submit_backtest_batch.
pageSizeNoItems per page, 1-100. Default 20.
pollTimeoutMsNoDefaults to 300000 (5 minutes) — a batch's slowest item determines the total wait, so this is higher than get_backtest_result's default.
backtestApiKeyNoYour EmidLabs backtest API key. Not needed if this connector was added with a static 'x-api-key' header.
backtestBaseUrlNoDefaults to the public production API.
waitForCompletionNoIf true (default), polls internally until every item in the batch is done or pollTimeoutMs elapses.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
pageNo
itemsNo
batchIdNo
pageSizeNo
totalCountNoTotal items in this batch, across every page — not just this one.
totalPagesNo
failedCountNoHow many items finished unsuccessfully (Failed, Cancelled, or Expired).
pendingCountNoHow many items are still Queued or Running. The whole batch is done once this reaches 0 — true on every page, not just the last.
completedCountNoHow many items finished successfully.

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. Changed2 schema fields changed
    • addedOutput schema / properties / items / items / properties / result / properties / confirmedSignalsCount
      Added value: +{
      +  "description": "Only meaningful when the request declared confirmationSources — how many candidates cleared confirmation and became one of the Trades above.",
      +  "type": "integer"
      +}
    • addedOutput schema / properties / items / items / properties / result / properties / unconfirmedSignalsCount
      Added value: +{
      +  "description": "Only meaningful when the request declared confirmationSources — how many candidates were dropped before trade simulation because they weren't corroborated. ConfirmedSignalsCount + UnconfirmedSignalsCount is the total candidate count, same as what a backtest without confirmationSources would have produced.",
      +  "type": "integer"
      +}
  2. Changed3 schema fields changed
    • addedOutput schema / properties / items / items / properties / candlesProcessed
      Added value: +{
      +  "description": "Number of candles the analyser processed for this item. Null until Status is \"Completed\". This is raw volume, not the plan's billing unit — see UnitsConsumed for that.",
      +  "type": [
      +    "integer",
      +    "null"
      +  ]
      +}
    • changedOutput schema / properties / items / items / properties / unitsConsumed / description
      Previous value: -"Number of candles the analyser processed for this item. Null until Status is \"Completed\"."New value: +"The actual execution-unit cost of this item, matching what's debited from the account's plan balance (CandlesProcessed normalized by the account's candles-per-unit rate). Null until Status is \"Completed\"."
    • changedOutput schema / properties / items / items / properties / unitsConsumed / type
      Previous value: -[
      -  "integer",
      -  "null"
      -]New value: +[
      +  "number",
      +  "null"
      +]
  3. Changed6 schema fields changed
    • changedOutput schema / properties / items / items / properties / result / properties / bothHit / description
      Previous value: -"Trades where both stop-loss and take-profit were hit on the same candle (resolved as stop-loss)."New value: +"Trades where both stop-loss and take-profit were hit on the same candle (resolved as stop-loss). A high BothHit relative to Trades means many trades' outcome was decided by the engine's stop-wins-ties precedence rule rather than real intracandle price path data — treat results with more skepticism the higher this ratio is."
    • changedOutput schema / properties / items / items / properties / result / properties / conditionsDistributionPct / description
      Previous value: -"For each condition name (see strategySnapshotJson.conditions): fraction of candles where it was true."New value: +"For each possible count of simultaneously-true conditions (0, 1, 2...N): fraction of all candles where exactly that many were true at once. A strategy-tuning diagnostic (how selective is the entry setup), not a performance metric."
    • addedOutput schema / properties / items / items / properties / result / properties / currentDrawdownR
      Added value: +{
      +  "description": "How far below its own peak the equity curve sits at the end of the backtest window, in R-units. 0 if the backtest ends at a new high. Includes any still-open position's unrealized PnL (see UnrealizedPnlRAtEnd) — a slump caused by an open, underwater position at window end shows up here.",
      +  "type": "number"
      +}
    • addedOutput schema / properties / items / items / properties / result / properties / maxDrawdownR
      Added value: +{
      +  "description": "Worst peak-to-trough dip across closed trades, in R-units. 0 if equity never fell below its running high-water mark. Historical/all-time — see CurrentDrawdownR for where the equity curve sits right now.",
      +  "type": "number"
      +}
    • addedOutput schema / properties / items / items / properties / result / properties / openPositionsAtEnd
      Added value: +{
      +  "description": "Number of positions still open (never hit stop/take/exit-signal) when the backtest's date range ended. 0 in the common case. Check this before trusting CurrentDrawdownR/UnrealizedPnlRAtEnd at face value.",
      +  "type": "integer"
      +}
    • addedOutput schema / properties / items / items / properties / result / properties / unrealizedPnlRAtEnd
      Added value: +{
      +  "description": "Sum of unrealized PnL, in R-units, across all positions still open at window end — marked to market against the last available candle's close. 0 when OpenPositionsAtEnd is 0. Does NOT include exit fee (the position hasn't closed, so none has been paid) — a slight overestimate of true current drawdown when a position is open. This value feeds ONLY CurrentDrawdownR/MaxDrawdownR — it is never included in PnlR/ExpectancyR/Trades/Wins/Losses or any other metric describing closed, realized trades.",
      +  "type": "number"
      +}
  4. Changed1 schema field changed
    • addedOutput schema / properties / items / items / properties / result / properties / totalFeeR
      Added value: +{
      +  "description": "Total R subtracted across all trades by configuration.entryFeePct/exitFeePct (0 if neither was set on the request). expectancyR/pnlR above are already net of this — TotalFeeR is just how much fees cost, for diagnostics. Caveat: a trade's fee-in-R cost scales inversely with that trade's own stop distance, so once fees are applied, expectancyR is only a fair comparison WITHIN one archetype's own stop convention — use pnlPct-based metrics (see get_backtest_trades) for comparisons across strategies/timeframes with different typical stop widths.",
      +  "type": "number"
      +}
  5. Changed2 schema fields changed
    • changedOutput schema / properties / items / items / properties / result / properties / profitFactor / description
      Previous value: -"grossProfitR / abs(grossLossR). Greater than 1 means profitable."New value: +"grossProfitR / abs(grossLossR). Greater than 1 means profitable. Null when there are no losing trades — the ratio is undefined (division by zero), not infinite."
    • changedOutput schema / properties / items / items / properties / result / properties / profitFactor / type
      Previous value: -"number"New value: +[
      +  "number",
      +  "null"
      +]
  6. Changed2 schema fields changed
    • addedOutput schema / properties / items / items / properties / runtimeMs
      Added value: +{
      +  "description": "How long the analyser actually took to run this item, in milliseconds — pure compute time. Null until Status is \"Completed\".",
      +  "type": [
      +    "integer",
      +    "null"
      +  ]
      +}
    • addedOutput schema / properties / items / items / properties / unitsConsumed
      Added value: +{
      +  "description": "Number of candles the analyser processed for this item. Null until Status is \"Completed\".",
      +  "type": [
      +    "integer",
      +    "null"
      +  ]
      +}
  7. Added

TDQS

A4.7/5.0
Behavior5/5

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

Beyond readOnly/idempotent/non-destructive annotations, it discloses internal polling (waitForCompletion), that a call returns only the finished page, and that counts appear on every page. It also explains the response shape stays consistent with get_backtest_result, which is valuable behavioral context.

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

Conciseness5/5

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

Four sentences, with purpose first, then behavior and edge-case tips; no filler. Despite length, every sentence adds non-redundant operational knowledge.

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?

For a paginated polling tool with 7 optional params and an output schema, the description covers the data shape, pagination counts, polling timeout semantics, and relation to sibling tools. Output schema handles return values, so nothing essential is missing.

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 baseline is 3; the description adds meaningful semantics around waitForCompletion ('polls internally until every item... done', 'cheap check') and the pageSize=1 trick. It doesn't need to restate parameter properties because the schema already documents them.

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?

States a specific verb and resource ('Fetches every asset's outcome from a submit_backtest_batch call') and adds pagination. It is clearly distinguished from get_backtest_result (single-result) and submit_backtest_batch (submission).

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

Usage Guidelines4/5

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

Names the originating call (submit_backtest_batch) and contrasts with the single-backtest tool get_backtest_result, giving an agent enough context to choose between them. It gives concrete usage advice (waitForCompletion behavior, pageSize=1 completion check), though it doesn't explicitly state exclusion conditions.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.5/5.0
Disambiguation5/5

Each tool maps to a distinct resource and action: submitting/fetching backtests, fetching batch results, fetching trades, submitting/fetching confirmation sources, fetching signals, and listing available assets. The singular vs. batch result tools are explicitly cross-referenced and serve different call patterns, so an agent shouldn't confuse them.

Naming Consistency5/5

All tool names follow a consistent snake_case verb_noun pattern: submit_*, get_*, and list_*. Resource names are clear and predictable, such as backtest, backtest_batch, backtest_trades, confirmation_source, and confirmation_source_signals. The list_/get_ verb variation is conventional and not confusing.

Tool Count5/5

Nine tools is well-scoped for this domain, covering single and batch backtests, result and trade retrieval, asset discovery, and the confirmation-source workflow. Each tool has a distinct role, and none feel like filler or duplication.

Completeness5/5

The tool set covers the full backtesting lifecycle: submit single/batch, fetch aggregate results, fetch trade detail, list available assets, and submit/fetch confirmation sources plus their signals. The confirmation-source workflow integrates cleanly with submit_backtest, and there are no dead ends or obvious missing operations.

Resources