Miro MCP: What an Agent Can Actually Read

Miro shipped an official MCP server in February 2026 and it works. You can point Claude Code at a board, ask what is on it, and get back a tidy summary of the sticky notes. That part is genuinely good, and it took about ninety seconds to set up.

Then you ask it something a whiteboard is actually for. Which of these three options did we pick, and why does that arrow go back to the second one? And the answer comes back confident and wrong, because the agent never saw the arrow.

Every page ranking for this term is a setup walkthrough. Miro owns half of them with its own docs. Nobody writes the other half, which is what the server hands your agent and what it quietly leaves behind. That is what this is.

What the Miro MCP server actually is

The Model Context Protocol, or MCP, is the open standard that lets an AI client call outside tools mid-conversation. If you want the ground-up version, we wrote a plain English explainer on what MCP is.

Miro’s implementation is a hosted remote server at https://mcp.miro.com/, announced on February 2, 2026 and built with Anthropic, AWS, GitHub, Google and Windsurf. It speaks streamable HTTP and authenticates with OAuth 2.1. There is no npm package, no API token, no local process.

The pitch is bidirectional. Your agent reads the board for context, and writes back diagrams, docs and tables so the rest of the team can see what it did. Miro’s supported client list runs to Claude Code, Cursor, VS Code with Copilot, Gemini CLI, OpenAI Codex, Replit, Lovable, AWS Kiro and Devin.

Miro also ships an official repo, miroapp/miro-ai, which bundles the server config together with a set of Claude Code skills for browse, code-review, code-spec, code-explain-on-board, diagram, doc and table. The skills are worth knowing about. They are prompt-level scaffolding on top of the same tools, and installing the plugin gets you both at once.

The tools, grouped by what they do

Miro documents the full set in its MCP tools reference. Here is the shape of it, because the raw list is long and most of it is write tools you will never call by name.

Reading a board: board_search_boards, board_list_items, context_explore, context_get, doc_get, table_list_rows, comment_list_comments, code_widget_list_items, code_widget_get, image_get_url, image_get_data, canvas_read_as_svg, prototype_read.

Writing to a board: board_create, diagram_create_mermaid, diagram_update_mermaid, doc_create, doc_update, table_create, table_sync_rows, image_create, code_widget_create, comment_reply, comment_resolve, canvas_create_from_svg, canvas_update_from_svg, prototype_create.

Two details in there matter more than the rest.

context_get is the metered one. Miro’s own table marks exactly one tool as spending AI credits, and it is the tool that turns a board or an item into text. Everything else, including every tool that lists and pages through items, is free. So the cheap workflow is to explore first and summarize last, not the other way round.

board_list_items filters by parent container. That is the flag that saves your context window. A busy Miro board has hundreds of items and cursor-based pagination will happily feed you all of them. Filtering to a single frame is the difference between a useful answer and an agent that spends its whole window reading sticky notes about a project you closed in March.

What it cannot read

Miro lists the item types the MCP works with in its own MCP server FAQ, and they are frames, sticky notes, shapes, text, cards, docs, tables, and images from public URLs, plus generated diagrams.

Read that list again and notice what is missing. There is no connector. There is no tool with the word connector in its name anywhere in the reference. Miro is upfront about why, describing the server as “a purposeful abstraction rather than a full mirror of the Miro REST API,” and pointing you at the REST API for anything it does not cover.

I understand the decision. I still think it is the wrong place to draw the line, and it is worth saying why plainly.

A whiteboard is not a list of items. It is items plus the relationships between them. Six sticky notes in a row and six sticky notes in a decision tree are the same six strings of text and completely different pieces of information. The arrows are where the thinking is. Strip them and you have handed the agent the nouns and kept all the verbs.

You can watch this happen. Ask an agent to summarize a Miro board holding an architecture sketch and you get a competent inventory of every box on it, delivered in the same confident tone it would use if it had understood the diagram. It will not tell you it could not see the lines, because as far as the tool result is concerned there were no lines.

Freehand drawing has the same problem for a different reason. Miro’s REST API v2 has no item type for pen strokes at all, so nothing downstream of it can see them either. If someone circled three cards and scrawled “this bit first,” that annotation does not exist to any agent, on any server, official or not.

This shape repeats across official servers, so it is worth recognizing rather than relearning. Trello’s official MCP server hands an agent every card title on a board and no comment on any of them, which loses the reasoning for exactly the same reason the missing arrows do here.

Official server vs the community one

There is exactly one community server worth considering, and the most-starred one on GitHub is not it.

That last row is the trap. evalstate/mcp-miro has more stars than any other Miro MCP server, it predates the official one by more than a year, and it has not been touched since December 2024. Directory sites rank by stars, so it still turns up near the top of aggregator listings. It is twenty months stale and it was written against an older API surface.

