Ask any coding assistant to "diagram this service" and you get the same thing back: a fenced Mermaid block, or some ASCII boxes, or a PNG you drop into a doc and never touch again. It's fine. It's also a dead end — the moment a teammate wants to move a box, add a note, or present it, they're redrawing it by hand somewhere else.

I wanted the other thing: an agent that draws onto a real whiteboard — a shared canvas my team already opens, with nodes you can drag, connectors that stay attached, and sticky notes you can argue in. So I wired one up over MCP, and it turned out to be less work than I expected. Here's how it went.

The gap: "diagram output" vs. "a thing your team uses"

A Mermaid snippet is text that renders a diagram. A whiteboard is an artifact your team works on. Those are different objects with different half-lives:

  • The snippet lives in one chat transcript. Nobody finds it next week.
  • The board has a URL. You share it, link it from the ticket, and open it in the standup.

If the agent can only produce the first, the human still has to do the translation into the second — which is exactly the tedious part. The interesting version of "AI draws my architecture" is the one where the output is the shared artifact.

MCP is the missing socket

DrawlyHub (the whiteboard I work on) exposes an MCP server. MCP is just a standard way for an AI client — Claude, an IDE agent, your own script — to discover a tool's capabilities and call them with your authorization. So instead of the agent printing diagram syntax, it calls tools like "create a board," "add a frame," "place these nodes," "connect A to B."

Connecting it is the ordinary OAuth dance, and the one detail worth watching is the consent screen:

  1. The client hits /.well-known/oauth-authorization-server and discovers the endpoints.
  2. It registers itself (open Dynamic Client Registration, RFC 7591 — standard for MCP).
  3. You get a consent screen in your browser and approve what the agent may do.

That third step is the whole security model, and it's worth saying plainly: the agent can only ever act on your data after you approve it on a screen you control. A client that isn't one of the first-party apps shows up labeled unverified, so a look-alike can't dress itself up as something you trust. You're not handing out a
standing key; you're granting a scoped, revocable session to a named app.

The demo: "draw me a three-tier setup on AWS"

With the agent connected, I asked for something concrete:

Draw a three-tier web architecture on a new board: CloudFront in front of an ALB,
an ECS service behind it, RDS and an S3 bucket below. Label the connectors with the protocol.

What came back wasn't a code block — it was a board. Under the hood the agent doesn't poke the canvas box by box. It asks the server to describe_format, composes the whole diagram as one board document, validates it, and submits it:

describe_format() # learn the .drawly schema board = { "format": "drawly-spec", "version": 1, "title": "Three-tier web on AWS", "frames": [{ "key": "request-path", "title": "Request path", "elements": [ {"kind": "box", "id": "cf", "x": 120, "y": 80, "w": 200, "h": 80, "text": "CloudFront", "palette": "sky"}, {"kind": "box", "id": "alb", "x": 120, "y": 220, "w": 200, "h": 80, "text": "ALB", "palette": "sky"}, {"kind": "box", "id": "ecs", "x": 120, "y": 360, "w": 200, "h": 80, "text": "ECS service", "palette": "violet"}, {"kind": "box", "id": "rds", "x": 420, "y": 360, "w": 200, "h": 80, "text": "RDS", "palette": "emerald"}, {"kind": "box", "id": "s3", "x": 420, "y": 220, "w": 200, "h": 80, "text": "S3 bucket", "palette": "emerald"}, {"kind": "link", "id": "k1", "from": "cf", "to": "alb", "text": "HTTPS"}, {"kind": "link", "id": "k2", "from": "alb", "to": "ecs", "text": "HTTP"}, {"kind": "link", "id": "k3", "from": "ecs", "to": "rds", "text": "5432"}, {"kind": "link", "id": "k4", "from": "ecs", "to": "s3", "text": "SDK"} ] }] } validate_board(document=board) # dry-run: catches a dangling link or bad id create_board(document=board) # creates it, hands back the board's URL

The declarative shape is the nice part: the agent authors the whole diagram as data, validate_board catches a connector pointing at nothing before anything is created, and create_board returns a URL. Connectors are link elements that reference box ids, so they stay attached when you move a box around later.

I opened the board URL and the boxes were there, wired up, laid out on a frame I could pan and zoom. Then I did the thing you can't do with a Mermaid block: I grabbed the RDS box and moved it, dropped a sticky note on the ECS box that said "autoscaling TBD," and sent the link to a teammate to finish.

For the parts that genuinely are better as code than as hand-placed boxes — a sequence diagram, say — the agent can drop a Mermaid container onto the board instead, so the diagram renders from text but still lives on the same canvas as everything else. Text where text wins, boxes where boxes win, one surface either way.

Why the board beats the snippet

  • It has a URL. The architecture is linkable from the PR, the ticket, the doc. It doesn't evaporate with the chat.
  • It's editable by humans. The agent gives you a first draft in seconds; you refine it by dragging, not by re-prompting. Boards organize into frames (think slides), so one board can hold the request path, the data model, and the deploy pipeline side by side.
  • You can hand it off. Share it view-only with a link, or give a teammate edit access, and present it frame by frame. The agent did the typing; the team does the thinking.

The honest caveats

This is early, and I'd rather tell you than have you find out:

  • It's a first draft, not an architect. The agent places what you describe; layout and correctness are still yours to own. It's a huge head start, not a replacement for judgment.
  • Creating boards from an agent is a Pro feature. There's a two-week trial with no card if you want to kick the tires on the whole thing, including the MCP flow.
  • It's a whiteboard, not a modeling tool. If you need validated infrastructure-as-code or a cloud cost estimate, this isn't that. It's for thinking visually, fast, with an agent doing the grunt work of placement.

Try it

  • Open the live demo board to see what the canvas feels like — no account needed.
  • If you run an MCP-capable client, point it at DrawlyHub and ask it to draw something. The consent screen will walk you through what it's allowed to do.

If you build something fun with it — or break it — I'd genuinely like to hear about it.
The gap between "AI output" and "a thing my team actually uses" is the whole reason this exists, and MCP turned out to be the clean way to close it.