mcp_excalidraw replaced its browser tab with a Node renderer and kept the tab as a flag

Screenshots stopped needing a browser tab

The current release line is headless rendering, and the change is worth understanding because it is the difference between a tool that works in continuous integration and one that does not. Previously, taking a screenshot or exporting an image meant driving a real browser tab showing the canvas. Now the exporter from Excalidraw itself runs inside Node under a DOM emulation library, and a native rasteriser turns its SVG into a PNG, with four font families bundled in so the output does not depend on the host's fonts. The page claims three things about this: the same output as the tab, determinism in the sense that an unchanged scene renders byte-identically, and a few milliseconds per render. The old path is still there behind a renderer flag on the command line, which is the right way to keep a behavioural escape hatch. There is also a new command that renders a committed diagram file to an image with no canvas server running at all.

Zero-size elements used to export as invisible

Two bugs from the same release are worth naming because they describe a whole class of failure in this kind of tool. The first: shapes created without a width or a height collapsed to zero by zero in exports and renders, so they appeared on the canvas but vanished in the image. The fix gives them a default of one hundred by one hundred to match what the canvas shows. The second is the same disease in text: a scene stored with zero width and zero height, which is what a server older than version two wrote, exported as invisible text, and is now re-measured on export instead. The second one carries an issue number, which is a good sign about how the project handles reports. Together they say something useful about the format: a scene file is a document with numeric geometry that different producers fill in differently, and any tool reading it has to defend against the zeros.

It speaks a protocol revision with no handshake, and keeps the old handshake

The server declares support for a dated protocol revision, in this case one from July 2026, and describes what that revision changes: clients may call tools statelessly, with no initialisation step, using a discovery call and a per-request metadata envelope. Clients from the previous generation still work, because those open with the initialisation call as before. That combination, new and old in one binary, is the interesting engineering claim here, and it is the kind of thing that is either cheap or very expensive depending on how the protocol layer is structured. The runtime floor moved in the same release, from Node 18 to Node 20, and the stated reason is that version two of the protocol's TypeScript library sets it. Everything else was kept backward compatible, including existing client configurations, which is the right boundary to draw for a tool people have already wired into editors.

The canvas binds to all interfaces in Docker and the project tests the local bind

Two facts that only make sense together. The canvas server serves a web interface, a REST API and a real-time sync channel, and its documented default address is a loopback address on port three thousand. In the container configuration, that is overridden: the host variable is set to all interfaces, port three thousand is published to the host, cross-origin access is enabled as a dependency, and a health check polls a health endpoint every thirty seconds with a forty-second grace period. Since this is a server that can read and rewrite a diagram, that is the line to think about before running it anywhere shared. The mitigation is that the project has a check for it: one of the three scripts in the default test command inspects the local bind. So the loopback default is not merely documented, it is verified by a test that runs before the render checks.

The MCP-only compose scenario contradicts its own dependency

The compose file documents three ways to run it in comments at the top: canvas only, MCP only, and both together through a profile. The second of those says to bring up just the MCP service and notes that it requires a canvas running elsewhere. But the MCP service declares a dependency on the canvas container with the condition that the canvas must be healthy, and that dependency is inside the same service definition as the profile that gates the combined scenario. So the documented MCP-only invocation is in tension with the declared dependency: bringing up the MCP service alone would ask the orchestrator to start the canvas too. Both services also set the environment variable that disables canvas auto-start, the MCP container because it ships no user interface build and would otherwise serve a blank page, which is a neat piece of self-knowledge in a build file. Both images are built locally rather than pulled, and the MCP one keeps standard input open with a terminal attached, because it speaks a protocol over those two streams.

Three checks, each of which rebuilds the server first

The default test command is a chain of three named checks: one for the protocol over standard streams, one for the local bind, and one for rendering. Each one starts by rebuilding the server, so a full run compiles the TypeScript three times. That is slow and it is also the reason the checks are honest, because they exercise the compiled artefact rather than the sources. A fourth entry point runs the full build and hands off to a browser-driven suite, configured by its own file at the root, which is where the canvas interface itself gets tested. The production image is a two-stage build as well, compiling in one stage and copying only the compiled output and production dependencies into a slim runtime stage, where a non-root account is created with a fixed numeric identifier and given ownership of the application directory before the runtime command runs.

The comparison with the official server is twelve rows long

The page includes a side-by-side table against the official Excalidraw protocol server, and it is the most informative paragraph in the documentation because every row is a design decision rather than a feature. The official server is a chat widget that streams a finished diagram, giving the model two tools: a format reference and a create-view call. This project is element-level control over a persistent canvas, with create, read, update and delete per element, structured description plus screenshots so the model can see its own output, layout operations such as align, distribute, group, lock and duplicate, file import and export, named server-side snapshots, Mermaid conversion, viewport control, and multiple agents working on the same canvas concurrently. The summary the page settles on is that the official server shows diagrams in a chat, while this one gives a coding agent a workbench. Two claims in the table are the load-bearing ones: byte-stable rendering and concurrency, and both are things a reader should test on their own diagrams.

Local rendering, fonts and sharing

The naming runs to four conventions: the repository uses an underscore in its name, the published package uses a hyphen and a server suffix, the command exposes two binaries sharing one file, and the compose images use a third spelling. None of it is a problem, and it is all in one repository to check, but it is the kind of friction that costs a confused first-time user. The privacy story is equally short and worth stating in full. Core drawing is local and needs no keys, Mermaid conversion happens in the local canvas, and the optional share command uploads an encrypted scene to Excalidraw. The README also states that the canvas page loads fonts from the esm.sh CDN, so an offline or privacy-sensitive deployment should verify its network behavior. There is a second export to a shareable link for the same kind of artefact. Check the configured endpoint and deployment before sharing sensitive diagrams.

Editorial conclusion

Adopt this if your agent needs to produce diagrams that live in your repository as files, because that is the specific thing it does and the export format is the point. The loop it closes, draw, look at a screenshot, fix the element that overlaps, look again, is genuinely different from asking for a picture. Two things to check before you wire it into a pipeline. First, where the canvas listens: the default is a loopback address, but the container configuration overrides that to all interfaces on a published port, with cross-origin access enabled and a health endpoint, so a shared or hosted machine needs a firewall decision. Second, what you are trusting for visual verification: the renderer claims byte-identical output for an unchanged scene, which is the property you want, and it bundles four font families so that the claim does not depend on what fonts the machine has.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. Project website
4. README
5. yctimlin/mcp_excalidraw on GitHub