What can you do with this server?

QUOTEZ is a read-only MCP server that exposes market data from MetaTrader 5 (or a synthetic replay source) as typed, agent-callable tools. * List available instruments with list_symbols, including optional MetaTrader group filtering (*, ,, !). * Fetch real-time quotes with get_quote: bid, ask, spread, UTC timestamp, and provenance flags. * Retrieve recent OHLCV bars with get_bars across M1, M5, M15, M30, H1, H4, D1 timeframes. * Retrieve bars by date range with get_bars_range, with inclusive start and exclusive end bounds. * Get detailed contract specifications with symbol_info: digits, point size, spread, tick value/size, contract size, volume limits, and currencies. * Read account state with get_account: balance, equity, margin, leverage, masked login. * List open positions with list_positions and pending orders with list_orders. * Access the instrument universe as a resource via symbols://list. * Every response is read-only, carries a source and synthetic flag, uses UTC timestamps, and is validated against a generated output schema. * The server is structurally incapable of writes: no order placement, modification, cancellation, or file writes exist in the codebase.

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@QUOTEZ show me recent quotes for EURUSD" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

de en es ja ko ru zh

QUOTEZ

by PNX89

Overview Schema Source Related Servers Score Discussions Admin

Python

Local

QUOTEZ

Market data for agents. Read only by construction, not by configuration.

One file to start with: src/quotez/server.py. Eight tools in a fixed registration order, and no write path anywhere in it to find.

Python License: MIT

A real run of the demo: an agent listing symbols, pulling a quote and pulling bars, every
payload carrying its source and a synthetic flag

Nothing above was typed by hand. The frame replays what the session actually printed, and this repository's own suite re-runs it on every push and diffs the result, so an out of date picture is a red build rather than a flattering one. Untruncated at pnx89.github.io/QUOTEZ.

An MCP server that exposes MetaTrader 5 market data as typed, read only tools an LLM agent can call. Python 3.11 or newer, one runtime dependency, stdio transport. The badge stops at 3.13 because that is where the classifiers stop; CI runs a 3.14 leg as well, marked advisory, and 3.14 joins the badge once it has been green long enough to be a promise rather than a hope.

An agent is only as good as the tools you hand it, and market data is where a sloppy tool does real damage. The model restates whatever a tool returns as fact, so a payload with no units, no timezone and no provenance becomes a confident sentence about a price someone might act on. QUOTEZ answers with generated output schemas rather than text blobs, UTC everywhere, a synthetic flag on every payload, and no write path in the code.

This is one tool built so that it cannot do damage, which is a smaller and more checkable question than whether an agent as a whole can be trusted with tools. That larger one is QUELLZ's.

Scope and limits

Read only: no order_send, no order_check, no symbol_select, no writes of any kind.
Live MetaTrader data needs Windows and a running terminal; the wheels are win_amd64 only.
The default source replays generated data and labels every payload synthetic: true.
Times are UTC and every bar is labelled by its open, the left edge of its interval.

Related MCP server: ibkr-mcp

Example agent session

Real output, not a paste. Regenerate it with uv run python examples/agent_session.py; tests/test_readme.py asserts this block byte for byte against that command's stdout. The replay prices are generated, not recorded from any market.

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.

Quickstart

One command, nothing to configure, no MetaTrader install anywhere:

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

QUOTEZ is not published to PyPI, so the git form is the install; append @main, a tag or a commit to pin a ref, per uv's dependency documentation. It then appears to hang, because stdout is the JSON-RPC wire and a host drives it. To watch it work without a host, clone the repository and run the example session, which drives the same server from an in-process client:

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

On Windows, against a terminal already running and logged in:

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

The console script is the only entry point that takes flags, and flags win over the environment. mcp run src/quotez/server.py also serves this server through the module level mcp global, but it forwards nothing, so that path reads the variables instead.

Flag	Environment variable	Default	Meaning
`--source`	`QUOTEZ_SOURCE`	`replay`	`replay` reads the bundled generated files, `mt5` reads a live terminal
`--symbols`	`QUOTEZ_SYMBOLS`	empty	Comma separated whitelist, case insensitive. Empty exposes everything the source has
`--max-bars`	`QUOTEZ_MAX_BARS`	`1000`	Most bars one call may return, 1 to 5000
`--log-level`	`QUOTEZ_LOG_LEVEL`	`INFO`	Logging threshold. Records always go to stderr, because stdout is the wire

