An MCP server providing tools to interact with Miro boards, including creating, reading, updating, and deleting items such as text, shapes, sticky notes, images, cards, documents, embeds, and frames.
Server demonstrates adequate tool definition quality with mostly complete schemas and reasonable descriptions. However, several parameters lack descriptions, output schemas are not documented, and error handling guidance is minimal. The server uses FastMCP framework with Zod validation, which provides some structural rigor, but documentation falls short of production standards. Average tool score: 62.
Deletes a specific item (sticky note, text, shape, card, document, embed, image, app card) from the current board.
Retrieves a list of items on the current board. Supports filtering by type and pagination.
Retrieves information about the current board.
Updates the current board.
Updates the position or parent of a specific item on the current board.
Output schemas not documented. Tools return formatted JSON responses via formatApiResponse(), but no JSON Schema definition of the response structure is provided. LLMs cannot predict the structure of returned data to plan downstream operations.
Error handling lacks recovery guidance. formatApiError() throws generic error messages ('Miro API Error (status): ...'). LLMs have no actionable next steps: should they retry? Call a different tool? Ask the user? No differentiation between retryable and fatal errors.
Parameter 'limit' in get_items is a string type but semantically a numeric constraint. Schema declares z.string() but description references '10-50' as numeric bounds. Should be z.number().min(10).max(50). Current definition invites type confusion.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | B | 75 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 0 | - | v1 |
Tool update_item_position_or_parent conflates two independent operations (position update and parent reparenting) into one tool. LLM intent is clearer if split into update_item_position and update_item_parent. The combined name is ambiguous about which operation takes precedence if both are provided.
No pagination documentation in get_items. Cursor and limit are present, but tool description does not explain how to iterate through large result sets, whether cursor is required on second call, or what 'total' count would be. Agents may misuse pagination.
Destructive tool delete_item lacks confirmation or dry-run capability. No pattern to prevent accidental deletion. Tool is directly callable without a pre-check or confirmation step.
get_items description does not explain what fields are returned for each item. LLM cannot determine whether to call this before or after other tools, or what item metadata is available for chaining.