The metatrader5-mcp server bridges AI clients like Claude to a MetaTrader 5 terminal for read-only data, market analysis, MQL5 development, and backtesting preparation — never executing live trades.
Read-Only Market & Account Data
Account balance, equity, margin, leverage, and trade mode
Terminal connection state, build version, and data paths
Symbol specifications, latest ticks, and OHLCV bar data
Open positions, pending orders, and historical deals
MT5 terminal/expert logs and Strategy Tester HTML reports
Performance & Market Analysis
Summarize open positions by symbol and side (long/short)
Compute peak-to-trough drawdown with optional equity curve
Analyze trade history: win rate, profit factor, trade averages
Calculate basic risk/reward ratios from entry, SL, and TP prices
Hypothetical Order Planning (requires explicit human approval, demo accounts only, never sent to market)
Calculate required margin and estimated profit/loss
Run MT5's server-side order_check validation
Build full order plans including margin, P&L, and validation results
MQL5 Code Development
Read, diff, draft, backup, restore, and review MQL5 source files
Generate EA, indicator, and script templates
Create, update, patch, rename, and delete files (with approval, backups, and rollback)
Fix compile errors and manage file mutations
MetaEditor & Strategy Tester
Prepare and run compilation; parse errors/warnings; generate fix plans
Prepare signal-only backtests, validate tester configurations
Import, collect, compare, and generate backtest reports
Environment & Workspace Management
Detect terminal path, MetaEditor, data folders, and MQL5 folder
Sync workspace files to the MT5 Data Folder (with approval and backup)
Audit & Introspection
List and inspect tool policies and permission levels
Read the server's audit log of all executed actions
What it cannot do: No order execution, modification, or cancellation. All trading-related tools are planning-only, restricted to demo accounts, and blocked on real/contest accounts. Chart, EA runtime, and live account tools are strictly disabled.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@metatrader5-mcp show my current positions"
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.
A local MCP (Model Context Protocol) server that connects Claude (or any MCP client) to a running MetaTrader 5 terminal.
A user-directed bridge between you, Claude, and MetaTrader 5. You can ask for
read-only market/account data, performance analysis, MQL5 development (read /
draft / diff / backup / approved file changes), compile and backtest preparation,
and report review. The design principle is user authority broad, model autonomy
narrow: every tool is governed by a ToolPolicy (permission level 0–5), the
model never auto-initiates a risky action, and file/runtime changes require
explicit human approval with a diff, a backup, a rollback point, and an audit
entry. No tool sends, modifies, or cancels an order; live trading is never
implemented. Chart/EA-runtime and live-account tools are declared in the policy
model but disabled by default. This is a tool-rich development bridge, not a
trading bot.
The two names below differ intentionally:
Repository / project identity: metatrader5-mcp
Installable package / command: mt5-mcp (the Python import package is
mt5_mcp, and pip install -e . also exposes an mt5-mcp console command)
Related MCP server: metatrader-mcp
Windows, with a running MetaTrader 5 terminal (the MetaTrader5 Python
package only works on Windows, next to the terminal). On other platforms
the server still runs and lists its tools, but every tool that touches MT5
will raise a clear MT5NotAvailableError.
Python 3.10+
New to this on Windows? Follow
docs/QUICKSTART_WINDOWS.mdfor a step-by-step setup, first tool calls, and a smoke-test checklist.
python -m venv .venv
.venv\Scripts\activate # Windows
pip install -e .Copy .env.example to .env and adjust as needed. Nothing here is a secret
that gets committed - .env is gitignored, and the server never logs your
password.
cp .env.example .envKey settings:
Variable | Default | Purpose |
| unset | Optional explicit terminal/account to connect to. If unset, attaches to the terminal already running on the machine. |
|
|
|
|
| In |
|
| Order-planning tools are disabled even on a demo account unless this is |
|
| Where |
|
| Directory that |
|
| MQL5 source root the file/code tools are confined to. Point at the terminal's |
|
| Where file mutations write backups + rollback metadata, and where snapshots go. |
|
| Where |
| unset | Full path to |
| unset | The terminal's Data Folder. |
|
| Where tester |
python -m mt5_mcp.serverThis starts the MCP server over stdio. Point any MCP client (Claude Desktop,
Claude Code, the mcp Python client, etc.) at this command. Example Claude
Desktop / Claude Code config:
{
"mcpServers": {
"metatrader5": {
"command": "python",
"args": ["-m", "mt5_mcp.server"],
"cwd": "/path/to/metatrader5-mcp"
}
}
}See examples/example_client.py for a minimal standalone client that lists
tools and calls one tool per permission tier (read, analysis, and a
planning-only call that is never sent). examples/claude_desktop_config.example.json
and examples/claude_code_config.example.json show client wiring with the
venv's python.exe and an absolute cwd. docs/EXAMPLES.md walks through
usage by tool group.
Before pointing a client at the server, you can run the read-only readiness helper to confirm your environment (it never plans or sends orders):
python scripts/mt5_readiness_check.pySAFE_READ (always allowed, logged, no approval needed):
get_account_info, get_terminal_info, get_symbol_info, get_tick,
get_rates, get_positions, get_orders, get_history_deals, read_log,
read_strategy_report.
SAFE_ANALYSIS (pure computation over data you already read, no approval
needed): summarize_positions, analyze_drawdown, analyze_trade_history,
calculate_profit_risk_basic.
REQUIRES_APPROVAL (order planning - margin/profit math and MT5's own
dry-run order_check; a human must approve every call, and the risk guard
still requires a demo account with MT5_MCP_ENABLE_DEMO_TRADING=true):
calculate_margin, calculate_profit, check_order, prepare_order_plan.
Bridge tools (governed by ToolPolicy; see list_tool_policies):
Workspace/code, Level 0/1 — workspace status & listing, mql5_file_read,
mql5_file_diff, mql5_file_write_draft, mql5_file_backup, mql5_code_review,
mql5_code_generate_ea/indicator/script, mql5_code_fix_compile_error. No
approval; never mutate a real source file.
File mutations, Level 2 — mql5_file_create/update/apply_patch/rename/delete/ restore/revert_patch, workspace_restore_snapshot. Approval required, with
backup + diff + rollback id.
Environment, Level 0 — mt5_env_detect (terminal path, MetaEditor, Data Folder(s),
MQL5 folder, reports/logs; env-var-honoring, Windows auto-detect, never raises).
Data Folder sync — workspace_plan_sync (L1 preview) and
workspace_sync_to_data_folder (L2; approval + backup + rollback; requires explicit
MT5_MCP_DATA_FOLDER).
MetaEditor/Tester, Level 0/1 + gated Level 3 — metaeditor_prepare_compile,
metaeditor_parse_errors/warnings, metaeditor_generate_fix_plan,
tester_prepare_signal_only_test, tester_validate_config, tester_import_csv/html,
tester_collect_reports, tester_review_results, tester_compare_runs,
tester_generate_backtest_report; plus the gated metaeditor_run_compile /
tester_run_backtest_if_supported (Windows only; tester run is validated-[Tester]-only).
Audit/introspection, Level 0 — list_tool_policies, get_tool_policy,
read_audit_log.
Declared but disabled (Level 4/5) — mt5_chart_*, mt5_ea_*, mt5_live_*
are in the policy model but not registered as tools in this phase.
BLOCKED (not implemented at all - no tool by these names exists, and the router refuses them by name as a safety net): sending, modifying, or cancelling any order; live trading in general.
See docs/TOOLS.md for full parameter reference, docs/EXAMPLES.md for usage
examples by tool group, docs/TROUBLESHOOTING.md for a symptom → cause → fix
guide, docs/SECURITY_MODEL.md for the canonical safety model (how the approval
gate and risk guard work, and what is intentionally excluded), and
docs/ARCHITECTURE.md for the module layout and request flow. docs/SAFETY.md
is a short summary that points to docs/SECURITY_MODEL.md. See
docs/RELEASE_CHECKLIST.md for the maintainer checklist used before tagging a
release.
pip install -e ".[dev]"
pytestTests run against a fake in-memory MT5 module (see tests/conftest.py), so
they pass on any platform without a real terminal.
No order execution (order_send) - intentionally not implemented.
No VPS/remote mode, no plugin system, no multi-strategy framework.
get_rates only supports the "most recent N bars" mode
(copy_rates_from_pos), not arbitrary date ranges.
read_strategy_report uses a generic HTML table parser (label/value cell
pairing); unusual report layouts may need raw row inspection.
The file-based approval mode polls the filesystem; it is not push-based.
No persistence/database - approvals and logs are plain files.
Compute basic peak-to-trough drawdown from history deals (fetched live if deals is omitted).
| Name | Required | Description | Default |
|---|---|---|---|
| deals | No | ||
| date_to | No | ||
| date_from | No | ||
| include_curve | No | ||
| starting_balance | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses that deals can be fetched live if omitted, but does not mention auth requirements, rate limits, destructive behavior, or output details. The statement 'basic' hints at simplicity but lacks depth.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, front-loaded with the core function. Every word adds value; no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 5 parameters, no output schema, and no annotations, the description is incomplete. It explains the main computation and data source but misses details on date range effects, the meaning of 'include_curve', and expected return values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaning to the 'deals' parameter by noting live fetching behavior, but provides no information about other parameters (date_to, date_from, include_curve, starting_balance) which are undocumented in the schema (0% coverage). This leaves four parameters unexplained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool computes 'basic peak-to-trough drawdown' from history deals, with the option to fetch live data if 'deals' is omitted. It uses a specific verb and resource, distinguishing it from sibling tools like analyze_trade_history or calculate_profit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use it (for drawdown calculation) but does not explicitly state when not to use it or how it differs from alternatives. No guidance on prerequisites or context is provided, leaving the agent to infer from the tool's name and siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compute win rate / profit factor / averages from history deals (fetched live if deals is omitted).
| Name | Required | Description | Default |
|---|---|---|---|
| deals | No | ||
| date_to | No | ||
| date_from | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must convey behavioral traits. It discloses that it fetches live data if 'deals' is omitted, which is useful. However, it does not explicitly state that the tool is read-only or non-destructive, nor does it mention any side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that efficiently conveys the core purpose and a key behavioral note. It is concise and front-loaded, though it could benefit from more structured formatting.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and 0% schema description coverage, the tool description is insufficient. It does not explain return values, date formats, error handling, or provide enough context for an agent to use the tool reliably.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, leaving three parameters undocumented. The description partially compensates by explaining the behavior when 'deals' is omitted (fetched live), but it does not clarify the date parameters or the structure of 'deals'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'compute' and the resource 'history deals', listing specific metrics like win rate, profit factor, and averages. It also mentions the conditional live fetching behavior, distinguishing it from sibling tools that might analyze different aspects.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for computing trade history metrics but provides no explicit guidance on when to use this tool versus alternatives like calculate_profit or calculate_profit_risk_basic. No exclusions or alternatives are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Calculate required margin for a hypothetical order. Requires approval; demo accounts only; never sent.
| Name | Required | Description | Default |
|---|---|---|---|
| price | Yes | ||
| symbol | Yes | ||
| volume | Yes | ||
| order_type | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so description carries full burden. It discloses approval requirement, demo-only restriction, and that the order is not actually sent. This is clear for a calculation tool, though no mention of rate limits or error conditions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is two sentences, direct and efficient. It hits the key points without extraneous text, though a more structured format (e.g., listing constraints) could improve readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 4 required parameters and no output schema, the description covers the tool's purpose and constraints but lacks parameter elaboration, leaving the agent with gaps in understanding how to correctly fill inputs.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% (no descriptions in schema) and the description does not explain any parameter meaning beyond their names. The agent must infer from parameter names like 'price', 'symbol', 'volume', 'order_type', which is ambiguous without further clarification.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Calculate required margin for a hypothetical order' with a specific verb and resource, and the context of margin calculation distinguishes it from sibling tools like calculate_profit or check_order.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit constraints: 'Requires approval; demo accounts only; never sent.' This tells the agent when to use (demo accounts) and important behavioral notes, though it doesn't explicitly list alternatives among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Calculate hypothetical profit/loss between two prices. Requires approval; demo accounts only; never sent.
| Name | Required | Description | Default |
|---|---|---|---|
| symbol | Yes | ||
| volume | Yes | ||
| order_type | Yes | ||
| price_open | Yes | ||
| price_close | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It discloses behavioral traits: requires approval, restricted to demo accounts, and never sends an order. This adds valuable context beyond the schema, though it does not detail side effects or return behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one concise sentence plus three key phrases. It is front-loaded with the core purpose. No unnecessary words, but added structure (e.g., bullet points) could improve readability for multiple constraints.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, 5 undocumented parameters, and no annotations, the description is insufficient. It does not explain what the calculation returns, what units are used, or how parameters interact. The agent lacks critical context to use this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% (no parameter titles have descriptions). The tool description does not explain any of the 5 parameters (symbol, volume, order_type, price_open, price_close). Without compensation, the agent has no guidance on parameter values or constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Calculate hypothetical profit/loss between two prices', which is a specific verb+resource. It distinguishes from siblings like 'calculate_margin' and 'analyze_drawdown', but could be more precise about what 'hypothetical' entails.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides important usage constraints: 'Requires approval; demo accounts only; never sent.' This tells the agent when to use (demo accounts) and that no real order is sent. However, it does not differentiate from the sibling 'calculate_profit_risk_basic'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Pure price-math risk/reward ratio calculation. No MT5 connection or symbol lookup needed.
| Name | Required | Description | Default |
|---|---|---|---|
| volume | No | ||
| stop_loss | Yes | ||
| entry_price | Yes | ||
| take_profit | Yes | ||
| value_per_point | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears full burden. It clearly states the tool is a pure math calculation and requires no external connection or symbol lookup, which is transparent enough for a simple calculator. It does not mention edge cases or precision, but the simplicity keeps it adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the purpose and key differentiating trait. Every word serves a purpose with no wasted content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, low schema coverage, and five parameters, the description lacks essential details about return values and parameter semantics. It only covers the high-level purpose, leaving the agent with insufficient information to correctly invoke the tool or interpret results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description does not explain any parameter. It only mentions the overall purpose of risk/reward calculation. The schema has five parameters (entry_price, stop_loss, take_profit, volume, value_per_point) with no description of their roles, leaving the agent guessing about their meaning and usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool calculates risk/reward ratio using price math and explicitly distinguishes it from tools requiring MT5 connection. 'Pure price-math' and 'No MT5 connection or symbol lookup needed' make the purpose specific and differentiate it from siblings like get_rates or get_symbol_info.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use: for quick calculations without MT5 dependency. The contrast with MT5-requiring tools provides clear context, but it does not explicitly state when not to use or provide alternatives. However, the guidance is sufficient for an agent to decide between this and other tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run MT5's server-side order_check validation for a hypothetical order. Requires approval; demo only; never sent.
| Name | Required | Description | Default |
|---|---|---|---|
| sl | No | ||
| tp | No | ||
| magic | No | ||
| price | Yes | ||
| symbol | Yes | ||
| volume | Yes | ||
| comment | No | mt5-mcp check (not sent) | |
| deviation | No | ||
| order_type | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description should fully disclose behavioral traits. It covers that the tool requires approval, is demo-only, and never sends the order. However, it omits details about error handling, rate limits, or what the response looks like.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that efficiently conveys the core purpose, requirements, and constraints without wasted words. It is well front-loaded with the action and key caveats.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having 9 parameters, no output schema, and no annotations, the description provides only minimal context. It does not explain parameter behavior, return values, or validation errors, making it insufficient for confident use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It does not mention any of the 9 parameters (e.g., order_type, symbol, volume, price, sl, tp, etc.) or explain their purpose beyond what is obvious from the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool runs MT5's server-side order_check validation for a hypothetical order, which is a specific verb+resource pair. It distinguishes itself from sibling tools (e.g., prepare_order_plan, get_orders) by emphasizing the hypothetical, demo-only nature of the order check.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implicitly tells when to use the tool: for hypothetical orders that should never be sent, and requires approval. It does not explicitly list when not to use it or name alternatives, but the demo-only and never-sent cues provide clear usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the connected MT5 account's balance, equity, margin, leverage, and trade mode.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It only states what is retrieved but does not mention authentication, real-time nature, potential failures (e.g., no connected account), or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single clear sentence with no extraneous words. It is front-loaded with the action and resource.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description should specify the return format or structure. It also lacks context on when to use this tool versus siblings. However, it covers the core purpose adequately.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With zero parameters, baseline is 4. The description adds value by specifying the fields returned (balance, equity, margin, leverage, trade mode), going beyond the empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'Get' and the specific resource: the connected MT5 account's balance, equity, margin, leverage, and trade mode. It is distinct from sibling tools like get_terminal_info or get_symbol_info.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives such as analyze_trade_history or calculate_margin. The description implies a simple read operation but does not clarify context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List historical deals between date_from/date_to (ISO dates), or by ticket/position.
| Name | Required | Description | Default |
|---|---|---|---|
| group | No | ||
| ticket | No | ||
| date_to | No | ||
| position | No | ||
| date_from | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It only states 'list' and mentions ISO dates, but fails to disclose side effects, authentication needs, rate limits, output format, or pagination. Significant gaps remain.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, with one sentence that front-loads the purpose. It could benefit from slight restructuring to separate filtering modes, but it efficiently conveys core functionality without excess.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 5 parameters and 0% schema coverage, the description is incomplete. It omits the role of the group parameter and does not note that all parameters are optional. While an output schema exists, the description lacks sufficient context for full autonomous use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaning by indicating date_from/date_to are ISO dates and that ticket/position can be used as filters. However, it does not explain the 'group' parameter, leaving one parameter unaddressed. With 0% schema coverage, more detail is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists historical deals and specifies two filtering modes: by date range or by ticket/position. This distinguishes it from sibling tools like analyze_trade_history or calculate_profit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool (to get historical deals) and gives context on parameter usage, but does not explicitly exclude alternative scenarios or mention when not to use it. No sibling differentiation provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List active pending orders, optionally filtered by symbol or ticket.
| Name | Required | Description | Default |
|---|---|---|---|
| symbol | No | ||
| ticket | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden for behavioral disclosure. It only states the basic action and optional filters, but fails to disclose pagination, rate limits, or what 'active pending' specifically entails.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no wasted words, but could be slightly more structured by separating the verb and filter explanation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema, return value details are not needed. However, the description lacks behavioral context and usage guidance, making it somewhat incomplete for a tool with multiple siblings.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description must compensate. It clarifies that 'symbol' and 'ticket' are optional filters, adding value beyond parameter names, but does not explain format or allowed values.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'List' and identifies the resource 'active pending orders', distinguishing it from siblings like 'get_positions' or 'get_history_deals' which handle different order states or types.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like 'check_order' or when filters should be applied. The description does not mention exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List open positions, optionally filtered by symbol or ticket.
| Name | Required | Description | Default |
|---|---|---|---|
| symbol | No | ||
| ticket | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries full burden. It only states the basic function without detailing behavior like ordering, pagination, or authentication needs. Important for an open-positions listing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence with no wasted words, but it is underspecified. It could be expanded without verbosity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists but is not shown; the description does not mention return structure. For a straightforward list tool, more completeness is expected to match annotation absence.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, and the description merely mentions symbol and ticket without adding format, examples, or constraints. The schema provides basename only.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists open positions with optional filters by symbol or ticket. This is a specific verb-resource pair and distinguishes from sibling tools like summarize_positions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance provided on when to use this tool versus alternatives such as summarize_positions or analyze_trade_history. The description lacks context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get OHLCV bars for symbol on timeframe (e.g. M1, M15, H1, H4, D1).
| Name | Required | Description | Default |
|---|---|---|---|
| count | No | ||
| symbol | Yes | ||
| start_pos | No | ||
| timeframe | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description only mentions output format (OHLCV bars) but no behavioral traits like rate limits, data depth, or side effects. With zero annotation coverage, description carries full burden but lacks detail.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, efficient, front-loaded with verb and resource. No redundant words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Missing parameter details for count and start_pos, no usage guidelines, and limited behavioral transparency. Output schema exists but does not compensate for the gaps in the description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Description only covers symbol and timeframe with examples, but fails to explain count and start_pos. Schema description coverage is 0%, so description must compensate, which it does not. Two parameters are left undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the verb 'Get' and resource 'OHLCV bars' with parameters symbol and timeframe. It distinguishes from sibling tools which focus on analysis, orders, and account info.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides examples of timeframes but no explicit when-to-use vs alternatives, no when-not or exclusions. Context implies basic data retrieval, but more guidance would help.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get full symbol specification (point, digits, contract size, spread, limits) for symbol.
| Name | Required | Description | Default |
|---|---|---|---|
| symbol | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must carry disclosure. 'Get' implies read-only, but it does not explicitly state no side effects, idempotency, or error conditions. The description is minimal beyond the action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, no redundant words. Information is front-loaded with the verb and resource, and the parenthetical list efficiently communicates output content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a low-complexity tool with one parameter and no output schema, the description adequately explains what the tool returns by listing fields. No additional context is needed for an agent to understand the function.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description only references the parameter by name. It does not specify symbol format (e.g., ticker, exchange prefix) or constraints, leaving ambiguity for the agent.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves full symbol specification and lists the specific fields (point, digits, contract size, spread, limits). It distinguishes from siblings like get_rates and get_tick by focusing on detailed symbol metadata.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use (need symbol details) but provides no explicit when-to-use vs alternatives or exclusions. While adequate for a simple tool, it lacks guidance on context like prerequisite symbol info.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get MT5 terminal status: connection state, data path, build, trade-allowed flags.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite no annotations, the description identifies it as a read operation ('Get terminal status') and lists the data returned. However, it does not disclose any behavioral traits such as rate limits, authentication requirements, or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence that efficiently communicates the tool's purpose. Every word contributes value with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the primary content of the terminal status, which is sufficient for a simple parameterless tool. Lacking an output schema, additional detail on return format would be helpful but not essential given the listing of specific fields.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With zero parameters, the description's listing of returned fields adds meaning beyond the schema. For a parameterless tool, this is appropriate and adequately informative.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and explicitly lists the terminal status fields: connection state, data path, build, trade-allowed flags. This clearly distinguishes it from sibling tools like get_account_info or get_rates.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for checking MT5 terminal status but provides no explicit guidance on when to use it over alternatives or any exclusions. No context about prerequisites or conditions is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the latest bid/ask/last tick for symbol.
| Name | Required | Description | Default |
|---|---|---|---|
| symbol | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries the full burden. It correctly implies a read operation (get) but does not disclose any potential side effects, data freshness, or limitations. Adequate for simple read.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence achieves the purpose without extraneous content. Slightly more detail on the parameter could be added without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (1 param, no output schema, no annotations), the description covers the basics but omits return format and edge cases. Adequate but not thorough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%; the description only mentions the parameter name in backticks without adding format, constraints, or examples. For a simple string parameter, the lack of context reduces clarity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get', the resource 'latest bid/ask/last tick', and the parameter 'symbol'. It is specific and distinguishes from sibling tools like get_rates or get_symbol_info.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives (e.g., get_rates). No when-not-to-use or prerequisites are mentioned, leaving the agent to infer usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Build a full order plan (request + margin + estimated P/L + order_check). Requires approval; demo only; NEVER sent.
| Name | Required | Description | Default |
|---|---|---|---|
| sl | No | ||
| tp | No | ||
| magic | No | ||
| price | Yes | ||
| symbol | Yes | ||
| volume | Yes | ||
| comment | No | mt5-mcp plan (not sent) | |
| deviation | No | ||
| order_type | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears full responsibility. It discloses key behavioral traits: requires approval, demo only, never sent. However, it is vague about what 'requires approval' entails and does not mention error conditions, permissions, or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, informative sentence with no fluff. While concise, it could benefit from slight restructuring or bullet points for readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 9 parameters, no output schema, and no parameter descriptions, the description is incomplete. It does not specify return values or parameter semantics, leaving significant ambiguity for a complex planning tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate, but it provides no parameter explanations. Users must infer parameter roles from context, which is insufficient for 9 parameters including required fields like 'order_type' and 'price'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool builds a full order plan including request, margin, estimated P/L, and order_check. It distinguishes itself by noting it is demo-only and never sent, though it doesn't explicitly contrast with sibling tools like 'check_order' or 'calculate_margin'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides usage context: 'Requires approval; demo only; NEVER sent.' This implies it's for planning rather than execution. However, it lacks explicit guidance on when to use this tool versus alternatives such as 'calculate_margin' or 'check_order' for individual components.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read the tail of an MT5 log file for date (YYYYMMDD, default today). kind: 'terminal' or 'experts'.
| Name | Required | Description | Default |
|---|---|---|---|
| date | No | ||
| kind | No | terminal | |
| lines | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description bears full burden. It discloses read-only behavior ('Read the tail') and parameter details (date format, kind options), but does not mention rate limits, error handling, or behavior for missing files.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise: two sentences with no filler. Front-loaded with the main action and parameter specifics. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (read log tail), but the description lacks details on return format, error cases, and the 'lines' parameter. With no output schema, more context would be beneficial for a complete understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, requiring the description to compensate. It adds meaning for 'date' (format and default) and 'kind' (allowed values), but omits the 'lines' parameter entirely, leaving its purpose unclear.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it reads the tail of an MT5 log file, specifying verb (read), resource (log file), and scope (tail). Distinguishes from all sibling tools, which are for trade analysis or order operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or when-not-to-use. Context from sibling tools implies uniqueness, but description does not provide guidance on alternatives or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Parse an MT5 Strategy Tester HTML report into a summary dict and raw table rows.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the burden of disclosing behavior. It indicates a read-only parse operation, but does not mention error handling, performance implications, or file existence requirements. Acceptable but not thorough.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that effectively communicates purpose and output without unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers basic purpose and output, but lacks details on error conditions, file size limits, or a comparison with similar tools like 'read_log'. Without an output schema, more structure of the returned data would be beneficial.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter 'path' is not described in the schema (0% coverage). The description provides context by specifying the report type (MT5 Strategy Tester HTML), implying what the path should point to, but does not detail format or constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action ('Parse') and resource ('an MT5 Strategy Tester HTML report'), and specifies the output format ('summary dict and raw table rows'). This distinguishes it from sibling tools like 'read_log' which parse logs, not strategy reports.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is used for MT5 Strategy Tester HTML reports, but it does not explicitly state when to use it versus alternatives, nor does it provide any exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Summarize open positions by total, symbol, and side. Fetches live positions if positions is omitted.
| Name | Required | Description | Default |
|---|---|---|---|
| positions | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries the burden. It discloses the key behavior of fetching live positions when the parameter is omitted. However, it does not mention side effects, performance implications, or error conditions, which would be helpful for a read-oriented tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two sentences that front-load the core purpose. It is efficient and without redundancy, though a brief mention of the output format could improve structure without adding much length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of output schema, the description should hint at the return format. It mentions grouping by total, symbol, and side but does not specify the type of summary (e.g., list of objects). The parameter behavior is well-explained, but overall completeness is moderate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaning by explaining that omitting 'positions' fetches live data, which the schema's default of null implies but does not clarify. However, it does not describe the expected structure of the positions array (schema has additionalProperties: true), leaving the parameter semantics incomplete.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool summarizes open positions by total, symbol, and side, distinguishing it from siblings like get_positions which provides raw lists. However, it does not define what 'total' means (e.g., count or value), leaving some ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when a summary is needed and notes that live positions are fetched if omitted. It does not specify when not to use this tool or mention alternatives, but the context of sibling tools provides implicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Each tool has a distinct purpose. Analysis tools are differentiated (drawdown vs. trade history vs. profit calculation variants). Data retrieval tools are separate (rates, ticks, symbols, account, terminal). No overlapping functionality.
All tools follow a consistent verb_noun snake_case pattern: get_*, analyze_*, calculate_*, check_*, prepare_*, read_*, summarize_*. No mixing of conventions.
18 tools are well-scoped for a MetaTrader 5 assistant covering account info, market data, position/order status, trade analysis, risk calculation, and logging. Not overwhelming or insufficient.
The tool surface covers core functionalities (data retrieval, analysis, planning) but lacks order execution (place, modify, close). Since several tools explicitly state 'never sent' (demo only), this appears intentional, leaving a minor gap for an analytical MCP.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Connect any MCP client to MetaTrader 4/5 to read prices, manage positions, and place trades.
Connect your AI to a funded trading account. Read & trade a simulated funded challenge.
Trade 16 crypto exchanges + MetaTrader 5 from your AI assistant via one MCP connection.
Connect your portfolio to Claude, ChatGPT, or Codex to analyze it and make smarter investments.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/alikhande70/metatrader5-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
