Feature request: Expose "Create board from frame" as MCP tool #57

Summary

Please expose Miro's existing UI action "Create board from frame" as an MCP tool (and ideally as a documented REST API endpoint). Agents today cannot invoke this native operation and must reconstruct frames manually via layout_read + layout_create, which is slower, lossy, and error-prone.

Submitter: Rick Sipin — rick@sipin.org
MCP client: Cursor

Proposed tool (sketch)

Name: board_create_from_frame (or frame_copy_to_board)

Inputs:

• source_miro_url — board URL with ?moveToWidget=<frame_id> targeting the frame to copy
• name — name for the new board (required)
• description — optional board description
• copy_mode — optional: copy (default, leave source unchanged) vs move (if ever supported)

Output:

• New board miro_url
• New frame miro_url (root frame on the new board)
• items_copied_count / items_skipped_count with reasons for skipped items

Behavior: Match the product UI feature: create a new board containing the selected frame and all supported child content (stickies, shapes, text, connectors, images, nested frames, etc.) with faithful geometry and parent/child relationships.

Motivation

We attempted to copy the "Event Storming Defined" frame from an Event Storming example board to a new board using MCP only. The manual DSL path worked partially but exposed clear gaps:

A first-class create board from frame tool would let agents perform the same operation users already trust in the UI.

Problems with the current workaround (layout_read + layout_create)

1. Unsupported item types — layout_read reported "skipped 2 unsupported items" (images) on our test frame.
2. Connectors — from/to local aliases only resolve within a single layout_create call; cross-batch or cross-board copies require remapping every endpoint to full item URLs.
3. Parent frame scope — parent=esd_frame aliases do not persist across separate layout_create batches; later batches created 84 items without a frame parent, shifting positions until manually corrected.
4. No nested frame fidelity — separate board-level frames near the source frame are not included when reading one frame; UI copy may behave differently.
5. Payload limits — large frames require batching, which compounds alias/parent/connector issues.
6. Rate limits & round-trips — reconstructing 200+ items is many API calls vs one native copy.

Real-world test case (optional reference for QA)

• Source board: Event Storming Example — frame "Event Storming Defined"
• Goal: New board with same name, frame copied, source board unchanged
• Manual MCP copy board: https://miro.com/app/board/uXjVHEXdRP4=/
• Connectors: 53 required a second pass with coordinate-based ID remapping

Suggested acceptance criteria

• New MCP tool creates a board from a frame URL in one call
• Source board/frame unchanged (copy semantics)
• Connectors, images, and nested frames preserved when the UI feature would preserve them
• Child item positions match source frame-relative layout within reasonable pixel tolerance
• Documented in Miro MCP Tools & Prompts
• Optional: equivalent REST endpoint for non-MCP integrations

Contact

Rick Sipin — rick@sipin.org

Thank you for considering this. Happy to provide additional reproduction details or retest a beta implementation.