I ended my comparison of three routes to build Mendix apps with AI by saying my curiosity sat with Mx CLI, and that I'd probably write more about it. This is that series. Before we get practical, I want to spend one post on the conceptual question underneath, because I think it's the more interesting one: how should an AI agent talk to Mendix in the first place?

Right now there are two fundamentally different answers.

Answer 1: Through Studio Pro

The first approach is Maia MCP. It exposes Studio Pro's capabilities through an MCP interface, so an AI agent can interact with your Mendix project using the official tooling. The agent effectively sits next to you in Studio Pro and operates it.

There's a lot to like here. It's the official route, it benefits from everything Studio Pro already knows, and it will be supported and developed by Mendix itself. If you want a safe default, this is it.

Answer 2: Straight to the Model

The second approach skips Studio Pro entirely. Mx CLI works directly on the MPR file, and this is where it gets interesting, because an MPR file is not some opaque binary blob. It's essentially a NoSQL database containing all the metadata of your model: your entities, your microflows, your pages, everything.

Once you see the MPR as a database, an obvious question follows: why click through an IDE to change it when you could query it? That's exactly what Mx CLI does. It gives you MDL, the Mendix Definition Language, an SQL-like syntax for reading and modifying the model as structured text:

SHOW MODULES;
SHOW ENTITIES IN Shop;
CREATE ENTITY Shop.Product (
  Name: String(200) NOT NULL,
  Price: Decimal(10,2)
);

Text based, token efficient, and really fast.

Why I Think the Second Answer Fits Agents Better

Here's the thing about large language models: they've been trained on staggering amounts of SQL and structured text. That's their native habitat. An agent that can express "show me every microflow that touches the Customer entity" as a single declarative statement is operating the way it operates internally anyway. An agent that has to drive an IDE through tool calls is working through a layer of indirection, and every layer costs tokens, time, and reliability.

Add to that the low-level control (you decide exactly what gets created, down to the pattern), and the openness (it's open source, so when something doesn't work you can see why), and you have my preference. The workflow simply aligns with how AI agents work.

The Honest Counterpoint

I should be fair about what you give up. Studio Pro does an enormous amount of consistency checking that you don't see until you miss it: across the domain model, microflows, pages, and security, it constantly verifies that everything still fits together. When you write directly to the MPR, you step outside that safety net. Mx CLI has its own validation and linting, and it's improving, but it's a younger ecosystem checking fewer things. Someone raised exactly this point when I shared this comparison on LinkedIn, and it's the right concern to have.

It's also alpha-quality software. The maintainers say so themselves: it can corrupt your project files, so you work on a copy. Always.

So no, I'm not arguing anyone should move production workflows to Mx CLI today. I'm arguing that working on the model as structured text is the architecturally right idea for AI-driven development, and that's why this is the route I keep investing my evenings in.

In the next post we get practical: installing Mx CLI on Windows and running your first commands, in the simplest possible setup. No Docker, no devcontainers, just you and an MPR file.