New MetaTrader 5 Platform Build 6230: Expanded AI Capabilities
Dear MetaQuotes Team,
I would like to propose a small but, in my opinion, high-value extension to ENUM_STATISTICS and TesterStatistics() in MetaTrader 5.
The proposed additions are:
STAT_DAYS STAT_CAGR STAT_SORTINO_RATIO STAT_MAR_RATIO STAT_CALMAR_RATIO STAT_TRADES_PER_YEAR STAT_PROFIT_PER_YEAR
The exact names can of course be adapted to MetaQuotes naming conventions.
The main motivation is simple: these statistics are frequently needed when developing custom optimization criteria in OnTester() , yet developers currently have to reconstruct them manually even though the Strategy Tester already possesses almost all of the required underlying information.
This proposal would therefore not require a new API design. It would extend the existing TesterStatistics() mechanism with a small set of derived statistics.
From an implementation perspective, five of the seven proposed statistics appear to be simple O(1) calculations based entirely on values the tester already calculates. The other two could potentially reuse the equity/return processing already required by existing statistics such as STAT_SHARPE_RATIO and drawdown.
I have included suggested definitions, edge cases and implementation notes below to make the proposal as concrete as possible.
1. STAT_DAYS
Purpose
Expose the effective duration of the Strategy Tester run.
This is a basic input required to normalize almost every performance statistic over time.
Suggested definition
STAT_DAYS = (test_end_time - test_start_time) / 86400.0
The return value should preferably be a double , allowing partial days.
Example:
Test start: 2020-01-01 00:00 Test end: 2025-01-01 00:00 STAT_DAYS ≈ 1827
The statistic should refer to the tested time interval, not the interval between the first and last trade.
This distinction is important because a strategy that trades only occasionally still needs to be evaluated over the complete period during which it was exposed to the market.
Implementation footprint
Required information:
test_start_time test_end_time
Calculation:
days = double(end - start) / 86400.0;
Complexity:
Time: O(1) Memory: O(1)
No equity history, trade history, or additional sampling is required.
2. STAT_CAGR
Purpose
Expose compounded annual growth directly through TesterStatistics() .
Net profit alone cannot correctly compare strategies tested over different periods.
For example, a strategy returning 100% over two years and one returning 100% over ten years should clearly not have the same time-normalized performance.
Suggested definition
Years = STAT_DAYS / 365.2425
Then:
CAGR = (FinalValue / InitialValue)^(1 / Years) - 1
Equivalent implementation:
cagr = MathPow(final_value / initial_value, 365.2425 / days) - 1.0;
For example:
Initial value = 100,000 Final value = 161,051 Period = 5 years CAGR = 10%
Important distinction
STAT_CAGR should represent compounded percentage growth.
It is therefore fundamentally different from the proposed STAT_PROFIT_PER_YEAR , which measures average absolute monetary profit per year.
For example:
CAGR -> capital efficiency Profit per year -> absolute monetary output
Both are useful, but they answer different questions.
Cash-flow consideration
If external deposits or withdrawals can occur during a Strategy Tester run, MetaQuotes could either:
-
define CAGR only for tests without external cash flows;
-
adjust the final value for external cash flows; or
-
use another internally consistent convention.
The important point would be documenting the selected convention.
For the normal Strategy Tester case without external cash flows, the calculation is straightforward.
Edge cases
Suggested documented behavior should cover:
STAT_DAYS <= 0 InitialValue <= 0 FinalValue <= 0
The exact sentinel behavior can follow existing MetaTrader conventions.
Implementation footprint
Required information:
initial account value final account value test duration
Complexity:
Time: O(1) Memory: O(1)
Only one power operation and a few arithmetic operations are required.
3. STAT_TRADES_PER_YEAR
Purpose
Normalize the number of trades by the duration of the test.
STAT_TRADES alone is not sufficient when comparing optimization passes or reports covering different periods.
Suggested definition
Years = STAT_DAYS / 365.2425
Then:
STAT_TRADES_PER_YEAR = STAT_TRADES / Years
Equivalent:
trades_per_year = TesterStatistics(STAT_TRADES) * 365.2425 / days;
Example:
Backtest duration = 5 years Trades = 1,500 Trades/year = 300
Why this matters
Trading frequency affects much more than presentation.
It directly influences:
-
statistical significance;
-
exposure to transaction costs;
-
spread sensitivity;
-
commission sensitivity;
-
slippage sensitivity;
-
execution requirements;
-
capacity and scalability;
-
broker dependency;
-
reliability of performance estimates.
It is also extremely useful in custom optimization.
For example:
if(TesterStatistics(STAT_TRADES_PER_YEAR) < 100.0) return 0.0;
A developer could immediately reject parameter combinations that produce attractive statistics from an insufficient number of observations.
Implementation footprint
Required information:
STAT_TRADES STAT_DAYS
Complexity:
Time: O(1) Memory: O(1)
It is only one normalization operation.
4. STAT_PROFIT_PER_YEAR
Purpose
Expose average absolute net profit normalized to one year.
Suggested definition
Years = STAT_DAYS / 365.2425
Then:
STAT_PROFIT_PER_YEAR = STAT_PROFIT / Years
Equivalent:
profit_per_year = TesterStatistics(STAT_PROFIT) * 365.2425 / days;
Example:
Net profit = 50,000 Backtest duration = 5 years Profit/year = 10,000
The result would naturally be expressed in the deposit currency, just like STAT_PROFIT .
Why it should not be confused with CAGR
Consider two systems using different starting balances.
Absolute annualized profit can be important when evaluating actual economic output, while CAGR evaluates the efficiency of the capital employed.
Therefore:
STAT_PROFIT -> total absolute result STAT_PROFIT_PER_YEAR -> time-normalized absolute result STAT_CAGR -> compounded percentage result
These three values are complementary rather than redundant.
Implementation footprint
Required information:
STAT_PROFIT STAT_DAYS
Complexity:
Time: O(1) Memory: O(1)
Again, only one normalization operation is required.
5. STAT_MAR_RATIO
Purpose
Provide an annualized return-to-drawdown measure over the complete testing history.
To avoid ambiguity, by MAR Ratio here I mean the commonly used Managed Account Reports ratio, not the Minimum Acceptable Return parameter sometimes denoted as MAR in the Sortino Ratio.
Suggested definition
MAR Ratio = CAGR / Maximum Drawdown Fraction
Using maximum relative equity drawdown:
STAT_MAR_RATIO = STAT_CAGR / (STAT_EQUITY_DDREL_PERCENT / 100.0)
Example:
CAGR = 20% Maximum equity drawdown = 10% MAR Ratio = 0.20 / 0.10 = 2.0
Why equity drawdown
For systematic strategy evaluation, maximum relative equity drawdown may be preferable to balance drawdown because equity reflects mark-to-market losses while positions remain open.
However, MetaQuotes could naturally choose the drawdown definition that best matches the existing Strategy Tester conventions.
The important part would be documenting which drawdown statistic is used.
Implementation footprint
Required information:
STAT_CAGR maximum relative drawdown
Complexity:
Time: O(1) Memory: O(1)
Once CAGR and maximum drawdown are known, MAR Ratio is essentially one division.
Zero-drawdown edge case
If:
MaximumDrawdown = 0
MetaTrader could follow a convention similar to other ratio statistics with a zero denominator.
For example, DBL_MAX could represent an unbounded positive ratio when appropriate, or another existing platform convention could be used.
The exact convention matters less than documenting it consistently.
6. STAT_SORTINO_RATIO
Purpose
Complement the existing STAT_SHARPE_RATIO with a downside-risk-adjusted performance statistic.
Sharpe Ratio penalizes both positive and negative volatility.
Sortino Ratio penalizes only harmful downside deviation.
This distinction is particularly useful for asymmetric strategies, trend-following systems, option-like payoff profiles, and other systems where positive volatility should not necessarily be treated as risk.
Suggested implementation
The lowest-complexity and most internally consistent implementation would be to reuse the same return series and sampling convention already used internally for STAT_SHARPE_RATIO .
If MetaTrader internally generates periodic equity returns:
r1, r2, ..., rn
the Sortino calculation could reuse those values.
With Minimum Acceptable Return:
MAR = 0
define downside deviation as:
DownsideDeviation = sqrt( sum(min(ri - MAR, 0)^2) / N )
Then:
Sortino = (MeanReturn - MAR) / DownsideDeviation
If annualization is performed:
Annualized Sortino = sqrt(P) * (MeanReturn - MAR) / DownsideDeviation
where P is the number of return periods per year under the same convention already used by MetaTrader for Sharpe.
Recommended implementation principle
Rather than introducing another sampling convention, I would suggest:
Use the exact same return observations used by STAT_SHARPE_RATIO.
This has several advantages:
-
Sharpe and Sortino remain directly comparable;
-
no second equity sampling mechanism is needed;
-
no duplicated data collection is required;
-
existing tester behavior is preserved;
-
implementation complexity is reduced;
-
documentation becomes simpler.
Conceptually, if Sharpe processing already resembles:
for(each return r) { sum += r; sum_squared += r*r; }
Sortino could be accumulated in the same pass:
for(each return r)
{
sum += r;
if(r < MAR)
downside_squared += (r-MAR)*(r-MAR);
} No additional traversal would necessarily be required.
Complexity
Worst-case conceptual complexity:
Time: O(N) Memory: O(1)
where N is the number of return observations.
However, if calculated together with Sharpe, the incremental asymptotic complexity is effectively unchanged because the same return stream can be processed in the same pass.
The additional work per return is only:
one comparison and, for downside observations, a subtraction/multiplication/addition
This is likely negligible compared with the cost of running the actual Strategy Tester simulation.
Edge cases
The implementation should document behavior when:
N is insufficient DownsideDeviation = 0
This could follow the existing behavior used for insufficient Sharpe observations or zero denominators.
7. STAT_CALMAR_RATIO
Purpose
Provide a standardized recent return-to-drawdown measure.
To distinguish it meaningfully from the full-history MAR Ratio, Calmar could use its conventional trailing 36-month window.
Suggested definition
Calmar Ratio = CAGR over trailing 36 months / Maximum drawdown over trailing 36 months
Therefore:
STAT_CALMAR_RATIO = CAGR_36M / MaxEquityDrawdown_36M
Example:
Trailing 36-month CAGR = 18% Trailing max drawdown = 9% Calmar Ratio = 2.0
This gives a useful distinction:
STAT_MAR_RATIO -> complete backtest history STAT_CALMAR_RATIO -> trailing 36-month history
The MAR Ratio therefore measures the complete historical record, while Calmar gives more weight to the recent behavior of the system.
Tests shorter than 36 months
MetaQuotes could choose one of two reasonable conventions:
A. Return an unavailable/undefined value until 36 months exist. B. Use the complete available period when the test is shorter than 36 months.
I would personally prefer a clearly documented convention over any particular choice.
Implementation footprint
Unlike the five O(1) metrics above, Calmar requires information about a trailing interval.
However, the Strategy Tester already maintains equity information for reporting and drawdown calculation.
A simple post-test implementation could conceptually be:
window_start = test_end - 36_months; start_equity = equity_at_or_after(window_start); end_equity = final_equity; cagr_36m = annualized_growth(start_equity, end_equity, window_duration); max_dd_36m = calculate_max_drawdown(window_start, test_end); calmar = cagr_36m / max_dd_36m;
Complexity for a final scan:
Time: O(N36)
Memory: potentially O(1) additional,
if equity history already exists where N36 is the number of observations in the trailing 36-month interval.
There may therefore be little or no additional historical-data storage required if the tester already retains the data needed to produce the final equity graph and report.
From an external API perspective, the proposed statistics naturally split into two groups.
Group A: extremely low implementation footprint
STAT_DAYS STAT_TRADES_PER_YEAR STAT_PROFIT_PER_YEAR STAT_CAGR STAT_MAR_RATIO
These require no new time series and are derivable from values the Strategy Tester already necessarily knows.
Conceptually:
STAT_DAYS
= time difference
STAT_TRADES_PER_YEAR
= STAT_TRADES / years
STAT_PROFIT_PER_YEAR
= STAT_PROFIT / years
STAT_CAGR
= annualization of initial/final account value
STAT_MAR_RATIO
= STAT_CAGR / maximum drawdown All five are:
Time complexity: O(1) Additional memory: O(1)
Group B: low implementation footprint using existing series
STAT_SORTINO_RATIO STAT_CALMAR_RATIO
These require periodic return/equity information.
However:
STAT_SORTINO_RATIO
can potentially reuse the exact return stream already processed for STAT_SHARPE_RATIO .
And:
STAT_CALMAR_RATIO
can potentially reuse equity history already required for the Strategy Tester report and drawdown analysis.
Therefore these metrics do not appear to require a fundamentally new data collection system.
If adding all statistics in one release is undesirable, the request could also be implemented incrementally.
Phase 1
Add the statistics that only require scalar values:
STAT_DAYS STAT_CAGR STAT_MAR_RATIO STAT_TRADES_PER_YEAR STAT_PROFIT_PER_YEAR
These appear to have minimal computational and architectural impact.
Phase 2
Add:
STAT_SORTINO_RATIO STAT_CALMAR_RATIO
which make use of periodic equity/return information.
This would allow MetaQuotes to deliver most of the benefit even if the two history-dependent statistics require more review.
The proposal requires no change to the signature of TesterStatistics() :
double TesterStatistics( ENUM_STATISTICS statistic_id );
It only requires additional ENUM_STATISTICS values.
For example:
double days = TesterStatistics(STAT_DAYS); double cagr = TesterStatistics(STAT_CAGR); double sortino = TesterStatistics(STAT_SORTINO_RATIO); double mar = TesterStatistics(STAT_MAR_RATIO); double calmar = TesterStatistics(STAT_CALMAR_RATIO); double trades_per_year = TesterStatistics(STAT_TRADES_PER_YEAR); double profit_per_year = TesterStatistics(STAT_PROFIT_PER_YEAR);
If the new enum values are appended without changing existing numeric values, this should also minimize backward-compatibility concerns for existing MQL5 programs.
The feature could initially be API-only if changing the graphical Strategy Tester report would increase implementation scope.
In other words, exposing the values through TesterStatistics() alone would already provide most of the value to developers.
A UI/report column could always be added separately later.
The main benefit is not simply displaying the values.
It is making them available during optimization.
For example:
double OnTester() { const double days = TesterStatistics(STAT_DAYS); const double cagr = TesterStatistics(STAT_CAGR); const double sortino = TesterStatistics(STAT_SORTINO_RATIO); const double mar = TesterStatistics(STAT_MAR_RATIO); const double calmar = TesterStatistics(STAT_CALMAR_RATIO); const double trades_per_year = TesterStatistics(STAT_TRADES_PER_YEAR); const double profit_per_year = TesterStatistics(STAT_PROFIT_PER_YEAR); // Require sufficient historical coverage if(days < 5.0 * 365.2425) return 0.0; // Reject statistically weak parameter sets if(trades_per_year < 100.0) return 0.0; // Example custom fitness function return 0.30 * mar + 0.30 * sortino + 0.20 * calmar + 0.20 * cagr; }
This is exactly the type of work for which OnTester() and TesterStatistics() are useful.
Technically, developers can recreate some of these statistics themselves.
However, that is not a strong reason to omit them from TesterStatistics() .
The same argument could be made for many statistics already exposed by the API.
Native implementation offers several advantages.
1. Standardization
Without a native definition, different developers implement:
different annualization factors different equity sampling different drawdown definitions different Sortino denominators different handling of zero denominators different handling of short test periods
Two EAs can therefore report the same named statistic but calculate different numbers.
A documented MetaTrader implementation would provide one canonical reference.
2. Less duplicated code
At present, each EA that requires these values must independently implement the same infrastructure.
This increases code size and maintenance burden without adding strategy-specific value.
3. Reduced risk of errors
Annualization and risk metrics are simple conceptually, but small differences in implementation can produce materially different optimization results.
Centralizing them inside the tester would eliminate an unnecessary source of user-side errors.
4. Better optimization performance
In large optimizations, the same user-side calculations may be repeated thousands, hundreds of thousands, or millions of times.
Even if each calculation is individually inexpensive, duplicating return/equity processing in every Expert Advisor is unnecessary when the tester already processes much of the same information.
Native calculations can also reuse intermediate values generated by the tester.
5. Cleaner Expert Advisors
Strategy code should ideally contain strategy logic.
It should not require a separate statistics subsystem merely to access widely used performance measures.
6. Reproducibility
A standardized implementation makes optimization results easier to compare between:
different Expert Advisors different developers different optimization runs different machines different MetaTrader installations
assuming the same tester version and inputs.
Most of the proposed statistics can be built from a very small dependency graph:
TEST START ───────┐
├──> STAT_DAYS
TEST END ─────────┘
│
├──> STAT_TRADES_PER_YEAR
STAT_TRADES ────────────┘
STAT_PROFIT ────────────┐
├──> STAT_PROFIT_PER_YEAR
STAT_DAYS ──────────────┘
INITIAL VALUE ──────────┐
FINAL VALUE ────────────┼──> STAT_CAGR
STAT_DAYS ──────────────┘
│
├──> STAT_MAR_RATIO
MAX EQUITY DRAWDOWN ──────────┘
EXISTING RETURN STREAM
USED FOR SHARPE
│
└──> downside deviation
│
└──> STAT_SORTINO_RATIO
TRAILING EQUITY HISTORY
│
├──> trailing CAGR
└──> trailing max drawdown
│
└──> STAT_CALMAR_RATIO This is why the requested functionality appears to have a favorable implementation-cost-to-user-value ratio.
Five metrics are simple scalar transformations.
Sortino can potentially share the Sharpe return-processing path.
Calmar can potentially share the existing equity/drawdown data path.
A few deterministic tests would be enough to validate most of the implementation.
Duration
Period = exactly 365.2425 days Expected: STAT_DAYS = 365.2425
Trades per year
STAT_DAYS = 5 * 365.2425 STAT_TRADES = 1,500 Expected: STAT_TRADES_PER_YEAR = 300
Profit per year
STAT_DAYS = 5 * 365.2425 STAT_PROFIT = 50,000 Expected: STAT_PROFIT_PER_YEAR = 10,000
CAGR
Initial = 100,000 Final = 161,051 Period = 5 years Expected: STAT_CAGR ≈ 0.10
MAR
STAT_CAGR = 0.20 STAT_EQUITY_DDREL_PERCENT = 10 Expected: STAT_MAR_RATIO = 2.0
Sortino
A deterministic synthetic equity-return series could be passed through both the reference implementation and the tester implementation.
The important validation requirement would be that the return sampling convention is identical to the one documented for the tester.
Calmar
A synthetic 36-month equity history with known annualized growth and known maximum drawdown could similarly provide an exact regression test.
For consistency and predictability, it would be useful to document behavior for:
zero-length test very short test no trades zero profit negative CAGR zero drawdown zero downside deviation insufficient Sortino observations test shorter than the Calmar window zero or negative ending account value external deposits/withdrawals
The exact choices do not need to match the definitions suggested here.
A documented and stable convention is more important than selecting any one convention.
MetaTrader 5 already provides a very capable Strategy Tester and optimization framework.
The proposed additions would strengthen an area where relatively little platform-side work can remove a disproportionate amount of duplicated user-side work.
The benefit is particularly significant for quantitative developers performing:
-
large parameter optimizations;
-
walk-forward analysis;
-
robustness testing;
-
multi-strategy comparison;
-
portfolio research;
-
automated model selection;
-
custom genetic optimization;
-
risk-adjusted ranking of parameter sets.
Metrics such as raw profit and total trades are useful, but they are not time-normalized.
Sharpe is valuable, but it is only one view of risk-adjusted performance.
Adding duration, annualized activity, annualized profitability, CAGR, Sortino, MAR and Calmar would provide a much more complete set of primitives for professional strategy evaluation.
Most importantly, this proposal does not require replacing or redesigning anything.
It only extends an already successful interface:
TesterStatistics()
with statistics naturally derived from data the Strategy Tester already processes.
Even implementing only the five O(1) statistics first would already be a meaningful improvement:
STAT_DAYS STAT_CAGR STAT_MAR_RATIO STAT_TRADES_PER_YEAR STAT_PROFIT_PER_YEAR
Adding Sortino and Calmar afterward would complete the set.
I believe this would be a relatively small extension from the platform perspective, while providing significant value to a large class of developers using MetaTrader 5 for serious quantitative research and optimization.
Thank you for considering this proposal and for continuing to improve the MetaTrader 5 Strategy Tester and MQL5 API.
Best regards,
Gio
I would like to propose a small but, in my opinion, high-value extension to ENUM_STATISTICS and TesterStatistics() in MetaTrader 5.
Note that the subtitle of this very thread is "Expanded AI Capabilities." Just prompt your highly detailed description into the MT5-integrated AI Assistant, and re-prompt as necessary. I'm speaking from my own experience because I have used the AI Assistant to create a different kind of custom backtest report.
Thanks Ryan. I agree that the AI Assistant can help generate MQL5 code for calculating custom statistics or producing a custom report.
However, that is not really the problem I am trying to solve here.
The request is specifically about extending the native TesterStatistics() API, not about whether these statistics can be implemented manually.
There is an important difference.
An AI Assistant can generate code such as:
double cagr = CalculateCAGR(...); double sortino = CalculateSortino(...);
but it cannot make this possible:
double cagr = TesterStatistics(STAT_CAGR); double sortino = TesterStatistics(STAT_SORTINO_RATIO); double mar = TesterStatistics(STAT_MAR_RATIO);
unless MetaQuotes exposes those statistics natively.
And this matters particularly inside OnTester() during optimization.
OnTester() is not only useful for producing a report. It is also used to return the custom fitness value used by the Strategy Tester during optimization.
For example, I would like to be able to write something as simple as:
double OnTester()
{ double cagr = TesterStatistics(STAT_CAGR);
double sortino = TesterStatistics(STAT_SORTINO_RATIO);
double mar = TesterStatistics(STAT_MAR_RATIO);
double trades_year = TesterStatistics(STAT_TRADES_PER_YEAR);
if(trades_year < 100.0) return 0.0; return 0.5 * mar + 0.5 * sortino;
}
The issue is therefore not whether a developer, or an AI, is capable of reproducing the formulas.
Almost every statistic currently exposed by TesterStatistics() could theoretically be calculated manually as well.
For example, Profit Factor can be reconstructed from gross profit and gross loss, Recovery Factor can be calculated from profit and drawdown, and many other statistics could be recomputed by user code.
Yet they are exposed by TesterStatistics() because having them available natively has real value.
The same reasoning applies here.
There are several advantages to native statistics:
1. Standardization
If every developer implements CAGR, Sortino, MAR or Calmar independently, implementations will inevitably differ in:
-
return sampling frequency;
-
annualization factor;
-
drawdown definition;
-
treatment of zero denominators;
-
treatment of short testing periods;
-
treatment of incomplete periods;
-
equity vs. balance usage.
A native implementation gives the MQL5 ecosystem one documented definition.
2. Access to internal tester data
Some statistics cannot be reconstructed efficiently from the scalar values currently exposed by TesterStatistics().
For example, Sortino requires a periodic return series, while a proper trailing Calmar calculation requires historical equity and drawdown information over the selected window.
The Strategy Tester already internally processes equity, drawdown and return information.
User code may therefore have to reconstruct and maintain data that the tester already has.
An AI-generated implementation does not remove that duplication. It only writes the duplicated implementation for us.
3. Optimization efficiency
This becomes more relevant when running large optimizations.
If an optimization performs hundreds of thousands or millions of passes, having every EA independently reconstruct statistics that could be calculated by the native tester engine is unnecessary overhead.
For some of the requested values, the additional native calculation is extremely small:
STAT_DAYS = test duration STAT_TRADES_PER_YEAR = trades / years STAT_PROFIT_PER_YEAR = profit / years STAT_CAGR = annualized initial/final value STAT_MAR_RATIO = CAGR / maximum drawdown
These are essentially O(1) derived statistics based on information already available to the Strategy Tester.
4. Cleaner Expert Advisors
Strategy code should ideally contain strategy logic and optimization logic, rather than repeatedly implementing a statistics library.
The fact that AI can generate boilerplate does not make the boilerplate desirable.
5. Reproducibility
If MetaTrader defines these statistics, two developers using:
TesterStatistics(STAT_SORTINO_RATIO)
will get the same value under the same test conditions.
If both ask an AI to implement Sortino, they may receive different formulas and different results while both functions are called "Sortino".
That is precisely the kind of ambiguity a platform API can eliminate.
6. The required API extension is small
My proposal does not require redesigning the Strategy Tester.
The existing interface:
double TesterStatistics( ENUM_STATISTICS statistic_id );
does not need to change at all.
Only additional ENUM_STATISTICS values are required.
For example:
STAT_DAYS STAT_CAGR STAT_SORTINO_RATIO STAT_MAR_RATIO STAT_CALMAR_RATIO STAT_TRADES_PER_YEAR STAT_PROFIT_PER_YEAR
Five of those can be derived directly from scalar information that the tester already has.
Sortino could potentially reuse the same return-processing pipeline used for Sharpe Ratio.
Calmar could potentially reuse existing equity/drawdown history.
So I completely agree that the AI Assistant is useful for creating custom reports and custom calculations.
But this feature request addresses a different layer of the platform.
AI can help developers work around a missing API feature.
It cannot replace the API feature itself.
In fact, I would argue that good AI integration makes a clean and complete underlying API even more valuable: the AI can then generate much simpler and more reliable code using standardized platform primitives instead of generating a different reimplementation of the same financial statistics in every Expert Advisor.
In build 6230 the release notes say that the AI Assistant "can retrieve an Expert Advisor's input parameters and prepare them for a Strategy Tester run". I am testing this through the built-in MCP server and found that it works for every Expert Advisor except products purchased from the Market.
I know that this may be a slight case of apples to oranges but in/with Build 6244, MQL5.community, MQL5 Lite, All requests (I don't do this in my live terminal), and MCP enabled, the AI Assistant worked hard to retrieve the input parameters of a Market product and succeeded via set file and Market listing analysis:
Prompt: Analyze the input parameters of my [Market product redacted] and report those parameters back to me.
Response: Done.
Note first: [Market product redacted] is an installed MetaTrader Market product (compiled [Market product redacted].ex5 , no .mq5 source), so its input descriptors cannot be reflected. get_expert_advisor_parameters fails on every Market EA in this terminal ( [Market product redacted].ex5 , [Market product redacted].ex5 ), and the name table inside the .ex5 is stored obfuscated (not plain text). So I reconstructed the inputs from two consistent sources:
- The saved parameter set: MQL5\Profiles\Templates\[Market product redacted].set
- The product documentation (labels), product id [Market product redacted]
Both describe the same 12 settings, in the same order, which is strong evidence this is the complete input list...
[input parameters followed.]
User code may therefore have to reconstruct and maintain data that the tester already has.
There is data that the Tester has, versus data that the Tester reports.
Not a custom test reporting EA, but an MQL5 service that runs at the terminal level.
If a journal, log, or custom file is generated in MT5, the AI Assistant can access it.
Hello,
since about 18:50 (UTC+3) today, October 10, 2026, the AI Assistant in MetaTrader 5 no longer works for me. I am using the MQL5 Lite model. My terminal is FxPro MT5, version 5.00 build 6252 (10 Oct 2026).
The assistant alternates between these two errors:
- “Request failed: Resource not found (404) at https://api4.inferdeck.net/v1/chat/completions: The request is invalid.”
- “Network error: Could not connect to api4.inferdeck.net – check your network connection and try again.”
What I already tried:
- Restarted MetaTrader 5
- Opened a new chat
- Checked my internet connection, which works normally
- Opened https://api4.inferdeck.net in my browser, and the page loads fine
So the server seems reachable, but the chat endpoint fails. Is this a known issue with the new build or the server, and is anyone else affected?
Thank you.
Forum on trading, automated trading systems, and trading strategy testing
New MetaTrader 5 Platform Build 6230: More AI Capabilities
Renat Fatkhullin , 2026.10.10 15:34
We migrated the cluster across all five regions, and it wasn't as smooth as it seems.
When we're all done, I'll write. In the meantime, there will be interruptions for a few hours.
- Free trading apps
- Over 8,000 signals for copying
- Economic news for exploring financial markets
You agree to website policy and terms of use
On Friday, September 25, 2026, an updated version of the MetaTrader 5 platform will be released.
We have significantly expanded the capabilities of the AI Assistant for interacting with the platform. New tools have been added for working with Expert Advisors, scripts, and indicators, preparing parameters before testing, and retrieving Economic Calendar data. The agent can now independently perform even more complex sequences of actions — from preparing a trading robot for testing to analyzing the market in the context of macroeconomic events.
Just two months after the official launch of AI in MetaTrader 5, traders have already processed 3 trillion tokens through the free MQL5 Lite model, demonstrating the strong demand for the service. As we continue to expand the capabilities of the built-in AI Assistant, we expect its usage to grow further and new use cases for artificial intelligence in trading to emerge.
For developers, MQL5 capabilities have also been expanded. Vectors and matrices now feature a new sorting method, while complex matrices and vectors support additional mathematical operations, including products and methods for solving systems of equations. A Print method has also been added for matrices.
In addition, a number of issues related to interface rendering, chart operation, and connections to trading accounts have been fixed in the desktop and web terminals.
MetaTrader 5 Client Terminal
AI Assistant can retrieve an Expert Advisor's input parameters and prepare them for a Strategy Tester run. This simplifies complex testing and optimization scenarios in which the agent needs to determine the available parameters and configure them before starting a test.
The Assistant can retrieve Expert Advisor and script parameters, launch them on charts, remove Expert Advisors and indicators, and check the current state of indicators. This allows the agent to independently prepare the working environment and manage running MQL5 programs as part of a given task.
AI Assistant can now retrieve data from the built-in Economic Calendar: request a list of countries and events, retrieve economic indicator values, and find specific records by their IDs. This makes it possible to use macroeconomic data directly in complex market analysis scenarios — for example, to assess upcoming and recently released indicators alongside price data.
As a result, AI Assistant can perform longer sequences of actions without requiring manual preparation by the user: retrieve Expert Advisor parameters, configure testing, analyze the results, or supplement market analysis with up-to-date Economic Calendar data.
Vector sorting:
bool vector<T>::Sort(ENUM_SORT_MODE mode);Sorting a matrix by all elements: Sorting a matrix along axes: The sorting mode can be specified using SORT_ASCENDING or SORT_DESCENDING.MetaTrader 5 Web Terminal
The update will be delivered through the Live Update system.