EmidLabs Backtest
Run crypto trading strategy backtests through EmidLabs's Backtesting API.
| Endpoint | https://mcp.backtest.emidlabs.com/mcp (streamable-http) |
|---|---|
| Registry version | 0.1.0 |
| Now | 9 tools · grade D (55) · pin ts_ea1a54840187c4f7e865f49836e39433 · protocol 2025-06-18 |
| First / last listed | 2026-10-31 02:26 UTC / 2026-10-31 02:26 UTC |
| Grade over time | 2026-10-31: D (55), 9 tools |
Is this your server? Own a server? ToolFit hosted watch re-checks it every 24 h ($0.25 per 30 days) or 6 h ($0.60) and sends you an HMAC-signed webhook when its tools or grade change: POST https://api.youraitools.co/toolfit/v1/watch. To opt out, see About & opt-out.
Tools: submit_confirmation_source list_available_assets submit_backtest_batch get_backtest_batch_results get_backtest_trades get_backtest_result submit_backtest get_confirmation_source get_confirmation_source_signals
submit_confirmation_source | Runs a strategy against historical data purely to produce a signal timeline used to confirm OTHER backtests — not a backtest itself. Walks the same candles and evaluates the same DSL as submit_backtest, but never simulates a position: no trade, no PnL, no WinRate/drawdown, none of that applies here, because this strategy is never meant to be traded on its own. Returns immediately with an id and st params: assetPair, initialDate, finalDate, strategySnapshotJson, backtestApiKey, backtestBaseUrl |
list_available_assets | Lists every asset pair with real historical data, each with its supported timeframes and the date range actually available. Optional to call — submit_backtest already returns a clear error (with the real available range) when an asset or date range doesn't have data, so this is for up-front exploration or for recovering from an "unknown asset" error, not a required step before every submit_backtes params: backtestApiKey, backtestBaseUrl |
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 ra params: assetPairs, initialDate, finalDate, strategySnapshotJson, confirmationSources, backtestApiKey, backtestBaseUrl |
get_backtest_batch_results | 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 params: batchId, page, pageSize, waitForCompletion, pollTimeoutMs, backtestApiKey, backtestBaseUrl |
get_backtest_trades | Fetches the closed-trade list for a completed backtest, paginated and sortable — the trade-by-trade detail get_backtest_result deliberately omits. Only closed trades ever appear; a position still open when the backtest's date range ends isn't represented here or anywhere else. Example: sortBy="exitTime", sortDirection="desc", pageSize=5 for the most recently closed trades. params: id, page, pageSize, sortBy, sortDirection, backtestApiKey, backtestBaseUrl |
get_backtest_result | Fetches a submitted backtest by id. By default (waitForCompletion: true) polls internally until it finishes, so one call returns one final answer — no need to poll from the caller's side. Only aggregate metrics are returned here, no trade-by-trade detail — call get_backtest_trades for that (paginated, sortable). Fetching many results from the same submit_backtest_batch call? Use get_backtest_batch params: id, backtestApiKey, waitForCompletion, pollTimeoutMs, backtestBaseUrl |
submit_backtest | Submits a strategy for backtesting against historical OHLCV data. Returns immediately with an id and status — call get_backtest_result to fetch the outcome once it finishes. Testing the same strategy against many assets? Use submit_backtest_batch instead — one call per asset here adds up fast. Optionally accepts confirmationSources to only count a candidate Entry/Exit as a real trade once corrobor params: assetPair, initialDate, finalDate, strategySnapshotJson, confirmationSources, backtestApiKey, backtestBaseUrl |
get_confirmation_source | Fetches a submitted confirmation source by id. By default (waitForCompletion: true) polls internally until it finishes, so one call returns one final answer. No trade-outcome fields here at all (no PnlR/WinRate/...) — a confirmation source never opens a position. Once Completed, its id can be used as a confirmationSources sourceId in submit_backtest; its raw signal timeline is available separately params: id, backtestApiKey, waitForCompletion, pollTimeoutMs, backtestBaseUrl |
get_confirmation_source_signals | Fetches a completed confirmation source's raw signal timeline, paginated — the actual data a backtest's confirmationSources requirement is checked against. Can easily run into the thousands for a frequent condition over a long range (every candle-condition match is a row, not just closed trades), which is why this is paginated from the start. Debugging/inspection only — you do NOT need this tool t params: id, page, pageSize, backtestApiKey, backtestBaseUrl |
Entries describe changes in tool definitions. They are not statements about a server, its quality or its author. The grade measures how the tool definitions fit model providers (token cost, schema compatibility, confusable names) as scored by the ToolFit engine at the time of the listing. JSON: append .json. Opt-out: how or hello@youraitools.co.