get_account_type returns scrambled values: DEMO accounts reported as "real"

[minada422]

Summary

In metatrader-mcp-server v0.5.1, the get_account_type() function returns incorrect values because the mapping between MT5's trade_mode integer and the returned string is rotated by one position. The most concerning consequence: demo accounts are reported as "real", which inverts the safety-critical signal that downstream code typically uses to gate live trading.

Reproduction

1. Connect to any MT5 demo account (verified with XS Fintech demo, login on XSFintech-DEMO server, MT5 title bar shows "デモ口座" / DEMO).
2. Call the get_account_info MCP tool.
3. Inspect the account_type field in the response.

Expected: "demo"
Actual: "real"

Independently verified via direct Python: mt5.account_info().trade_mode returns 0 (= ACCOUNT_TRADE_MODE_DEMO per MetaTrader 5 documentation), confirming the underlying MT5 value is correct and the bug is purely in the mapping.

Root cause

In metatrader_client/account/get_account_type.py (lines 14–20), the mapping is:

if trade_mode == 0:
    return "real"
elif trade_mode == 1:
    return "demo"
elif trade_mode == 2:
    return "contest"

The correct mapping per MT5's ENUM_ACCOUNT_TRADE_MODE is:

trade_mode value	Constant	Should return
0	ACCOUNT_TRADE_MODE_DEMO	"demo"
1	ACCOUNT_TRADE_MODE_CONTEST	"contest"
2	ACCOUNT_TRADE_MODE_REAL	"real"

A secondary inconsistency exists in metatrader_client/account/get_account_info.py line 12 docstring, which documents the same wrong premise (0-real, 1-demo, 2-contest). This consistent error across at least two locations suggests the misunderstanding is repository-wide rather than isolated to one function.

The MCP tool get_account_info reaches the buggy mapping via:
metatrader_openapi/routers/accounts.py (account_info endpoint) → client.account.get_trade_statistics() → get_account_type(). The docstring in get_account_info.py is unused by this path but documents the same incorrect ordering.

Suggested fix

Swap the return values in get_account_type.py to match MT5's actual enum, and update the docstring in get_account_info.py accordingly.

Impact

Any caller using account_type to gate live-vs-demo behavior (e.g., "only place real orders if account_type == 'real'") will do the opposite of intended. Trading bots are the obvious risk surface — a strategy designed to fire on a genuine demo account for testing will refuse to fire there, while strategies meant to execute only on live will fire on what the system believes is a real account but is actually demo (or vice versa depending on logic direction). Even safety patterns like if account_type != 'real': abort() invert silently.

Flagging now so other users don't trip the same wire.

Environment

• metatrader-mcp-server 0.5.1 (PyPI)
• Python 3.12.10 on Windows 11
• MT5 terminal 5.0.0.5833
• MetaTrader5 package 5.0.5735

[NadirAliOfficial]

Can confirm this bug — MT5's trade_mode values are:

• 0 = Demo
• 1 = Contest
• 2 = Real

The off-by-one mapping is a critical issue since most safety checks use account_type == 'demo' before enabling live execution.

Quick fix while waiting for a patch:

import MetaTrader5 as mt5

TRADE_MODE_MAP = {
    mt5.ACCOUNT_TRADE_MODE_DEMO: 'demo',
    mt5.ACCOUNT_TRADE_MODE_CONTEST: 'contest', 
    mt5.ACCOUNT_TRADE_MODE_REAL: 'real',
}

def get_account_type():
    info = mt5.account_info()
    if info is None:
        return None
    return TRADE_MODE_MAP.get(info.trade_mode, 'unknown')

Using MT5's named constants (ACCOUNT_TRADE_MODE_DEMO etc.) instead of raw integers avoids the mapping issue entirely and is more readable. The constants are guaranteed to match the API regardless of version.

[luizotaviojr-cloud]

Confirming this on 0.5.1 against a Brazilian broker. One thing the thread hasn't covered yet: the fix is not only the mapping — it's the return type.

Both proposed patches (the issue body's swap and @NadirAliOfficial's TRADE_MODE_MAP) return a label string. That leaves the safety property dependent on which comparison idiom each caller happened to pick:

if account_type == "real": abort()   # fails OPEN on an unrecognised trade_mode
if account_type != "real": abort()   # fails CLOSED

Both read as equally correct at the call site, and TRADE_MODE_MAP.get(..., "unknown") doesn't disambiguate them — it supplies a third string that each caller still has to reason about. If a future MT5 build adds a fourth ENUM_ACCOUNT_TRADE_MODE member, the first form silently permits live orders on an account nobody classified.

A boolean guard removes the choice from the caller:

_SIMULATED_MODES = frozenset({0, 1})  # DEMO, CONTEST

def blocks_live_trading(connection) -> bool:
    """True unless the account is provably simulated."""
    ...
    return trade_mode not in _SIMULATED_MODES

Membership grants permission; absence blocks. The negative name is deliberate and worth keeping: under fail-closed semantics a positively-named is_real_account() would make if is_real_account(): log("real account") emit a false statement whenever the trade mode is unknown. blocks_live_trading has exactly one reading — True means block.

Small correction to the root-cause section: the MCP tool and the REST endpoint are two independent surfaces rather than one chain. metatrader_mcp/server.py calls client.account.get_trade_statistics() directly and never touches FastAPI; metatrader_openapi/routers/accounts.py calls it separately. So get_trade_statistics() is indeed the single carrier, but the blast radius is both transports.

I have a branch carrying this plus #25 and #26, with regression tests that run without MetaTrader5 installed (the module is stubbed before collection), so the fixes are reviewable on Linux/CI without a terminal: luizotaviojr-cloud/metatrader-mcp-server@investia/fixes. Opening it as a PR shortly.