Skip to main content
Glama

EmidLabs Backtest

by io.github.emidlabs
OverviewDiscussionsAdmin

Get Backtest Trades

get_backtest_trades
Read-onlyIdempotent

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.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
idNoThe id returned by submit_backtest.
pageNo1-based page number. Default 1.
sortByNoOne of: number, pnlR, pnlPct, entryTime, exitTime. Defaults to number (closing order).
pageSizeNoTrades per page, 1-100. Default 20.
sortDirectionNo"asc" or "desc". Defaults to asc.
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.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
pageNo
itemsNoThe trades on this page, in the requested sort order.
pageSizeNo
totalCountNoTotal closed trades across the whole backtest, not just this page.
totalPagesNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed10 schema fields changed
    • addedOutput schema / properties / items / items / properties / conditionsAtEntry / description
      Added value: +"Every named condition from strategySnapshotJson.conditions at entry time — true AND false, not just the ones that were true."
    • addedOutput schema / properties / items / items / properties / entryExecutionCandleOpenTime / description
      Added value: +"Candle open time this trade's entry actually filled on. Currently always equal to EntrySignalCandleOpenTime — see that field's note."
    • addedOutput schema / properties / items / items / properties / entryPrice / description
      Added value: +"Fill price at entry — always the entry candle's close."
    • addedOutput schema / properties / items / items / properties / entrySignalCandleOpenTime / description
      Added value: +"Candle open time this trade's entry signal fired on. Currently always equal to EntryExecutionCandleOpenTime — reserved for a future delayed-fill model (e.g. signal on candle close, execution on next candle open), not yet implemented. Don't rely on these differing today."
    • addedOutput schema / properties / items / items / properties / exitExecutionCandleOpenTime / description
      Added value: +"Candle open time this trade's exit actually filled on. Currently always equal to ExitSignalCandleOpenTime — see that field's note."
    • addedOutput schema / properties / items / items / properties / exitPrice / description
      Added value: +"Fill price at exit — StopPrice, TakePrice, or the exit candle's close, depending on ExitReason."
    • addedOutput schema / properties / items / items / properties / exitSignalCandleOpenTime / description
      Added value: +"Candle open time this trade's exit signal fired on. Currently always equal to ExitExecutionCandleOpenTime — same reserved-for-future-use note as the entry pair."
    • addedOutput schema / properties / items / items / properties / holdingCandles
      Added value: +{
+  "description": "Timeframe-agnostic candle count the position was held for (exit candle index minus entry candle index). Minimum possible value is 1, not 0 — a position opened on candle i can earliest close on candle i+1. Derive real elapsed time from EntryExecutionCandleOpenTime/ExitExecutionCandleOpenTime if needed.",
+  "type": "integer"
+}
    • addedOutput schema / properties / items / items / properties / scoreBreakdownAtEntry / description
      Added value: +"Weight contributed by each condition toward TotalScoreAtEntry — 0 for conditions that were false."
    • addedOutput schema / properties / items / items / properties / totalScoreAtEntry / description
      Added value: +"Total score at entry — the value compared against the threshold in decision.entry."
  2. Changed4 schema fields changed
    • addedOutput schema / properties / items / items / properties / feeR
      Added value: +{
+  "description": "R-units subtracted from this trade's PnlR by configuration.entryFeePct/exitFeePct (0 if neither was set). PnlR is already net of this — PnlR + FeeR recovers the pre-fee raw R. Not directly comparable across trades with different RiskDistance: this scales inversely with each trade's own stop distance.",
+  "type": "number"
+}
    • addedOutput schema / properties / items / items / properties / riskDistance
      Added value: +{
+  "description": "Price distance between EntryPrice and StopPrice — the denominator PnlR/FeeR are expressed in units of.",
+  "type": "number"
+}
    • addedOutput schema / properties / items / items / properties / stopPrice
      Added value: +{
+  "description": "The stop-loss price this trade was risk-managed against.",
+  "type": "number"
+}
    • addedOutput schema / properties / items / items / properties / takePrice
      Added value: +{
+  "description": "The take-profit price this trade was risk-managed against.",
+  "type": "number"
+}
  3. Added

TDQS

A4/5.0
Behavior3/5

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

Annotations already declare readOnlyHint and idempotentHint, so the bar is lower. The description adds valuable info: only closed trades ever appear, open positions are not represented anywhere. It does not mention pagination performance or error handling, but the open-position caveat is meaningful beyond annotations, so a 3 is fair.

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?

Three sentences: first defines the tool and its key differentiator, second adds the critical behavioral caveat, third is a concrete example. Every sentence adds value with no filler. Front-loaded and efficiently structured.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool has a rich output schema and 100% schema parameter coverage, so the description need not elaborate return format. It covers the essential nuance about closed trades. Slightly less than a 5 because it could mention what happens if the backtest ID is invalid or the backtest isn't completed, but the essentials are covered.

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?

Schema coverage is 100%, so the schema already documents all parameters. The description adds an example usage that shows the meaning of sortBy/sortDirection/pageSize, but does not explain each parameter beyond the schema. Baseline 3 applies.

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?

Clear verb+resource ('Fetches the closed-trade list for a completed backtest'), plus specifics: paginated, sortable, and deliberately omits trade-by-trade detail that get_backtest_result provides. This sharply distinguishes it from the sibling tool.

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?

Explicitly states when to use: for trade-by-trade detail and when get_backtest_result omits it. Also provides a concrete example. It does not explicitly list alternatives like get_backtest_batch_results, but naming the primary alternative is sufficient.

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

All EmidLabs Backtest toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources