de en es ja ko ru zh

QUOTEZ

Name: QUOTEZ
Author: PNX89

by PNX89

Overview Schema Source Related Servers Discussions Admin

Python

Local

QUOTEZ

Рыночные данные для агентов. Только чтение по конструкции, а не по настройке.

Python License: MIT

MCP-сервер, который предоставляет рыночные данные MetaTrader 5 в виде типизированных инструментов только для чтения, которые может вызывать LLM-агент. Требуется Python 3.11 или новее, одна зависимость времени выполнения, транспорт stdio. Значок останавливается на 3.13, потому что там останавливаются классификаторы; CI также запускает 3.14, помеченный как рекомендательный, и 3.14 присоединится к значку, как только он станет достаточно стабильным, чтобы быть обещанием, а не надеждой.

Агент настолько хорош, насколько хороши инструменты, которые вы ему даёте, и рыночные данные — это то, где неаккуратный инструмент наносит реальный ущерб. Модель пересказывает всё, что возвращает инструмент, как факт, поэтому полезная нагрузка без единиц измерения, часового пояса и источника происхождения превращается в уверенное предложение о цене, на которую кто-то может отреагировать. QUOTEZ отвечает сгенерированными схемами вывода, а не текстовыми блоками, везде UTC, флагом synthetic на каждой полезной нагрузке и отсутствием пути записи в коде.

Это один инструмент, созданный так, чтобы он не мог нанести ущерб, что является меньшим и более проверяемым вопросом, чем можно ли доверять агенту в целом с инструментами. Более крупный вопрос решается в QUELLZ.

Область применения и ограничения

Только чтение: никаких order_send, order_check, symbol_select, никаких операций записи любого рода.
Для live-данных MetaTrader требуется Windows и работающий терминал; колеса только для win_amd64.
Источник по умолчанию воспроизводит сгенерированные данные и помечает каждую полезную нагрузку synthetic: true.
Время везде UTC, и каждый бар помечен своим открытием (левая граница интервала).

Related MCP server: ibkr-mcp

Пример сессии агента

Реальный вывод, а не вставка. Повторно сгенерируйте его с помощью uv run python examples/agent_session.py; tests/test_readme.py проверяет этот блок побайтово на соответствие stdout этой команды. Цены воспроизведения сгенерированы, а не записаны с какого-либо рынка.

QUOTEZ over an in-memory MCP client, source=replay.
Every price below is generated. This repository bundles no real market data.

>>> list_symbols(group="*FX*")
{
  "source": "replay",
  "synthetic": true,
  "count": 2,
  "symbols": [
    {"name": "SYNTH_FX_ALPHA", "description": "Synthetic FX pair Alpha", "digits": 5, "point": 1e-05},
    {"name": "SYNTH_FX_BETA", "description": "Synthetic FX pair Beta", "digits": 3, "point": 0.001}
  ]
}

>>> get_quote(symbol="SYNTH_FX_ALPHA")
{
  "symbol": "SYNTH_FX_ALPHA",
  "time": "2026-06-12T13:59:00Z",
  "bid": 1.08044,
  "ask": 1.08056,
  "spread_points": 12,
  "source": "replay",
  "synthetic": true
}

>>> get_bars(symbol="SYNTH_FX_ALPHA", timeframe="H1", count=5)
{
  "symbol": "SYNTH_FX_ALPHA",
  "timeframe": "H1",
  "source": "replay",
  "synthetic": true,
  "count": 5,
  "bars": [
    {"time": "2026-06-12T08:00:00Z", "open": 1.07985, "high": 1.08231, "low": 1.07978, "close": 1.08125, "tick_volume": 4257, "spread": null},
    {"time": "2026-06-12T09:00:00Z", "open": 1.08125, "high": 1.0844, "low": 1.08113, "close": 1.08302, "tick_volume": 2501, "spread": null},
    {"time": "2026-06-12T10:00:00Z", "open": 1.08302, "high": 1.08439, "low": 1.08298, "close": 1.08368, "tick_volume": 1643, "spread": null},
    {"time": "2026-06-12T11:00:00Z", "open": 1.08368, "high": 1.08395, "low": 1.08036, "close": 1.08097, "tick_volume": 1570, "spread": null},
    {"time": "2026-06-12T12:00:00Z", "open": 1.08097, "high": 1.08284, "low": 1.08084, "close": 1.08159, "tick_volume": 2589, "spread": null}
  ]
}

>>> symbol_info(symbol="SYNTH_FX_ALPHA")
{
  "name": "SYNTH_FX_ALPHA",
  "description": "Synthetic FX pair Alpha",
  "digits": 5,
  "point": 1e-05,
  "spread": 12,
  "spread_float": true,
  "trade_stops_level": 10,
  "trade_freeze_level": 0,
  "trade_tick_value": 1.0,
  "trade_tick_size": 1e-05,
  "trade_contract_size": 100000.0,
  "volume_min": 0.01,
  "volume_max": 100.0,
  "volume_step": 0.01,
  "currency_base": "SYA",
  "currency_profit": "SYN",
  "currency_margin": "SYA",
  "source": "replay",
  "synthetic": true
}

A symbol that does not exist, to show what the model actually sees:

>>> get_quote(symbol="NOT_A_SYMBOL")
is_error: true
Error executing tool get_quote: Symbol 'NOT_A_SYMBOL' is not available on this server.

Быстрый старт

Одна команда, ничего настраивать не нужно, никакой установки MetaTrader:

uvx --from git+https://github.com/PNX89/QUOTEZ quotez --source replay

QUOTEZ не опубликован на PyPI, поэтому установка производится из git-формы; добавьте @main, тег или коммит для фиксации ревизии, согласно документации по зависимостям uv. Затем команда может зависнуть, потому что stdout — это провод JSON-RPC, и управление осуществляется хостом. Чтобы увидеть его работу без хоста, клонируйте репозиторий и запустите пример сессии, которая управляет тем же сервером из внутрипроцессного клиента:

git clone https://github.com/PNX89/QUOTEZ && cd QUOTEZ
uv run python examples/agent_session.py

В Windows, если терминал уже запущен и выполнен вход:

uvx --from "quotez[mt5] @ git+https://github.com/PNX89/QUOTEZ" quotez --source mt5

Скрипт консоли — единственная точка входа, принимающая флаги, и флаги имеют приоритет над переменными окружения. mcp run src/quotez/server.py также запускает этот сервер через глобальный объект mcp на уровне модуля, но он ничего не передаёт, поэтому этот путь считывает переменные.

Флаг	Переменная окружения	По умолчанию	Значение
`--source`	`QUOTEZ_SOURCE`	`replay`	`replay` читает встроенные сгенерированные файлы, `mt5` читает live-терминал
`--symbols`	`QUOTEZ_SYMBOLS`	пусто	Разделённый запятыми белый список, без учёта регистра. Пустое значение открывает всё, что есть в источнике
`--max-bars`	`QUOTEZ_MAX_BARS`	`1000`	Максимальное количество баров, которое может вернуть один вызов, от 1 до 5000
`--log-level`	`QUOTEZ_LOG_LEVEL`	`INFO`	Порог логирования. Записи всегда идут в stderr, потому что stdout — это провод

Подключение к хосту

Хосты не сходятся в ключе конфигурации, и путаница между mcpServers и servers — обычная причина, по которой сервер никогда не появляется.

Хост	Файл	Ключ
Claude Desktop	`~/Library/Application Support/Claude/claude_desktop_config.json` на macOS, `%APPDATA%\Claude\claude_desktop_config.json` на Windows	`mcpServers`
Cursor	`.cursor/mcp.json`	`mcpServers`
VS Code	`.vscode/mcp.json`	`servers`, и добавьте `"type": "stdio"` рядом с `command`
Claude Code	нет файла, используйте CLI	`claude mcp add quotez -- uv tool run --from git+https://github.com/PNX89/QUOTEZ quotez --source replay`

{
  "mcpServers": {
    "quotez": {
      "command": "/absolute/path/to/uv",
      "args": ["tool", "run", "--from", "git+https://github.com/PNX89/QUOTEZ",
               "quotez", "--source", "replay"]
    }
  }
}

command должен быть абсолютным путём из which uv. Хост запускает сервер с почти пустым PATH, поэтому голый uv — самая распространённая причина, по которой сервер молча не подключается.

Инструменты

Восемь инструментов, зарегистрированных в этом порядке, который является порядком, возвращаемым tools/list; клиенты кешируют этот список, поэтому порядок зафиксирован намеренно. Один ресурс, symbols://list, предоставляет ту же вселенную инструментов в виде application/json.

Инструмент	Аргументы	Возвращает	Доступ	Источник Replay	Источник MetaTrader
`list_symbols`	`group` необязательный, синтаксис групп MetaTrader	`SymbolList`	чтение	4 сгенерированных инструмента	`symbols_get(group=...)`
`get_quote`	`symbol`	`Quote`	чтение	вычисляется из последнего сохранённого бара	`symbol_info_tick`
`get_bars`	`symbol`, `timeframe`, `count` (от 1 до 5000, не более `--max-bars`)	`BarSeries`	чтение	M1 сворачивается локально	`copy_rates_from_pos`
`get_bars_range`	`symbol`, `timeframe`, `start`, `end`	`BarSeries`	чтение	M1 сворачивается локально	`copy_rates_range`
`symbol_info`	`symbol`	`SymbolSpec`	чтение	из `symbols.json`	`symbol_info`
`get_account`	нет	`Account`	чтение	фиктивные данные, `synthetic: true`	`account_info`, логин маскируется
`list_positions`	нет	`PositionList`	чтение	всегда пусто	`positions_get`
`list_orders`	нет	`OrderList`	чтение	всегда пусто	`orders_get`

list_symbols использует собственный синтаксис фильтра групп MetaTrader вместо создания собственного: подстановочные знаки * в начале и конце шаблона, условия, разделённые запятыми, и ! для отрицания. Включения должны предшествовать исключениям, поэтому "*, !*USD*" — это всё, кроме инструментов USD, а "!*USD*, *" соответствует всему. Mt5Source передаёт строку в symbols_get; источник воспроизведения применяет тот же синтаксис через quotez.groups, поэтому оба одинаково обрабатывают фильтр.

Каждый инструмент возвращает модель Pydantic, поэтому SDK выводит outputSchema из аннотации возврата, заполняет structuredContent и проверяет полезную нагрузку перед тем, как она покинет сервер. Используется незавёрнутый BaseModel, поэтому get_bars возвращает объект с ключом bars, а не {"result": ...}.

Как это работает

flowchart LR
    host["MCP host<br/>Claude Desktop, Cursor, VS Code"]
    server["quotez.server<br/>8 tools, 1 resource"]
    proto["MarketDataSource<br/>Protocol"]
    replay["ReplaySource<br/>bundled CSVs, any OS"]
    mt5["Mt5Source<br/>Windows only, lazy import"]
    term["MetaTrader 5 terminal"]
    host -- "JSON-RPC over stdio" --> server
    server --> proto
    proto --> replay
    proto --> mt5
    mt5 -- "read calls only" --> term

MarketDataSource — это шов, на котором написан весь сервер. Ничто выше него не импортирует MetaTrader5, и Mt5Source разрешает расширение внутри частного помощника при первом использовании, а не при импорте модуля, поэтому import quotez работает там, где нет установленного колеса. Именно это делает ReplaySource полноценной реализацией, а не макетом: уровень инструментов не может различить их, поэтому весь набор выполняется по реальному пути кода без установленного терминала.

Встроенные данные — это четыре сгенерированных инструмента (SYNTH_FX_ALPHA, SYNTH_FX_BETA, SYNTH_IDX_GAMMA, SYNTH_MTL_DELTA), по 3600 баров M1 каждый, с 08:00 до 14:00 UTC по будням с 2026-06-01 по 2026-06-12, с девятью разрывами сессий: восемь ночных и один через выходные, потому что непрерывный ряд — это ряд, скрывающий ошибку агрегации. scripts/generate_replay_data.py создал файлы один раз из seed-генератора random.Random, и вывод зафиксирован. CSV-файлы читаются через importlib.resources, а не через Path(__file__).parent, что работает в репозитории, но ломается под запакованной установкой, которую выполняет uvx.

Инструменты и ресурсы — это не одно и то же

Инструмент — это то, что вызывать решает МОДЕЛЬ; ресурс — это то, что загружать решает ПРИЛОЖЕНИЕ. get_bars управляется моделью: она выбирает символ, таймфрейм и количество в процессе рассуждения. symbols://list управляется приложением: хост один раз помещает вселенную в контекст до того, как модель что-либо решит. Вот почему это не случайное дублирование list_symbols, который является фильтрованным поиском, запускаемым моделью намеренно.

Очевидный следующий ресурс, bars://{symbol}/{timeframe}, был намеренно не построен: он дублирует get_bars для тех же данных, а URI с заполнителями — это шаблон ресурса, который переводит resources/list в resources/templates/list и плохо или вообще не отображается многими хостами. Тест проверяет, что не зарегистрировано никаких шаблонов ресурсов.

Агрегация таймфреймов

Источник воспроизведения хранит один базовый таймфрейм, M1, а quotez.aggregate сворачивает из него M5, M15, M30, H1, H4 и D1. Одна сохранённая копия, одно сворачивание, тестируется самостоятельно, что важно, потому что его режим отказа молчалив: неправильная агрегация возвращает правдоподобные числа вечно и никогда не вызывает исключений.

Источник MetaTrader ничего не сворачивает. Терминал уже содержит все периоды, поэтому его запрашивают напрямую по таймфрейму; повторное получение их из M1 было бы медленнее и расходилось бы с графиками, которые открыты у оператора. Поэтому два источника отвечают на один и тот же вызов слегка по-разному для D1, H4 и spread, что указано в ограничениях, а не оставлено для самостоятельного обнаружения.

Инварианты сворачивания, каждый из которых является именем теста:

M1 — единственный базовый таймфрейм. Все старшие получаются агрегацией.
Бары привязаны к астрономическому времени и вычисляются целочисленным делением эпохальной секунды, а не группировкой каждых N строк подряд.
Целевые таймфреймы — целые кратные 60 секунд. Всё остальное вызывает InvalidRequest.
OHLC: первый open, максимальный high, минимальный low, последний close.
tick_volume суммируется. spread — нет: это свойство котировки в конкретный момент времени, поэтому агрегированный бар возвращает null.
Бары маркируются по левой границе в UTC.
Незавершённый последний бар отбрасывается, а не выдаётся как частичный. Бар эмитируется только тогда, когда во входных данных есть бар на момент окончания этого бара или позже.
Пустой ввод возвращает пустой список.

Инвариант 2 заслуживает своих тестов. Группировка по позиции совпадает с группировкой по астрономическому времени на непрерывном ряде и расходится при наличии пропуска: группировка 360 баров сессии по четыре помещает закрытие пятницы и открытие понедельника в один бар, называя его четырёхчасовой свечой. Инвариант 7 — его пара, потому что окончание сессии — не то же самое, что исчерпание данных.

Безопасность

Утверждение структурное, а не настраиваемое. В этой кодовой базе нет путей записи. В src/quotez/ нет order_send, order_check, symbol_select, изменений MarketWatch или записи в файлы. Никакая конфигурация не может включить запись, потому что включать нечего.

Два теста это закрепляют, и второй из них — значимый. Первый ищет в пакете три вызова MetaTrader: дёшево, покрывает все файлы и обходится именем, собранным во время выполнения. Второй обходит AST mt5source.py и утверждает позитивное свойство: набор атрибутов, которые этот пакет читает из терминального модуля, в точности равен вызовам чтения, перечисленным в его собственной строке документации, плюс семь констант таймфреймов, без доступа через getattr и без переприсваивания второй переменной. _mt5() возвращает весь модуль MetaTrader5, поэтому отсутствие трёх имён из нескольких сотен атрибутов само по себе мало что доказывает. Пять намеренно сломанных фрагментов проверяются этим обходом, чтобы сам обход гарантированно выдавал ошибку, когда должен.

Каждый инструмент объявлен как ToolAnnotations(read_only_hint=True, open_world_hint=False). Это объявление — любезность для клиентов и не более: спецификация MCP предписывает клиентам считать аннотации инструментов ненадёжными, если они не получены от доверенного сервера. read_only_hint=True описывает инструмент, а не ограничивает клиента, и свойство, которое может проверить рецензент, — это отсутствие вызовов, а не наличие флага. В проекции на собственные Рекомендации по безопасности для инструментов спецификации, включая требования, которым этот сервер не соответствует:

Требование спецификации	QUOTEZ	Где
Проверять все входные данные	Да	JSON Schema, полученная из аннотаций типов, `Literal` таймфреймы, `Field(ge=1, le=5000)` для `count`, плюс проверки во время выполнения в обработчиках
Реализовать контроль доступа	Да	белый список символов применяется к каждому инструменту и ресурсу, а не только к геттерам
Ограничивать частоту вызовов	Нет	не реализовано и указано в ограничениях. Stdio-сервер — дочерний процесс ровно одного хоста, поэтому хост отвечает за ограничение частоты
Очищать выходные данные	Да	логин учётной записи маскируется до последних четырёх цифр, имена брокера, сервера и владельца счёта никогда не возвращаются, а `synthetic` — обязательное поле в каждой полезной нагрузке

Заблокированный символ сообщается как SymbolNotFound с сообщением, которое получает опечатка: «Символ 'X' недоступен на этом сервере». Отдельное «не разрешено» превратило бы белый список в оракул для обнаружения инструментов, которые оператор решил не раскрывать.

Ошибки передаются по одному из двух каналов, в зависимости от того, могла ли более умная модель избежать сбоя. Опечатка в символе — могла, поэтому SymbolNotFound и InvalidRequest — обычные исключения, которые становятся ошибками инструмента, которые модель может прочитать и повторить попытку. Терминал, который не запущен, — не мог, поэтому SourceUnavailable вызывается как MCPError, протокольная ошибка без какого-либо результата. Здесь ничего не возвращает строку ошибки: возвращаемая строка имеет is_error=False и читается как успешный ответ. Тест вызывает каждый инструмент с некорректными данными и проверяет флаг.

Проектные решения

mcp>=2.0.0,<3 и MCPServer, а не привязка к v1 и FastMCP. SDK всё ещё предлагает mcp>=1.28,<2 для тех, кто ещё не мигрировал, но сервер эпохи v1 выдаёт себя за три секунды: from mcp.server.fastmcp import FastMCP. В руководстве по миграции есть переименования. Низкоуровневый Server был альтернативой и больше не оборачивает возвращаемые значения автоматически, поэтому пришлось бы вручную писать JSON Schema для восьми инструментов.

Типизированные возвращаемые значения Pydantic, а не текстовые блоки. Большинство публичных MCP-серверов возвращают прозу и оставляют её парсинг модели. Здесь аннотация возврата — это выходная схема, поэтому типизация ничего не стоит и даёт валидацию до того, как полезная нагрузка покинет сервер.

Два инструмента для баров, а не один с необязательными аргументами. JSON Schema не может выразить взаимное исключение, поэтому один get_bars(count or start..end) перенёс бы «либо то, либо другое, но не оба» на модель в виде прозы. У двух инструментов две полностью валидные схемы, и класс ошибки «оба заданы, ни один не задан» перестаёт существовать.

Сгенерированные данные, а не реальный фид. Лицензионное решение, а не предпочтение. Экспорт MetaTrader — это лицензированный фид брокера, а для индексных и акционерных CFD базовый актив лицензирован биржей. Страницы помощи Yahoo прямо указывают ограничение: вы не должны распространять информацию, отображаемую или предоставляемую Yahoo Finance, а её условия API для разработчиков отдельно ограничивают продажу или сублицензирование доступа. FAQ HistData не предоставляет никаких прав на распространение; там сказано только, что данные предоставляются без гарантии, а молчание — не лицензия. Размещение любых таких данных в репозитории MIT означало бы перелицензирование данных, на которое у меня нет прав.

Стандартная библиотека, а не pandas или numpy. В масштабах CSV-файлов в комплекте csv плюс datetime плюс dataclasses достаточно, и дерево остаётся проверяемым. Однако это дерево стоит называть честно, целиком: mcp 2.x — это одна прямая зависимость, которая тянет anyio, httpx2, jsonschema, mcp-types, opentelemetry-api, pydantic, pyjwt с его крипто-дополнением, python-multipart, sse-starlette, starlette, typing-extensions, typing-inspection и uvicorn, плюс pywin32 на Windows. Крипто-дополнение тянет за собой cryptography, cffi и pycparser. Это больший объём, чем v1, и тест читает зафиксированный uv.lock и завершается ошибкой, если этот список перестаёт ему соответствовать, потому что абзац, существующий для именования дерева, ничего не стоит, если он называет большую его часть.

Нет инструмента run_backtest. Бэктест неограничен по вычислительным ресурсам, требует гораздо больше, чем MarketDataSource, и дублировал бы QUACKZ, поэтому пара выглядела бы как два половинчатых проекта вместо двух сфокусированных. По той же причине ограничения здесь локальны для предметной области: проверка входных данных, ограниченные запросы, фиксированная вселенная инструментов, отсутствие побочных эффектов. Общие ограничения для агентов принадлежат QUELLZ, а не изобретаются заново пять раз.

Ограничения

Ни один исполнитель непрерывной интеграции не тестирует живой путь MetaTrader, нигде. Нет колеса для не-Windows, и ни у одного исполнителя нет терминала или брокерского счёта. Задание Windows доказывает, что расширение импортируется и что Mt5Source корректно сообщает об отсутствующем терминале, и это всё. Сопоставление полей Mt5Source — наименее протестированный код здесь, покрытый тестами с фиктивным модулем.
MetaTrader5 работает только на Windows и не публикует исходную дистрибуцию, поэтому pip install quotez[mt5] намеренно ничего не делает на macOS и Linux. Тест проверяет, что маркер окружения сохраняет это поведение.
initialize() запускает терминал, если он ещё не запущен, и вся операция ограничена его аргументом timeout, по документации по умолчанию равным 60000 миллисекунд. Страница не указывает время самого запуска, поэтому считайте 60 секунд верхней границей вызова, а не измеренным временем запуска. QUOTEZ открывает соединение один раз за время жизни сервера, а не на каждый вызов, поэтому его стоимость ложится на запуск, а не заставляет первый вызов инструмента выглядеть зависшим.
Два источника не сходятся в том, где начинается D1 или H4 бар. Агрегация воспроизведения округляет вниз по эпохальной секунде, поэтому D1 открывается в 00:00 UTC, а H4 — в 00, 04, 08, 12, 16 и 20 UTC. Терминал MetaTrader выравнивает D1 и H4 по серверному дню брокера, который обычно UTC+2 или UTC+3, поэтому один и тот же get_bars(symbol, "D1") возвращает свечу с другим временем открытия и другими OHLC в зависимости от того, какой источник настроен. Здесь ничего не пересэмплирует M1 терминала, чтобы скрыть это, потому что бар, расходящийся с собственным графиком оператора, хуже документированного смещения.
По той же причине spread равен null на каждом баре воспроизведения выше M1 и установлен на каждом баре MetaTrader. Агрегация намеренно его очищает; терминал сообщает своё собственное значение на каждом таймфрейме, и QUOTEZ передаёт его, не отбрасывая данные, предоставленные источником.
copy_rates_from_pos и copy_rates_range молча ограничиваются настройкой терминала «Макс. баров в графике», поэтому запрос в пределах собственного лимита сервера всё равно может вернуться укороченным, и ничто в API MetaTrader об этом не сообщает.
get_bars пропускает бар, который терминал всё ещё строит, поэтому его самый новый бар всегда закрыт. get_bars_range — нет, потому что границы заданы вызывающей стороной: end внутри текущего интервала возвращает частичный бар этого интервала.
symbol_info() возвращает None для неизвестного символа вместо вызова исключения, как и symbols_get() при ошибке. Каждое место вызова здесь это проверяет, но такова форма оборачиваемого API.
MetaTrader хранит время баров и тиков в UTC без смещения, в то время как наивный datetime Python разрешается относительно локальной зоны; документация copy _rates _range говорит об этом. Каждая исходящая временная метка строится с tz=UTC, а наивные входные данные отклоняются, но это ловушка, которая молча сдвигает целый ряд на час.
Нет ограничения частоты запросов. Stdio-сервер — дочерний процесс одного хоста, и хост за это отвечает.
Данные воспроизведения — образцового масштаба и сгенерированы: 4 инструмента, по 3600 M1 баров каждый, десять торговых дней. Они демонстрируют инструменты и проверяют агрегацию, но не являются ни исследовательским набором данных, ни рынком.
Версия 0.1.0 — только для чтения и только stdio, без возможности prompts, без транспорта SSE или streamable HTTP и без OAuth.

