MCP for Designers: Connecting Figma, Miro and Your Canvas to an Agent

If you have used a coding agent for design work without MCP, you already know the tax. You export a frame as a PNG and drag it into the chat. You copy hex values out of the inspect panel one at a time. You screenshot a Miro board and hope the agent can read sticky-note handwriting at 40 percent zoom. Then you switch to the browser, screenshot the half-built page, paste that in too, and ask the agent to compare two images it can barely see. Every handoff between your design tools and the agent is manual, lossy, and yours to repeat tomorrow.

The cost is not just time. The agent is working from degraded copies of your intent. A flattened PNG has no token names, no spacing values, no component boundaries, no auto-layout rules. A pasted screenshot of the live page has no breakpoints other than the one you happened to capture. So the agent guesses, and you spend review cycles correcting guesses you caused by feeding it pictures of data instead of the data.

Several articles on this site already assume a better setup. Visual QA with Agents assumes the agent can capture the page itself. Screenshot to Implementation assumes it can read the design closely enough to preserve intent. The mechanism that makes both honest rather than hopeful is the Model Context Protocol — MCP — and it is much less mysterious than the acronym suggests. This article explains what it is in plain language, which design servers are worth connecting as of 9 October 2026, how to configure them, how to chain two servers into a review, and how to keep write tools behind a prompt.

MCP is a shared way for an agent to call other software. A program that speaks the protocol on the tool side is called a server. It announces a small list of named functions — the spec calls them tools — along with what each one needs as input and what it returns. Your agent platform speaks the protocol on the other side as a client. When you ask the agent to review a page against a Figma frame, it looks at the tools its connected servers offer, picks the relevant ones, calls them mid-conversation, and the results come back into its context window the same way a file it just read would. That is the entire trick. No plugin marketplace, no per-tool integration code, no vendor-specific SDK in your project.

Servers can also expose resources, which are readable pieces of data such as a file or a board, and prompts, which are pre-written workflows the server suggests. For design work you will spend almost all of your attention on tools: get the design context for this frame, return the variables, take a screenshot, write this HTML to the canvas, navigate the browser to this URL.

The one distinction worth internalizing is local versus remote, because it predicts both how a server behaves and how it fails. Local servers run on your machine — either as a small process your agent starts (the configuration says, in effect, run this command), or inside a desktop app that listens on localhost. Paper, Pencil, Playwright and Chrome DevTools all work this way, and they operate on whatever file or page you have open, which means the app has to be running. Remote servers live at a URL — Figma's hosted server and Miro's are the prominent design examples — and you authenticate with OAuth in the browser, the same consent screen flow you know from connecting any two web products. They work from anywhere but bring rate limits and the question of what data leaves your machine.

The diagram below is the picture to keep in your head. One agent, one protocol, several servers, and each server is a narrow door into a design surface or the live page.

A host calls a server. The server exposes tool cards. The stable spec is 2026-07-28. Figma write, use_figma, is open beta. Paper connects with paper mcp. pen.dev's server name is pencil.

A reasonable first question is whether MCP is one vendor's idea that the rest of the industry will route around. As of 9 October 2026 the answer is no. Anthropic released the protocol in late 2024 and in December 2025 donated it to the Agentic AI Foundation under the Linux Foundation. Claude Code, Codex CLI, OpenCode, Antigravity CLI, and Cursor all ship an MCP client. GitHub Copilot does too, and it is worth splitting the name: IDE agent mode edits the local workspace while you supervise, and Copilot cloud agent works in a GitHub Actions environment and can open a pull request. Neither mode is autocomplete. Cursor's Design Mode, in the browser inside the Agents Window, is the client that lets you point at the running UI.

The stable specification to cite is 2026-07-28, published 28 July 2026. It makes the core stateless: the old initialize handshake and Mcp-Session-Id are gone, and each request carries its protocol version. The previous revision was 2025-11-25. The mental model in this article — a server advertises tools, the client calls them — did not change. The registry at registry.modelcontextprotocol.io is still where you check who published a server.

