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., "@mt4ctl Which demo terminals are down?" 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.

mt4ctl

by ak40u

Overview Schema Related Servers Score Discussions

Python

Remote

mt4ctl

An MCP server for operating headless MetaTrader terminals — over SSH, from your agent.

Manage MetaTrader 4 terminals running under Wine + systemd on remote hosts (native Linux or WSL2) entirely through the Model Context Protocol: check status, read logs, capture screenshots, control the systemd lifecycle, and perform the tricky headless first-login — all as clean, typed tools.

PyPI Python MCP License: MIT

Why

Algo traders increasingly run MetaTrader 4 headless on Linux — Wine under Xvfb, supervised by systemd, no GUI. That's great for uptime and terrible for day-to-day operations: every "is it connected?", "restart that one", or "log this new account in" turns into a fragile chain of ssh → (Windows cmd → wsl) → bash → systemctl → wine, with quoting hazards at every hop.

mt4ctl collapses that chain into a handful of MCP tools. Point it at a registry of your hosts and terminals, wire it into Claude (or any MCP client), and operate the whole farm conversationally:

"Which demo terminals are down?" · "Restart demo2." · "Log demo2 into account 1000002 on ExampleBroker-Demo." · "Screenshot the live terminal so I can see the AutoTrading state."

Related MCP server: mt5ctl

Quickstart (5 minutes)

The init → list → doctor commands let you set up and verify everything before wiring an MCP client:

# 1. write a starter registry, then fill in your hosts + terminals
uvx mt4ctl init                 # creates ~/.config/mt4ctl/terminals.yaml
$EDITOR ~/.config/mt4ctl/terminals.yaml

# 2. verify — offline, then over SSH (no MCP client needed)
uvx mt4ctl list                 # confirms the registry parses
uvx mt4ctl doctor               # checks SSH, remote tools, units, data dirs

# 3. wire into Claude Code
claude mcp add --scope user mt4ctl \
  --env MT4CTL_CONFIG="$HOME/.config/mt4ctl/terminals.yaml" \
  -- uvx mt4ctl

Then ask Claude: "Use mt4_list to show my configured terminals," then "mt4_status," and "mt4_doctor" if anything looks off. Full setup and other clients are below.

Features

