Miro MCP server
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| MIRO_TOKEN | Yes | Miro OAuth access token with boards:read and boards:write scopes. | |
| MIRO_BOARD_ID | No | Optional board ID for integration testing. |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| list_board_itemsA | Lists all items on a Miro board, optionally filtered by type. Use this to understand what is already on the board before creating or modifying anything. Returns item IDs, types, positions, and text content. |
| get_board_infoA | Returns metadata about a Miro board: its name, description, creation date, owner, and dimensions. Use this at the start of a session to confirm you are working on the correct board before reading or modifying content. |
| create_sticky_noteA | Creates a sticky note on a Miro board at a specified position. Use this to add ideas, tasks, labels, or annotations. You can optionally place it inside a frame. Choose a color that matches the semantic meaning (e.g. yellow for ideas, red for blockers, green for done). |
| create_frameA | Creates a named frame (a rectangular container) on the board. Frames are used to group related content into sections. Use this before populating a new area with items so they can be logically grouped. Returns the frame ID which you can then use to place items inside it. |
| create_shapeA | Creates a geometric shape (rectangle, rounded rectangle, circle, pill, etc.) on the board with optional text inside. Use this to create labels, containers, or visual nodes in diagrams and flows. For Miro's native mind map widgets (hierarchy, auto connectors), use list_mindmap_nodes and create_mindmap_node instead. |
| create_connectorA | Creates a connector (line/arrow) between two existing items on the board. Use this to draw relationships in diagrams (e.g. link shapes, stickies, or cards). You need the item IDs of both endpoints — call list_board_items first if you don't have them. Native mind map hierarchies use create_mindmap_node instead of manual connectors. |
| list_mindmap_nodesA | Lists native Miro mind map widget nodes on a board using the experimental REST API.
This is not the same as generic board items from list_board_items: mind maps are
text-based nodes with hierarchy and auto-managed connectors. Use this to read an
existing mind map (node IDs, parents, text, positions when the API returns them).
Each node includes |
| create_mindmap_nodeA | Creates a native Miro mind map node (experimental REST API). Layout rule for this tool: left-to-right mind maps only—the root is leftmost; every child is always placed to the RIGHT of its parent (positive X offset); multiple children of the same parent are spaced vertically (layout_sibling_index 0,1,2,…). The Miro desktop + button does not send coordinates because the app runs its own layout engine; the REST create endpoint still requires a position object and defaults missing coordinates to (0,0), which stacks nodes—see https://developers.miro.com/reference/create-mindmap-nodes-experimental —so this server computes x/y for you unless you pass explicit x/y. MindmapCreateRequest allows only data.nodeView, position, geometry, parent. When creating several children under one parent in quick succession, list_mindmap_nodes often lags—pass layout_sibling_index per child so Y offsets differ. Example: root Center (optional x/y); under Center—node1 with layout_sibling_index 0, node2 with 1 (both to the right of Center); under node1—four leaves with indices 0–3; under node2—four leaves with 0–3. Insert short delays between calls for rate limits. Overview: https://developers.miro.com/docs/mind-maps |
| delete_mindmap_nodeA | Deletes a native mind map node and all of its descendant nodes (experimental REST API). Use list_mindmap_nodes to find node ids. See https://developers.miro.com/docs/mind-maps |
| update_mindmap_nodeA | Updates the HTML/text content of an existing native mind map node (experimental PATCH).
Use this instead of update_item_content: generic GET /items/{id} does not support mindmap_node.
Content is stored in data.nodeView (same shape as create). Example: |
| update_item_contentA | Updates the text content of an existing sticky note, shape, or text item on the board. Use this to correct or improve existing content without moving or deleting the item. Requires the item ID — call list_board_items first if you don't have it. |
| move_itemA | Moves an existing item to a new position on the board. Use this to reorganize layout, avoid overlaps, or align items visually. Coordinates are absolute board coordinates (center of board is 0,0). |
| delete_itemB | Deletes an item from the board permanently. Use with caution. Use this to clean up placeholder content or remove outdated items. Requires item ID. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 13 tools
Each tool targets a distinct item type or action, and the descriptions explicitly clarify the tricky boundary between generic items (update_item_content, delete_item) and native mind map nodes (update_mindmap_node, delete_mindmap_node). Minor ambiguity remains around whether delete_item/move_item apply to mind map nodes, but overall boundaries are clear.
All 13 tools follow a strict snake_case verb_noun pattern (list_board_items, create_sticky_note, update_mindmap_node, delete_item), with a consistent `<verb>_<resource>` structure across both generic and mind-map-specific tools. No convention mixing.
13 tools is well-scoped for a board-manipulation server, with each tool earning its place by covering a distinct item type or lifecycle operation. No redundant or filler tools.
Covers solid create/read/update/delete across standard items (sticky, shape, frame, connector) and mind map nodes. Minor gaps exist: no way to discover/list available boards to obtain a board ID, and no update for connector endpoints or item styling/geometry beyond content.