Next release (AmiBroker 7.20) news thread

Announcements & Discussions News
1

Three exciting additions coming to AmiBroker

I'm happy to share a preview of three new features currently being developed for AmiBroker.

1. New Analysis mode: RADAR

A continously running exploration with double buffering (so output doesn't reset and doesn't flicker and keeps its position / selection ) allowing constant monitoring nearly like "real-time" window but with completely custom columns

2. Preliminary IPC support using Named Pipes

A new inter-process communication (IPC) method based on named pipes is being added. The primary motivation is to provide a modern, lightweight way for external applications to control AmiBroker.

One important advantage is that named pipes work well under Linux/WINE , unlike OLE automation, which has long been unreliable or completely broken in WINE environments. This opens the door for much better integration with external tools on Linux systems running AmiBroker through WINE.

The implementation is still preliminary, but it already enables external programs to send commands directly to AmiBroker without relying on COM/OLE.

3. Experimental MCP Server

Another experimental addition is an MCP (Model Context Protocol) server built into AmiBroker.

The goal is to allow local LLMs and other MCP-compatible AI assistants to communicate directly with AmiBroker. Instead of relying on custom scripts or manual workflows, an AI assistant will be able to interact with AmiBroker through a standard protocol.

Potential use cases include:

  • Running analysis on request.
  • Querying symbols, charts, and data.
  • Automating repetitive tasks.
  • Building AI-powered trading and research workflows.
  • Connecting any MCP-compatible client to AmiBroker.

This is still an experimental feature, but it should make it much easier to integrate AmiBroker into modern AI-assisted workflows.

The MCP server will be offered as open-source Python code so you will be able to customize it to your likes.

More details and documentation will follow as both features mature. Stay tuned!

28 Likes
Next big release (AmiBroker 7.x) wish list
2

Wow, these sound amazing! Looking forward to using that hot new version! :fire:

3 Likes
3

Thanks for the great news! I’m looking forward to trying it out. :clap:

2 Likes
4

All these sounds great, Tomasz! Can't wait to try these out.

2 Likes
5

The following is a preliminary demonstration of how an MCP (Model Context Protocol) server allows an LLM to communicate directly with AmiBroker.

MCP is an open protocol that gives an AI model access to a well-defined set of application-specific tools . Instead of being limited to generating text, the LLM can invoke these tools to retrieve information, inspect application state, and perform real actions. In effect, the LLM becomes an intelligent assistant that can interact with software rather than simply describe what should be done.

For AmiBroker, the MCP server acts as a bridge between the LLM and the application. It exposes selected functionality as callable tools, allowing the AI to query charts, run analysis, access market data, and manipulate the user interface under programmatic control. The LLM decides which tool to call based on the user's request, receives the result, and can chain multiple tool calls together to complete more sophisticated tasks.

This significantly expands what is possible with AmiBroker. Instead of relying solely on traditional menus, keyboard shortcuts, or custom AFL code, users can interact with AmiBroker using natural language. AI assistants can inspect charts, answer questions about the current workspace, annotate charts, automate repetitive workflows, and combine AmiBroker's powerful analytical capabilities with external knowledge and reasoning.

This demo runs entirely locally using the Gemma 4 12B language model, on a single RTX5060 TI 16GB card, no cloud services are involved. During the demonstration, the LLM invokes the following MCP tools:

  • get_current_symbol – retrieves the currently selected symbol.
  • chart_get_image – captures the current chart so the LLM can analyze what is displayed.
  • chart_draw_line – draws a trend line on the chart based on the LLM's analysis.

Watch the demo video: https://www.amibroker.com/video/mcp_demo.mp4

12 Likes
Fun with Pipe
6

I’m already using named pipes through a plugin, and they’re really convenient. Adding an MCP server is fantastic because it opens up completely new possibilities.
Would it be possible to extend these commands to allow retrieving an array (by providing the chart_id and the variable name, or simply for a static variable identified by its name)?

7

You will be able to run your own code, and via simple printf() output any text, including contents of arrays, if you wish to do so. MCP is text based so everything goes as text. Note however that AmiBroker can easily produce millions of lines of text in fraction of second and todays LLMs will totally choke on that amount of data, so you need to limit heavily what you are feeding to LLM as they are completely incapable of handling gigabytes of data in a blink of an eye as AmiBroker does.