Connect it to a host

The hosts do not agree on the configuration key, and getting mcpServers versus servers wrong is the usual reason a server never appears.

Host	File	Key
Claude Desktop	`~/Library/Application Support/Claude/claude_desktop_config.json` on macOS, `%APPDATA%\Claude\claude_desktop_config.json` on Windows	`mcpServers`
Cursor	`.cursor/mcp.json`	`mcpServers`
VS Code	`.vscode/mcp.json`	`servers`, and add `"type": "stdio"` next to `command`
Claude Code	no file, use the 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 must be the absolute path from which uv. A host spawns the server with a near empty PATH, so a bare uv is the single most common reason a server silently fails to connect.

Tools

Eight tools, registered in this order, which is the order tools/list returns; clients cache that list, so the order is fixed on purpose. One resource, symbols://list, serves the same instrument universe as application/json.

Tool	Arguments	Returns	Access	Replay source	MetaTrader source
`list_symbols`	`group` optional, MetaTrader group syntax	`SymbolList`	read	4 generated instruments	`symbols_get(group=...)`
`get_quote`	`symbol`	`Quote`	read	derived from the last stored bar	`symbol_info_tick`
`get_bars`	`symbol`, `timeframe`, `count` (1 to 5000, capped by `--max-bars`)	`BarSeries`	read	M1 rolled up locally	`copy_rates_from_pos`
`get_bars_range`	`symbol`, `timeframe`, `start`, `end`	`BarSeries`	read	M1 rolled up locally	`copy_rates_range`
`symbol_info`	`symbol`	`SymbolSpec`	read	from `symbols.json`	`symbol_info`
`get_account`	none	`Account`	read	placeholder figures, `synthetic: true`	`account_info`, login masked
`list_positions`	none	`PositionList`	read	always empty	`positions_get`
`list_orders`	none	`OrderList`	read	always empty	`orders_get`

list_symbols takes MetaTrader's own group filter syntax rather than inventing one: * wildcards at the start and end of a pattern, comma separated conditions, and ! to negate one. Inclusions must come before exclusions, so "*, !*USD*" is everything except the USD instruments while "!*USD*, *" matches everything. Mt5Source hands the string to symbols_get; the replay source runs the same syntax through quotez.groups, so both answer a filter identically.

Every tool returns a Pydantic model, so the SDK derives an outputSchema from the return annotation, fills structuredContent, and validates the payload before it leaves the server. A BaseModel is used unwrapped, which is why get_bars returns an object with a bars key rather than {"result": ...}.

How it works

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 is the seam the whole server is written against. Nothing above it imports MetaTrader5, and Mt5Source resolves the extension inside a private helper on first use rather than at module import, so import quotez works where no wheel exists. That is what makes ReplaySource a first class implementation instead of a mock: the tool layer cannot tell the two apart, so the whole suite exercises the real code path with no terminal installed.

The bundled data is four generated instruments (SYNTH_FX_ALPHA, SYNTH_FX_BETA, SYNTH_IDX_GAMMA, SYNTH_MTL_DELTA), 3600 M1 bars each, 08:00 to 14:00 UTC on weekdays from 2026-06-01 to 2026-06-12, with nine session breaks in it, eight overnight and one across a weekend, because a gapless series is the series that hides an aggregation bug. scripts/generate_replay_data.py produced the files once from a seeded random.Random and the output is committed. CSVs are read through importlib.resources, never Path(__file__).parent, which works in a checkout and breaks under the zipped install uvx performs.

Tools and resources are not the same thing

A tool is what the MODEL decides to call; a resource is what the APPLICATION decides to load. get_bars is model driven: it picks a symbol, a timeframe and a count in the middle of reasoning. symbols://list is application driven: a host pins the universe into context once, before the model has decided anything. That is why it is not incidental duplication of list_symbols, which is a filtered search the model runs on purpose.

