PushToDisplay CLI and MCP server — send real-time updates to display boards from your terminal or AI agents
The server provides 8 well-named tools with complete Zod schemas and mostly good descriptions. All tools follow the verb_noun naming convention (send_update, list_boards, get_board, list_devices, create_board, update_board, set_default_board, delete_board). Schemas are present and properly typed with Zod validation. Descriptions are generally adequate (averaging ~90-120 characters), though some lack actionable context about when to use them or error recovery. Parameter descriptions are mostly present but lack some constraint details (e.g., 'boardId' has no guidance on format or examples). Output schemas are not documented, callers must infer structure from JSON responses. Error handling is minimal: no guidance on retryability, not-found cases, or user-fixable errors. The destructive tool (delete_board) lacks confirmation or dry-run support.
Create a new board.
Permanently delete a board and all its data. This action cannot be undone.
Get details of a specific board by ID.
List all boards owned by the authenticated user.
List active device-board stream connections.
Send a display update to a PushToDisplay board. Publishes text content to all devices connected to the specified board.
No output schema documentation. Callers cannot predict response structure, forces parse-and-infer pattern. The handler returns JSON.stringify(result), but no schema is provided so LLMs cannot plan downstream tool chaining or field extraction.
delete_board is a destructive operation with no confirmation, dry-run, or recovery guidance. Per pattern:confirmation-request, irreversible operations should require confirmation or support dry-run mode to prevent accidental data loss.
Error handling is silent. No guidance on retryable vs. fatal errors. If a board ID is not found or API rate limit is hit, the LLM receives raw JSON error with no actionable recovery hint (e.g., 'Board not found. Try list_boards() to verify ID.').
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | B | 73 | 2026-07-28+ | v2 |
Set a board as the user's default board. The default board is used when no board ID is specified in send_update.
Update an existing board's name, description, or layout.
Parameter descriptions lack actionable constraint details. 'boardId' is described as 'The board ID to retrieve' with no hint about format, length, or example. 'blocks' array has no guidance on max items, text length limits, or how color hex validation works. Per pattern:constrained-input, constraints should be explicit in descriptions.
List tools (list_boards, list_devices) lack pagination support. No limit, offset, or cursor parameters visible. For discovery tools, this is acceptable at small scale, but the description does not mention if results are capped or if pagination is needed.
Tool descriptions do not answer 'When should the LLM call this instead of a similar tool?' All list/get tools are minimal. For example, list_boards and get_board both retrieve board data, the description should explain when to use each.