For Mendix architects, developers and reviewers
MxScout opens the model and turns it into documentation people actually read — what the app is for, its business processes, the domain model, every microflow drawn the way Studio Pro draws it, and the risks ranked P1 to P3. On your own machine. Nothing installed, nothing sent.
A Mendix app's real documentation is its model: every entity, every access rule, every decision in every microflow. It just isn't written for people. The business can't open Studio Pro, a new developer doesn't know where to start, and the reviewer has a day to say whether it is safe.
MxScout reads the .mpr straight from the project folder and lays it out as a report you can hand to anyone — and, with an AI agent of your choice, adds the words: what each flow does, the processes told as stories, and what could go wrong.
Your projects, and where they live
Every project says, in plain words, where it is kept — and how to point your AI agent at it. Nothing of yours goes into the Mendix project unless you put it there.
One folder you choose once: every project gets a folder of its own there — the model, what the agent wrote, your notes. Tell Claude /mxscout-project Dockyard from anywhere.
When the team wants the documentation in git: mxscout/ beside the .mpr, committed with the app. What is only yours stays out of it.
Anywhere you like, or nowhere on disk at all. The card says what that means — and what to do to let an agent read it.
A tour, on a real-looking app
These are MxScout's own screens, on Dockyard — the demo app you can open yourself.
The application in two layers — a summary anyone reads, and the full story behind it — with who uses it and its numbers at a glance. Written by an agent from the model, and marked as such.
Each business process followed through one case, stage by stage — who starts it, what the app checks, where it can be refused — with a diagram when it branches, and links to the flows that carry it.
Every entity with its attributes and associations, laid out so you can read it. Pick one and see exactly who may read, write, create and delete it — and on which rows.
The flow drawn step by step, each step in words. Trace a variable and see where it is set, changed and read. Who may run it, what it calls, what calls it, and the risks that name it.
The same flow laid out where the model keeps every object, with each activity's properties dialog. No Studio Pro, no licence, no project download — just the model.
The client side, read the same way — here the technician's offline phone app: start a visit, record the position, fall back when the phone has none.
Each page drawn as Studio Pro's page editor draws it: the layout, its data views, tabs, inputs and buttons — and which of them are shown or editable only on a condition.
The C4 model, adapted to Mendix: who uses the app and which systems it talks to, what it runs as, how the modules depend on one another and which roles reach which module.
What could go wrong, P1 to P3, grouped by pattern — missing access checks, secrets in the model, commits in loops, errors that vanish — each with what happens, where, and what to do. Mark one fixed or a false positive and it stays decided.
Model quality needs no AI at all: checks read from the model against Mendix's own guidelines — flows nothing calls, loops that commit, rules without constraints.
One file, for anyone
Export the whole thing — every page above, the flows, the domain model — as one file that opens in any browser, offline, with no MxScout on the other side. Or as Markdown, for the wiki. Or keep it in the Mendix project's git, next to the app, so the team gets it with every pull.
AI, on your terms
The numbers, the structure and the drawings come from the model. The words — what a flow is for, how a process goes, what is risky — come from an agent you choose, and every sentence it wrote is marked as its.
Three skills ship with MxScout. /mxscout-project opens any of your projects by name; mendix-describe writes the documentation and keeps it up to date when the model changes. mendix-assist checks a Service Desk ticket against the model, works out a Jira issue or an idea, and keeps each as an item with its status — bug or as designed, with the evidence and a reply to paste back.
The skills are plain Markdown and dependency-free Node scripts. One command installs them for Codex too; then you just ask: “use the mendix-assist skill — I have a ticket”.
No agent at all? Put the entities, flows and pages you are talking about into the Context, copy one prompt into Copilot and work the solution out. Ask it for the JSON, paste it back: a business and a technical description, with the model attached — ready to send to whoever builds it.
Built to pass a security department
MxScout is meant for a company laptop inside a company network. Every one of these is written down in the app, on its About & security page, as a promise to whoever audits it.
No npm packages — not in the app, not in the tests, not in a build step. There is no build step. What runs is what you read.
A small Node server bound to 127.0.0.1. No telemetry, no CDN, no external assets, no account, no cloud.
The model is read in your browser, in a Web Worker. Projects live in the browser's own database — or in a folder you pick, written by the browser.
A folder and a launcher. No administrator rights, no background service, no registry, no PATH change.
Share a project as an AES-256-GCM package, WebCrypto only, unlocked with an access code that is shown once and never stored.
The suite ships with the app and drives a real Chromium: npm test. GPL-3.0 — every line is there to read.
Try it on Dockyard
Dockyard is a made-up Mendix app of a marine service company. Alarms come in from the engine rooms of its customers' vessels; dispatchers triage them into work orders and plan technicians; the technicians work on board from an offline phone app; spare parts are taken from stock and the work is invoiced.
It is built to show what MxScout finds — so it has a published service anyone can call, a live API key in the model, parts that never reach the invoice, and a few more. Ten of them are on its Risks page. Can you find them in the flows first?
The documentation MxScout exports, as it would reach your client: one HTML file, opened in this browser.
Open the documentationThe model and its descriptions in one package. In MxScout: New project, drop the file on Choose a JSON file (or click it and pick the file), then type the code.
Download Dockyard.mxscoutAccess code MXS-PW25Z-Y6G8F-K6W4Y-5JF7F
The bare .mpr: the model and nothing written about it. New project, drop it on the file box. Add the descriptions later from Documentation → Other ways.
Dockyard is invented from start to finish; any likeness to a real company or application is a coincidence. It is generated straight into the .mpr format for MxScout to read, and is not meant to be opened in Studio Pro.
Get it
MxScout needs Node.js and a modern browser — Chrome or Edge, if you want to keep projects in a folder or in the Mendix project's git. Get the folder, double-click MxScout.cmd on Windows or MxScout.command on macOS, and your browser opens on it. No Node.js on the machine? The launcher offers to put an official copy in the MxScout folder — only after you type yes.
Then New project, and pick your Mendix project folder.
# get it
git clone https://github.com/ksiejek/mxscout.git
cd mxscout
# run it — http://127.0.0.1:4289
./start.sh
# later: update it
./update.sh
# the Claude skills, for Claude Code and Codex
skills/install.sh --codex