Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@design-canvas-mcp Show me all routes on the canvas."
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
MCP server for Design Canvas — control the infinite canvas from AI coding agents.
Design Canvas is a native Mac app that shows all your web app's routes on an infinite canvas with live browser views. This MCP server lets AI agents (Claude Code, Cursor) add routes, capture screenshots, and manage what's displayed.
Design Canvas Mac app must be running on your machine
The app must be connected to a running dev server (e.g., localhost:3000)
Node.js 20+
Related MCP server: Excalidraw MCP Server
claude mcp add design-canvas -s user -- npx -y design-canvas-mcpAdd to .cursor/mcp.json:
{
"mcpServers": {
"design-canvas": {
"command": "npx",
"args": ["-y", "design-canvas-mcp"]
}
}
}npm install -g design-canvas-mcpThen configure with command: "design-canvas-mcp" instead of the npx variant.
Tool | Description | Key Parameters |
| List all routes on the canvas with IDs, paths, dimensions, positions | — |
| Add a route to the canvas from the connected dev server |
|
| Remove a route frame by ID or path |
|
| Capture screenshots of routes and return as images |
|
"Show me all routes on the canvas" → list_routes
"Add /dashboard at desktop and mobile" → add_route at 1280 + 375
"Capture the canvas so you can see my app" → capture_canvas
"Remove the mobile version of /dashboard" → list_routes then remove_route by ID
The MCP server communicates with the Design Canvas Mac app via a local HTTP API on localhost:7420. The server is an adapter layer — it translates between the HTTP API and MCP's content block format.
Claude Code / Cursor
→ spawns design-canvas-mcp (stdio)
→ HTTP requests to localhost:7420
→ Design Canvas Mac app respondsScreenshots are captured by the Mac app's WebKit rendering engine, resized to 1200px width, and returned as base64 JPEG images.
"Design Canvas is not running" The Mac app isn't open or isn't listening on port 7420. Open Design Canvas and make sure it shows the canvas view.
Routes show but pages are blank
The dev server isn't running. Start your dev server (e.g., npm run dev) and make sure Design Canvas is connected to it.
Screenshots are from WebKit, not Chrome Design Canvas uses WebKit (Safari's engine) for rendering. For pixel-perfect Chromium verification, use Playwright. The MCP screenshots are for quick layout checks, not cross-browser QA.
MIT
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:
Path must start with '/' (e.g., '/dashboard', '/settings', '/blog/[slug]')
Do not pass full URLs — the dev server base URL is configured in the app
Use standard responsive widths: 1280 desktop (default), 768 tablet, 375 mobile
Position (x, y) is auto-calculated if omitted — frames stack horizontally
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.
| Name | Required | Description | Default |
|---|---|---|---|
| x | No | X position on canvas. Auto-positioned next to existing frames if omitted. | |
| y | No | Y position on canvas. Auto-positioned if omitted. | |
| path | Yes | The route path, e.g. '/' or '/dashboard'. Must start with '/'. | |
| width | No | Viewport width in pixels. Use 1280 for desktop (default), 768 for tablet, 375 for mobile. | |
| height | No | Viewport height in pixels. Default: 800. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully carries the behavioral transparency burden. It discloses that the route is loaded from the connected dev server, displayed as a live frame, and returns a route ID. It also explains auto-positioning, horizontal stacking, and the behavior of adding duplicate routes at different widths for responsive comparison.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear main statement, bulleted constraints, and a separate responsive comparison note. Every section earns its place, and there is no redundant or filler content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having no output schema, the description explicitly states that the tool returns the route ID. It covers purpose, restrictions, positional defaults, width labels, and a non-obvious use case (adding the same path multiple times for responsive comparison). This is a complete and self-sufficient description for an add-route tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although schema coverage is 100%, the description adds substantial meaning beyond the schema: it constrains paths to start with '/', explicitly prohibits full URLs, defines standard viewport widths, and explains how omitted x/y coordinates lead to horizontal stacking. This operational guidance is not present in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource: 'Add a web page route to the Design Canvas.' It clearly distinguishes this tool from siblings like list_routes, remove_route, and capture_canvas by describing its unique purpose of adding a live frame to the canvas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear usage context: routes are loaded from the dev server and displayed as live frames, with explicit constraints on path format, width standards, and auto-positioning. It also provides a concrete responsive-comparison workflow. It does not explicitly name sibling alternatives or state when not to use it, but the intended use case is well conveyed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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:
Returns 3 images by default. Pass limit for more, or ids for specific routes.
If the canvas has many routes, pass specific route IDs to capture only what changed — this saves context space and is significantly faster
Route IDs are returned by list_routes and add_route
For precise cross-browser verification, use Playwright instead
| Name | Required | Description | Default |
|---|---|---|---|
| ids | No | Route IDs to capture. If omitted, captures all routes. | |
| limit | No | Maximum number of screenshot images to return. Default: 3. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does so thoroughly. It discloses non-cached rendering, full page load waiting, WebKit rendering, performance cost, default image count, and the ability to target specific routes—important behavioral traits beyond what the schema shows.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear USAGE and CONSTRAINTS sections. Every sentence adds practical value—no filler or redundancy—and the format makes it easy for an agent to scan and apply the guidance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is fully contextualized despite having no output schema: it covers purpose, performance, constraints, parameter usage, alternatives, and expected output format. The information is sufficient for an agent to decide when and how to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is already 100%, but the description adds meaningful context: the default limit of 3, the benefit of passing specific route IDs for speed and context savings, and the source of route IDs (list_routes/add_route). This goes well beyond the raw schema definitions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool captures fresh screenshots of routes on the Design Canvas, with specific details like triggering a new render and returning images. It distinguishes itself from sibling tools (list_routes, add_route, remove_route) by focusing on visual verification rather than route management.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit usage guidance is provided: use after making code changes for visual verification, avoid speculative calls due to cost, and pass specific route IDs to save time/context. It also names Playwright as the alternative for cross-browser verification, giving clear when-to-use and when-not-to-use direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that the tool returns a list of routes with stable IDs and reflects the current canvas state. This is useful behavioral context, though it does not address potential limitations like pagination or performance.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: two short sentences cover purpose, return values, and usage guidance. It is front-loaded with the most important information and contains no filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter list tool with no output schema, the description is complete. It explains what the tool does, what it returns, when to use it, and the stability of route IDs, leaving no ambiguity about its purpose or invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline is 4. The description adds value by explaining the purpose of the returned data (route IDs for removal/duplicate avoidance), which compensates for the lack of parameter details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a clear verb-resource pair: 'List all routes' on the 'Design Canvas'. It specifies what is returned (route ID, path, viewport dimensions, canvas position), distinguishing it from sibling tools like add_route, remove_route, and capture_canvas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage guidance is explicit: 'Call this before removing routes... or before adding routes'. This tells when to use the tool, though it does not explicitly name alternative tools or state when not to use it. The context is clear, so it earns a 4 rather than a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Remove a route frame from the Design Canvas.
CONSTRAINTS:
Prefer removal by ID (from list_routes or add_route response) — unambiguous
Removal by path is supported but removes only the first match — risky when duplicate paths exist (e.g., same route at desktop + mobile widths)
If you need to remove a specific viewport size, call list_routes first to find the exact route ID
| Name | Required | Description | Default |
|---|---|---|---|
| id | No | Route ID from list_routes or add_route. Preferred — unambiguous. | |
| path | No | Route path to remove. Removes first match only. Use id for precision. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It clearly discloses that path-based removal only removes the first match and can be risky with duplicate paths, which is a critical behavioral nuance. It could mention whether removal is permanent or affects attached elements, but the key risk is well-covered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is tightly structured: one purpose sentence followed by three concise constraint bullets. No filler; every sentence provides actionable guidance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (2 optional params, no output schema), and the description covers main usage scenarios and the edge case of duplicate paths. However, it does not specify whether id and path are mutually exclusive or what happens to attached elements when a frame is removed, leaving a minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides 100% description coverage for both parameters, so the baseline is 3. The description adds workflow context—preferring id, calling list_routes for exact viewport—which goes beyond the schema and justifies a 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a clear verb+resource statement ('Remove a route frame from the Design Canvas'), immediately distinguishing it from sibling tools like list_routes and add_route. The purpose is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The CONSTRAINTS section explicitly instructs the agent to prefer removal by ID, warns against path removal due to duplicate risk, and directs the agent to call list_routes first for specific viewport removal. This provides clear when/how guidance and names an alternative tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.1.0add_routecapture_canvaslist_routesremove_routeEach 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.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Create and edit architecture diagrams from your AI agent; get an SVG and a live editable canvas.
Give your AI agents the tools to build, manage, and run automation workflows.
Build and run visual creative-production workflows from your AI agent.
Generate images, GIFs, and PDFs from HTML, URLs, or templates — from your AI agent.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/charlieellington/design-canvas-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