Зачем я это создал

Я провожу исследования методом walk forward на индексных данных и держу терминалы MetaTrader для валютной и металлической стороны, так что обе половины уже были у меня на столе. Поводом написать это стало наблюдение за агентом, который повторял число из плохо типизированного инструмента как факт — без единиц, без часового пояса и без указания источника. В рыночных данных это не косметика: бар, обозначенный ценой закрытия вместо цены открытия, или метка времени, незаметно сдвинутая на местное время, даёт ответ, который выглядит правильным, но сдвинут на час. Поэтому в основном это решения о происхождении данных и о том, что может утверждать инструмент, обёрнутые вокруг небольшого кода агрегации.

Разработка

uv sync --dev
uv run pytest
uv run ruff check .
uv run ruff format --check .
uv run mypy

251 тест, без сети, за несколько секунд, и идентично на macOS, Linux и Windows. Это число проверено на реальном наборе данных, потому что число в README — это число, которое никто не обновляет.

Лицензия

MIT. См. LICENSE.

Часть набора инструментов Q...Z, пять инструментов для сбоя, который не объявляет о себе:

QUACKZ, сдувающий бэктест, который выглядит хорошо только потому, что был выбран из двухсот.
QUOTEZ, этот: рыночные данные, которые агент может прочитать, но не может на них действовать.
QUELLZ, измеряющий, во что обходится сдерживание инъекции промптов — как в полезности, так и в частоте атак.
QUIDZ, отклоняющий исходящий платёж, который мог бы уйти дважды.
QUESTZ, останавливающий скрапер, прежде чем он запишет CSV со страницы, изменившей форму.

Available Tools

8 tools

get_accountGet account stateA

Read-only

Return the connected account's balance, equity, margin and leverage.

The login is masked to its last four digits and the broker, server and account holder names are never returned. On the replay source these figures are invented placeholders describing no real account: the payload carries synthetic=true, the currency is SYN and the login is ****0000. Do not restate them as a real balance.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`equity`	Yes	Balance plus floating profit and loss.
`margin`	Yes	Margin currently in use.
`source`	Yes	Data source that produced these figures.
`balance`	Yes	Balance, excluding floating profit and loss.
`currency`	Yes	Account deposit currency.
`leverage`	Yes	Account leverage, for example 100 for 1:100.
`synthetic`	Yes	True when the figures are generated. The replay source always sets this, and its balance and equity are invented placeholders that describe no real account.
`margin_free`	Yes	Margin available for new positions.
`login_masked`	Yes	Account login masked to its last four digits. The full login is never returned.
`margin_level`	Yes	Equity divided by margin, as a percentage.

TDQS

A4.5/5.0

Behavior5/5

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

The description discloses key behavioral traits beyond annotations: login masking, omission of broker/server/account holder names, and synthetic data indicators on replay. This adds significant value over the readOnlyHint and openWorldHint annotations.

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?

The description is three sentences long, front-loaded with the main purpose, and every sentence adds essential information. There is no redundancy or wasted language.

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?

Given the tool has no parameters and an output schema exists, the description adequately covers the return values and adds critical context about data masking and synthetic mode. It is complete for an agent to understand and invoke the tool correctly.

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?

The tool has no parameters and schema coverage is 100%, so the baseline is 3. The description does not add meaning to any parameters because there are none to explain; it appropriately focuses on the tool's output and behavior.

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 clearly states the verb 'Return' and the specific resource 'connected account's balance, equity, margin and leverage'. This distinguishes it from sibling tools like list_symbols, get_quote, and get_bars, which operate on different data.

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?

The description provides clear context about when the tool returns synthetic data on the replay source and warns against restating it as real. It does not explicitly contrast with siblings, but the context is sufficient for an agent to understand when to use this tool.

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

get_barsGet recent barsA

Read-only

Return the most recent OHLCV bars for a symbol, oldest first.

Times are UTC and label each bar's OPEN, the left edge of the interval it covers. count is capped by the server (see the server instructions for the current limit); ask for a coarser timeframe rather than more bars. The bar that is still forming is never returned, so the newest bar is always a closed one; call get_quote for the current price. An unknown or unavailable symbol returns a tool error naming the symbol; call list_symbols first if unsure. On the replay source the prices are generated, not recorded from any market.

ParametersJSON Schema

Name	Required	Description
`count`	No	How many of the most recent bars to return, newest last.
`symbol`	Yes	Instrument name exactly as list_symbols spells it.
`timeframe`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`bars`	Yes	The bars, oldest first.
`count`	Yes	Number of bars returned.
`source`	Yes	Data source that produced these bars.
`symbol`	Yes	Symbol these bars belong to.
`synthetic`	Yes	True when the prices are generated, not observed.
`timeframe`	Yes	Timeframe of each bar.

TDQS

A4.9/5.0

Behavior5/5

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

The description discloses critical behavioral traits beyond annotations: bars are in UTC labeling the open, the newest bar is always closed (never returns forming bar), the server caps count, and on replay source prices are generated (not recorded). The readOnlyHint annotation is consistent with the read-only nature described, and no contradiction exists.

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?

The description is concise (5 sentences) and front-loaded: first sentence states the core purpose and ordering. Every sentence adds distinct value (timezone, counting strategy, bar state, error handling, data source). No wasted words.

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?

Given the tool has 3 parameters, an output schema (present), and annotations (readOnlyHint, openWorldHint), the description covers all necessary context: purpose, parameters, error handling, alternatives, and data source behavior. The output schema likely describes return format, so no need to explain return values. Complete for a moderately complex tool.

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

