Discussing the article: "Building AI-Powered Trading Systems in MQL5 (Part 12): Giving the Assistant Chart Vision and Tool Access"
You are missing trading opportunities:
- Free trading apps
- Over 8,000 signals for copying
- Economic news for exploring financial markets
Registration
Log in
You agree to website policy and terms of use
If you do not have an account, please register
Check out the new article: Building AI-Powered Trading Systems in MQL5 (Part 12): Giving the Assistant Chart Vision and Tool Access.
We give our AI chat assistant two new abilities in MQL5: sight and tool access. It can now capture the chart as a screenshot, attach it to a message, and view it in the panel, and it can call tools that read live positions, trade history, indicator values, chart objects, and the economic calendar. The assistant reasons from what it sees and queries rather than text alone.
Until now, the assistant has lived entirely in text. A message goes up as words, a reply comes back as words, and anything about the chart or the account has to be typed out by hand before the model can reason about it. The two abilities we add in this article break that limit from opposite ends: vision lets the model take in a picture, and tool calling lets the model reach out for data it does not have. One widens what we can send; the other widens what the model can fetch.
Vision input rests on the fact that a modern model can accept an image alongside text in the same message. We capture the chart as a screenshot, encode it as base64, and attach it to the message as image content. The model then receives the chart as an image and can interpret the candles, levels, and drawn objects visible in it, though it is reading pixels rather than chart data and can misjudge fine detail. Anything drawn on the chart is captured with it, so a chart we have marked up becomes something the assistant can read rather than guess at. The illustration below traces this path from the chart to the model.
Tool calling flips the direction of the exchange. Instead of us pushing everything the model might need into the prompt, we hand the model a menu of tools it can request, each described by a name, a purpose, and the inputs it accepts. When the model decides it needs live data to answer, it does not reply with prose; it replies with a call, naming the tool and its arguments. Our program runs that call against the terminal, returns the result, and lets the model continue with the answer in hand.
Author: Allan Munene Mutiiria