Why should a designer care about governance at all? Because connecting your design tools to an agent is an investment. You will write configuration, build team conventions, maybe build a workflow this site would call a harness around specific servers. A protocol with neutral governance, an official registry, and adoption across competing platforms is a much safer place to make that investment than a proprietary plugin system that one pricing change could strand.

The useful design-relevant servers split cleanly into three groups: design canvases and boards, the browser, and everything else. Within the first two groups, every server worth starting with is official — published and maintained by the vendor whose tool it reaches — which matters more than it might sound, because an MCP server sits inside your agent's trust boundary.

Figma's official server is the one most often described wrongly. Figma recommends the remote endpoint at https://mcp.figma.com/mcp. The desktop server is the narrower option, for specific organization and government setups. Read tools return structured design context, variables, and a screenshot. Write is use_figma on the remote server. It entered open beta on 16 June 2026 and the docs still called it beta on 9 October 2026: free during the beta, usage-based pricing planned, a Full seat required to write outside drafts, and Dev seats read-only outside drafts. Code Connect maps a published component to code. Figma Make is a separate surface. Its GitHub path can open a pull request and is still a closed beta. Treat Make output as evidence, not as the production codebase.

Miro's official server was not re-fetched for this October pass. The June description — boards readable and writable, OAuth — is left standing with that caveat. Paper and pen.dev, the product formerly called Pencil, were re-read. Paper Desktop now ships for macOS, Windows, and Linux. The current connect path is the Paper CLI, paper mcp. The older HTTP endpoint at http://127.0.0.1:29979/mcp still runs while a file is open. pen.dev is free, with paid plans not yet published. Its MCP server still registers as pencil. The documented top-level tools are get_style, read_skill, get_app_state, and execute, plus browser and spawn_agents when those are enabled. Older names such as batch_design are not in that list. Check the live tool list in the client.

The browser servers are the half of the story designers overlook. Playwright MCP, from Microsoft, drives a real browser through its accessibility tree: navigate, resize, click, snapshot, screenshot. Chrome DevTools MCP, from Google, attaches to Chrome and reads what DevTools can read: console errors, network requests, performance traces, screenshots. Neither touches your design files. Together with a design server they complete the loop this article's case study traces — read the intent from the design tool, observe the reality in the browser, report the difference. Beyond these, community servers exist for most gaps (an API-key-based Figma server predates the official one, and OpenPencil ships its own), but treat them as third-party dependencies and check the registry before installing — more on that in the security section.

• Figma MCP (official, write still in beta): remote server preferred; use_figma writes on the remote server; Full seat to write outside drafts; Dev seats read-only outside drafts; free during beta.
• Miro MCP: not re-fetched on 9 October 2026. The June note said official, remote, OAuth, read and write. Confirm before you depend on a tool name.
• Paper MCP: Paper Desktop on macOS, Windows, and Linux; connect with paper mcp; legacy HTTP at 127.0.0.1:29979/mcp still works while a file is open.
• pen.dev MCP (server name pencil): free as of the pricing page; .pen file in the repo; documented tools are get_style, read_skill, get_app_state, and execute.
• Playwright MCP (official, Microsoft): drives Chromium, Firefox or WebKit; navigation, snapshots and screenshots for the implementation side of any review.
• Chrome DevTools MCP (official, Google): console, network, performance and screenshots from a real Chrome instance.
• Community servers: useful for gaps, but verify the publisher in the official registry and treat them like any other dependency you would audit.

Every agent platform asks you for the same three facts about a server: what to call it, how to start or reach it, and what credentials it needs. A local server is a command to run; a remote server is a URL plus an OAuth flow or a token. Once you see that triple, the per-platform differences stop being intimidating — they are the same sentence in four dialects, written into four differently named files.

Claude Code is the most common starting point for readers of this site, so here is its dialect first. The claude mcp add command registers a server at one of three scopes: local (just you, just this project), user (you, every project) and project. Project scope is the one teams should care about, because it writes a plain .mcp.json file at the repo root that you commit — the same logic as a checked-in DESIGN.md. A teammate who clones the repo gets the same servers after a one-time approval prompt. The /mcp command inside a session shows which servers are connected, lets you authenticate the OAuth ones, and lists the tools each exposes — worth running once after setup just to see how small these tool lists really are.

