mcp-screen
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| PORT | No | Port the canvas server listens on (CLI option --port, default 4747) | 4747 |
| NO_OPEN | No | Do not automatically open the canvas in a browser (CLI option --no-open) |
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 | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| place_widgetA | Show something to the human on their mcp-screen canvas (a browser tab next to the terminal). Returns the widget id. Widget kinds and their data:
|
| update_widgetA | Update an existing widget. |
| read_widgetB | Read a widget back, including |
| read_canvasA | List every widget on the canvas with its id, kind, title, live status and current selection. |
| remove_widgetB | Remove a widget (and stop its live refresh). |
| clear_canvasA | Remove every widget from the canvas (standup cards stay). The human can undo it from the canvas, or you can call clear_canvas with undo:true right after. |
| ask_userA | Ask the human a visual question: places clickable choice cards on the canvas and BLOCKS until they click one (or the timeout passes). Use it for decisions that are easier to make by looking: layouts, copy options, which bug to fix first. Returns {answered, choice:{id,label}} or {answered:false, reason}. |
| post_reportB | Post a standup card when you finish a task: what you changed, test results, a short summary and risks. Cards are grouped by worktree and agent on the Standup board. |
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 8 tools
Each tool has a clearly distinct purpose: place/update/read/remove widgets, read/clear the canvas, ask the user, and post reports. There is no overlapping functionality; the only potential confusion is between read_widget and read_canvas, but they operate at different scopes (single widget vs. entire canvas).
All tool names follow a consistent snake_case verb_noun pattern (place_widget, update_widget, read_widget, read_canvas, remove_widget, clear_canvas, ask_user, post_report). No deviations or mixed conventions.
With 8 tools, the set is well-scoped for a canvas UI management server. Each tool earns its place, covering creation, updates, reads, removals, bulk clearing, user interaction, and reporting without redundancy.
The surface provides full CRUD for widgets (create, read, update, delete, list), bulk clear, plus user interaction and reporting. No obvious gaps for the stated purpose; minor operations like reordering or renaming titles are not essential and can be inferred as part of widget data or skipped.