Skip to main content
Glama
PHUICMT

mcp-mt5

by PHUICMT
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

patch_tester_ini

Destructive

Update tester.ini settings in place by mapping Section.Key to values, preserving file encoding and existing lines. Add missing sections and keys for MT5 backtesting configuration.

Instructions

Set keys in a tester.ini in place, keeping the file's encoding and other lines.

updates maps "Section.Key" to a value, e.g. {"Tester.Symbol": "EURUSD", "Tester.FromDate": "2025.01.01", "TesterInputs.RiskPct": "1.5"}. Missing sections/keys are added. Run validate_tester_ini afterwards; always set Deposit, Currency, Leverage, Model, Optimization, Visual, UseLocal/UseRemote/UseCloud and Report explicitly so a run does not inherit the machine's last UI state.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
configYesAbsolute path to the tester.ini file.
updatesYesMapping of "Section.Key" to new value, e.g. {"Tester.Symbol": "EURUSD"}.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changedv0.5.0
    • addedInput schema / properties / config / description
      Added value: +"Absolute path to the tester.ini file."
    • addedInput schema / properties / updates / description
      Added value: +"Mapping of \"Section.Key\" to new value, e.g. {\"Tester.Symbol\": \"EURUSD\"}."
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
+  "additionalProperties": true,
+  "title": "patch_tester_iniDictOutput",
+  "type": "object"
+}
  2. First observedv0.4.1

TDQS

A4.5/5.0
Behavior4/5

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

Beyond destructiveHint=true, the description discloses that it preserves the file's encoding and other lines, adds missing sections/keys, and modifies in place. This tells the agent what side effects to expect and what is preserved, which is exactly the contextual value annotations don't carry.

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 first sentence is a clear, informative one-liner; the second block gives concrete examples and critical usage caveats with no filler. Every sentence earns its place.

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 mutating config tool, the description covers what is preserved, how updates are applied, required follow-up validation, and mandatory keys to avoid stale UI state. Combined with the output schema and annotations, nothing essential is missing for correct invocation.

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?

Both params are already described in schema (100% coverage), and the description adds behavior for the updates object: missing sections/keys are added, with a concrete mapping example. It reinforces the dotted Section.Key format and lists critical keys that should be set, going beyond schema basics.

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 states a specific action and target ('Set keys in a tester.ini in place'), with 'in place' clarifying mutation scope. It is clearly distinct from sibling tools like validate_tester_ini, which checks the file, and run_backtest, which consumes it.

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?

It gives practical invocation guidance: run validate_tester_ini afterwards and always set a named list of keys so a run does not inherit UI state. It doesn't express when-not-to-use or name an alternative, but the guidance is explicit enough for correct use.

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

Deploy Server

Other Tools