Miro MCP server

create_mindmap_node

Creates a native Miro mind map node and computes x/y positions automatically unless coordinates are provided. Attach it under an existing parent and use layout_sibling_index to prevent stacked nodes.

Instructions

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

Input Schema

TableJSON Schema

Name	Required	Description
`x`	No	Board X coordinate; if omitted with y, a non-collapsed position is computed automatically
`y`	No	Board Y coordinate; if omitted with x, a non-collapsed position is computed automatically
`width`	No	Node width in pixels (geometry.width)
`content`	Yes	Text shown in the mind map node
`board_id`	Yes	Miro board ID
`parent_node_id`	No	Existing mind map node id to attach under; omit for a new root node
`layout_sibling_index`	No	0-based vertical index among children of this parent (LTR: all children share parent.x + offset; Y staggers). Use when list_mindmap_nodes lags so counts stay wrong

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Sep 13, 2026

TDQS

A4.3/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden and does well: it discloses the experimental API status, that the server auto-computes x/y, that missing coordinates default to (0,0) and stack nodes, the allowed request fields, and rate-limit behavior. It omits auth/permission requirements and what happens on an invalid parent_node_id.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with the essential layout rule (LTR, children to the right, vertical sibling spacing) before the supporting rationale. It is dense but the excursion into why the desktop + button lacks coordinates and the dual doc links make it longer than strictly necessary.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a create tool with no annotations and no output schema, the description covers the layout model, coordinate fallback, sibling indexing, and rate limits well. Remaining gaps are auth requirements and error/return behavior, which are not covered anywhere given the missing output schema and annotations.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the per-parameter descriptions already carry most meaning (baseline 3). The description goes beyond by explaining how x/y auto-computation interacts with parent_node_id and layout_sibling_index, plus a worked example showing root/child/leaf combinations, which clarifies parameter interaction rather than just restating fields.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Creates a native Miro mind map node') and scopes it to the experimental REST API. It is immediately distinguishable from siblings like create_sticky_note, create_shape, and update_mindmap_node/delete_mindmap_node.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives concrete when-to guidance: omit parent_node_id for a root, pass layout_sibling_index when creating several children quickly because list_mindmap_nodes lags, and insert delays for rate limits. It does not, however, explicitly state when to prefer a mind map node over sibling primitives like create_sticky_note or create_shape.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server

create_mindmap_node

Instructions

Input Schema

Schema Changelog

TDQS

Other Tools