Parameters4/5

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

Schema coverage is 67% (only 2 of 3 parameters have descriptions). The description adds value: clarifies that 'count' is capped by server ('ask for a coarser timeframe rather than more bars'), that 'symbol' must match list_symbols spelling, and that 'timeframe' is the interval length. The description compensates for the missing schema description on 'timeframe' by listing enum values contextually (M1, M5, etc.) and implying the left-edge labeling. However, it doesn't explain the 'timeframe' enum beyond listing intervals, so a 4 is appropriate.

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 clearly states the tool returns 'the most recent OHLCV bars for a symbol, oldest first'. It identifies the specific verb (return), resource (OHLCV bars), and ordering (oldest first), distinguishing it from siblings like get_quote (current price) and get_bars_range (range-based).

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?

The description provides explicit guidance: when to use alternatives ('call get_quote for the current price'), when to call list_symbols first ('call list_symbols first if unsure'), how to handle timeframes ('ask for a coarser timeframe rather than more bars'), and error handling ('An unknown or unavailable symbol returns a tool error naming the symbol'). It also notes the 'count' cap and server limit.

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

get_bars_rangeGet bars in a date rangeA

Read-only

Return the OHLCV bars whose open time falls in [start, end), oldest first.

Both bounds must carry a UTC offset, for example 2026-06-01T08:00:00Z. start is inclusive and end is exclusive, so consecutive ranges tile without repeating a bar. The number of bars the range spans is capped by the same limit that applies to get_bars, so a wide window at a fine timeframe returns a tool error asking for a coarser one rather than a truncated answer. Unlike get_bars, an end that reaches into the interval currently forming can return that bar, because the bounds are yours; stop end at a closed interval if that matters. On the replay source the prices are generated, not recorded from any market.

ParametersJSON Schema

Name	Required	Description
`end`	Yes	Exclusive, ISO 8601, UTC.
`start`	Yes	Inclusive, ISO 8601, UTC.
`symbol`	Yes	Instrument name exactly as list_symbols spells it.
`timeframe`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`bars`	Yes	The bars, oldest first.
`count`	Yes	Number of bars returned.
`source`	Yes	Data source that produced these bars.
`symbol`	Yes	Symbol these bars belong to.
`synthetic`	Yes	True when the prices are generated, not observed.
`timeframe`	Yes	Timeframe of each bar.

TDQS

A4.7/5.0

Behavior5/5

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

The description goes well beyond the readOnlyHint annotation, explaining the inclusive/exclusive bounds, UTC offset requirement, tiling behavior, error on exceeding limits, the nuance with forming bars, and the synthetic nature of replay data. This gives the agent a full behavioral model.

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?

The description is front-loaded with the core purpose, and every subsequent sentence adds essential behavioral or usage detail. It is concise given the complexity, with no redundant wording.

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?

The description covers not only the basic operation but also edge cases like limit-caused errors, the difference from get_bars, data source caveat, and formatting requirements. Given the output schema exists, return values need no explanation, and the description is fully sufficient for an agent to invoke the tool correctly.

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

Parameters4/5

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

The schema already covers 75% of parameters with descriptions, but the description adds critical semantics for start/end (inclusive/exclusive, UTC offset, example format) and clarifies the meaning of range-related behavior beyond the schema. Timeframe is only an enum, but the values are self-explanatory.

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 clearly states the tool returns OHLCV bars within a half-open date range, ordered oldest first. The title 'Get bars in a date range' plus the explicit interval notation [start, end) distinguishes it from its sibling get_bars.

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?

The description references get_bars multiple times, noting the same limit applies and highlighting a key difference regarding forming bars. This provides clear comparative context, though it does not include a direct 'use this when' statement or explicit when-not-to-use guidance.

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

get_quoteGet a quoteA

Read-only

Return the latest bid, ask and spread in points for one instrument.

The time is UTC. On the replay source it is the last stored bar's open time rather than the current clock, so the answer is reproducible and is NOT a live market price. An unknown or unavailable symbol returns a tool error naming the symbol; call list_symbols if unsure.

ParametersJSON Schema

Name	Required	Description	Default
`symbol`	Yes	Instrument name exactly as list_symbols spells it.

Output Schema

ParametersJSON Schema

Name	Required	Description
`ask`	Yes	Best ask price.
`bid`	Yes	Best bid price.
`time`	Yes	Quote time in UTC. On the replay source this is the last stored bar's open time, never the wall clock.
`source`	Yes	Data source that produced this quote.
`symbol`	Yes	Symbol this quote belongs to.
`synthetic`	Yes	True when the price is generated, not observed.
`spread_points`	Yes	Ask minus bid, expressed in points.

TDQS

A4.5/5.0

Behavior5/5

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

The description discloses crucial behavior beyond the annotations: 'On the replay source it is the last stored bar's open time rather than the current clock, so the answer is reproducible and is NOT a live market price.' It also details error handling for unknown symbols. This adds significant context for an agent deciding whether to trust the result as live.

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?

The description is two short sentences plus a crucial behavioral note. Every sentence adds value, and the key action ('Return...') is front-loaded. No redundant or vague language. It is concise without omitting necessary information.

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?

Given the tool's simplicity (one required parameter, no nested types) and the existence of an output schema (not shown but indicated in context signals), the description adequately covers the return value, time source, error behavior, and a pointer to list_symbols. It is complete for an agent to use correctly.

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?

The input schema has 100% coverage for its single parameter 'symbol', with description 'Instrument name exactly as list_symbols spells it.' The tool description does not add new semantic meaning; it only repeats the schema's point about exact spelling. Baseline 3 is appropriate when schema already fully documents the parameter.

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 clearly states 'Return the latest bid, ask and spread in points for one instrument.' The verb 'return' and resource 'quote for one instrument' are specific. It implicitly distinguishes from sibling tools like get_bars (historical bars) and list_symbols (listing symbols).

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?

The description provides explicit guidance: 'An unknown or unavailable symbol returns a tool error naming the symbol; call list_symbols if unsure.' This tells the agent when to use list_symbols instead. It does not explicitly state when not to use this tool (e.g., for historical prices use get_bars), but the sibling context and the mention of 'latest' imply the appropriate use case.

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

