Run crypto trading strategy backtests through EmidLabs's Backtesting API.
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Average 4.5/5 across 6 of 6 tools scored.
Each tool targets a distinct action: submission (single vs batch), result fetching (single vs batch), trade details, and asset listing. No overlapping purposes exist, so an agent can easily differentiate them.
All tool names follow a consistent verb_noun pattern using snake_case, such as submit_backtest, get_backtest_result, and list_available_assets. There are no deviations or mixed conventions.
With six tools covering submission, result retrieval, trade details, and asset exploration, the number is well-scoped for a backtesting server. Each tool serves a necessary purpose without redundancy.
The tool surface covers the core workflow: submit, fetch results (aggregate and trades), and batch operations. A minor gap is the absence of a tool to list or cancel previously submitted backtests, but the existing set handles the primary use cases effectively.
get_backtest_batch_resultsGet Backtest Batch ResultsAFetches 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.
| Name | Required | Description | Default |
|---|---|---|---|
| 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. |
| 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. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, and non-destructive, but the description adds substantial behavioral context: internal polling with waitForCompletion, the 'cheap check' semantics, counts on every page, and shape parity with single-result. 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Four sentences, each adding distinct value: purpose, polling behavior, item shape, and count semantics. No filler or redundancy; every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (7 params, output schema, annotations), the description covers purpose, behavior, output structure, and pagination nuance sufficiently. It also references sibling get_backtest_result to clarify relationship, making it complete for agent selection.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description enriches key parameters like waitForCompletion (explains polling behavior and 'cheap check') and pollTimeoutMs (context for higher default), adding value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it fetches every asset's outcome from a submit_backtest_batch call, paginated. It distinguishes itself from get_backtest_result by explicitly comparing batch and single-result shapes, making the resource and scope unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies when to use the tool (after a submit_backtest_batch call) and provides context about polling behavior. However, it does not explicitly state alternatives for single-result queries or situations where this tool should not be used, so it slightly misses the full 'when/when-not' bar.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_backtest_resultGet Backtest ResultAFetches 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_results instead.
| Name | Required | Description | Default |
|---|---|---|---|
| id | No | The id returned by submit_backtest. | |
| pollTimeoutMs | No | Defaults to 120000 (2 minutes). | |
| 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 the backtest finishes or pollTimeoutMs elapses. |
| Name | Required | Description |
|---|---|---|
| id | No | |
| result | No | |
| status | No | |
| runtimeMs | No | How long the analyser actually took to run this backtest, in milliseconds — pure compute time, not counting queue/messaging latency. Null until Status is "Completed". |
| errorMessage | No | |
| recentAvgPnlR | No | Average pnlR of the most recent RecentTradeCount closed trades. This is the recency signal for a rolling ranking — weighted alongside expectancyR, not a replacement for it. |
| unitsConsumed | No | Number of candles the analyser processed for this backtest. Null until Status is "Completed". |
| recentOutcomes | No | "Win"/"Loss" per recent trade, chronological — oldest first, so the LAST element is the most recent trade. Lets a caller see whether recent trades were genuinely a streak (e.g. all "Loss") versus alternating, which RecentAvgPnlR alone can't distinguish. |
| recentTradeCount | No | Number of trades the recency fields below are based on (up to 5, fewer if the backtest has fewer trades). Null until Status is "Completed". |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only, idempotent, non-destructive behavior. The description adds valuable context about internal polling (waitForCompletion default) and that it returns a single final answer, which complements the annotations without contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, consisting of three clear sentences without redundancy. It efficiently covers purpose, polling behavior, and sibling distinctions, with no unnecessary fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is complete for the tool's scope: it explains what it returns (aggregate metrics), how it behaves (polling), and how it differs from related tools. Given the rich schema and annotations, no additional context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides descriptions for all five parameters, covering their defaults and purposes. The tool description adds little beyond restating the polling behavior, so it does not significantly enhance parameter understanding beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool fetches a submitted backtest by id, and explicitly distinguishes from siblings (get_backtest_trades for trade details, get_backtest_batch_results for batch fetches). The verb 'Fetches' and specific resource make the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use this tool versus alternatives: 'Only aggregate metrics are returned here... call get_backtest_trades for that' and 'Fetching many results... Use get_backtest_batch_results instead.' It also explains the default polling behavior, making usage clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_backtest_tradesGet Backtest TradesAFetches 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.
| Name | Required | Description | Default |
|---|---|---|---|
| id | No | The id returned by submit_backtest. | |
| page | No | 1-based page number. Default 1. | |
| sortBy | No | One of: number, pnlR, pnlPct, entryTime, exitTime. Defaults to number (closing order). | |
| pageSize | No | Trades per page, 1-100. Default 20. | |
| sortDirection | No | "asc" or "desc". Defaults to asc. | |
| 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. |
| Name | Required | Description |
|---|---|---|
| page | No | |
| items | No | The trades on this page, in the requested sort order. |
| pageSize | No | |
| totalCount | No | Total closed trades across the whole backtest, not just this page. |
| totalPages | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only and idempotent behavior. The description adds a key limitation—that open positions are never represented—which is not present in annotations. This is valuable context, but no further behavioral traits are disclosed, so a 4 is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences: the first defines the core function and differentiates from a sibling, the second states a critical limitation, and the third gives an example. Each sentence earns its place with no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the rich schema, annotations, and output schema, the description adequately covers purpose, limitations, and an example. For this type of list tool, no additional return-value or pagination details are needed because the output schema already exists.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers all 7 parameters with descriptions (100% coverage), so baseline is 3. The description adds a concrete example showing how sortBy, sortDirection, and pageSize work together, which provides usage context beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Fetches the closed-trade list for a completed backtest' with a specific verb and resource. It also distinguishes itself from sibling get_backtest_result by noting it provides 'trade-by-trade detail' that the sibling omits.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives a concrete example and states the scope (only closed trades), and contrasts with get_backtest_result. However, it does not explicitly say when not to use this tool or name alternatives directly, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_available_assetsList Available AssetsALists 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_backtest.
| Name | Required | Description | 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. Override only for self-hosted/staging use. |
| Name | Required | Description |
|---|---|---|
| assets | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, which covers safety. The description adds useful context by noting the tool is optional and that submit_backtest errors provide the real range, and clarifies it lists only assets with real historical data. This goes beyond the annotations without contradicting them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that leads with the core function and then explains usage context and optionality. Every clause adds value; there is no redundancy or wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has an output schema, and the description explains purpose, scope, and usage trade-offs with a sibling. It is complete for a read-only list tool. Minor gaps like pagination or result size limits are not mentioned, but these are not essential given the output schema and annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with both parameters (backtestApiKey and backtestBaseUrl) already described in the schema. The description does not add parameter-specific semantics beyond what the schema provides, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists asset pairs with real historical data, including supported timeframes and date ranges. It uses a specific verb ('Lists') and resource ('every asset pair with real historical data'), effectively distinguishing it from the sibling tools submit_backtest and get_backtest_result.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says the tool is optional and explains the alternative: submit_backtest already returns a clear error with the available range. It gives concrete scenarios for use (up-front exploration, recovering from an 'unknown asset' error) and states it is not required before every submit_backtest.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
submit_backtestSubmit BacktestAInspectSubmits 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.
| Name | Required | Description | Default |
|---|---|---|---|
| assetPair | No | e.g. "BTC-USDC". | |
| finalDate | No | ISO date string, e.g. "2025-06-01". | |
| 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. | |
| strategySnapshotJson | No | The Strategy DSL object — every field below documents its own exact shape, this is just the execution model that ties them together. Entry fills at the close of the candle where decision.entry turns true (no lookahead). A position closes on the first of these to happen, checked in this order: stop-loss hit, take-profit hit, decision.exit turning true (a same-candle stop/take-profit always wins over exit). Multiple positions can be open at once by default — cap with configuration.maxOpenPositions. Results are measured in R-units (risk multiples); expectancyR (average R per trade) is the metric to optimize, not raw win rate or trade count. |
| Name | Required | Description |
|---|---|---|
| id | No | |
| status | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses asynchronous behavior ('Returns immediately with an id and status') and implies resource cost for repeated calls. Annotations are neutral, so the description adds context beyond them, though it could mention authentication requirements or side effects in more detail.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences: purpose, async behavior, and alternative guidance. Every sentence adds value, and it's front-loaded with the primary action. No fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with a complex strategy DSL schema, the description efficiently orients the agent by covering the submission flow and alternatives. The extensive schema descriptions handle the details, so the description doesn't need to enumerate them. Slightly less complete on prerequisites (e.g., API key) but those appear in schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all six parameters with individual descriptions. The tool description adds no additional parameter-level meaning, but the schema descriptions are comprehensive, justifying the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Submits' and clearly identifies the resource ('a strategy for backtesting against historical OHLCV data'). It also distinguishes itself from the sibling tool by noting the alternative for batch submissions, making its unique scope obvious.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use an alternative: 'Testing the same strategy against many assets? Use submit_backtest_batch instead — one call per asset here adds up fast.' Also instructs to use get_backtest_result to retrieve the result, providing clear workflow guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
submit_backtest_batchSubmit Backtest BatchAInspectSubmits 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.
| Name | Required | Description | Default |
|---|---|---|---|
| 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. | |
| strategySnapshotJson | No | Same Strategy DSL object submit_backtest takes — see that tool's description for the full shape. |
| Name | Required | Description |
|---|---|---|
| items | No | |
| batchId | No | Pass this to get_backtest_batch_results to fetch every item's status/result, paginated. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses important behavioral traits beyond the annotations, including immediate return with batchId, per-asset id/status availability, and best-effort error handling where a bad asset pair only fails that item. These details are valuable for the agent to predict tool behavior and handle partial failures.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, front-loaded with the core purpose, and every sentence adds value (purpose, return behavior, error handling). It is tight and easy to parse, with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity, the description covers the full workflow: what it does, what it returns, how to fetch results, and how failures are handled. It references submit_backtest for the strategy object and get_backtest_batch_results for retrieval, making it self-contained enough for an agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description does not add parameter-level guidance, but the schema already provides detailed semantic descriptions for all parameters, including for strategySnapshotJson referencing submit_backtest. The description mentions batchId and pagination but not parameter specifics, so it neither compensates nor detracts.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Submits ONE strategy against MANY asset pairs in a single call.' It uses a specific verb and resource, and explicitly contrasts with submit_backtest to distinguish itself. The mention of returning a batchId and per-asset id/status further clarifies the scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool ('without needing dozens of round trips') and references an alternative workflow (submit_backtest per asset). It also directs the user to get_backtest_batch_results for fetching results. However, it does not explicitly state when not to use this tool (e.g., for a single asset), so it stops short of a full when/when-not guide.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
No comments yet. Be the first to start the discussion!
