EA Trade Tester by TrueTest

Get a Strategy Lab's status and result

get_lab_status

Read-onlyIdempotent

Returns where a Strategy Lab stands - waiting for the rule card, waiting for the user's check, queued, running, done or watching forward - with the place in the queue, a rough wait, and once tested the verdict and its reason. Use it when the user asks how their test is going. It changes nothing in the lab; a look counts as a visit, which keeps the lab for 12 more months.

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": {
      "lab": "<lab>"
    },
    "name": "get_lab_status"
  }
}

Input Schema

Name	Required	Description	Default
`lab`	Yes	The private lab link from test_strategy_code or from a TrueTest email (https://truetest.uk/lab/...), or its 32-character code; 'demo' for the public sample lab

Output Schema

Name	Required	Description
`note`	Yes
`reason`	No
`sample`	No	present only for the public sample lab
`status`	Yes
`lab_url`	Yes
`meaning`	Yes
`rebuild`	No	present when the rebuild differs from the original
`summary`	Yes
`verdict`	No
`kept_note`	No	how long the lab is kept and what moves that date on
`worst_day`	No	info only: the largest daily loss, for scale
`good_points`	No	once tested: what the rebuilt strategy does well; it follows the verdict
`luck_counter`	No
`queue_length`	No	queued or running: labs in the queue
`cost_estimate`	No	present when the costs of some tested symbols are an estimate not yet checked against live prices: which ones
`forward_watch`	No
`evidence_scope`	No	once tested: what the result shows and does not show
`versions_tested`	Yes
`rough_wait_minutes`	No	queued or running: a rough wait
`kept_at_least_until`	No	a customer lab: the UTC date (yyyy-mm-dd) until which it is kept at least, under the current policy

Schema Changelog

Changes observed during successful MCP inspections.

Changed8 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"

addedOutput schema / properties / cost_estimate

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "present when the costs of some tested symbols are an estimate not yet checked against live prices: which ones",
+  "title": "Cost Estimate"
+}

changedOutput schema / properties / good_points / description

Previous value: -"once tested: what the rebuilt strategy does well, after the verdict; never on its own"New value: +"once tested: what the rebuilt strategy does well; it follows the verdict"

addedOutput schema / properties / kept_at_least_until

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "a customer lab: the UTC date (yyyy-mm-dd) until which it is kept at least, under the current policy",
+  "title": "Kept At Least Until"
+}

addedOutput schema / properties / kept_note

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "how long the lab is kept and what moves that date on",
+  "title": "Kept Note"
+}

First observedNov 10, 2026

TDQS

A4.4/5.0

Behavior5/5

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

Annotations already declare readOnlyHint, idempotentHint, non-destructive and closed-world, yet the description still adds genuinely non-obvious behavior: 'It changes nothing in the lab; a look counts as a visit, which keeps the lab for 12 more months.' That retention side effect is exactly the kind of consequence an agent could not infer from structured fields, and it also clarifies the scope of readOnly (no lab content is altered).

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?

Two front-loaded sentences: the first defines the return content, the second gives the trigger and the retention side effect. The six-state enumeration is longer than strictly necessary given an output schema exists, but each state is informative and nothing is redundant filler.

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?

For a one-parameter read tool with an output schema, the description covers purpose, states, queue/wait information, when to call it, and the visit-retention side effect. Nothing an agent needs in order to call it correctly is missing.

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 description coverage is 100% and the single 'lab' parameter is already fully documented there (private lab link from test_strategy_code or a TrueTest email, 32-character code, or 'demo'). The description adds no further meaning about the parameter, so the 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?

The description opens with a specific verb and resource: it 'Returns where a Strategy Lab stands,' then enumerates the concrete states (waiting for the rule card, waiting for the user's check, queued, running, done, watching forward) plus queue position, rough wait, verdict and reason. An agent can immediately tell this is the read-status counterpart to starting a test, without opening the schema.

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?

It gives an explicit trigger: 'Use it when the user asks how their test is going,' which is the natural moment to call this rather than test_strategy_code. It stops short of naming alternatives or stating when-not to use it (e.g. for a code that was never submitted), so it is clear context but not full routing guidance.

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.