Your agent can already write the code, run the tests, and open the pull request. The one thing it usually cannot do is hand you a picture of what it just built. It describes the architecture in prose, you nod, and then someone still has to open a canvas and draw the thing by hand. MCP closes that gap. With a few lines of config, your agent gets a tool that produces a real LetDraw diagram, not an ASCII sketch but an actual editable board you can open, tweak and share.
This is the practical version: what MCP is in one paragraph, then the exact steps to wire it up and the first prompt to try.
MCP in one paragraph
The Model Context Protocol is a small, standard way for an AI agent to call external tools. A tool is described once (its name, what it does, and the shape of its inputs) and any MCP-aware agent can then decide to call it and read the result. LetDraw ships an MCP server that exposes diagram-making as exactly this kind of tool. The agent does not need to know how LetDraw renders anything; it just calls a tool like "create a diagram from this description" and gets back a link to the finished board.
Step 1: mint an API token
The MCP server acts on your behalf, so it needs a credential. In LetDraw, open Account → API Keys and create a personal API token. Copy it once and keep it somewhere your agent's config can read; an environment variable is ideal. Treat it like a password; anyone with it can create diagrams as you.
# from Account → API Keys LETDRAW_API_TOKEN="ld_live_xxxxxxxxxxxxxxxxxxxx"
Step 2: register the MCP server
Point your agent at the LetDraw MCP server and pass the token through. Most MCP-aware clients read a small JSON block that lists the servers they can use. The shape is always the same: a name, how to launch it, and the environment it runs with.
{
"mcpServers": {
"letdraw": {
"command": "npx",
"args": ["-y", "@letdraw/mcp"],
"env": { "LETDRAW_API_TOKEN": "${LETDRAW_API_TOKEN}" }
}
}
}
Restart the agent and it will discover the LetDraw tools automatically: things like creating a diagram from a description, from a piece of code, or from a compose or Kubernetes file. You do not wire each one up by hand; MCP advertises them for you.
Step 3: ask for a diagram
Now the fun part. Because the tool is described in plain terms, you drive it with plain language. The agent decides when to call it and fills in the inputs from your request.
You: Draw the architecture for the service you just scaffolded ,
API, worker, Postgres and Redis, and give me the link.
Agent → calls letdraw.create_diagram({
"description": "API service behind a load balancer, a queue
feeding a background worker, Postgres primary with a
read replica, Redis cache in front of the API"
})
Agent: Done → https://letdraw.com/d/abc123 (open to edit)
The agent does not draw the diagram. It asks for one, and hands you a canvas you can keep working in.
That last detail is what makes this useful rather than a party trick. The result is a normal LetDraw board, so the AI gives you a first draft and you stay in control. Open the link, drag a box, fix the one relationship the model got slightly wrong, add the thing it did not know about, and share it. The agent did the tedious placement; you did the judgement.
docker-compose.yml" or "diagram these Kubernetes manifests" gives the model structure to work from, so the first draft needs far less cleanup.Where this earns its keep
A generated diagram is most valuable exactly when documentation is least likely to exist: the moment code is written or changed. Wire the MCP server in once, and "and draw me the architecture" becomes a normal thing to say at the end of a task. The picture arrives while the design is fresh in everyone's head, it is editable rather than throwaway, and it lives on a canvas your teammates can open without installing anything. Your agent was already doing the work; now it can show it.
Mint a token, drop in the config, and ask your agent for its first diagram.