The obvious next resource, bars://{symbol}/{timeframe}, was deliberately not built: it duplicates get_bars for the same data, and a URI with placeholders is a resource template, which leaves resources/list for resources/templates/list and is surfaced poorly or not at all by many hosts. A test asserts no resource templates are registered.

Timeframe aggregation

The replay source stores one base timeframe, M1, and quotez.aggregate rolls up M5, M15, M30, H1, H4 and D1 from it. One stored copy, one roll up, testable on its own, which matters because its failure mode is silent: a wrong aggregation returns plausible numbers forever and never raises.

The MetaTrader source rolls nothing up. A terminal already holds every period, so it is asked for the timeframe directly; deriving them again from M1 would be slower and would disagree with the charts the operator has open. The two sources therefore answer the same call slightly differently on D1, H4 and spread, which is in Limitations rather than left for you to find.

The invariants of the roll up, each of which is a test name:

M1 is the only base timeframe. Everything coarser is derived.
Buckets are wall clock, computed by floor division on the epoch second, never by grouping every N rows positionally.
Targets are whole multiples of 60 seconds. Anything else raises InvalidRequest.
OHLC is first open, max high, min low, last close.
tick_volume is summed. spread is not: it is a point in time property of a quote, so an aggregated bar reports null.
Bars are labelled by their left edge, in UTC.
An incomplete trailing bucket is dropped rather than emitted as a partial bar. A bucket is emitted only when the input holds a bar at or after that bucket's end.
Empty input returns an empty list.

Invariant 2 earns its tests. Positional grouping agrees with wall clock bucketing on a gapless series and disagrees the moment there is a hole: grouping 360 bar sessions in fours puts Friday's close and Monday's open in one bar and calls it a four hour candle. Invariant 7 is its pair, because a session ending is not the same event as the data running out.

Safety design

The claim is structural, not configurable. This codebase contains no write path. There is no order_send, no order_check, no symbol_select, no MarketWatch mutation and no file write anywhere in src/quotez/. No configuration can turn a write on, because there is nothing to turn on.

Two tests hold that in place, and the second one is the one that means something. The first greps the package for those three MetaTrader calls: cheap, covers every file, and satisfied by a name assembled at run time. The second walks the AST of mt5source.py and asserts the positive property instead, that the set of attributes this package reads off the terminal module is exactly the eleven read calls the test file permits plus the seven timeframe constants, with nothing reached through getattr and nothing rebound to a second variable. _mt5() returns the whole MetaTrader5 module, so the absence of three names out of several hundred attributes proves very little on its own.

The permitted list lives in tests/test_server.py, not in the module being audited, and the module's own docstring is asserted against it. Two files in two roles, which is the smaller and truer claim: while the docstring alone was the specification, a new terminal call could arrive carrying its own permission in the same edit, and an audit walked one straight through. The walk follows what is bound to what rather than watching a fixed pair of names, so an annotated assignment, a walrus, a tuple unpack and a for target reach the module as surely as a plain one does. Eleven deliberately broken snippets are checked against the walk so the walk itself is known to fail when it should, and six of those are forms it used to go straight past.

Every tool is declared ToolAnnotations(read_only_hint=True, open_world_hint=False). That declaration is a courtesy to clients and nothing more: the MCP specification tells clients to treat tool annotations as untrusted unless they come from a trusted server. read_only_hint=True describes the tool, it does not constrain the client, and the property a reviewer can check is the absence of the calls rather than the presence of the flag. Mapped onto the specification's own Security Considerations for tools, including the requirement this server does not meet:

Specification requirement	QUOTEZ	Where
Validate all tool inputs	Yes	JSON Schema derived from the type hints, `Literal` timeframes, `Field(ge=1, le=5000)` on `count`, plus runtime checks in the handlers
Implement proper access controls	Yes	the symbol whitelist is applied to every tool and to the resource, not only to the getters
Rate limit tool invocations	No	not implemented, and listed in Limitations. A stdio server is a child process of exactly one host, so the host owns the rate limit
Sanitize tool outputs	Yes	the account login is masked to its last four digits, the broker, server and account holder names are never returned at all, and `synthetic` is a required field on every payload

