mt5-mcp

Overview Schema Source Related Servers Discussions Admin

smoke_test

Compile an Expert Advisor, run a one-day Strategy Tester backtest, and scan the journal for blocking init, history-sync, tester, or runtime errors without placing live orders.

Instructions

Compile an EA, run that one day, and scan the tester journal.

date is both FromDate and ToDate. timeout_sec defaults to 180. Blocking lines are init failures, history not synchronized, tester rejects, and runtime errors. A history-sync miss is retried once. This does not place a live order.

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": {
      "source": "<source>",
      "symbol": "<symbol>"
    },
    "name": "smoke_test"
  }
}

Input Schema

Name	Required	Default
`date`	No	2024.01.02
`model`	No	ohlc
`period`	No	H1
`source`	Yes
`symbol`	Yes
`timeout_sec`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Nov 6, 2026

TDQS

B3.4/5.0

Behavior4/5

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

Beyond the annotations (readOnlyHint=false, openWorldHint=true, destructiveHint=false), the description discloses real behavior: which journal lines count as blocking, that a history-sync miss is retried once, and that no live order is placed. It stops short of saying what the tool returns on failure or how the blocking lines are surfaced.

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?

Four short sentences, front-loaded with the action sequence, then scope, then the safety disclaimer. Almost no waste; only 'run that one day' is slightly loose phrasing for what is really a single-date backtest window.

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

Completeness3/5

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

For a six-parameter execution tool with no output schema, the description gives a reasonable mental model of the failure modes it scans for, but omits what a successful versus failing result looks like (pass/fail flag, journal excerpt) and what 'source' should contain. An agent could call it, but would be guessing about the response.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must carry parameter meaning, and it only covers two of six: 'date' is clarified as both FromDate and ToDate (genuinely valuable) and timeout_sec's default is repeated from the schema. The required 'source' and 'symbol' plus 'model' and 'period' get no explanation at all, leaving the most load-bearing parameters ambiguous.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description gives a concrete three-step sequence: compile an EA, run a single day, scan the tester journal, which is specific enough to distinguish it from the bare 'compile' and general 'run_backtest' siblings. It does not explicitly name those siblings as alternatives, so the differentiation is implied rather than stated.

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

Usage Guidelines3/5

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

Usage is implied by the name 'smoke_test' and by the single-day scope, and 'This does not place a live order' usefully bounds the blast radius. However, there is no explicit statement of when to prefer this over compile-then-run_backtest, nor any prerequisite about terminal state or symbol selection.

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