The example below wires up the three servers used later in this article: a design canvas, a browser, and Figma's remote server. The Figma entry only needs a URL because the server is remote; the first time the agent uses it you will be sent through Figma's OAuth screen. The shapes were re-checked on 9 October 2026. If a key name has drifted, the vendor page wins.

{
  "mcpServers": {
    "pencil": {
      "command": "npx",
      "args": ["@pencil.dev/cli", "mcp"]
    },
    "playwright": {
      "command": "npx",
      "args": ["@playwright/mcp@latest"]
    },
    "figma": {
      "type": "http",
      "url": "https://mcp.figma.com/mcp"
    }
  }
}

# or add them one at a time, choosing the scope explicitly:
$ claude mcp add --scope project playwright -- npx @playwright/mcp@latest
$ claude mcp add --scope project --transport http figma https://mcp.figma.com/mcp

# inside a session: check status, run OAuth, list tools
> /mcp

The other three platforms express the same triple — name, how to reach it, credentials — in their own files. Codex keeps MCP servers in config.toml, in ~/.codex/config.toml or in a trusted project's .codex/config.toml. A stdio server uses command and args. An HTTP server uses url. OpenCode uses a top-level mcp block in opencode.json, with type local or type remote and an enabled flag. Antigravity CLI does not nest servers inside settings.json. They live in ~/.gemini/config/mcp_config.json or .agents/mcp_config.json. A remote server uses serverUrl. The Gemini CLI keys url and httpUrl are rejected.

Enterprise Gemini CLI, still served for Code Assist Standard and Enterprise and for paid API keys, is a different config. Do not copy the Antigravity file into it and expect the keys to match. The snippets below were checked against the vendor docs on 9 October 2026.

The practical takeaway is portability. Your investment is in knowing which servers matter for your work and what their tools can do. Re-expressing that knowledge in a different dialect when you move platforms — or when half your team uses a different agent — is a fifteen-minute job, not a migration.

# ~/.codex/config.toml — Codex CLI
[mcp_servers.playwright]
command = "npx"
args = ["@playwright/mcp@latest"]

[mcp_servers.figma]
url = "https://mcp.figma.com/mcp"

// opencode.json — OpenCode (project root)
{
  "$schema": "https://opencode.ai/config.json",
  "mcp": {
    "playwright": {
      "type": "local",
      "command": ["npx", "@playwright/mcp@latest"],
      "enabled": true
    },
    "figma": {
      "type": "remote",
      "url": "https://mcp.figma.com/mcp",
      "enabled": true
    }
  }
}

// .agents/mcp_config.json — Antigravity CLI
{
  "mcpServers": {
    "playwright": {
      "command": "npx",
      "args": ["@playwright/mcp@latest"]
    },
    "figma": {
      "serverUrl": "https://mcp.figma.com/mcp"
    }
  }
}

A single design server is useful — it removes the copy-paste tax for one tool. The workflows that change how you work appear when the agent can call two servers in one conversation, because that is when it can compare sources of truth instead of just reading one.

Three chains come up constantly in design work. The first is token sync: read variables from the design tool, compare them against the CSS custom properties or token JSON in the repo, and report or fix the drift. The second is content sync: read real content from where it lives — a Miro research board, a CMS, a spreadsheet — and push it into design mockups so the layouts get tested against reality instead of lorem ipsum. The third, and the one this article traces, is the implementation review: read the design intent from the design server, capture the implementation through the browser server, and produce a structured report of where they disagree.

Chaining also has a failure mode worth naming early: context burn. Every tool result lands in the agent's context window, and design workflows are screenshot-heavy. A session that pulls full-page captures from a design canvas and the browser at three breakpoints each is spending a meaningful slice of its context on pixels before any reasoning starts. The fixes are unglamorous — request specific frames or nodes rather than whole pages, capture two breakpoints rather than five, keep review sessions separate from build sessions, and disconnect servers you are not using, because even an idle server's tool definitions take up space in every request.