list_ordersList pending ordersA

Read-only

Return every pending order, with its type, volumes and trigger price.

Read only: this server can place, modify and cancel nothing. On the replay source the list is always empty and the payload carries synthetic=true.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`count`	Yes	Number of pending orders.
`orders`	Yes	The pending orders.
`source`	Yes	Data source that produced this list.
`synthetic`	Yes	True when the orders are generated, not real.

TDQS

A4.1/5.0

Behavior4/5

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

Annotations already mark readOnlyHint=true. The description reinforces this with 'this server can place, modify and cancel nothing' and adds critical context about the replay source (list always empty, synthetic flag). This goes beyond what annotations provide, though it does not cover all possible behavioral traits (e.g., rate limits, auth needs).

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?

The description is three sentences, each earning its place: purpose, read-only assertion, and replay-specific behavior. No unnecessary words, front-loaded with the core action.

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?

The tool has no parameters and an output schema exists. The description covers return fields and a key behavioral detail about replay sources, making it fully adequate for the low complexity of this tool.

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 zero parameters and 100% schema coverage, the description need not add parameter-level meaning. It correctly describes the output fields but not parameter semantics; baseline 3 is appropriate as the schema carries the full load.

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 clearly states the verb 'Return' and the resource 'every pending order', and specifies the data included (type, volumes, trigger price). It differentiates from sibling tools which deal with symbols, quotes, bars, account, and positions, leaving no ambiguity about what this tool does.

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?

The description implies usage for retrieving pending orders and includes the read-only note, but does not explicitly say when to use this tool over alternatives like list_positions. It lacks mentions of conditions under which the tool should or should not be used, nor does it reference sibling tools for comparison.

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

list_positionsList open positionsA

Read-only

Return every open position, with entry price, current price and floating profit.

Read only: this server can open, modify and close nothing. On the replay source the list is always empty and the payload carries synthetic=true.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`count`	Yes	Number of open positions.
`source`	Yes	Data source that produced this list.
`positions`	Yes	The open positions.
`synthetic`	Yes	True when the positions are generated, not real.

TDQS

A4.4/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true and openWorldHint=false. The description adds value beyond annotations by stating the server can 'open, modify and close nothing', and explains the synthetic flag behavior on replay sources. This provides meaningful behavioral context without contradiction.

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?

The description is two short sentences, each providing essential information. No filler or redundancy. Perfectly sized for a tool with no parameters and clear purpose.

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?

Given no parameters and an output schema present, the description is largely complete. It explains the tool's purpose, return fields, and special behavior (read-only, synthetic flag on replay). One minor gap: it doesn't mention whether the list is always empty in certain modes beyond replay.

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

Parameters4/5

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

The input schema has no parameters, so the description has no responsibility to document parameters. With 0 parameters and 100% schema coverage, the description adds value by explaining return fields (entry price, current price, floating profit), which aids correct invocation and interpretation.

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 uses a specific verb ('Return') and resource ('open position'), and lists the fields returned (entry price, current price, floating profit). It clearly distinguishes this tool from siblings like `list_symbols` and `list_orders`.

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?

The description clarifies that the tool is read-only and explains behavior on replay sources (always empty, payload has synthetic=true). However, it doesn't explicitly state when to use this tool over alternatives like `get_account` or `list_orders`, though the purpose is clear enough.

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

list_symbolsList instrumentsA

Read-only

Return every instrument this server exposes, with its digits and point size.

Call this before anything else: it is the only authoritative list of symbol names, and a name that is not in it produces a tool error everywhere else. The optional group filter uses MetaTrader's own syntax, described in the argument. On the replay source the instruments are generated and the payload carries synthetic=true.

ParametersJSON Schema

Name	Required	Description	Default
`group`	No	Optional filter. MetaTrader group syntax: '' wildcards at the start and end of a pattern, several comma separated conditions, and '!' to negate one. Inclusions must come before exclusions, so ", !USD" is everything except the USD instruments while "!USD, *" matches everything.

Output Schema

ParametersJSON Schema

Name	Required	Description
`count`	Yes	Number of instruments returned.
`source`	Yes	Data source that produced this list.
`symbols`	Yes	The instruments, in source order.
`synthetic`	Yes	True when the instruments are generated, not real.

TDQS

A4.7/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true (safe read) and openWorldHint=false (closed set). The description adds value by noting that missing symbols cause errors in other tools, and that replay sources return synthetic=true. This complements the annotations without contradicting them.

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?

The description is three sentences with zero wasted words. Each sentence serves a distinct purpose: stating the return value, explaining when to call and consequences, and describing the optional filter. Information is front-loaded with the core purpose first.

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?

Given the tool's simplicity (1 optional parameter, read-only, closed set), output schema exists, and annotations are clear, the description is fully complete. It covers purpose, usage guidance, parameter behavior, and edge cases (replay vs. live), leaving no gaps for an agent.

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

Parameters4/5

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

Schema coverage is 100% and already documents the group parameter syntax thoroughly. The description reinforces this by referencing the syntax explanation in the argument description, adding the context of how the filter interacts with the overall tool purpose, which is helpful for an agent.

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 clearly states the tool returns 'every instrument this server exposes, with its digits and point size'. It uses a specific verb ('Return') and resource ('every instrument'), and distinguishes itself from siblings like get_quote and symbol_info by positioning itself as the authoritative source of symbol names.

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?

Explicitly advises 'Call this before anything else', warns that missing names cause errors elsewhere, explains the optional group filter's syntax, and clarifies behavior differences on replay sources. No alternative tools are needed for this purpose, and it sets clear prerequisites for using other tools.

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

symbol_infoGet contract specificationA

Read-only

Return the contract specification for one instrument.

Digits and point size for rounding prices, current spread, minimum stop distance, tick value and size, contract size, the tradable volume range, and the base, profit and margin currencies. Field names are MetaTrader's own. An unknown or unavailable symbol returns a tool error naming the symbol. On the replay source the instrument is generated and the payload carries synthetic=true.

ParametersJSON Schema

Name	Required	Description	Default
`symbol`	Yes	Instrument name exactly as list_symbols spells it.

