drawio-scientific-illustrator: live draw.io canvas control from Codex, now a legacy repo
Live MCP control of the visible draw.io canvas for step-by-step scientific illustration in Codex.
At a glance
- What is it?
- The plugin drives draw.io's own graph API through a localhost MCP server so an agent draws on a visible canvas instead of emitting XML. Development has moved to scientific-illustrator, and the README says so before anything else.
- Who is it for?
- Use this repository only if you are on Windows, already have draw.io desktop installed, and specifically want to see an agent build a figure on the live canvas through drawio_live_add_shape and drawio_live_add_edge rather than generate XML. Everyone else should follow the README's own instruction and install scientific-illustrator, since this repo receives no feature or compatibility updates.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 48 days ago.
- What is it written in?
- Mainly JavaScript, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The problem is not drawing, it is watching the drawing happen
Most agent-driven diagram tools work in one of two ways. They generate a file, then hand it to a viewer, or they drive the operating system's mouse and keyboard to poke at whatever window is in front. The README rejects both explicitly: the live workflow "does not automate the operating-system mouse or keyboard and does not create XML first and merely open it afterward." What it does instead is call draw.io's own graph API through a localhost-only MCP server, which means every shape, label, arrow and style change lands in the editor's active graph model as an editable object.
The audience is narrow and specific. You need a scientific figure you want to redraw, a reference image to work from, and a reason to care that the result stays editable rather than being a flat export. Reviewers who need to correct a panel label, or authors who want to adjust a legend after the fact, get something a generated SVG does not give them. If you only need a one-shot diagram and never intend to touch it again, the live-canvas machinery is overhead you are paying for nothing.
Two MCP servers, one skill, and a marketplace to bind them
The repository ships four pieces. The drawio-live MCP server launches or connects to the visible draw.io desktop editor and edits its active graph model in real time. The drawio-file-utils MCP server does a different job: it validates saved .drawio documents and exports PNG, SVG, PDF or JPG deliverables. A Codex skill sits on top and encodes the working method, which the README describes as inspecting a reference, decomposing it into editable primitives, drawing with pacing, reviewing sections visually, refining the live graph, and saving only after the visible drawing exists. Finally there is a repository-local Codex marketplace so the whole thing installs as one unit.
That split matters more than it looks. The live server never touches the filesystem, and the file server never touches the canvas. Export is a separate step against a saved document, which is why the README can tell the agent to save only after the visible drawing exists. The pacing parameter is the other design choice worth naming: drawio_live_draw_sequence accepts a step interval, and the recommended prompt asks for a 100 ms delay. That is not decoration. It is what makes the process reviewable while it runs, and it is also the reason a complex figure takes longer than a batch XML write would.
The tool order the skill expects
The README lists the sequence the agent normally follows. It starts with drawio_live_launch to launch or connect to a visible editor, then drawio_live_status to confirm the graph is ready. Construction happens through drawio_live_add_shape, drawio_live_add_edge, or the paced drawio_live_draw_sequence. After logical sections, the agent calls drawio_live_screenshot to inspect the draw.io renderer, and drawio_live_inspect to read back state. The README text is truncated at that point, so the full parameter surface of drawio_live_inspect and the tools that follow it cannot be confirmed from the supplied material.
The ordering is the interesting part. Status before drawing, screenshot after a section rather than after every shape. That implies the skill treats visual review as a checkpoint between logical groups, not a continuous loop, which keeps screenshot calls from dominating the run. Whether that is the right granularity for a dense multi-panel figure is something you would have to judge on your own references; the README does not give a figure-complexity threshold.
Installation, and the fork in the road the README builds in
The README's most unusual feature is that the recommended install path asks you to reconsider. The suggested Codex prompt instructs the agent to state that active development has moved to scientific-illustrator, recommend the new project, and ask you to choose between installing scientific-illustrator (marked recommended, actively maintained) or continuing with drawio-scientific-illustrator (marked legacy, no further updates). It explicitly says not to perform any installation step until you answer.
The one-command installers bypass that question. On Windows, the README gives a PowerShell command that downloads install.ps1 to a temp path and runs it with ExecutionPolicy Bypass; on macOS and Linux, a curl pipe to bash for install.sh. The README notes both intentionally install the legacy plugin and tells you to use them only after explicitly choosing the legacy option. The manual path is auditable and short:
git clone https://github.com/icebird1998/drawio-scientific-illustrator.git cd drawio-scientific-illustrator codex plugin marketplace add "$(pwd)" codex plugin add drawio-scientific-illustrator@drawio-scientific-tools
On PowerShell, the README substitutes (Get-Location).Path for "$(pwd)". After installation you restart Codex and start a new task so the skill and MCP tools load. If draw.io lives somewhere non-standard, set DRAWIO_PATH to the executable before starting Codex; otherwise the plugin auto-detects common locations on Windows, macOS and Linux. Node.js 22 or newer is recommended, but only when running the MCP servers outside the bundled Codex runtime.
Windows was the tested platform, and that is the honest limitation
The README states plainly that Windows was the tested platform for this version, and points to scientific-illustrator for cross-platform support. Auto-detection of draw.io locations is claimed for macOS and Linux, but auto-detection is not the same as a tested run, and the README does not claim a tested run. If you are on macOS or Linux and need this to work, that gap is the first thing to resolve.
There are other constraints. The plugin needs Codex desktop or Codex CLI with plugin support, so a plain MCP client will not pick up the skill, the marketplace registration, or the presentation metadata. draw.io desktop must be installed locally; this is not a web-app integration. The README also recommends GPT-5.6 Sol at Max reasoning effort for complex scientific redraws, and warns that the Max option only appears after enabling the six-level reasoning selector in Codex settings, since the default five-level selector does not show it. It adds that this setting can increase response time and token use. That is a real cost, stated without hedging, and it is the kind of thing that turns a quick redraw into a slow one.
The wrong tool case is straightforward. If you want a diagram generated once and exported, an XML-emitting tool is cheaper and faster. The live canvas exists to make the intermediate states visible and the final objects editable, and if you do not need either, you are paying for both.
Where it sits against plain MCP draw.io servers
The obvious alternative is an MCP server that writes .drawio XML directly and opens the result. The difference is not cosmetic. An XML-first tool has no live graph to inspect, so the agent cannot call anything equivalent to drawio_live_screenshot to see what the renderer actually produced, and corrections happen by editing the document and reopening it. The drawio-scientific-illustrator approach keeps a running graph model that both the agent and you can look at between steps, which is why the skill can instruct the agent to review sections and refine before saving.
The trade is latency and coupling. You need draw.io desktop running and reachable, the MCP server is localhost-only, and the paced sequence stretches the run. An XML-first server has none of those dependencies and works headless. For a figure you will revise, the live model is worth the coupling. For a figure you will never reopen, it is not.
Licence, maintenance, and what the migration actually means
The repository is MIT licensed, with the LICENSE file linked from the README. MIT is permissive, so forking and continuing to use the code is permitted; this is not legal advice, and if you plan to redistribute the plugin inside a product you should read the licence text yourself.
Maintenance is the sharper issue. The README states that the repository remains publicly accessible and is not being archived or deleted, but receives no feature or compatibility updates, and that all future development, releases and fixes have moved to scientific-illustrator. The single listed release is v1.0.0 from 2026-07-12, and the last push to the repository is 2026-07-30. So this is a frozen artifact with a documented successor, not an abandoned one. Upgrading means switching repositories, registering a different marketplace root, and installing scientific-illustrator@scientific-illustrator-tools instead of drawio-scientific-illustrator@drawio-scientific-tools. There is no in-place upgrade path described in the material, and the README does not describe what changed between the two projects beyond cross-platform support and continued maintenance.
Who should install this, and what to check first
Adopt this repository if you are on Windows, have draw.io desktop already installed, run a Codex build with plugin support, and want to watch an agent build a scientific figure on a live canvas with editable output. The install prompt in the README is the right entry point because it forces the legacy-versus-maintained decision before anything is cloned.
Do not adopt it if you are on macOS or Linux and need tested behaviour, if you only need a diagram exported once, or if you are starting fresh and have no existing dependency on this plugin. In those cases the README's own recommendation applies: install scientific-illustrator.
Three things to verify before you commit either way. First, that your Codex installation accepts codex plugin marketplace add and codex plugin add, since the whole install path depends on those subcommands. Second, that draw.io desktop is detected, or that DRAWIO_PATH points at the executable. Third, that the reasoning selector in Codex settings exposes the Max level if you intend to follow the recommended configuration for complex redraws. If any of those three fails, the plugin will install and then do nothing useful, which is the failure mode worth catching before you attach a reference figure.
Editorial conclusion
Use this repository only if you are on Windows, already have draw.io desktop installed, and specifically want to see an agent build a figure on the live canvas through drawio_live_add_shape and drawio_live_add_edge rather than generate XML. Everyone else should follow the README's own instruction and install scientific-illustrator, since this repo receives no feature or compatibility updates. Before committing to either, verify that your Codex build exposes the plugin marketplace commands and that the bundled Node.js satisfies the MCP servers, because the README recommends Node.js 22 or newer only when you run those servers outside the bundled runtime.
Community notes