EA Trade Tester by TrueTest

Check a trading record (MT5 report, statement or CSV)

check_trading_record

Read-onlyIdempotent

Judges whether a finished trading record's results look real or like luck: reads the trades, applies a luck test that allows for the number of versions tried, checks costs, losing years and grid/martingale signs, and returns a verdict (REAL / PROMISING / LIKELY_LUCK / NO_EVIDENCE / FAIL / HIDDEN_RISK / TOO_FEW) with its reason. Use it for a record of trades already taken or backtested; for strategy code or written rules use test_strategy_code. Nothing is stored: the record is read as data, never run, and discarded after the answer.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "record_text": "<record_text>"
    },
    "name": "check_trading_record"
  }
}

Input Schema

Name	Required	Description	Default
`name`	No	Optional name of the strategy or EA
`filename`	No	The file's name, e.g. ReportTester.html or trades.csv (helps read the format)	trades.csv
`is_forward`	No	True if every trade in the record was taken after the strategy was fixed (a forward or live record)
`record_text`	Yes	Text of an MT5 Strategy Tester report (HTML), an MT4/MT5 account statement (HTML), a cTrader, NinjaTrader, TradingView ('List of trades') or Myfxbook CSV export, or any CSV of closed trades (close time + profit); under 1 MB
`versions_tried`	No	How many versions, settings or EAs were tried before this one, as stated by the user (it raises the luck bar)

Output Schema

Name	Required	Description
`last`	Yes
`more`	Yes
`note`	Yes
`read`	No	what was read from the record (trades, net, dates, currency, rows left out)
`first`	Yes
`reason`	Yes
`trades`	Yes
`summary`	Yes
`verdict`	Yes
`luck_bar`	Yes
`next_step`	No
`worst_day`	No	info only: the largest daily loss, for scale (never a verdict input)
`trade_days`	Yes
`good_points`	No	what the record does well; it follows the verdict and its reason
`losing_years`	Yes
`luck_counter`	No
`evidence_scope`	No	what the verdict shows and what it does not show
`versions_tried`	Yes
`t_day_clustered`	No	left out when the record has no spread of results to measure
`hidden_risk_found`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedNov 11, 2026

addedOutput schema / $defs / RecordRead

Added value: +{
+  "description": "upload-formats council 3 (11 Nov 2026, item 7): the same \"what we read\" block the website shows, so the assistant can check the\nrecord is the user's before trusting the verdict. Nothing from the file's own text",
+  "properties": {
+    "currency": {
+      "description": "the account currency where the file states it (a 3-letter code), else \"\"; amounts are never converted",
+      "title": "Currency",
+      "type": "string"
+    },
+    "date_order": {
+      "description": "day/month or month/day when the file's dates were slash or dot dates, else \"\"",
+      "title": "Date Order",
+      "type": "string"
+    },
+    "first": {
+      "description": "the first close date read (yyyy-mm-dd)",
+      "title": "First",
+      "type": "string"
+    },
+    "kind": {
+      "description": "the kind of record read (\"\" when not known)",
+      "title": "Kind",
+      "type": "string"
+    },
+    "language": {
+      "description": "the MT5 report language read, else \"\"",
+      "title": "Language",
+      "type": "string"
+    },
+    "last": {
+      "description": "the last close date read (yyyy-mm-dd)",
+      "title": "Last",
+      "type": "string"
+    },
+    "net": {
+      "description": "their total profit after costs, in the account currency",
+      "title": "Net",
+      "type": "number"
+    },
+    "net_check": {
+      "description": "the balance check of a translated MT5 report, else \"\"",
+      "title": "Net Check",
+      "type": "string"
+    },
+    "note": {
+      "description": "a fact about the record's costs (for example fees the export leaves out), else \"\"",
+      "title": "Note",
+      "type": "string"
+    },
+    "parser": {
+      "description": "the reader version that read the record",
+      "title": "Parser",
+      "type": "string"
+    },
+    "skipped": {
+      "description": "rows left out and why, with their line numbers; \"\" when none",
+      "title": "Skipped",
+      "type": "string"
+    },
+    "time_zone": {
+      "description": "the time zone the export states, else \"\"",
+      "title": "Time Zone",
+      "type": "string"
+    },
+    "trades": {
+      "description": "closed trades read",
+      "title": "Trades",
+      "type": "integer"
+    }
+  },
+  "required": [
+    "trades",
+    "net",
+    "first",
+    "last",
+    "kind",
+    "date_order",
+    "skipped",
+    "time_zone",
+    "language",
+    "net_check",
+    "currency",
+    "parser",
+    "note"
+  ],
+  "title": "RecordRead",
+  "type": "object"
+}

