Miro MCP Server: Setup, Tools & Real Limits
Miro's official remote MCP endpoint turns boards into agent-readable context and writable canvases, but its OAuth, quotas, and layout quality need careful handling.
The Miro MCP Server is Miro’s official remote gateway for letting an MCP-compatible AI client read, summarize, search, and change Miro boards. Connect https://mcp.miro.com, authorize one Miro team through OAuth, and the agent can create diagrams, documents, tables, images, comments, and layouts—within your existing board access and daily call allowance.
Table of contents
- What Miro MCP actually is
- What exists today
- Setup
- Tools you get
- Permissions and blast radius
- Real limits
- When not to use it
What Miro MCP actually is
Miro MCP is a hosted translation layer between an AI client and a Miro workspace. It exposes named operations the model can call, so a prompt such as “summarize this board, then turn unresolved feedback into an action table” can become several authenticated board actions rather than copied-and-pasted text.
The useful distinction is between understanding and editing. The server can retrieve raw items, extract higher-level context, read documents or comments, and then create or update board artifacts. Miro’s official introduction names concrete outputs including frames, sticky notes, shapes, text, cards, docs, tables, public-URL images, and diagrams. For readers comparing this with other integrations, our capability index explains how MCP tools differ from passive resources and prompts.
My view: its best job is converting messy visual context into a bounded deliverable—a summary, diagram, table, or comment response. I would not give an agent a vague instruction to “clean up the board.”
What exists today
There is now a first-party Miro MCP Server, so the old advice to install an unofficial npm wrapper is obsolete for most users. Miro hosts the remote endpoint, documents it, and maintains the related miroapp/miro-ai repository, which includes integrations and skills for supported AI clients.
That changes the production calculation. You do not need to entrust a long-lived personal token to an unknown local package, and you do not need to run server infrastructure. The official service uses an interactive OAuth flow and inherits current Miro permissions. It is also listed alongside other vendor-backed options in our official MCP collection.
Community servers may make sense for an omitted API operation or mandatory local processing. The trade-off is ownership: you must review source, pin versions, manage credentials, and monitor API changes. I would start with Miro’s endpoint and add custom REST code only for a documented gap, rather than making a community wrapper the default path.
Setup
Setup requires a recent MCP client that supports remote HTTP servers and OAuth, plus access to the Miro team containing your boards. Free, Starter, Business, and Education accounts can connect directly; Enterprise admins must enable MCP for the relevant organization or selected teams, according to Miro’s user enablement guide.
- Open the client’s MCP or connector settings. If it offers an official Miro plugin, use that installation route.
- Otherwise add the official remote endpoint with the configuration shape Miro publishes:
{
"mcpServers": {
"miro": {
"url": "https://mcp.miro.com/"
}
}
}
- Trigger a Miro operation, complete the browser-based OAuth flow, and select the team that owns the target board.
- Test with a full board URL and a read request, such as asking for its frames or a short summary.
Do not configure both the plugin and the manual endpoint. Miro’s troubleshooting guide says duplicate installation methods create separate OAuth sessions, repeated tools, and authentication confusion. If your client uses a different schema, use its native UI or adapt the verified endpoint with our configuration generator; do not copy client-specific keys blindly. No developer token or hand-selected REST scope belongs in this remote-server config.
Tools you get
The server exposes a broad but curated tool set, not every Miro API endpoint. These are representative names from Miro’s current tools reference, and they are the ones I would use to test a connection before attempting a larger workflow.
| Tool name | What it does | Risk |
|---|---|---|
board_list_items | Lists board items with cursor pagination and filters | Read |
board_search_boards | Searches boards accessible in the authorized team | Read |
context_get | Extracts text context from a board or item | Read; uses AI credits |
layout_read | Returns existing items as Miro’s layout DSL | Read |
diagram_create | Creates a diagram from DSL text | Write |
layout_create | Creates multiple positioned items from layout DSL | Write |
doc_create | Adds a structured document item | Write |
table_sync_rows | Inserts or updates rows by a matching key | Write |
comment_list_comments | Reads board or item comment threads | Read |
comment_resolve | Resolves or reopens a comment thread | Write |
The DSL tools are the differentiator: they let an agent create a coordinated layout in fewer calls than placing every sticky and connector separately. They are also where mistakes become visually expensive. I would first call layout_read, ask for a proposed placement outside occupied coordinates, and approve one frame-sized change. Treat live tool discovery in your client as authoritative because names can change.
Permissions and blast radius
Miro MCP acts with the authenticated user’s current access, so the safest identity is one that can view the necessary boards and edit only a sandbox or explicitly chosen production board. OAuth is not a read-only safety switch if the server presents write tools and the connected identity already has edit rights.
Start on a duplicated board and keep client-side confirmation enabled for writes. Miro says authorization is one user to one team at a time, and access is evaluated against current board permissions; losing access removes the server’s access rather than leaving a copied entitlement behind. The official FAQ also confirms OAuth 2.1 with dynamic client registration.
A careless write has Miro-specific consequences: bulk layout creation can overlap workshop content, table upserts can replace rows when the chosen key matches, comment resolution can hide an active discussion, and a document update can alter a shared source of truth. I would avoid an all-access executive account. Use a dedicated integration member where licensing and policy permit, restrict its board membership, and require approval before writes.
Real limits
The practical limits are daily calls, one-team authentication, finite model context, curated object support, and nondeterministic layout quality. These constraints matter more than connection speed, because they determine whether a workflow completes reliably.
Miro currently documents 100 MCP tool calls per day on Free, 500 on Starter, 2,000 on Business, and 10,000 on Enterprise, resetting at 00:00 UTC. Every tool invocation counts, whether or not it consumes Miro AI credits; context_get does consume AI credits. Non-Enterprise users cannot currently inspect usage in-product and discover exhaustion through an error. See Miro’s daily limits page for the latest figures.
Large boards create a second ceiling. board_list_items paginates, but pulling hundreds of items into an agent can exhaust its context window or bury the relevant signal. Search or filter by frame and item type, summarize in stages, and pass only the needed result forward. Parallel calls can also trigger stricter tool-specific or standard API rate limits; reduce concurrency and retry later rather than launching another swarm of reads.
Finally, the server is not a full REST mirror. Miro’s MCP-versus-REST comparison says team, organization, and project data are outside MCP, and the MCP interface favors a curated set of formats. The OAuth connection is also “last one wins”: authorizing another team or client supersedes the previous connection. That is a poor fit for unattended cross-team automation.
When not to use it
Do not use Miro MCP when the workflow must be deterministic, high-volume, event-driven, or spread across teams. A plain REST integration is easier to test, retry, log, and constrain when exact item IDs, scheduled synchronization, organization data, or predictable transformations matter.
The choice is straightforward:
| Need | Better choice | Why |
|---|---|---|
| Ad hoc board summary or diagram from a chat | Miro MCP | The agent can reason over context and choose tools |
| Scheduled CRM-to-board synchronization | REST API script | Repeatable mappings, explicit errors, and controlled retries |
| Live panel inside an open board | Miro Web SDK | It provides in-canvas UI and session events |
| Brainstorming or rewriting wholly inside Miro | Miro AI | Less data movement and no external client setup |
| Bulk changes across many boards | REST API script | MCP quotas and model judgment add unnecessary failure modes |
I would choose Miro’s own AI features when collaborators want ideation, clustering, or content generation without leaving the canvas. I would choose MCP when an external coding or reasoning agent needs board context as one step in a human-supervised task. Browse our best MCP servers if the workflow also needs source control, tickets, or documents—but add integrations one at a time, because every extra writable system expands the blast radius.