You can connect Miro to Claude in a few minutes using the Model Context Protocol (MCP), and once it’s connected, Claude can read and create diagrams, sticky notes, and frames directly on a Miro board instead of you describing the board in a prompt and pasting screenshots back and forth. Miro’s OAuth also just works with a new client, unlike several other design tools in this series. This guide covers what the Miro MCP server does, both ways to connect it, and why a shared, multiplayer board deserves a different kind of caution than a personal file.

What the Miro MCP server actually does

Miro publishes a remote MCP server at mcp.miro.com that exposes your boards — frames, sticky notes, shapes, connectors — as tools Claude can call directly. See the Miro server page in gate’s directory for the current tool list and connectivity status. In practice that means prompts like:

  • “Summarize everything on the ‘Q3 retro’ board into three themes.”
  • “Turn these bullet points into sticky notes on a new frame.”
  • “List every action item written on the board and who it’s assigned to.”
  • “Lay out a simple flowchart for this signup process.”

Claude reads and writes through the same permissions your Miro account already has — it isn’t a read-only snapshot of a board, it’s your account acting on the board directly, which matters more than it sounds like once you remember most Miro boards aren’t yours alone.

Option 1: Connect Miro to Claude directly

Claude supports remote MCP servers natively. The short version of the setup:

  • Open Claude’s connector or MCP settings.
  • Add a remote server pointing at Miro’s MCP endpoint.
  • Sign in with your Miro account when prompted — this is standard OAuth, so Claude never sees your Miro password, and you can revoke access from Miro’s own account settings at any time.

That’s enough for one person using Miro inside Claude. The tradeoffs show up once you add a second tool or a second person: every additional AI client (ChatGPT, Cursor, an agent) needs its own copy of that same connection, its own OAuth grant, and its own place where the config can go stale or get lost.

Option 2: Connect it once, through a gateway

If you’re already juggling more than one MCP server, or more than one AI client, wiring each pair directly gets old fast — that’s the connection sprawl we wrote about in what an MCP gateway is. The alternative is connecting Miro (and everything else) to one gateway URL, then pointing every AI client at that single URL instead of reconfiguring each one.

With gate specifically, connecting Miro looks like this: add gate’s gateway URL to Claude once, then pick Miro from the MCP servers directory and sign in with OAuth the same way you would directly. From then on, Miro’s tools are available in every client connected to your gate URL — Claude, ChatGPT, or Cursor — without a second setup step.

Why the connection matters for a shared board

A whiteboard MCP server is a different risk shape than a single-player document editor — a Miro board is usually shared with a team, and what Claude can read or move on it is whatever your account can already reach, not just the one board you had in mind. A few things worth checking before or right after you connect:

  • Which teams and boards can it actually reach? An MCP connection to Miro typically covers every board your account can open, including ones owned by other teams in the same workspace, not just the board open in your browser tab.
  • Can it delete or rearrange content, not just add to it? Check whether the tools you’ve granted can move, overwrite, or remove existing frames and notes — useful for cleanup, risky if a prompt goes sideways on a board other people are actively using.
  • Who else on your team can reach it? If more than one teammate connects Miro to their own AI client, you likely want a shared, revocable setup rather than everyone holding their own token — the same access-control question we cover in MCP access control for teams.

You can run a quick, no-signup check on any server’s tool list — including ones that require OAuth, once connected — with gate’s free MCP security scanner, which looks for prompt injection and hidden instructions in tool descriptions before you rely on a server day to day.

Troubleshooting the connection

A few things that commonly go wrong when connecting any remote MCP server, Miro included:

  • Claude can’t find a board you know exists. Miro’s tools respect your permissions in Miro itself — if a board lives in a team you don’t belong to, or you haven’t opened it before, Claude won’t see it either.
  • OAuth prompts you into the wrong workspace. If you’re a member of more than one Miro organization, make sure you’re authorizing from the workspace you actually meant to connect — a mismatched org is the most common cause of “my boards aren’t there.”
  • Tools disappear or change shape after a Miro update. Remote servers can change their tool list without warning. If you’re connected through a gateway, that’s exactly what drift detection is meant to catch.

The bottom line

Connecting Miro to Claude with MCP takes a few minutes either way: point Claude directly at Miro’s server and sign in, or connect it once through a gateway if you want the same Miro access available in every AI client you use, with the server’s tools checked before they go live. Either way, treat write access to a shared board the way you’d treat any other tool that acts on your team’s behalf — worth a minute’s thought about who else is on that board before you say yes.