Excalidraw MCP: streaming hand-drawn diagrams into Claude, VS Code and ChatGPT

The gap Excalidraw MCP fills: diagrams as an interface, not as text

Ask a chat model to describe an architecture diagram and you get a paragraph. The reader still has to hold the topology in their head, and there is no artifact to move, edit or screenshot. Excalidraw MCP targets that gap directly. It is an MCP server that returns a rendered Excalidraw canvas inside the chat client, described in the README as "MCP server that streams hand-drawn Excalidraw diagrams with smooth viewport camera control and interactive fullscreen editing."

The intended user is not a diagramming tool power user. It is someone already working inside an MCP Apps capable client who wants a throwaway sketch: a quick architecture picture, a flow, a whiteboard scribble. The README's own example prompts are "Draw a cute cat using excalidraw" and "Draw an architecture diagram showing a user connecting to an API server which talks to a database". Neither implies a saved file, a shared workspace, or a version history. That framing matters when you decide whether this is the right tool.

It is a thin layer over an existing renderer rather than a new drawing engine. The credits section states the project is "Built with Excalidraw", and package.json depends on @excalidraw/excalidraw ^0.18.0. If you already trust Excalidraw's rendering, the question is only whether the MCP transport and the streaming behaviour hold up.

How the server streams a canvas: MCP Apps, morphdom and the stdio path

MCP Apps is the piece that makes this possible. The README explains the extension as one that "lets servers return interactive HTML interfaces (data visualizations, forms, dashboards) that render directly in the chat." A plain MCP tool returns structured text; an MCP App returns a UI surface the host renders. That is the whole reason a diagram can appear at all.

The dependency list shows the shape of the implementation. @modelcontextprotocol/ext-apps ^0.4.0 and @modelcontextprotocol/sdk 1.25.2 handle the protocol, express ^5.1.0 and mcp-handler 1.0.7 serve it, and morphdom ^2.7.8 does incremental DOM patching. morphdom is the interesting one: patching an existing DOM tree rather than re-rendering it is what makes "streaming" plausible, since the canvas can be updated as the model produces elements instead of appearing all at once. The README mentions "smooth viewport camera control", which suggests the viewport is animated as content arrives, though the README does not document the camera API or its parameters.

There are two transport paths. The hosted server lives at https://mcp.excalidraw.com, and the Vercel deployment notes say a self-hosted copy ends up at https://your-project.vercel.app/mcp. The local build runs as a Node process with a --stdio argument, which is what the Claude Desktop config below uses. @upstash/redis ^1.34.0 is in the dependency list, implying the hosted path uses Redis for state, but the README does not describe what is stored there or for how long. Treat any assumption about session persistence as unverified.

Installing Excalidraw MCP in Claude Desktop and getting a first diagram

The README recommends the remote endpoint first: "Works with any client that supports MCP Apps (Claude, ChatGPT, VS Code, Goose, and others)." For clients without an official integration, the instruction is to add a custom MCP connector, with the caveat that naming varies between apps. If your client accepts a URL, https://mcp.excalidraw.com is the whole configuration.

For Claude Desktop there is a packaged route. Download excalidraw-mcp-app.mcpb from the Releases page and double-click it to install. The alternative is building from source, which the README gives as:

git clone https://github.com/excalidraw/excalidraw-mcp.git
cd excalidraw-mcp-app
pnpm install && pnpm run build

Note the mismatch: the clone target is excalidraw-mcp but the directory you enter is excalidraw-mcp-app. After the build, register the server in ~/Library/Application Support/Claude/claude_desktop_config.json. The README's snippet looks like this:

{
  "mcpServers": {
    "excalidraw": {
      "command": "node",
      "args": ["/path/to/excalidraw-mcp-app/dist/index.js", "--stdio"]
    }
  }
}

Replace the placeholder path with the real location of dist/index.js from your clone, then restart Claude Desktop. The package.json bin entry is mcp-server-excalidraw pointing at dist/index.js, so that file is the expected entry point. Once the server is registered, a prompt such as "Draw an architecture diagram showing a user connecting to an API server which talks to a database" should produce a canvas rather than a description. If nothing renders, the README points you at the issue tracker for the project rather than offering a troubleshooting section.

Self-hosting on Vercel, and what the repository does not tell you

The README gives a self-hosting path that is genuinely short: fork the repository, import the fork at vercel.com/new, and deploy. It states no environment variables are needed, and the resulting server sits at https://your-project.vercel.app/mcp.

The gap is that the README does not explain what the Redis dependency is doing in production. It is listed as a normal dependency, not a dev dependency, so a self-hosted deployment presumably reaches for it, yet the deployment instructions promise no configuration. Either the code degrades gracefully without it or the hosted instance is the only one exercising that path. The README is silent, and that is worth resolving before you point a team at your own deployment.