A blocked symbol is reported as SymbolNotFound with the message a typo gets, "Symbol 'X' is not available on this server." A distinct "not permitted" would turn the whitelist into a discovery oracle for instruments an operator chose not to expose.

Errors take one of two channels, chosen by whether a smarter model could have avoided the failure. A misspelled symbol could be, so SymbolNotFound and InvalidRequest are ordinary exceptions, which become tool errors the model can read and retry from. A terminal that is not running could not, so SourceUnavailable is raised as MCPError, a protocol error with no result at all. Nothing here returns an error string: a returned string carries is_error=False and reads as a successful answer. A test calls every tool with bad input and asserts the flag.

Design decisions

mcp>=2.0.0,<3 and MCPServer, not the v1 pin and FastMCP. The SDK still offers mcp>=1.28,<2 for people who have not migrated, but a v1 era server gives itself away in three seconds: from mcp.server.fastmcp import FastMCP. The migration guide has the renames. The low level Server was the alternative and no longer auto wraps return values, so it meant hand writing JSON Schema for eight tools.

Typed Pydantic returns, not text blobs. Most public MCP servers return prose and leave the model parsing it. Here the return annotation is the output schema, so typed costs nothing and buys validation before the payload leaves the server.

Two bar tools, not one with optional arguments. JSON Schema cannot express mutual exclusivity, so a single get_bars(count or start..end) would push "either of these but not both" onto the model as prose. Two tools have two fully valid schemas, and the "both given, neither given" error class stops existing.

Generated data, not a real feed. A licensing decision, not a preference. MetaTrader exports are the broker's licensed feed, and for index and equity CFDs the underlying is exchange licensed. Yahoo's help pages state the restriction in as many words, you must not redistribute information displayed on or provided by Yahoo Finance, and its developer API terms separately restrict selling or sublicensing access. HistData's FAQ grants no redistribution rights at all; it says only that the data comes with no warranty, and silence is not a licence. Committing any of it to an MIT repository would relicense data I have no right to relicense.

The standard library, not pandas or numpy. At bundled CSV scale csv plus datetime plus dataclasses is enough and the tree stays auditable. That tree is worth naming honestly though, all of it: mcp 2.x is one direct dependency that pulls anyio, httpx2, jsonschema, mcp-types, opentelemetry-api, pydantic, pyjwt with its crypto extra, python-multipart, sse-starlette, starlette, typing-extensions, typing-inspection and uvicorn, plus pywin32 on Windows. The crypto extra brings cryptography, cffi and pycparser in behind it. That is a bigger footprint than v1, and a test reads the committed uv.lock and fails if this list stops matching it, because a paragraph that exists to name the tree is worth nothing if it names most of the tree.

No run_backtest tool. A backtest is compute unbounded, needs far more than a MarketDataSource, and would duplicate QUACKZ, so the pair would read as two half projects instead of two focused ones. For the same reason the guardrails here are domain local: input validation, bounded queries, a fixed instrument universe, no side effects. General agent guardrails belong in QUELLZ, not reinvented five times.

Limitations

