EmidLabs Backtest

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

Name	Required	Description
`page`	No	1-based page number. Default 1.
`batchId`	No	The batchId returned by submit_backtest_batch.
`pageSize`	No	Items per page, 1-100. Default 20.
`pollTimeoutMs`	No	Defaults to 300000 (5 minutes) — a batch's slowest item determines the total wait, so this is higher than get_backtest_result's default.
`backtestApiKey`	No	Your EmidLabs backtest API key. Not needed if this connector was added with a static 'x-api-key' header.
`backtestBaseUrl`	No	Defaults to the public production API.
`waitForCompletion`	No	If true (default), polls internally until every item in the batch is done or pollTimeoutMs elapses.

Output Schema

TableJSON Schema

Name	Required	Description
`page`	No
`items`	No
`batchId`	No
`pageSize`	No
`totalCount`	No	Total items in this batch, across every page — not just this one.
`totalPages`	No
`failedCount`	No	How many items finished unsuccessfully (Failed, Cancelled, or Expired).
`pendingCount`	No	How many items are still Queued or Running. The whole batch is done once this reaches 0 — true on every page, not just the last.
`completedCount`	No	How many items finished successfully.

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.

All EmidLabs Backtest tools Inspect

Try in Browser

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.6/5.0

Disambiguation5/5

Each tool targets a distinct resource/action: single backtests, batch backtests, trades, confirmation sources, signals, and asset discovery. The batch getter is explicitly differentiated from the single-result getter, and confirmation sources are clearly separated from tradable backtests.

Naming Consistency5/5

Tool names follow a clear verb_noun pattern: submit_backtest, submit_backtest_batch, get_backtest_result, get_backtest_trades, get_confirmation_source, list_available_assets. Modifiers like batch, trades, and signals are consistent and make each tool's role predictable.

Tool Count5/5

Nine tools is well-scoped for a backtesting server: three submission endpoints, four result-fetching endpoints, signal retrieval, and asset discovery. There is no apparent redundancy or tool bloat.

Completeness5/5

The surface covers the full backtest lifecycle: submitting single and batch backtests, retrieving aggregate results, drilling into trades, creating and reading confirmation sources, and discovering available assets. No critical operation appears missing for the stated domain.

Resources

Need Help?