Licensing is clearer. The README ends with a License section reading MIT, and package.json carries "license": "MIT". The top-level repository listing shows no separate LICENSE file, so the README and package manifest are your sources. MIT is permissive, but since this bundles @excalidraw/excalidraw, which is a separate project with its own licence, check that dependency's terms if you redistribute a build. That is a question for your own review, not something the README addresses.

Where Excalidraw MCP is the wrong tool

The most obvious limitation is durability. Nothing in the README describes where a finished diagram goes. There is no mention of exporting to .excalidraw, saving to a file, or persisting a scene between sessions. If your requirement is a diagram that survives a chat being closed, or that a colleague can open in excalidraw.com, this server does not document that path. It is a rendering surface, not a document store.

The second limitation is the MCP Apps requirement. The README is explicit that it works with clients supporting the extension and that some apps lack an official integration, in which case you add a custom connector. In a client that does not render MCP App HTML, the tool has nothing to show. There is no documented text fallback, so a client that only handles plain tool results will not get a diagram out of this.

Third, there is no CLI. package.json exposes a bin entry for the server process, not a drawing command. You cannot run this from a terminal to produce a file. Finally, the release history is short and the cadence is not obviously ongoing. v0.3.0, v0.3.1 and v0.3.2 all landed within three days in February 2026, and the last push to the repository was on 2026-03-24. That is more than seven months before this check, so describing the project as actively developed would overstate what the repository shows.

How it differs from the MCP servers you would otherwise reach for

The natural alternative is a diagram-as-code MCP server, the kind that wraps Mermaid or Graphviz and returns a text diagram definition the client renders or you paste elsewhere. The difference is in the return type. A Mermaid server hands back a string; you own the rendering step and the resulting image is static. Excalidraw MCP returns an interactive HTML surface through the MCP Apps extension, and the README advertises "interactive fullscreen editing", so the user can adjust the drawing in place. That is a real capability difference, not a cosmetic one.

It costs you portability. A Mermaid string can be committed to a repository, diffed, and rendered by GitHub. An MCP App canvas is bound to a client that renders MCP Apps, and the README does not describe an export step that would let you move the result out. If your diagrams are artifacts that live in version control, the text-based approach wins on every axis except interactivity.

The other alternative is simply not using an MCP server. Excalidraw itself is a browser whiteboard, and the README's credits describe it as "a virtual whiteboard for sketching hand-drawn like diagrams". Opening excalidraw.com and drawing takes seconds. What the MCP server adds is generation: you describe the diagram and the model lays it out. That is worth the setup only if the describing is the slow part for you.

Maintenance, upgrade cost and the release checklist

The repository is not archived, and the last push was on 2026-03-24. Three releases shipped in February 2026, all patch-level or minor: v0.3.0 on 2026-02-07, v0.3.1 on 2026-02-09, and v0.3.2 on 2026-02-09. The package.json version is 0.3.2, matching the newest release. There is no published roadmap or deprecation notice in the README.

Upgrading a local install is a rebuild, not a package update, because the Claude Desktop config points at a file path inside your clone. The README's release checklist, written for maintainers, gives the sequence and doubles as the upgrade procedure if you self-host:

pnpm run build && mcpb pack .
gh release create v0.3.0 excalidraw-mcp-app.mcpb --title "v0.3.0" --notes "What changed"
vercel --prod

The first line rebuilds and packs the .mcpb extension, the second creates a GitHub release (the version in the example is v0.3.0, so substitute your own), and the third deploys to Vercel. The checklist also notes that manifest.json and package.json versions must be bumped together, which is a manual step and therefore a place where a fork can drift.

The dependency surface is the real upgrade cost. React 19, Express 5, the MCP SDK pinned at exactly 1.25.2 rather than a range, and @excalidraw/excalidraw ^0.18.0 all move independently. Expect to test after any bump. The postinstall script attempts to set up Bun and falls back with an echo if it fails, so a build can succeed with only a printed warning; check that line if the serve script misbehaves.

Editorial conclusion

Adopt it if your workflow already lives in an MCP Apps client and you want diagrams you can edit rather than read. Skip it if you need a stable drawing file on disk, a non-MCP integration, or a long-lived project whose release cadence you can predict: v0.3.2 shipped on 2026-02-09 and the last push landed on 2026-03-24. Before wiring it into anything, open https://mcp.excalidraw.com in your client and confirm the canvas renders and the fullscreen edit step works.

Frequently asked questions

Official sources

1. excalidraw/excalidraw-mcp on GitHub
2. Issues
3. Project website
4. README
5. Releases