design-canvas-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
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 | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| list_routesA | List all routes currently displayed on the Design Canvas. Returns each route's ID, path, viewport dimensions (width × height), and canvas position. USAGE: Call this before removing routes (you need the route ID for precise removal) or before adding routes (to avoid duplicates). Route IDs are stable — use them to reference specific frames. |
| add_routeA | Add a web page route to the Design Canvas. The route is loaded from the connected dev server and displayed as a live frame on the infinite canvas. Returns the route ID for future reference. CONSTRAINTS:
RESPONSIVE COMPARISON: To compare layouts at different viewports, add the same path multiple times with different widths. Example: add '/dashboard' at width 1280, then add '/dashboard' again at width 375. |
| remove_routeA | Remove a route frame from the Design Canvas. CONSTRAINTS:
|
| capture_canvasA | Capture fresh screenshots of routes on the Design Canvas. Triggers a new render (not cached), waits for pages to fully load, and returns screenshots as images. Screenshots use WebKit rendering — use for quick layout verification, not pixel-perfect cross-browser QA. USAGE: Use after making code changes to visually verify how routes look. This is an expensive operation (several seconds) — do not call speculatively. CONSTRAINTS:
|
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 4 tools
Each tool has a clearly distinct purpose: listing, adding, removing, and capturing. There is no overlap in functionality, and the descriptions strongly reinforce the boundaries between them.
All four tool names follow the same verb_noun pattern (list_routes, add_route, remove_route, capture_canvas). The naming is consistent, predictable, and easy to infer.
With 4 tools, the set is well-scoped for the server's purpose of managing routes on a design canvas. Each tool covers a core operation without unnecessary redundancy.
The set covers the main lifecycle (list, add, remove) and adds a capture action. An update route operation is missing, but adding/removing routes can serve as a workaround, so the gap is minor.