addedOutput schema / properties / read

Added value: +{
+  "anyOf": [
+    {
+      "$ref": "#/$defs/RecordRead"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "what was read from the record (trades, net, dates, currency, rows left out)"
+}

Changed6 schema fields changedNov 10, 2026

changedOutput schema / $defs / EvidenceScope / properties / does_not_show / description

Previous value: -"what it does not cover; tell the user both"New value: +"what the verdict does not cover (shown together with shows)"

changedOutput schema / $defs / GoodPoints / properties / context / description

Previous value: -"say this first: the points are true facts from the record and do not change the verdict"New value: +"the points are true facts from the record and do not change the verdict"

changedOutput schema / $defs / GoodPoints / properties / points / description

Previous value: -"up to 3 things the record does well, computed from its trades; give them AFTER the verdict, never alone"New value: +"up to 3 things the record does well, computed from its trades; they come after the verdict and never replace it"

changedOutput schema / $defs / GoodPoints / properties / what_if_note / description

Previous value: -"always give this with the what-if"New value: +"the condition that belongs with the what-if"

changedOutput schema / properties / evidence_scope / description

Previous value: -"what the verdict shows and does not show; tell the user both"New value: +"what the verdict shows and what it does not show"

changedOutput schema / properties / good_points / description

Previous value: -"what the record does well, after the verdict and its reason; never on its own"New value: +"what the record does well; it follows the verdict and its reason"

First observedNov 10, 2026

TDQS

A4.3/5.0

Behavior4/5

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

Annotations already declare readOnly/idempotent/non-destructive/openWorld=false, so the safety bar is lower, yet the description adds real value: it names the analytic steps (costs, losing years, grid/martingale signs, a luck test adjusted for the number of versions tried) and states the data-handling contract ('nothing is stored: the record is read as data, never run, and discarded'). It does not mention failure modes such as unparseable formats or the size limit, which keeps it short of a 5.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with the core judgement and the key distinction, with the data-handling note last where it belongs. The verdict enumeration and parenthetical are dense but each earns its place; the single long first sentence is heavy but not padded.

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?

For a complex analytic tool with an output schema and fully described parameters, the description covers purpose, alternative routing, processing steps and the read-as-data contract. Residual gaps (format parse failures, the 1 MB ceiling, latency of the luck test) are minor because the schema and output schema carry them.

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 every parameter including the format hints in record_text and the meaning of versions_tried is already documented in structured data. The description's only addition is that the version count 'raises the luck bar', which the schema itself already states, so it adds little beyond the baseline.

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 ('Judges whether a finished trading record's results look real or like luck') and enumerates the checks performed plus the exact verdict vocabulary (REAL / PROMISING / LIKELY_LUCK / NO_EVIDENCE / FAIL / HIDDEN_RISK / TOO_FEW). It explicitly distinguishes itself from test_strategy_code, so an agent can route correctly without opening either schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives an explicit positive condition ('a record of trades already taken or backtested') and an explicit exclusion with the named alternative ('for strategy code or written rules use test_strategy_code'). Nothing about when to select this tool is left to inference.

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

All EA Trade Tester by TrueTest tools Inspect

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.