I am actually quite skeptic for AI, but some uses are quite interesting, especially those uses that involve lots of words and little substance.
As you know there are plenty of "market commentaries" and "expert analysis" web sites where you can read articles with explanations of how chart look, waves, etc and all that "subjective" or "discretionary" stuff. Now you can generate such "market commentaries" completely automatically using setup demonstrated above. I can imagine that entire "market expert web site" publishing commentaries for thousands of stocks daily can be run without human intervention.

The words are easy for LLMs. So using them for words, for explanations, for novice education is not bad. I would imagine that the beginner would find such commentaries useful to educate themselves how to read and interpret charts.

The other possibility is "visual inspection" of charts. Coding "discretionary" rules is problematic and one may argue that AI that is trained on past charts might "see" the patterns without need to code them as explicit mathematical rules. I am not big fan of "discretionary" trading, but who knows maybe that is some possible application.

I am not 100% convinced though if there is more substance and more value than just novice tool.

The MCP server as I wrote will be open-source code. The intention of such release is to collect feedback and suggestions of what you might want to do with it and what tools you need for your goals. I don't want to invest much time into a thing that no-body would use, so I want to release some basic thing early to collect feedback and decide if and how this should be extended.

2 Likes
8

I'd like to use AI to automate my strategy testing process and have AI interpret the results. For example, I'd like the AI to create, run, and interpret tests like:

  • Varying key parameter values and running many backtests or optimizations
  • Assess performance during different market regimes
  • Interpret what the equity curve and drawdown profile is telling me about the strategy stability
  • Randomly skip a lot of entry signals
  • Randomly exclude a lot of the symbols
  • Run tests on multiple watchlists separately and compare results
  • Compare equity curves of different strategies or different strategy variants and provide insights on how they may complement each other, and assess their correlation

I can do these tasks myself but it would be great to hand off a lot of it to AI and then I could just review the results and feed back my thoughts into the AI for future tests.

2 Likes
9

Now all features mentioned are available in:

4 Likes
10

Hi Tom,
Exciting. A few question if I may?

  1. So, as far as the MCP "Pipe" functionality, is this meant to replace OLE, or atleast match all of OLE functionality, but perhaps more?
  2. Is the performance equal to OLE or better?
  3. Regarding the PID, OLE was limited by connection to the first instance of a running AB, will this new PID allow multiple running instances, without collision between local running AB(s), with same or different database loaded?
  4. Can this pipe access a running AB instance on another machine on our local network?
  5. As far as massive data being passed and the issue you outlined, can the data be referenced as a memory object using RDMA, instead of a copy and pass operation? Either local machine or across a local network? I guess if this is text only in both directions I can guess no?
  6. One pipe connected to one running instance of AB or can more than one pipe be running at the same time? Or maybe I have the pipe, confuced with the server messages and the messages can come from anywhere, multiple apps at the same time?
2 Likes
11

First and foremost: do NOT confuse IPC with MCP.
IPC stands for "Inter-Process Communication". It is just communication between various processes. It can be done via OLE, or named pipes, or shared memory or sockets.

MCP on the other hand stands for "Model Control Protocol" it is the method for LLMs to communicate with "tools".

AmiBroker does NOT expose MCP server by itself. MCP serve is an add-on Python program (open source) that talks to AmiBroker using IPC (named pipes).

  1. No. It is currently added as alternative (option), not replacement. It is also experimental, while OLE is mature. Main motivation is broken WINE support for OLE.
  2. No noticeable difference in practice and frankly, nothing that OLE interface does in AmiBroker really needs any "performance" and don't transfer any significant amount of data to be worried
  3. Each running instance opens it own named pipe
  4. Yes it can
  5. No massive data is ever passed. Those commands are just few bytes. No data are actually transfered. Any import or export is just command that actually writes to files not to the pipe.
  6. If you use CallNamedPipe function, it essentially performs atomic write->wait->read transaction over the pipe. It is like message that gets response within short time. Multiple clients can do their own "messages" to one pipe. They get serialized automatically just by windows as CallNamedPipe will block the pipe until it returns. Therefore lengthy operations (like backtest) are made asynchronously (return immediately).

Most of these questions and way more are already answered here:

4 Likes