In the previous post I explained why I think Mx CLI's approach, working directly on the MPR file with an SQL-like language, is the right idea for AI-driven Mendix development. Time to get practical.

One thing before we start. If you've looked at the official quickstart or other write-ups, you've probably seen mentions of devcontainers, Docker, WSL 2, and running your Mendix app inside a container. You can skip all of that. It's useful later, when you want to give an AI agent a sandboxed environment to work in, and I'll cover it in the next post of this series. For your first steps, none of it is needed. Just Windows, one .exe, and an MPR file.

Mx CLI is alpha-quality software and can corrupt your project files. Always work on a copy of your project, never on the original. The maintainers say this themselves, and they mean it.

Step 1: Install

Grab the latest Windows binary from the GitHub releases page. Put mxcli.exe somewhere sensible, for example C:\Tools\, and add that folder to your PATH (search for "environment variables" in the Start menu, edit Path, add the folder).

Open a new terminal and verify:

mxcli --version

If that prints a version number, you're done installing. That was it.

Step 2: Open a Project

First make a copy of an existing Mendix project, and close Studio Pro. That second part matters: Studio Pro locks the MPR file, and you don't want two programs writing to the same model.

Then point Mx CLI at the copy:

mxcli -p "C:\Mendix\Copies\MyApp\MyApp.mpr"

This drops you into an interactive shell. No existing project handy? You can also create a fresh one:

mxcli new test-app --version 11.8.0

Step 3: Look Around

The first thing I'd do is explore, because reading is risk-free. In the interactive shell, try:

SHOW MODULES;
SHOW ENTITIES IN MyFirstModule;
DESCRIBE ENTITY MyFirstModule.Customer;

If you know a bit of SQL, this will feel familiar immediately. That's the point of MDL.

Step 4: Change Something

Now the interesting part. Create an entity:

CREATE ENTITY MyFirstModule.Product (
  Name: String(200) NOT NULL,
  Price: Decimal(10,2),
  IsActive: Boolean DEFAULT true
);

Then check your work:

DESCRIBE ENTITY MyFirstModule.Product;

Open the project in Studio Pro afterward and you'll find the entity sitting in your domain model, as if you'd clicked it together yourself. The first time I saw that, the MPR-is-just-a-database idea from the previous post stopped being abstract.

Step 5: Lint and Report

Two commands that are worth running even if you never let Mx CLI write anything:

mxcli lint -p MyApp.mpr
mxcli report -p MyApp.mpr --format html --output report.html

The linter checks your project against dozens of built-in rules, and the report gives you a scored quality assessment across security, architecture, performance, and naming. Running these on an existing project is the gentlest possible introduction: zero risk, immediate insight. If you want to convince a colleague that this tool is worth a look, start here.

Step 6: Bring In the AI

Everything above is you typing commands. The reason this series exists is what comes next: letting an AI agent type them. Mx CLI ships with first-class support for this:

mxcli init --tool claude "C:\Mendix\Copies\MyApp"

This generates a CLAUDE.md, dozens of skill files, and command definitions, so an agent like Claude Code understands how to work with your project through MDL. Start the agent in that folder, describe what you want built, and watch it query and modify your model. Mohamed ElNady wrote a great account of letting an AI build a complete Mendix app this way, ending with twelve entities, twenty-five microflows, and twenty-two pages.

One caveat: an AI agent with write access to your model is exactly the scenario where you want a sandbox, and that's what the devcontainer setup we skipped is for. That's the subject of the next post. Until then: explore, lint, and experiment on copies.