Output Schema

ParametersJSON Schema

Name	Required	Description
`name`	Yes	Symbol name.
`point`	Yes	Value of one point, the smallest price step.
`digits`	Yes	Decimal places in a quoted price.
`source`	Yes	Data source that produced this specification.
`spread`	Yes	Current spread in points.
`synthetic`	Yes	True when the instrument is generated, not real.
`volume_max`	Yes	Largest tradable volume, in lots.
`volume_min`	Yes	Smallest tradable volume, in lots.
`description`	Yes	Human readable instrument name.
`volume_step`	Yes	Volume increment, in lots.
`spread_float`	Yes	True when the broker quotes a floating spread.
`currency_base`	Yes	Base currency of the instrument.
`currency_margin`	Yes	Currency the margin is charged in.
`currency_profit`	Yes	Currency the profit is denominated in.
`trade_tick_size`	Yes	Smallest price change, in price units.
`trade_tick_value`	Yes	Profit in the account currency from a one tick move on one lot.
`trade_stops_level`	Yes	Minimum distance in points between price and a stop or limit order.
`trade_freeze_level`	Yes	Distance in points within which orders are frozen and cannot be changed.
`trade_contract_size`	Yes	Units of the base asset in one lot.

TDQS

A4.3/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true, so the tool is safe to call without side effects. The description adds behavioral context: it lists the exact return fields (digits, spread, tick value, etc.), notes that unknown symbols cause a tool error, and mentions that on replay sources synthetic=true is added. This goes beyond annotations without contradicting them.

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?

The description is concise (three sentences) and front-loaded with the purpose. Each sentence adds relevant detail (return fields, naming, edge cases). Slightly verbose in listing fields could be trimmed, but it remains efficient.

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?

Given that there is no output schema but an output schema exists (context says 'Has output schema: true'), the description thoroughly lists return fields and covers the key edge case of unknown symbols. With annotations providing read-only guarantee, and one simple parameter, the description is complete enough for an agent to use correctly.

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

Parameters4/5

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

Even though schema coverage is 100% and the single parameter 'symbol' has a description, the description adds value by indicating that symbol names must match list_symbols exactly and that unknown symbols trigger an error. This aids correct invocation.

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 clearly states 'Return the contract specification for one instrument,' which identifies the action (return) and the resource (contract specification for one instrument). It distinguishes itself from siblings like 'list_symbols' (which lists symbols, not specifications) and 'get_quote' (which gets quotes) by focusing on static contract details.

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?

The description implies usage when needing instrument specifications (digits, spread, tick value, etc.) but does not explicitly state when to use this tool versus alternatives. It mentions that an unknown symbol returns a tool error, which is helpful context. No explicit exclusions or alternatives are given, but the context is clear.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

8 tool updatesv0.1.0Aug 19, 2026
- First observedget_account
- First observedget_bars
- First observedget_bars_range
- First observedget_quote
- First observedlist_orders
- First observedlist_positions
- First observedlist_symbols
- First observedsymbol_info

Deploy Server

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

TDQS

A4.4/5.0

Scored 2026-09-09 17:50 across 8 tools

Disambiguation5/5

Each tool targets a distinct concern: symbol discovery, current quote, recent bars, ranged bars, contract specs, account summary, positions, and orders. The overlap between get_bars and get_bars_range is clearly delineated by recent-count vs. explicit time range, and descriptions reinforce the boundary.

Naming Consistency4/5

The set mostly follows a clear list_* for enumerations and get_* for single-item or snapshot retrievals. The one deviation is symbol_info, which lacks the get_ prefix, but the overall pattern remains predictable and readable.

Tool Count5/5

Eight tools is well-scoped for a read-only market data and account snapshot server. Each tool contributes a distinct capability without redundancy or bloat, and the count fits comfortably within the ideal range.

Completeness5/5

The surface covers symbol discovery, live quotes, historical bars, contract specifications, account summary, positions, and orders, with explicit read-only constraints explaining why trading mutations are absent. There are no obvious dead ends: list_symbols feeds the symbol-dependent tools, and get_bars/get_bars_range cover both recent and range-based history.

Maintenance

ActivityMaintained

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Related MCP Connectors

openmm-mcp A
io.github.QBT-Labs
MCP server for OpenMM — exposes market data, account, trading, and strategy tools to AI agents
Finance
1513
Backtest360 A
com.backtest360
MCP server exposing the Backtest360 engine API as tools for AI agents.
Finance Research & Data
202
Marketdata App A
io.github.pipeworx-io
Market Data App MCP — wraps the Market Data App API (marketdata.app)
Finance Cryptocurrency
401
MTContext A
io.github.mtcontext
Connect any MCP client to MetaTrader 4/5 to read prices, manage positions, and place trades.
Finance Research & Data
1

Related MCP Servers

Meta-Trader-MCP
Finance AI & Machine Learning
shubhvisputek
A
license
Not graded
quality
A
maintenance
Exposes a unified AI interface to MetaTrader 5 over the Model Context Protocol, enabling live quotes, historical data, technical indicators, order execution, position management, and headless backtests.
Updated 4 months ago (2026-06-12 18:42 UTC)
MIT
ibkr-mcp
Finance
mark-liu
A
license
A
quality
C
maintenance
Read-only MCP server for Interactive Brokers that exposes market data, positions, and account info as MCP tools.
Updated 6 months ago (2026-04-17 23:11 UTC)
8
MIT
mt5-mcp
Finance Developer Tools
alikhande70
A
license
Not graded
quality
C
maintenance
A local-first MCP server that bridges AI coding agents with MetaTrader 5 for inspection, market data, MQL5 development, compiling, Strategy Tester review, workspace sync, logs, audit trails, demo trading, and carefully gated live trading.
Updated 3 months ago (2026-07-06 15:38 UTC)
MIT
tradingprogpt
Finance AI & Machine Learning
xentristech
F
license
Not graded
quality
C
maintenance
Read-only MCP server exposing MetaTrader 5 account and market data alongside Twelve Data quotes and technical indicators, with an LLM analysis layer.
Updated 3 months ago (2026-07-09 11:03 UTC)
-