mt5-mcp

Overview Schema Source Related Servers Discussions Admin

copy_rates

Downloads MetaTrader 5 bar history for a symbol and timeframe, paging until the terminal has no more data, and saves it as CSV or Parquet for offline analysis.

Instructions

Download bars, paging until the terminal runs out, and write CSV or Parquet.

Omit both dates to request every bar the terminal still serves. Pass both dates for one window. Bars outside that window are dropped, including the older bar the terminal returns when the window is before cached history. This is not how far back M1 goes. Use history_coverage for bars already on disk and extend_history with kind=m1 to download older months. The result is a file path, a count, a time range, and a short preview.

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

Input Schema

Name	Required	Default
`format`	No	csv
`symbol`	Yes
`date_to`	No
`save_to`	No
`date_from`	No
`timeframe`	No	H1

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Nov 6, 2026

TDQS

A4.3/5.0

Behavior4/5

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

Goes well beyond the annotations by disclosing the paging behavior, the filtering rule that silently drops out-of-window bars (including the extra older bar near cached history boundaries), and the shape of the result. Annotations already declare readOnlyHint=false, destructiveHint=false and openWorldHint=true, and the file-writing behavior is consistent with that. The remaining gap is that it never says the tool requires a launched terminal or where output lands when save_to is null.

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-loads the action and the paging behavior, then handles date semantics and alternatives in order, with no filler sentences. 'This is not how far back M1 goes' is useful but slightly clipped phrasing that reads as an aside rather than a clean constraint.

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?

There is no output schema, and the description compensates by enumerating the return payload (file path, count, time range, preview). For a six-parameter file-writing tool, the missing pieces are the save_to default location and timeframe meaning, which matter for correct invocation but are narrower gaps than the strong date and alternative guidance.

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?

With 0% schema description coverage the description must carry all six parameters, and it only covers date_from/date_to pairing and format values (CSV/Parquet). symbol, timeframe (default H1) and especially save_to, whose null default determines where the file is written, are left entirely undefined.

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 ('Download bars, paging until the terminal runs out') plus the artifact produced ('write CSV or Parquet'). It also distinguishes itself from the two nearest siblings by naming history_coverage and extend_history with kind=m1, so an agent can route correctly without opening schemas.

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 explicit call-shape rules: omit both dates for the full available history, pass both dates for a single window. It also names the alternatives and the condition that selects them ('Use history_coverage for bars already on disk and extend_history with kind=m1 to download older months') and warns that this tool is not how far back M1 goes.

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