• Token sync: design-tool variables compared against the repo's tokens — the chain behind keeping a design system honest.
• Content sync: real research or content pushed into mockups, instead of designing around placeholder text.
• Implementation review: design server for intent, browser server for reality, agent for the diff — the case study below.
• Anti-pattern: connecting every server you have to every session; tool definitions and screenshots both consume context.
• Anti-pattern: chaining write actions end-to-end with auto-approval; keep a human between read-and-compare and write-and-fix.

The case study the editorial plan asked for is a chained review of this site: read the design source through a design-canvas MCP server, capture the implemented pages through a browser MCP server, and have the agent produce the kind of P0-to-P3 review described in Visual QA with Agents. Honesty requires a clear label before the trace: in the session used to draft this article, the chain could not be executed end to end. The very first design-server call failed — the error appears verbatim in the transcript below, because it is the single most common failure anyone will hit with a local design server — and the drafting environment had no running design editor or dev server to retry against. What follows is a labelled reproduction. The failure is real. The later tool names — get_editor_state, get_variables, get_screenshot, batch_design — are the Pencil surface that session knew. pen.dev's documented tools on 9 October 2026 are get_style, read_skill, get_app_state, and execute. The findings are illustrative of the report format, not verified defects in this site.

The shape of the run is simple. The agent first asks the design server for its current state — which file is open, what is selected — then pulls the design variables and a screenshot of the relevant frame. That is the design contract: structure, tokens, and a reference image. It then turns to the browser server, navigates to the page, and captures it at a desktop and a mobile width. Both halves are now in its context, alongside the project's DESIGN.md, and the comparison step is plain reasoning: walk the surfaces, check tokens against tokens, spacing against spacing, states against states, and write up each difference with a severity, the breakpoint it appears at, and a proposed fix.

The first failed call is worth dwelling on because it teaches the most transferable lesson in this article: local design servers are only as alive as the app behind them. The Pencil server responds only when its editor is running and connected; Paper's server only exists while Paper Desktop is open; a browser server can only screenshot a dev URL if the dev server is up. When a chained review fails, it almost always fails at one of these seams, with an error that looks alarming and means nothing more than open the app and try again.

Counting honestly: assembled from documented tool surfaces, the full chain is eight to ten tool calls — three or four to the design server, four or five to the browser server — plus the comparison and write-up, and in practice the first attempt rarely survives without one connection or wrong-node retry. That is a few minutes of agent time for a review that takes a designer half an hour of tab-switching to do half as systematically, which is the trade that makes the setup cost worth paying.

> Review the articles index page against its design source. Use the design server
> for intent, the browser for the implementation, and report findings as P0-P3.

⏺ pencil — get_editor_state(include_schema: true)
  ⎿ Error: failed to connect to running Pencil app: WebSocket not connected
     # real output from this session — the design editor was not running.
     # fix: open the editor (or start the headless CLI), then retry.

# --- from here on: reproduced from the documented tool surface, not executed ---

⏺ pencil — get_editor_state(include_schema: true)
  ⎿ active file: designs/agenticdesign-school.pen · selection: "Articles index — desktop"

⏺ pencil — get_variables()
  ⎿ background, foreground, primary, secondary, accent, radius, spacing scale …

⏺ pencil — get_screenshot(nodeId: "<articles-index-frame>")
  ⎿ [reference image of the designed page]

⏺ playwright — browser_navigate(url: "http://localhost:3000/articles")
⏺ playwright — browser_resize(1280 × 900) → browser_take_screenshot()
⏺ playwright — browser_resize(390 × 844)  → browser_take_screenshot()

⏺ Comparing both against DESIGN.md and writing the review …
  ⎿ P1 · example: a panel radius above the documented 8px ceiling
  ⎿ P2 · example: badge wrapping under long titles at the mobile width
  ⎿ P3 · example: summary line-height drifting from the documented body value
     # findings shown are format examples, not verified defects in this site

