MCP

An alternative to the draw.io MCP server.

The difference is who decides where the boxes go.

Download for macOS
v0.1.33 · .dmg · Apple Silicon & Intel
Signed & notarized by Apple · opens without a Gatekeeper warning
sha256 698955a0187bc039f4c74f5d05a9f10fbb27376a45788a0a241d1326b73873c7
Download for Windows instead
$curl -fsSL https://lucidtrain.com/install.sh | sh

draw.io MCP servers expose drawing primitives, so the language model chooses shapes and coordinates, which is what produces overlapping boxes and crossing arrows on anything beyond a few nodes. Lucid Train's MCP server takes a semantic graph of components, tiers and edges with no coordinates at all and runs the ELK constraint solver over it. The model decides structure and never decides position.

Multi-tenant SaaS architecture. 12 components across 5 tiers.
Hover any component to see what it is responsible for.
Multi-tenant SaaS architecture. Produced by the app's layout engine from a semantic graph, not placed by hand.

Where primitive-level MCP servers struggle

Giving a model a create-shape and a create-connector tool works for four boxes and degrades quickly. Language models are poor at spatial arrangement: they place things that overlap, route edges through cards, and produce diagrams that need manual tidying, which defeats the purpose of generating them. No amount of prompting fixes it, because the request is asking the model to do the thing it is worst at.

The semantic graph approach

Lucid Train's emit_diagram takes nodes, edges and tiers with no coordinates. ELK, a layered constraint solver, computes positions and orthogonal routing. Overlaps are not unlikely, they are impossible, because nothing in the pipeline can express one. That also makes editing cheap: change a component and the whole layout re-solves rather than drifting.

What you give up

Free-form drawing. draw.io covers floor plans, org charts, BPMN and network topology with an enormous shape library, and Lucid Train does none of that. This is a software architecture tool, so if you need a diagram type outside that, the draw.io route is the right one.

Transport

Connections are stdio: the server runs as a local child process with piped stdin and stdout. Remote HTTP and SSE servers appear in the Connectors tab's registry search but cannot be connected, and that is a real limit rather than a configuration step you are missing. A remote server needs a local stdio bridge in front of it.

Output formats

SVG that renders natively in a GitHub README, 2x PNG, a Markdown Architecture section written into the repo, and the underlying Excalidraw scene, which opens in any Excalidraw client. There is no draw.io XML export, so this is not a drop-in for a team standardised on draw.io files.

Two approaches to a diagram MCP server

Lucid TrainPrimitive-level servers
Who chooses positionsAn ELK constraint solverThe language model
Overlapping boxesStructurally impossibleCommon past a few nodes
Edge routingOrthogonal, computedModel-chosen
Tier bandsYesNo
Real service iconsYes, bundled, offlineShape libraries
EditingRe-solves the layoutManual repositioning
Diagram typesSoftware architectureAnything
TransportstdioVaries
FAQ

Questions

Why do MCP-generated diagrams often look wrong?

Because most diagram MCP servers ask the model for coordinates, and spatial arrangement is the thing language models are least reliable at. A server that takes a semantic graph and runs a layout solver removes the failure entirely.

Can Lucid Train open .drawio files?

No. It works with Excalidraw scenes. Exported SVG and PNG go anywhere, but there is no round trip into draw.io's XML.

Does it work with the same MCP clients?

Any client that supports stdio servers, which includes Claude Code, Codex and Cursor.

Related