MCP Server vs REST API
Differences between the MCP Server and REST APIs and when to use each one.
MCP Server vs REST API
The Miro Developer Platform gives you two very different ways to work with a board programmatically: the MCP Server, driven by AI prompts, and the REST API, driven by your own code. This page explains what the MCP Server can do and how it compares to the REST API, so you can pick the right one for your use case.
Who this is forDevelopers deciding whether to build with Miro's MCP Server, the REST API, or both. Some familiarity with REST APIs and AI coding tools helps, but isn't required.
What the MCP Server can do
Miro's MCP Server connects an AI agent (such as Claude, Cursor, or GitHub Copilot) directly to your boards. Instead of writing requests, you write prompts, and the agent calls the right tools for you. The tools group into a few areas:
- Read and search boards: list items, explore high-level formats, search across boards, and pull text context to summarize what's on a board.
- Build board content: create boards, diagrams, documents, tables, images, code widgets, and multi-item layouts from a single prompt.
- Update content: edit documents, tables, code widgets, and layouts with find-and-replace.
- Work with comments: read comment threads, reply to them, and resolve or reopen them.
For the full list of tools and what each one does, see the Miro MCP Server Tools and Prompts page.
How the MCP Server and REST API differ
Both let you create and read board content, but they suit different jobs. The MCP Server is built for AI-assisted, conversational work. The REST API is built for reliable, programmatic integrations.
| Capability | Miro MCP Server | Miro REST API |
|---|---|---|
| Primary interface | Natural-language prompts through an AI client | HTTP requests you write in code |
| What drives the actions | An AI agent (Claude, Cursor, Copilot, and other MCP clients) | Your application code |
| Create and update board items | ✅ Boards, diagrams, docs, tables, images, code widgets, layouts | ✅ Cards, sticky notes, shapes, text, images, frames, connectors, tags, and more |
| Generate diagrams from text or code | ✅ From DSL, in a single prompt | ❌ Build items one by one |
| Summarize and understand board content | ✅ Semantic context with context_get (uses AI credits) | ❌ Returns raw item data, no summary |
| Generate code from a board | ✅ | ❌ |
| Read, reply to, and resolve comments | ✅ | ❌ Not supported |
| Access team, organization, and project data | ❌ | ✅ On Enterprise plans |
| Webhooks and event subscriptions | ❌ | ❌ |
| Backend hosting | Not required | Required for most integrations |
| Authentication | OAuth 2.1, handled by your MCP client | OAuth 2.0, implemented by you |
| Programming language | Any MCP-compatible client | Any language |
| Plan requirement | Enterprise plan only | Any plan, free to use |
| Best suited for | AI-assisted board creation and understanding | High-volume, deterministic integrations |
You can use bothThe two aren't mutually exclusive. A team might use the MCP Server for AI-assisted board creation and the REST API for scheduled data sync from a backend.
When to use the MCP Server
Reach for the MCP Server when the work is conversational and AI-driven:
- You want to turn a PRD, code, or notes into a diagram without writing code.
- You want an AI agent to read a board and summarize it or generate code from it.
- You're working inside an AI tool like Claude, Cursor, or Copilot and want it to act on your boards.
- Your organization is on the Enterprise plan and has enabled the MCP Server.
When to use the REST API
Reach for the REST API when you need control, scale, and predictability:
- You're building an integration between Miro and a third-party product or backend.
- You need deterministic, repeatable operations rather than AI-mediated ones.
- You need team, organization, or project data, or webhooks for board events.
- You want to work in any programming language, on any plan.
How this fits with the Web SDK
Miro also offers the Web SDK, which this page leaves out of the comparison table because it solves a different problem. The Web SDK runs inside a board in the browser and powers in-canvas experiences: custom panels and modals, drag and drop, and live interaction with users while they work. Reach for it when your app needs a UI on the board itself.
Web SDK events are not REST webhooksThe Web SDK has a board events system, but it fires only while a user has the board open and your app running, so it suits live, in-session reactions. For durable, server-side automation that runs whether or not the board is open, use REST webhooks.
For a full feature-by-feature comparison, see Web SDK vs REST API.
MCP Server resources
REST API resources
Updated about 7 hours ago