No continuous integration runner exercises the live MetaTrader path, anywhere. There is no non-Windows wheel and no runner has a terminal or a broker account. The Windows job proves the extension imports and that Mt5Source reports a missing terminal cleanly, and that is all. Mt5Source's field mapping is the least exercised code here, covered by fake module tests.
MetaTrader5 is Windows only and publishes no source distribution, so pip install quotez[mt5] is a no-op on macOS and Linux by design. A test asserts the environment marker keeps it that way.
initialize() launches the terminal if it is not already running, and the whole operation is bounded by its timeout argument, documented as defaulting to 60000 milliseconds. The page does not put a figure on the launch itself, so treat 60 seconds as the ceiling on the call rather than as a measured startup time. QUOTEZ opens the connection once in the server lifespan rather than per call, so whatever it costs lands at startup instead of making the first tool call look hung.
The two sources do not agree on where a D1 or an H4 bucket starts. The replay roll up floors on the epoch second, so D1 opens at 00:00 UTC and H4 at 00, 04, 08, 12, 16 and 20 UTC. A MetaTrader terminal aligns D1 and H4 to the broker's server day, which is commonly UTC+2 or UTC+3, so the same get_bars(symbol, "D1") returns a candle with a different open time and different OHLC depending on which source is configured. Nothing here resamples the terminal's M1 to hide that, because a bar that disagrees with the operator's own chart is worse than a documented offset.
For the same reason, spread is null on every replay bar above M1 and set on every MetaTrader bar. The roll up clears it on purpose; the terminal reports its own value on every timeframe and QUOTEZ passes that through rather than discarding data the source gave it.
copy_rates_from_pos and copy_rates_range are silently capped by the terminal's "Max. bars in chart" setting, so a request inside the server's own cap can still come back short and nothing in the MetaTrader API says so.
get_bars skips the bar the terminal is still building, so its newest bar is always closed. get_bars_range does not, because the bounds are the caller's: an end inside the current interval returns that interval's partial bar.
symbol_info() returns None for an unknown symbol instead of raising, as does symbols_get() on error. Every call site here checks, but that is the shape of the API being wrapped.
MetaTrader stores bar and tick times in UTC with no shift, while a naive Python datetime resolves against the local zone; the copy_rates_range documentation says so. Every outbound timestamp is built with tz=UTC and naive inputs are rejected, but this is the trap that silently shifts a whole series by an hour.
No rate limiting. A stdio server is a child process of one host, and the host owns that.
The replay data is sample scale and generated: 4 instruments, 3600 M1 bars each, ten trading days. It demonstrates the tools and exercises the aggregation, and it is neither a research dataset nor a market.
Version 0.1.0 is read only and stdio only, with no prompts capability, no SSE or streamable HTTP transport and no OAuth.

Why I built this

I run walk forward research on index data and keep MetaTrader terminals around for the FX and metals side of it, so both halves of this were already on my desk. What made me write it was watching an agent restate a number from a badly typed tool as though it were a fact, with no unit, no timezone and nothing saying where it came from. In market data that is not cosmetic: a bar labelled by its close instead of its open, or a timestamp quietly shifted into local time, gives an answer that looks right and is off by an hour. So this is mostly decisions about provenance and about what a tool may claim, wrapped around a little aggregation code.

Development

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

285 tests, no network, a few seconds, and identical on macOS, Linux and Windows. That count is asserted against a real collection run, because a number in a README is a number nobody updates.

License

MIT. See LICENSE.

Part of the Q...Z toolset, all of it designing for the failure that does not announce itself:

QUACKZ, deflating a backtest that only looks good because it was picked out of two hundred.
QUOTEZ, this one: market data an agent can read and cannot act on.
QUELLZ, measuring what prompt-injection containment costs in utility as well as in attack rate.
QUIDZ, refusing the outbound payment that would have gone out twice.
QUESTZ, stopping a scraper before it writes a CSV from a page that changed shape.
QUIZZ, answering what a statistic said at the time, and refusing when it cannot.
QUARANTINEZ, treating an outcome the venue never confirmed as terminal rather than as a retry.
QUENCHZ, deciding in the open what a tool server gets free while it is still somebody's subprocess.
QUILTZ, proving infrastructure code wrong without a cloud account, and saying what that cannot show.
QUAYZ, telling a crash loop from an OOMKill, and naming the failure that no single field finds.
QUARRYZ, keeping every version a statistical office published, and failing the build when it quietly issues another.
QUASHZ, refusing a row whose outcome had not been decided yet when the decision would have been made.
QUALMZ, a fixed number of looks at the holdout, where re-running the same configuration does not buy another.
QUEUEZ, ordering a feed by its sequence, because on a real recorded session the clock goes backwards.
QUANDARYZ, counting the distinct screens a component can settle into when its responses arrive out of order.
QUIETZ, watching whether the data arrived rather than whether the server answered.

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

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.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

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

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
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
midasflow-mcp-quickstart A
io.github.midasflowai-lab
Agent-native crypto market-data over MCP+REST: order flow, whales, liquidations, calibrated scores
Cryptocurrency Finance
142

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 3 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 5 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 2 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 2 months ago (2026-07-09 11:03 UTC)
-