Five steps, two servers, one report. The design-canvas variant is a labelled reproduction from documented tool surfaces; the Figma variant is reproduced from official docs and was not executed.

The same review with Figma as the design source was not executed for this article. The walkthrough below is documentation-level. On 9 October 2026 the write tool to name is use_figma on the remote server, still in beta, and a Full seat is required to write outside drafts. Re-check the tool list before you copy a call.

The configuration is the remote-server entry shown earlier: a URL, no command, OAuth on first use. The documented sequence mirrors the canvas variant. You give the agent a link to the frame or select it in the desktop app; it calls the tool that returns design context for that selection, which arrives as a structured representation of the layout and components rather than an image; it pulls the variable definitions for the same selection so token names and values are explicit; and it takes a screenshot of the frame as the visual reference. The browser half and the comparison are identical to the canvas variant — the design server only changes where the intent comes from.

Two practical cautions from the documentation are worth repeating. Rate limits differ sharply by seat type, and on the lighter seats they are tight enough that a single chained review can consume a meaningful share of a month's allowance — check your plan before making this a daily habit. And because the official server can also write to the canvas, the same permission posture applies as everywhere else in this article: the review chain needs only read tools, so there is no reason to pre-approve anything that creates or modifies frames.

MCP setups fail in repetitive, diagnosable ways. Almost every problem you will hit in the first month is one of six, and four of them are variations of something is not running. The table below maps the symptom you see to the cause that is usually behind it; the habit that makes all of them shorter is checking your platform's server status command — /mcp in Claude Code, the equivalents elsewhere — before assuming the problem is in your prompt.

The subtler failures are worth a sentence each. Long sessions can outlive a connection: a design server that worked an hour ago may have gone stale after the desktop app slept, and the fix is simply reconnecting or restarting the session. OAuth tokens for remote servers expire and need a re-authentication pass through the same consent flow as the first time. And occasionally the agent itself is the problem — it calls a tool with a parameter that does not exist or asks the design server for a node that is not selected. That is not a configuration bug; it is a prompting gap, fixed by being explicit about which file, frame or URL you mean.

An MCP server is code that runs with access to your tools and whose output lands directly in your agent's context. Treat it the way a careful engineer treats a dependency, because that is what it is. The MCP project publishes its own security best-practices document, and Claude Code's security docs say the quiet part plainly: use servers you trust or wrote yourself, and review what each tool can actually do before connecting it.

The first-order rules are about provenance and scope. Prefer official servers, and verify them in the official registry rather than installing whatever a search result suggests — name collisions and lookalike packages exist here just as they do on npm. Connect servers per project rather than globally, so a client project only sees the servers it needs. Scope the credentials: a Figma OAuth grant or a Miro token should belong to an account with access to the files this project requires, not your whole organization's workspace.

The second-order rule is the one designers tend to miss: content fetched through a server is untrusted input. Text layers in a Figma file, sticky notes on a Miro board, the visible text of a web page — all of it enters the agent's context, and any of it could contain instructions aimed at the agent rather than at human readers. This is prompt injection, and the defense is not paranoia about specific tools; it is keeping consequential actions behind permission prompts so that an instruction smuggled in through a sticky note cannot quietly become a file write, a canvas edit or an outbound request. Read tools can be pre-approved once you trust a server. Write tools — to the canvas, to the file system, to anything — should stay on ask, and the small friction of clicking approve is the feature, not the bug.

Platforms give you the levers to encode this. Claude Code lets a checked-in settings file declare which .mcp.json servers are enabled and which tools are allowed without prompting. OpenCode's enabled flags live in a reviewable JSON file. Antigravity can set disabled or disabledTools on a server in mcp_config.json, and its default toolPermission is request-review. The old Gemini CLI mcp.allowed allowlist is not the Antigravity control. The example below is the shape of a reviewed policy: read tools pre-approved, anything that mutates a design behind a prompt. pen.dev's current tool names are get_style, read_skill, get_app_state, and execute — match the live list, not a remembered batch_design call.