Per-terminal connection detection — attributes established broker sockets to each terminal's systemd cgroup, so terminals sharing a host (and a Wine prefix) are reported independently — not guessed from a host-wide count.
Headless first-login — automates the one-time bootstrap a migrated terminal needs (MetaTrader's saved password is machine-bound), then hands control back to systemd for automatic reconnection on every restart.
Idempotent strategy deploy — kubectl-apply for one terminal: push a local bundle of charts + experts and reconcile a terminal to it, touching only what mt4ctl deployed (foreign files like a watchdog's chart stay untouched), with a backup-and-restore-on-failure apply and a polling, report-only health verify that waits out the broker reconnect instead of guessing from a single snapshot.
Native and WSL2 hosts — one registry, two execution models; commands are base64-shipped so nothing breaks in the cmd.exe → wsl.exe → bash gauntlet.
Live-trading guardrails — terminals tagged env: live reject mutating operations unless you pass confirm=true.
Concurrent status — hosts are polled in parallel via asyncio.
Secrets stay secret — passwords resolve from arg → env → secrets file, are never logged, and the transient remote login config is shred-ed after use.

How it works

┌────────────┐   MCP/stdio   ┌──────────────────┐
│ MCP client │ ────────────► │     mt4ctl       │
│ (Claude…)  │               │  FastMCP server  │
└────────────┘               └────────┬─────────┘
                                       │ asyncio SSH (base64-framed)
                 ┌─────────────────────┼─────────────────────┐
                 ▼                                           ▼
        ┌─────────────────┐                        ┌──────────────────┐
        │  native Linux   │                        │  Windows + WSL2  │
        │  sudo systemctl │                        │  wsl -u root --  │
        ├─────────────────┤                        ├──────────────────┤
        │ mt4-live-main…  │  systemd units running │ mt4-demo1…       │
        │ wine terminal.exe (Xvfb display)         │ wine terminal.exe│
        └─────────────────┘                        └──────────────────┘

A thin, typed core (models → config → ssh → scripts → deploy → operations/login) sits under the server adapter, so the logic is testable without a network and the MCP layer stays a one-line-per-tool shell.

Install

The fastest path needs no clone and no global install — uv runs mt4ctl straight from the repo and fetches a matching Python itself:

uvx mt4ctl   # runs the stdio server

No uv yet? curl -LsSf https://astral.sh/uv/install.sh | sh — or skip it and use the pipx path below.

Prefer a persistent mt4ctl command? Install it with uv or pipx:

uv tool install mt4ctl
# or
pipx install mt4ctl

For development:

git clone https://github.com/ak40u/mt4ctl.git && cd mt4ctl
python -m venv venv && source venv/bin/activate
pip install -e ".[dev]"

The server machine needs either uv or Python 3.11+, plus SSH access to your hosts. The remote hosts need the usual tools mt4ctl shells out to: systemctl, ss, getent, (for screenshots) imagemagick/scrot + xdotool, and (for deploy/adopt) GNU tar + a sha256 tool.

Configure

Copy the example registry and fill in your real hosts and terminals:

mkdir -p ~/.config/mt4ctl
cp examples/terminals.example.yaml ~/.config/mt4ctl/terminals.yaml

The registry is resolved from MT4CTL_CONFIG, then ~/.config/mt4ctl/terminals.yaml, then ./terminals.yaml. See examples/terminals.example.yaml for the full schema and docs/configuration.md for details.

Keep your populated registry private. It maps your accounts and infrastructure. The default .gitignore excludes terminals.yaml.

Setting up terminal hosts

mt4ctl manages terminals; it doesn't install them. To stand up a host that runs MT4 headless (Wine + Xvfb + systemd) so mt4ctl has something to drive:

Ubuntu / Linux server — Wine, the Xvfb + window-manager display, fonts (incl. the real Wingdings the MT4 smiley needs), systemd units, and the one-time headless login.
Windows via WSL2 — the same stack inside WSL2, plus enabling WSL + systemd, copying fonts from the Windows C: drive, boot autostart, and the WSL-specific gotchas.

Connect to an MCP client

Claude Code — one command wires it up (user scope = available in every project):

claude mcp add --scope user mt4ctl \
  --env MT4CTL_CONFIG="$HOME/.config/mt4ctl/terminals.yaml" \
  -- uvx mt4ctl

Or commit a project .mcp.json to share with a team (Claude Code expands ${HOME}):

{
  "mcpServers": {
    "mt4ctl": {
      "command": "uvx",
      "args": ["mt4ctl"],
      "env": { "MT4CTL_CONFIG": "${HOME}/.config/mt4ctl/terminals.yaml" }
    }
  }
}

Claude Desktop — Settings → Developer → Edit Config (claude_desktop_config.json), same shape but use an absolute config path (Desktop does not expand ${HOME}), and an absolute command path if uvx is not on the GUI app's PATH (which uvx):

{
  "mcpServers": {
    "mt4ctl": {
      "command": "uvx",
      "args": ["mt4ctl"],
      "env": { "MT4CTL_CONFIG": "/Users/you/.config/mt4ctl/terminals.yaml" }
    }
  }
}

Installed mt4ctl persistently (uv/pipx)? Replace command/args with just "command": "mt4ctl".

Tools

Tool	Mutates	Description
`mt4_list`	–	List configured terminals (offline).
`mt4_status`	–	Per-terminal service state + broker connection + log age.
`mt4_logs`	–	Tail / grep a terminal's newest log file.
`mt4_screenshot`	–	Capture a terminal window as PNG.
`mt4_control`	✓	`start` / `stop` / `restart` a unit (live needs `confirm`).
`mt4_login`	✓	One-time headless login for auto-reconnect (live needs `confirm`).
`mt4_doctor`	–	Diagnose registry, SSH, remote tools, units, and data dirs.
`mt4_ea_list`	–	List the experts (strategies) attached per terminal.
`mt4_autotrading`	–	AutoTrading master switch + per-EA live-trading status.
`mt4_info`	–	Terminal build, broker server, and last broker ping.
`mt4_deploy`	✓	Reconcile a terminal to a local strategy bundle (live needs `confirm`).
`mt4_adopt`	✓	Record an already-running bundle as managed — the brownfield first cutover.
`mt4_verify`	–	Poll a terminal until it is healthy after a restart (or report the failure).

Full reference: docs/tools.md.

CLI

The subcommands mirror the MCP tool surface, so you can operate — and script — the whole farm without an MCP client:

# setup
mt4ctl init [path]   # write a starter terminals.yaml (default: XDG config path)
mt4ctl list          # list configured terminals (offline)
mt4ctl doctor        # check registry, SSH, remote tools, units, data dirs

# read / inspect
mt4ctl status [terminal]                 # service + broker per terminal (exit 1 if unhealthy)
mt4ctl logs <terminal> [--pattern RE] [--lines N]
mt4ctl ea-list [terminal]                # experts attached per terminal
mt4ctl autotrading [terminal]            # AutoTrading master + per-EA live status
mt4ctl info [terminal]                   # build / broker server / last ping
mt4ctl screenshot <terminal> [--out-dir DIR]

# control / lifecycle (env=live needs --confirm)
mt4ctl control <terminal> {start|stop|restart} [--confirm]
mt4ctl login <terminal> <server> [--account A] [--password P] [--confirm]
mt4ctl verify <terminal> [--timeout SECONDS]                # poll until healthy after a restart
mt4ctl deploy <terminal> <bundle> [--dry-run] [--confirm] [--reset-market-watch]
mt4ctl adopt <terminal> <bundle> [--confirm]                # adopt an already-running farm

mt4ctl serve         # run the MCP stdio server (the default with no subcommand)

Health-oriented commands (status, verify, doctor) exit non-zero when something is unhealthy, so a shell health-check can rely on the exit code rather than grepping the output.

Deploy

Push a local bundle of charts + experts onto a terminal and reconcile it to that desired set — idempotently, touching only what mt4ctl deployed. The bundle mirrors the MT4 layout:

<bundle>/
  profiles/default/<name>.chr        # ready charts (one expert each)
  MQL4/Experts/<folder>/<ea>.ex4     # the experts those charts reference

mt4ctl deploy demo3 ./bundle --dry-run   # preview the add/update/remove/foreign plan
mt4ctl deploy demo3 ./bundle             # apply (env=live terminals need --confirm)

It is apply-only (no selection, lot sizing, chart generation, or compilation — you build the bundle), idempotent (a re-run is a no-op that still verifies health), and managed-subset (foreign files like a watchdog's chart are never touched). The write order is stop → drain → backup → apply → start; after the restart verify polls until the terminal is healthy (report-only — it never reverts), and there is no rollback command — recovery is to re-deploy the previous bundle. Add --reset-market-watch to rebuild the terminal's Market Watch in the stopped window (deletes symbols.sel, backed up first) and cap unbounded symbol carry-over.

Already running strategies on the farm? Take it under management first with mt4ctl adopt <terminal> <bundle> (records the current footprint, changes nothing), then deploy as usual. Full model and caveats: docs/deploy.md.

Security

Mutations on env: live terminals require explicit confirm=true.
Credentials resolve from argument → MT4CTL_PASSWORD_<account> → secrets file; they are never written to logs and the transient remote login config is shredded after use.
All remote execution goes through your existing SSH config and key-based auth; mt4ctl stores no credentials of its own.
During mt4_login the password is embedded in the base64-framed script handed to ssh, so it is briefly visible in the local process list to your own user. On the remote side it is written only to a fresh mktemp config (mode 600) that a cleanup trap shreds on any exit path. On POSIX, the local secrets file is rejected if it is readable by group/other.

Deep dive

The MT4 "32 terminals per Windows user" limit — reproducing the cap on a clean box, locating the exact kernel object that enforces it (a per-instance Mutant in the session-local \Sessions\<id>\BaseNamedObjects), and why running headless under Wine on Linux — what mt4ctl drives — sidesteps it entirely.

Development

ruff check src tests      # lint
mypy                      # type-check (strict)
pytest                    # tests

See docs/architecture.md for the module boundaries.

License

MIT © Pavel Volkov. See LICENSE.

Available Tools

13 tools

mt4_adoptA

Take an already-running terminal under mt4ctl management (first cutover).

On a terminal whose strategies were NOT placed by mt4ctl, the first mt4_deploy refuses (every existing file is an unmanaged-overwrite). Run mt4_adopt once first: it records the bundle's footprint into the manifest at the files' current on-disk hashes, so deploy can reconcile from there.

This is RECORDS-ONLY: it changes NOTHING — no upload, no restart, no preview. It is bundle-scoped (foreign files like a watchdog's chart stay foreign) and requires every bundle file to already be present on the host (the premise is the farm runs this bundle; a missing file is refused). A live terminal needs confirm=true.

bundle is a LOCAL directory (the same layout mt4_deploy takes). After adopt, run mt4_deploy <terminal> <bundle> --dry-run to confirm a clean "no changes".

Args: terminal: terminal id. bundle: local bundle directory path. confirm: must be true to adopt a terminal tagged env=live.

ParametersJSON Schema

Name	Required	Description	Default
`terminal`	Yes
`bundle`	Yes
`confirm`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.8/5.0

Behavior5/5

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

With no annotations, the description carries full burden. It clearly states 'RECORDS-ONLY: it changes NOTHING — no upload, no restart, no preview,' and explains constraints and the confirm flag. This gives a complete picture of the tool's behavior.

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 well-structured with a clear summary, detailed explanation, and parameter list. It is slightly lengthy but each sentence adds value; could be slightly more concise but still effective.

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?

The description covers input parameters and behavior thoroughly, but does not mention the output schema or return values. Although an output schema exists (not shown), the description could briefly indicate what the tool returns (e.g., success/failure or manifest info). Otherwise, it is complete for this tool's typical use.

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

Parameters5/5

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

Schema has zero description coverage, so the description must compensate. It explains each parameter: terminal (id), bundle (local directory path), confirm (needed for live), and adds context about bundle layout and required presence of files.

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 purpose: 'Take an already-running terminal under mt4ctl management (first cutover).' It explains what the tool does (records file hashes) and distinguishes it from the sibling mt4_deploy, making the purpose unambiguous.

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?

Explicit guidance is provided: use before first mt4_deploy on an unmanaged terminal; it is bundle-scoped and requires all bundle files to exist; confirm=true is needed for live terminals. It also suggests a follow-up dry-run deploy to confirm clean state.

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

mt4_autotradingA

Report whether algo-trading is enabled — terminal master switch + per-EA.

Shows the terminal-level AutoTrading button (from terminal.ini) and how many attached experts have live-trading enabled. Flags terminals whose master is off (nothing trades) or whose experts have non-uniform/disabled flags.

Note: the per-EA live-trading flag is a best-effort decode of the MT4 chart-expert bitmask; the terminal master switch is authoritative.

Args: terminal: a terminal id, or "all" (default).

ParametersJSON Schema

Name	Required	Description	Default
`terminal`	No		all

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.5/5.0

Behavior4/5

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

With no annotations provided, the description effectively discloses behavioral traits: it reports terminal-level master switch, per-EA best-effort decode, and flags non-uniform configurations. It also notes the authoritative nature of the terminal master switch.

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 at about 7 sentences, well-structured with a summary followed by detailed notes. No redundant information, every sentence adds value.

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 one optional parameter and an output schema, the description covers all necessary aspects: what is reported (master switch, per-EA flags), limitations (best-effort decode), and output behavior (flags non-uniform/disabled). Complete for the tool's complexity.

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 has 0% description coverage, so the description compensates by explaining the single 'terminal' parameter, including its default value 'all' and that it can be a terminal id. This is sufficient for parameter understanding.

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 reports algo-trading status, covering terminal master switch and per-EA flags. It distinguishes from sibling tools by focusing specifically on autotrading status.

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 for when to use the tool (checking autotrading status) and explains its output structure. It implicitly guides usage but does not explicitly mention when not to use or compare with alternatives among siblings.

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

mt4_controlA

Start, stop, or restart a terminal's systemd unit.

Mutating a live terminal requires confirm=true.

Args: terminal: terminal id. action: one of "start", "stop", "restart". confirm: must be true to act on a terminal tagged env=live.

ParametersJSON Schema

Name	Required	Description	Default
`terminal`	Yes
`action`	Yes
`confirm`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.5/5.0

Behavior4/5

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

No annotations provided, so description carries full burden. It discloses that mutating a live terminal requires confirm=true, highlighting a critical safety constraint. This is adequate for a tool with a defined action set.

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?

Six-line description is extremely concise. First sentence states main purpose. No wasted words.

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 3 params and no annotations, description covers the essential behavioral trait (confirm for live). Output schema exists, so return values need not be described. Minor lack of detail about terminal format, but acceptable.

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

Parameters5/5

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

Schema coverage is 0%, but description explains all parameters: terminal, action (listing three options), and confirm (with usage condition). Adds meaning beyond schema structure.

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 'Start, stop, or restart a terminal's systemd unit,' specifying the verb and resource. It distinguishes from siblings like mt4_deploy or mt4_autotrading, which have different purposes.

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?

Provides explicit condition for confirm parameter when mutating a live terminal. Though it doesn't directly compare to alternatives, the action set (start/stop/restart) is self-contained and clear.

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

mt4_deployA

Deploy a strategy bundle to a terminal — idempotent, managed-subset.

Pushes pre-built charts + experts so the terminal's managed files match the bundle, while leaving foreign files (e.g. a watchdog's chart) untouched. This is apply-only: it does NOT select strategies, set lots/magic, generate charts, or compile — the caller owns the bundle's contents.

bundle is a LOCAL directory on this machine (read here and pushed over SSH — NOT a path on the remote host). It mirrors the MT4 layout:

<bundle>/
  profiles/default/<name>.chr        # ready charts (one expert each)
  MQL4/Experts/<folder>/<ea>.ex4     # the experts those charts reference

Always run with dry_run=true first to preview the add/update/remove/foreign plan. Re-running the same bundle is a no-op (reports "no changes"). A terminal tagged env=live requires confirm=true. There is no rollback command: to recover, re-deploy the previous bundle (a pre-apply backup is also retained and is restored automatically if an apply fails).

reset_market_watch deletes symbols.sel in the stopped window (backed up first) so MT4 rebuilds Market Watch on the deploy's own start — caps unbounded symbol carry-over; it forces a stop/start cycle even with no file changes. After the restart, verify polls up to verify_timeout seconds rather than taking a single snapshot, so normal reconnect timing is not reported as a failed deploy.

Args: terminal: terminal id. bundle: local bundle directory path. dry_run: preview the plan without changing anything (no lock, no upload). confirm: must be true to deploy to a terminal tagged env=live. reset_market_watch: rebuild Market Watch by deleting symbols.sel while stopped. verify_timeout: seconds to poll post-restart health before reporting (default ~120).

ParametersJSON Schema

Name	Required	Description	Default
`terminal`	Yes
`bundle`	Yes
`dry_run`	No
`confirm`	No
`reset_market_watch`	No
`verify_timeout`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.5/5.0

Behavior5/5

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

With zero annotations, the description fully bears the burden of disclosing behavioral traits. It thoroughly explains idempotency ('re-running the same bundle is a no-op'), the apply-only nature, no rollback but recovery via previous bundle, backup retention, and precise details on reset_market_watch and verify_timeout. It also lists what the tool does not do, which is excellent for transparency.

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 well-structured: a one-sentence summary followed by paragraphs on key behaviors and parameter details. It is front-loaded with the core action. While somewhat lengthy, the detail is necessary given zero schema coverage, and every sentence adds value. A slight reduction in verbosity (e.g., condensing the reset_market_watch explanation) could improve conciseness, but it remains clear.

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?

Despite having an output schema (not detailed in description), the description covers all behavioral aspects, including idempotency, what is and isn't done, parameter semantics, error handling (dry run, confirm), recovery strategy, and specifics of reset_market_watch and verify_timeout. For a deployment tool with six parameters and no annotations, this description is remarkably complete.

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

Parameters5/5

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

Schema description coverage is 0%, so the description must define all parameters. It does so comprehensively: terminal is a terminal id, bundle a local directory path with expected structure, dry_run for preview, confirm for live deployments, reset_market_watch deletes symbols.sel, verify_timeout a polling duration. The description adds context beyond the schema, like the bundle's MT4 layout and the effect of reset_market_watch on restart timing.

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 deploys a strategy bundle to a terminal, is idempotent, and manages only a subset of files. It specifies what the tool does (push pre-built charts + experts) and, notably, what it does NOT do (select strategies, set lots, etc.), making the purpose unmistakable. The verb 'Deploy' and resource 'bundle to a terminal' are specific and distinguish it from sibling tools like mt4_autotrading or mt4_control.

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 provides implicit usage guidance (e.g., always run with dry_run=true first, confirm required for live terminals) but does not explicitly state when to use this tool versus its siblings. It mentions idempotency and no rollback, but without direct comparisons to mt4_adopt, mt4_ea_list, etc. The guidance is clear for the tool's own usage but lacks exclusion criteria or alternative tool recommendations.

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

mt4_doctorA

Diagnose the mt4ctl setup without mutating anything.

Checks the registry, the secrets-file permissions, and — per host — SSH reachability, required remote tools, systemd units, and data directories. Run this when a terminal is unexpectedly unknown or mt4_status looks wrong. Read-only and safe.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.7/5.0

Behavior5/5

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

The description clearly states the tool is read-only and safe, using 'without mutating anything' and 'Read-only and safe'. It also details what it checks (registry, secrets-file, SSH, etc.), providing full behavioral transparency. Since no annotations are provided, the description carries the entire burden and meets it well.

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, front-loaded with the main action ('Diagnose...'), followed by details and usage guidance. Every sentence adds value with no redundancy or fluff. It is highly concise and well-structured.

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 (not shown but present), the description is complete. It covers what the tool checks, that it is read-only, and when to use it. For a diagnostic tool, this suffices for the agent to decide to invoke it.

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 tool has zero parameters, and the input schema is empty. According to guidelines, 0 parameters baseline is 4. The description adds no parameter-specific information but provides context for why no parameters are needed (it diagnoses the existing setup). The 100% schema coverage is satisfied.

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 diagnoses the mt4ctl setup without mutation, and lists specific checks (registry, secrets-file, SSH, systemd units, data directories). It distinguishes from siblings by specifying when to run (when terminal is unknown or mt4_status looks wrong), implying its unique role as a deeper diagnostic tool.

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 explicitly says when to run this tool: when a terminal is unexpectedly 'unknown' or when mt4_status looks wrong. It implies alternatives (mt4_status for normal checks) but does not explicitly state when not to use it or list other alternatives, which would be ideal.

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

mt4_ea_listA

List the expert advisors (strategies) attached to terminals.

For a single terminal, lists every attached EA; for "all", shows the count per terminal. Read-only (parses the terminal's chart files).

Args: terminal: a terminal id, or "all" (default).

ParametersJSON Schema

Name	Required	Description	Default
`terminal`	No		all

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.2/5.0

Behavior4/5

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

With no annotations provided, the description carries the full burden of disclosing behavior. It explicitly states 'Read-only (parses the terminal's chart files)', which signals safety and non-destructiveness. This suffices for a listing tool, though it does not cover failure modes or prerequisites.

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 extremely concise, using two short paragraphs and a single line for the parameter. It front-loads the core purpose in the first sentence. Every sentence adds value, with no redundant or irrelevant information.

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?

The tool has an output schema (not shown), so the description need not explain return values. It covers the two usage modes (single vs all), states read-only behavior, and explains the parameter. While it lacks details on error handling or prerequisites, it is sufficient for a simple list tool with one parameter.

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 0% description coverage, so the description must compensate. It adds meaning by explaining the 'terminal' parameter: 'a terminal id, or 'all' (default)' and clarifies that 'all' yields counts. However, it does not specify the format of a terminal ID or provide examples, leaving some ambiguity.

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 lists expert advisors (strategies) attached to terminals. It distinguishes behavior for a single terminal (list each EA) vs 'all' (shows count per terminal). This differentiates it from sibling tools like mt4_control or mt4_deploy, which perform actions rather than listing.

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 when to use the tool (to see attached EAs) and how the parameter affects output, but does not explicitly state when not to use it or mention alternatives among siblings. The behavior is clear enough for most use cases.

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

mt4_infoA

Report each terminal's build, broker server, and last broker ping.

Read-only (parsed from the terminal's log). Useful to confirm what build and broker a terminal is on and its connection latency.

Args: terminal: a terminal id, or "all" (default).

ParametersJSON Schema

Name	Required	Description	Default
`terminal`	No		all

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.5/5.0

Behavior4/5

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

With no annotations, the description carries the full burden. It declares read-only behavior and that data is parsed from the terminal's log, which is sufficient for the agent to understand its safe, non-destructive nature.

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 (two sentences plus an Args section) and front-loads the main purpose. Every sentence adds value with no redundancy.

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 presence of an output schema, the description need not explain return values. It covers purpose, parameters, and use-case thoroughly. It implies the scope (each terminal) and handles the 'all' case.

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 0%, so the description must compensate. It explains that 'terminal' accepts a terminal id or 'all' (default), adding significant meaning beyond the schema's just type string.

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 'Report' and clearly states the resource: each terminal's build, broker server, and last broker ping. This clearly distinguishes it from sibling tools like mt4_status or mt4_list.

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 explicitly states it is read-only and useful for confirming build, broker, and connection latency. It implies when to use (diagnostic/verification) but does not explicitly list when not to use or alternatives.

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

mt4_listA

List configured terminals with host, account, and environment.

Read-only and offline (no SSH). Use this first to learn which terminal ids exist before calling status/logs/control.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.7/5.0

Behavior4/5

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

No annotations provided, so description carries full burden. Discloses read-only and offline nature, which covers safety. Doesn't mention pagination or completeness, but output schema exists to fill that gap.

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?

Two sentences, no fluff, front-loaded with purpose. Every sentence adds value.

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 zero parameters and presence of output schema, the description is fully complete. Clearly explains what the tool returns and when to use it relative to siblings.

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?

No parameters exist, so schema coverage is 100%. Description appropriately doesn't mention parameters, which is fine. Baseline 4 for zero parameters.

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?

Clearly states 'List configured terminals with host, account, and environment', providing a specific verb and resource. Distinguishes from siblings like mt4_control or mt4_logs by being the list operation.

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 says 'Read-only and offline (no SSH)' and advises 'Use this first to learn which terminal ids exist before calling status/logs/control', giving clear when-to-use and sequencing guidance.

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

mt4_loginA

Perform a one-time headless login so a migrated terminal can auto-reconnect.

Needed when a terminal was copied to a new host: MetaTrader's saved password is machine-bound and must be re-entered once. After this succeeds the unit auto-logins on every restart. Live terminals require confirm=true.

Args: terminal: terminal id. server: broker server name, e.g. "ExampleBroker-Demo". account: login number; defaults to the terminal's configured account. password: explicit password; otherwise resolved from env/secrets file. confirm: must be true to act on a terminal tagged env=live.

ParametersJSON Schema

Name	Required	Description	Default
`terminal`	Yes
`server`	Yes
`account`	No
`password`	No
`confirm`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.6/5.0

Behavior4/5

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

With no annotations provided, the description carries full burden. It discloses that login is one-time, headless, and that auto-reconnect occurs after success. It also notes password resolution behavior. Missing details on side effects or error states but otherwise transparent.

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: a one-sentence intro followed by a bullet-style Args list. It is front-loaded and every sentence adds value without redundancy.

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 5 parameters and an output schema exists, the description covers usage context, prerequisites, and parameter behavior. There is no need to describe return values as output schema handles that.

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

Parameters5/5

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

Schema description coverage is 0%, so the description must add meaning. It explains each parameter: terminal, server (with example), account (defaults to configured), password (resolved from env/secrets), confirm (required for live). This fully compensates for the schema's lack of descriptions.

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's purpose: 'Perform a one-time headless login so a migrated terminal can auto-reconnect.' This specific verb+resource combination distinguishes it from siblings like mt4_adopt or mt4_control, which handle different aspects.

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 explains when the tool is needed (terminal copied to new host, machine-bound password) and notes that live terminals require confirm=true. However, it does not explicitly state when not to use it or compare it to alternatives like mt4_verify.

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

mt4_logsA

Return the tail of a terminal's newest log file.

Args: terminal: terminal id. pattern: optional case-insensitive regex to grep (e.g. "login|error"). lines: number of trailing lines to return (1-1000).

ParametersJSON Schema

Name	Required	Description	Default
`terminal`	Yes
`pattern`	No
`lines`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.5/5.0

Behavior2/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It does not mention the operation's read-only nature, potential side effects (none expected), error conditions (e.g., invalid terminal id), or authentication requirements. The default values for pattern and lines are implied but not explicitly stated as defaults in the description text.

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 extremely concise: one sentence for purpose followed by a clean parameter list. No wasted words, and the critical information is front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With an output schema present but not described, and no annotations, the description adequately covers the basic usage. However, it lacks context about the return format, error handling, or behavioral traits like rate limiting. For a simple file-reading tool, this is adequate but not complete.

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?

Despite 0% schema coverage (meaning the schema lacks descriptions), the description includes a clear list of parameters with useful details: 'terminal id', 'optional case-insensitive regex to grep (e.g. "login|error")', and 'number of trailing lines to return (1-1000)'. This adds significant meaning beyond the schema's type constraints.

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 action ('Return the tail') and the resource ('terminal's newest log file'), making the tool's purpose immediately obvious. It distinguishes itself from sibling tools like mt4_control or mt4_list, which deal with different aspects of MT4 terminals.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

While the description lists parameters, it provides no guidance on when to use this tool versus alternatives such as mt4_info or mt4_status. There is no mention of prerequisites (e.g., terminal must be running) or scenarios where pattern or lines parameters are particularly useful.

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

mt4_screenshotA

Capture a screenshot of a terminal's window (PNG).

Useful to visually confirm the chart, the AutoTrading state, and the EA smiley. On shared-display hosts the target window is raised first.

Args: terminal: terminal id.

ParametersJSON Schema

Name	Required	Description	Default
`terminal`	Yes

TDQS

A3.8/5.0

Behavior3/5

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

No annotations, so description carries burden. Discloses PNG format and window-raising on shared-display hosts. Does not specify exact capture area or blocking behavior. Adequate but not detailed.

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?

Very concise, four sentences, front-loaded main purpose. No wasted words. Efficient.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Covers purpose, use cases, and one behavior note. Missing return value description (format of screenshot output) despite no output schema. Incomplete for a new user.

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

Parameters2/5

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

Schema coverage is 0%, description adds only 'terminal: terminal id.' This provides minimal meaning beyond schema; lacks format or how to obtain the id. Insufficient compensation.

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?

Clearly states the action and resource: 'Capture a screenshot of a terminal's window (PNG).' Also describes use cases (confirm chart, state, EA smiley). Distinct from siblings.

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?

Provides context for when to use ('visually confirm...') and a behavior note about shared-display hosts. Does not explicitly mention when not to use or alternatives, but adequate for a straightforward tool.

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

mt4_statusA

Report health of one terminal or all of them.

Queries hosts concurrently and shows, per terminal: systemd service state, broker connection (per-terminal, via socket attribution), and how long since the log was last written. CONN=up plus SERVICE=active means healthy.

Args: terminal: a terminal id, or "all" (default).

ParametersJSON Schema

Name	Required	Description	Default
`terminal`	No		all

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.3/5.0

Behavior4/5

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

The description discloses key behavioral traits: concurrent queries, specific metrics shown (systemd state, broker connection, log age), and interpretation of healthy state. Since no annotations exist, description carries full burden and suffices. Minor gap: no mention of potential side effects or auth requirements, but none expected for a read-only health check.

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 efficient: two short paragraphs, front-loaded with purpose, and every sentence adds value (health metrics, concurrency, interpretation). No fluff.

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?

For a simple health check tool with one optional parameter and an output schema (assumed documented), the description covers input behavior, concurrency, metrics, and output interpretation. No missing details for an agent to use it 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?

Schema coverage is 0%, so description must compensate. The description explains the 'terminal' parameter as 'a terminal id, or "all" (default)', adding meaning beyond the schema's type and default. It is concise but sufficient.

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 reports health of one terminal or all terminals, using a specific verb ('report health') and resource ('terminal'). It distinguishes from siblings like mt4_doctor or mt4_info by focusing on health metrics (systemd state, broker connection, log age).

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 health checking but does not explicitly say when to use this tool vs. alternatives like mt4_doctor or mt4_info. It provides no exclusions or scenarios where other tools would be preferred.

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

mt4_verifyA

Poll a terminal until it is healthy (service active + broker connected) or times out.

Use after any restart to wait out the broker reconnect instead of guessing: instead of one snapshot it polls and reports the terminal's state at timeout, so a real failure is distinguishable from normal startup timing. Read-only.

Args: terminal: terminal id. timeout: seconds to poll before reporting (default ~120).

ParametersJSON Schema

Name	Required	Description	Default
`terminal`	Yes
`timeout`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.7/5.0

Behavior4/5

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

No annotations provided, so description carries full burden. It discloses polling behavior, timeout, read-only nature, and state reporting. Missing details like polling frequency or rate limits, but sufficient.

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?

Concise (~100 words), well-structured with purpose first, then usage guidance, then parameter list. No wasted words.

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?

Covers main aspects: action, usage, parameters, behavioral constraints. Output schema exists so return format is likely covered. Slightly incomplete on timeout behavior details, but adequate.

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

Parameters5/5

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

With 0% schema coverage, the description compensates by explaining both 'terminal' as terminal id and 'timeout' as seconds to poll with default ~120, adding meaning beyond raw schema.

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 specific verb 'Poll' and resource 'terminal until healthy or timeout', and distinguishes from siblings like mt4_status (snapshot) and mt4_doctor (diagnosis).

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 states 'Use after any restart' and contrasts with snapshot tools, making intended usage and alternatives clear. Also notes read-only.

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

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.1/5.0

Disambiguation5/5

Each tool targets a distinct operation on MT4 terminals: adopt, deploy, control, status, logs, screenshot, etc. There is no functional overlap; even similar tools like mt4_status and mt4_verify have different purposes (snapshot vs. polling).

Naming Consistency4/5

All tools follow an 'mt4_' prefix with verb or verb_noun names (e.g., mt4_deploy, mt4_ea_list). While most are verb_noun, a few like mt4_autotrading and mt4_screenshot are noun phrases, but the pattern is consistent and predictable.

Tool Count5/5

13 tools cover the core lifecycle of MT4 terminal management: adoption, deployment, control, monitoring, diagnostics, and visual feedback. This is a well-scoped count that avoids bloat while providing comprehensive functionality.

Completeness4/5

The toolset covers CRUD-like operations (deploy, control, status, logs) and diagnostics, but lacks explicit tools for deleting/removing terminals or managing terminal-level configuration beyond login and auto-trading. Minor gap, but core workflows are supported.

Maintenance

ActivityInactive

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

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
Os Automation Mcp C
io.github.varvararatta
MCP server for OS Automation
OS Automation Command Line
2
remote-mcp-serverOAuth
io.coupler
Coupler.io remote MCP server
Data Platforms App Automation Developer Tools
2
registry A
io.github.urnetwork
Cloud-hosted MCP server for URnetwork VPN and Proxy
Cloud Platforms Security App Automation
2

Related MCP Servers

acp-mcp
Shell Access Command Line
prmichaelsen
A
license
Not graded
quality
D
maintenance
MCP server for remote machine operations via SSH, providing a single tool to execute any shell command on remote machines with real-time progress streaming.
Updated 6 months ago (2026-02-24 01:01 UTC)
22
MIT
mt5ctl
Finance Shell Access
Chust-dev
A
license
Not graded
quality
B
maintenance
An MCP server for operating headless MetaTrader 5 terminals — over SSH, from your agent.
Updated 2 months ago (2026-07-06 01:41 UTC)
MIT
mt4-mcp
Finance Autonomous Agents
mergeos-bounties
A
license
Not graded
quality
A
maintenance
MCP server for AI agents to inspect and trade against a MetaTrader 4 terminal, with an offline mock mode for CI and demos.
Updated a month ago (2026-07-19 12:50 UTC)
2
MIT
ssh-mcp-server
wijzeu
A
license
Not graded
quality
C
maintenance
SSH-based MCP server that enables remote execution of SSH commands, file transfers, and secure server management via the MCP protocol.
Updated a month ago (2026-07-21 20:21 UTC)
ISC

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/ak40u/mt4ctl'

If you have feedback or need assistance with the MCP directory API, please join our Discord server