mt4ctl

by ak40u

Overview Schema Related Servers Score Discussions

Python

Remote

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.7.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.
Average 4.4/5 across 13 of 13 tools scored. Lowest: 3.5/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- Last stable release on May 24, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![mt4ctl MCP server](https://glama.ai/mcp/servers/ak40u/mt4ctl/badges/card.svg)](https://glama.ai/mcp/servers/ak40u/mt4ctl)

Score Badge

Copy to your README.md:

[![mt4ctl MCP server](https://glama.ai/mcp/servers/ak40u/mt4ctl/badges/score.svg)](https://glama.ai/mcp/servers/ak40u/mt4ctl)

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