{
  "enabledMcpjsonServers": ["pencil", "playwright"],
  "permissions": {
    "allow": [
      "mcp__pencil__get_app_state",
      "mcp__pencil__get_style",
      "mcp__playwright__browser_navigate",
      "mcp__playwright__browser_take_screenshot"
    ],
    "ask": [
      "mcp__pencil__execute",
      "mcp__figma__*"
    ]
  }
}

# The principle, in one line per platform:
# Claude Code     — enable servers and allow specific read tools in checked-in settings
# Antigravity CLI — disabled and disabledTools in mcp_config.json; default toolPermission is request-review
# OpenCode        — keep "enabled" flags in opencode.json so server changes show up in review
# Codex CLI       — keep config.toml minimal and review it like any other dotfile change

MCP removes the copy-paste tax; it does not remove judgment, and it adds a few costs of its own. The most underrated one is context. Tool definitions for every connected server ride along with every request, and tool results — especially screenshots — are large. A session with six servers connected and a dozen full-page captures in its history will reason noticeably worse than a lean one, and some vendors now offer lighter-weight CLI alternatives to their own MCP servers precisely because of token cost. Connect what the task needs, not what the project owns.

The second risk is treating write access casually. The ecosystem's biggest change over the past year is that the major design servers can now modify canvases — Figma writes frames and components, Miro writes to boards, Paper and Pencil edit their files. That is genuinely useful and genuinely riskier than reading. An agent that misreads intent and writes forty wrong stickies to a workshop board, or restructures a Figma page, has created cleanup work that a read-only mistake never could. Keep writes behind prompts, prefer reviewable surfaces (a .pen file in git can be diffed and reverted; a live shared board cannot), and do not chain a write step directly onto an automated review without a human in between.

Three anti-patterns round out the honest list. Do not connect servers as a substitute for a design harness — an agent that can see your Figma file but has no DESIGN.md and no review gates will reproduce the file's pixels and miss its system. Do not build team rituals on top of beta surfaces without a fallback; rate limits, tool names and plan gating for the newest servers are still moving, which is why every claim in this article carries a date. And do not let MCP become the goal. The point is never the protocol; it is that the agent can finally see the same things you see, so that the conversations you have with it can be about design instead of about file transfer.

• Context is finite: every connected server and every screenshot costs tokens; keep sessions lean.
• Write access is the new risk surface: prompts before mutations, reviewable artifacts over shared live surfaces.
• MCP without a harness reproduces pixels, not systems — pair servers with DESIGN.md and review gates.
• Beta servers move: date your team's assumptions and re-verify rate limits and tool names before relying on them.
• If a workflow works without a server — a checked-in token file, a static export — the simpler path is often still the better one.

Everything above compresses into a short procedure you can run the next time a tool you use announces an MCP server. It takes about fifteen minutes, it ends with a working connection your whole team inherits, and it forces the two questions that matter — is this the real server, and what can it write — before the first impressive demo rather than after the first incident.

Run it once for a browser server and once for whichever design tool holds your source of truth, and you have rebuilt the chain in this article for your own project. From there, the workflows are the ones this site keeps returning to: reviews that compare intent to implementation, tokens that stay in sync because something is checking, and design files that an agent can read without you photographing them first.

# Connecting a new MCP server — checklist

## Verify
- [ ] The server is published by the vendor (check registry.modelcontextprotocol.io)
- [ ] You know whether it runs locally (command / desktop app) or remotely (URL + OAuth)
- [ ] You have read its tool list and know which tools WRITE to a design surface

## Connect
- [ ] Add it at project scope, in a file the team can review (.mcp.json or equivalent)
- [ ] Authenticate with an account scoped to this project's files, not the whole org
- [ ] Run one read-only call (editor state, a board read, a screenshot) to confirm it works

## Constrain
- [ ] Pre-approve only the read tools you actually use
- [ ] Leave write tools on ask; never blanket auto-approve a server
- [ ] Note rate limits or plan gating, with a date, in the project docs

## Document
- [ ] Record why this server is connected and which workflows use it
- [ ] Add the troubleshooting basics: which app must be running, which URL to use
- [ ] Set a reminder to re-verify capabilities — beta servers change quickly