k-jarzyna/mcp-miro is the live one. Apache 2.0, 65 stars, pushed within the last week, and it wraps roughly sixty Miro SDK functions including connectors, frames, groups, tags and mindmaps. It needs Node 16 or later and a Miro API token in your environment.

So the honest recommendation is a split. Install the official server. It is first-party, it uses OAuth instead of a long-lived token, and it is the one Miro will keep current. Add the community server only if you have a specific job that needs the arrows, and treat the API token it requires with the caution any long-lived credential deserves. We went through how to vet an MCP server in more detail, and a personal API token sitting in a config file is the exact pattern that section is about.

Getting the arrows anyway

If you do need connector data, it is available. It is just two queries instead of one.

Miro’s REST API keeps connectors on their own endpoints, separate from items. Getting the items inside a frame does not return the lines between them. To reconstruct a diagram you pull the items, pull the connectors, and match each connector’s start and end item IDs back to the items you already have.

One constraint to know before you plan around it. Miro’s docs are explicit that “connectors that do not connect two items are not supported,” so a line drawn between two empty points on the canvas is not in the API at all. If your board uses free-floating lines as swimlanes or dividers, those are invisible even to the community server.

There is a much cheaper move available, and after two weeks of this I think it is the right default.

Stop asking the agent to read the drawing. Ask it to write the decision down. The doc_create and doc_update tools put a real document item on the board, and doc_get reads it back perfectly. So when a session ends in a conclusion, have the agent drop a doc next to the diagram summarizing what was decided and why. Next time, it reads that doc instead of guessing at the boxes.

This is the same problem as any other retrieval job. What survives the trip into a context window is whatever was already written as text, which is why how you chunk content for retrieval turns out to matter more than how much of it there is. A whiteboard is a hostile format for that, and the fix is to leave text behind on purpose rather than hope the tooling catches up.

The team switching thing

One operational detail that will catch you out and is easy to misread as a broken install.

The Miro MCP authenticates one team at a time. Miro’s FAQ calls this a 1:1 relationship between the connection and the team. If you belong to two Miro teams, say your company workspace and a client one, the agent can reach the boards in whichever team you authorized and nothing in the other. Switching means re-authenticating.

In practice that looks like board_search_boards returning nothing for a board you can see in your browser right now. The board is fine. The connection is pointed somewhere else.

The server is available across Miro plans, and Enterprise teams need an admin to approve it before anyone can connect, which is worth knowing before you spend twenty minutes debugging an OAuth flow that was never going to complete.

Where ContextBolt fits

The seam is a real one, so here it is plainly. Miro holds what your team drew. ContextBolt holds what you read on the way to drawing it, the articles, threads and posts you saved from the web and from X, Reddit and LinkedIn because they looked useful later. The two do not need to be wired to each other. They sit side by side in the same agent.

It is a Chrome extension. One click saves any web page with its article text, and your X, Reddit and LinkedIn saves are captured as you make them. Everything is AI-tagged and clustered on arrival, so nothing gets filed. Pro adds a personal MCP endpoint, and that is the half that matters here. The same Claude Code session that reads a frame off your board can search your saves by meaning, so a question about the trade-off you boxed in the corner gets answered from the thread you saved about it, not from the sticky note that summarized it.

There is a design point shared across both. ContextBolt’s bookmark server keeps its tool list short, search_bookmarks, list_clusters, get_cluster_bookmarks, get_recent_bookmarks and save_bookmark among them, because a server you leave running in every session has to be cheap to have running. Miro’s own advice to filter by frame rather than page a whole board is the same instinct arriving from the other direction.

Basic is free, with no account and no card, and is capped at 150 bookmarks. Pro is $6 a month, removes the cap, and adds cloud sync and the MCP endpoint.

Worth doing?

Yes, and probably not for the reason you came for.

As a way to get board context into an agent, it is partial. It reads the text on your board and misses the structure holding it together, and no amount of prompting recovers information the tool never returned. If your boards are mostly sticky notes, research dumps, retro columns or written specs, that limitation costs you almost nothing and the server is a straight win.

If your boards are diagrams, go in knowing the agent is reading an inventory, not a picture.

Where it earns its place immediately is the other direction. Generating a Mermaid diagram from a codebase and having it appear on a shared board, dropping a spec doc next to the sketch it came from, syncing a table of findings your team can actually see. That is the half of this nobody was doing before February, and it is the half that works completely.

Install the official one. Filter by frame. Spend your AI credits on context_get only when you know what you are asking about. And write the decisions down, because the arrows are not coming through.

Then give the same agent the reading behind the board. ContextBolt is free up to 150 bookmarks, needs no account, and runs alongside the Miro server in the same session.