EmidLabs Backtest

Submit Backtest Batch

submit_backtest_batch

Submits ONE strategy against MANY asset pairs in a single call — the same backtest you'd get from calling submit_backtest once per asset, without needing dozens of round trips. Returns immediately with a batchId (pass it to get_backtest_batch_results to fetch every asset's outcome, paginated) plus the per-asset id/status assigned right away. Best-effort: one bad asset pair (unknown, or its date range outside coverage) shows up with an error in that item only — every other asset in the batch is unaffected. Optionally accepts confirmationSources, applied identically to every asset in the batch — see submit_backtest's own confirmationSources argument for the full semantics.

Input Schema

TableJSON Schema

Name	Required	Description
`finalDate`	No	ISO date string, e.g. "2025-06-01".
`assetPairs`	No	e.g. ["BTC-USDC", "ETH-USDC", "SOL-USDC"]. Every asset gets the exact same strategySnapshotJson and date range.
`initialDate`	No	ISO date string, e.g. "2025-01-01".
`backtestApiKey`	No	Your EmidLabs backtest API key (created in the Console). Not needed if this connector was added with a static 'x-api-key' header.
`backtestBaseUrl`	No	Defaults to the public production API. Override only for self-hosted/staging use.
`confirmationSources`	No	Optional. A JSON-encoded STRING (not a native array/object — pass it exactly like a quoted string value), containing the same shape as submit_backtest's own confirmationSources: [{"sourceId":"<a submit_confirmation_source id>","signalType":"entry","validityWindow":{"count":1}}]. Applied identically to every asset pair in this batch (one shared gate, not one per asset). Passed as a raw JSON string rather than a native array because this tool already has one array parameter (assetPairs) — a second one crashes the MCP SDK's own parameter marshaller. A sourceId that doesn't exist, isn't Completed, or belongs to another account fails that item only (same best-effort semantics as an unknown asset pair), not the whole batch.
`strategySnapshotJson`	No	Same Strategy DSL object submit_backtest takes — see that tool's description for the full shape.

Output Schema

TableJSON Schema

Name	Required	Description	Default
`items`	No
`batchId`	No	Pass this to get_backtest_batch_results to fetch every item's status/result, paginated.

TDQS

A4.5/5.0

Behavior5/5

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

Beyond the all-false annotations, the description reveals that the call returns immediately with a batchId, assigns per-asset ids/statuses right away, and is best-effort so a single bad asset pair fails only that item. It also discloses that confirmationSources is applied identically across the batch and points to submit_backtest for full semantics. No contradiction with annotations.

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?

The description is a compact three-sentence block that front-loads the core batching purpose, then covers return behavior, best-effort error isolation, and the optional confirmationSources parameter. Every sentence contributes distinct, necessary information with no redundancy.

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?

Given that an output schema exists and every parameter is fully documented in the input schema, the description is sufficient: it explains batching semantics, immediate return, per-item failure isolation, and directs to the correct sibling for results. Cross-references to submit_backtest for confirmationSources and the strategy DSL close remaining gaps without duplicating schema content.

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

Parameters3/5

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

The input schema already has 100% parameter coverage with detailed explanations, so the description adds little new parameter-level meaning. Its only additions are shorthand references, such as strategySnapshotJson being 'the same DSL object submit_backtest takes' and confirmationSources being applied identically, both of which the schema already explains at length.

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?

The opening sentence states a specific action: 'Submits ONE strategy against MANY asset pairs in a single call' and explicitly frames it as equivalent to calling submit_backtest once per asset. This makes the tool's purpose unmistakable and clearly distinguishes it from the sibling submit_backtest.

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?

The description positions the tool as the batching alternative to dozens of submit_backtest round trips and routes the caller to get_backtest_batch_results for paginated results. It does not explicitly state that a single asset pair should go to submit_backtest instead, so exclusions are only implied rather than stated.

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?