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., "@svg-whiteboard-mcp create a canvas and add a red circle"
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 that keeps SVG path canvases in memory, serves a loopback HTML preview (127.0.0.1), and returns proj-airi Surface embedUrl payloads so AIRI can render chat tool results in a sandbox iframe.
Tool | Purpose |
| New canvas → |
| Remove canvas |
| List ids / sizes / path counts |
| Append SVG |
| Remove path by id |
| Inspect paths on a canvas |
| Return |
| Same envelope for arbitrary |
Related MCP server: nakkas
pnpm install
pnpm build
node dist/index.jsMCP client config example:
{
"mcpServers": {
"svg-whiteboard": {
"command": "node",
"args": ["/absolute/path/to/svg-whiteboard-mcp/dist/index.js"]
}
}
}Node 20+
Host (e.g. Electron) must allow the renderer to load http://127.0.0.1:* preview URLs.
structuredContent includes:
{
"projAiriSurface": {
"version": 1,
"kind": "embedUrl",
"title": "...",
"data": { "url": "http://127.0.0.1:PORT/preview/CANVAS_ID", "mimeType": "text/html" }
}
}Aligns with @proj-airi/mcp-surface-contract in the AIRI monorepo.
Add an SVG path (d attribute) to a canvas.
| Name | Required | Description | Default |
|---|---|---|---|
| d | Yes | SVG path data | |
| fill | No | none | |
| stroke | No | #000000 | |
| opacity | No | ||
| canvasId | Yes | ||
| strokeWidth | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden but only states 'Add'. It does not disclose behavior such as whether the path is appended, what happens if the canvas is missing, authentication requirements, or side effects. The minimal description leaves significant gaps.
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 a single, focused sentence that directly states the tool's purpose with no extraneous words. It is front-loaded and efficient, though it could be slightly longer to improve completeness without harming conciseness.
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?
Given the tool has 6 parameters (2 required) and no output schema or annotations, the description is very incomplete. It does not explain preconditions (canvas must exist), error cases, return value, or relationship with sibling tools.
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 description coverage is only 17% (only 'd' has a description). The tool description adds context for the 'd' parameter ('SVG path data'), but other parameters (fill, stroke, opacity, canvasId, strokeWidth) are not explained. The description does not compensate for the low schema coverage.
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 adds an SVG path (with emphasis on the 'd' attribute) to a canvas. It distinguishes from sibling tools that manage canvases or delete/list paths, as those have different purposes.
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?
No guidance is provided on when to use this tool versus alternatives. For example, it does not mention that the canvas must exist first (use create_canvas) or how it differs from delete_path or list_paths.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new SVG whiteboard canvas. Returns canvas id for add_path and present_preview.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Display name | |
| width | No | ||
| height | No | ||
| backgroundColor | No | #ffffff |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses creation of an SVG whiteboard canvas and return of an id, but lacks details on permissions, id format, or side effects. Adequate but minimal.
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?
Single sentence with a key note about return value; no wasted words. Front-loaded with the primary action and resource.
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 tool with 4 parameters and no output schema, the description is too sparse. It fails to detail parameter defaults (e.g., 800x600, white background) or the nature of the returned canvas id, leaving the agent underinformed.
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?
With schema description coverage only 25% (only name has description), the description does not add meaning to the parameters (width, height, backgroundColor). It omits explanation of defaults or constraints, failing to compensate for the coverage gap.
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?
Clearly states 'Create a new SVG whiteboard canvas' and specifies the return value as canvas id for use in add_path and present_preview, distinguishing from sibling tools like delete_canvas and list_canvases.
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?
Implies usage context by mentioning that the returned id is used by add_path and present_preview, providing a clear workflow hint. However, no explicit when-not-to-use or alternatives are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete a canvas by id.
| Name | Required | Description | Default |
|---|---|---|---|
| canvasId | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It only states the action without mentioning that deletion is irreversible or may affect other data (e.g., paths). This is a significant gap for a destructive operation.
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 extremely concise (6 words), but at the cost of omitting critical information. It earns its keep as a single sentence, but lacks necessary details for safe usage.
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?
Given the destructive nature and zero annotations, the description is insufficient. It does not cover return values, side effects, or required scopes. A delete operation needs more context to be safely invoked.
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 description coverage is 0%, and the description adds minimal meaning beyond the schema. 'by id' implies that canvasId identifies the canvas, but does not explain format, required permissions, or how to obtain the id.
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 action (delete) and resource (canvas) with the key parameter (id). It distinguishes from siblings like create_canvas and delete_path, but could be more precise about scope.
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?
No guidance on when to use this tool versus alternatives. No context about prerequisites or when it's appropriate to delete a canvas.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Remove a path from a canvas.
| Name | Required | Description | Default |
|---|---|---|---|
| pathId | Yes | ||
| canvasId | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears full responsibility for behavioral disclosure. It only states a destructive action but omits details like whether the path must exist, side effects, or reversal possibility.
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 a single sentence front-loaded with the verb 'Remove'. It is concise, though it could afford to include more detail without excessive length.
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?
Given the tool's simplicity (two required IDs), the description is insufficient. It lacks information on success/failure behavior, synchronization, and error handling, especially with no annotations or output schema.
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 description coverage is 0%, and the description does not add any parameter information beyond the parameter names themselves. The agent gains no extra meaning to aid correct invocation.
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 'Remove a path from a canvas.' uses a specific verb (remove) and resource (path from canvas), clearly distinguishing from sibling tools like delete_canvas (removes entire canvas) and add_path (adds a path).
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?
No guidance is provided on when to use delete_path versus alternatives (e.g., delete_canvas for removing the whole canvas), nor any prerequisites or conditions for use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all canvases with id, name, size, path count.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose read-only nature, side effects, auth needs, or rate limits. The tool likely has no side effects, but this is not stated.
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?
Single sentence, 8 words, front-loaded with action and fields. Every word earns its place.
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?
Given the simple 0-parameter tool and no output schema, the description lists the returned fields (id, name, size, path count), which is adequate. Could mention pagination or ordering, but not critical.
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?
There are no parameters, so baseline is 4. The description does not need to add parameter info.
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 explicitly states 'List all canvases', a clear verb+resource. Sibling tools create/delete canvases or paths, so this tool is well-distinguished.
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 implies when to use: to list canvases. No explicit when-not or alternatives are mentioned, but for a simple list tool the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List paths on a canvas (id and d) for inspection.
| Name | Required | Description | Default |
|---|---|---|---|
| canvasId | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It states 'for inspection' implying a read-only operation, but does not explicitly confirm safety, rate limits, or side effects. The lack of any destructive hint or read-only declaration leaves ambiguity.
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 a single sentence, which is concise, but at the expense of necessary detail. It is front-loaded but lacks structure (e.g., no separation of purpose and usage).
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?
Given the simplicity (one parameter, no output schema), the description is too minimal. It does not explain what a path is, what 'id and d' represent, or expected behavior for invalid inputs. Important context is missing.
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 schema has 0% description coverage for parameters, and the description does not add any meaning to 'canvasId'. The agent has no information about its format, allowed values, or how to obtain it.
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 action (list paths) and the resource (canvas), and specifies the returned attributes (id and d). It distinguishes from sibling tools like add_path and delete_path, but could be more explicit about the context of 'paths'.
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?
No guidance is provided on when to use this tool versus alternatives (e.g., add_path, delete_path, or list_canvases). There is no mention of prerequisites, limitations, or typical use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return proj-airi Surface (embedUrl) so AIRI and other hosts show this canvas in a sandbox iframe. The URL is served on loopback by this MCP process. Call after drawing or when the user should see the board.
| Name | Required | Description | Default |
|---|---|---|---|
| title | No | ||
| summary | No | ||
| canvasId | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist. Description discloses that the URL is served on loopback by this MCP process, implying a local network call. However, it does not discuss authentication, rate limits, or side effects beyond returning a URL.
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 brief and front-loaded with the core purpose. Two sentences convey the essential information without unnecessary words.
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?
While the description states the function and timing, it lacks details on return value structure, error cases, and the meaning of 'Surface'. For a tool with no output schema and no annotations, more context would be beneficial for correct usage.
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 0%. Description only implies canvasId is needed for identification but does not explain the 'title' or 'summary' parameters. These optional parameters remain undocumented, so the description adds minimal value over 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 clearly states it returns a Surface (embedUrl) for showing a canvas in an iframe, and specifies when to call it. It distinguishes from siblings by mentioning 'proj-airi' and loopback, which is specific to this tool.
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?
Provides clear context ('after drawing or when the user should see the board'), but does not mention when not to use it or alternatives like 'proj_airi_present_surface'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generic proj-airi envelope: embed any safe http(s) URL in AIRI chat (sandbox iframe). Same contract as other proj-airi MCP servers.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | ||
| title | No | ||
| summary | No | ||
| mimeType | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true. The description adds that the URL is embedded in a sandbox iframe, which is useful security context. However, it does not disclose behavior for unsafe URLs, rate limits, or response format, so the added value is moderate.
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 two sentences long with no verbose or redundant phrases. It front-loads the core action and quickly provides context about the server contract, making it highly concise.
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?
Given the tool has 4 parameters (1 required) and no output schema, the description adequately covers the main purpose but fails to explain optional parameters or return values. It is minimally complete but not thorough.
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?
With 0% schema description coverage, the description must compensate. It only explains the 'url' parameter as a safe http(s) URL, but completely omits the optional parameters 'title', 'summary', and 'mimeType', leaving their purpose unclear.
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 states the tool embeds a safe http(s) URL in an AIRI chat as a sandbox iframe, which is a specific verb+resource. However, it does not differentiate from the sibling tool 'present_preview', leaving ambiguity about which to use for similar tasks.
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 mentions it's a 'generic proj-airi envelope' and follows the same contract as other servers, implying a common pattern. But it provides no explicit when-to-use or when-not-to-use guidance, nor does it reference alternatives like 'present_preview'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Most tools have distinct purposes: canvas CRUD, path CRUD, and presentation. However, present_preview and proj_airi_present_surface both involve pushing content to AIRI, which could cause ambiguity despite differing descriptions.
All tool names follow a consistent verb_noun pattern with lowercase and underscores, e.g., create_canvas, add_path, present_preview. The proj_airi prefix maintains consistency.
Eight tools are well-scoped for an SVG whiteboard: three for canvas CRUD, three for path CRUD, and two for presentation. No tools feel extraneous or missing.
Core CRUD is present but missing update operations for both canvases (e.g., rename) and paths (e.g., modify d attribute). This is a notable gap that may frustrate agents.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
OAuth-protected, read-only-by-default MCP server for provenance-labeled QuillCaddie project memory.
Bar-first MCP server for Tabula chart authoring, PNG rendering, and editor handoff.
Collaborative whiteboard MCP server — create objects, connectors, C4 diagrams, and manage boards
HTML-to-PDF MCP server — render pixel-faithful PDFs from HTML.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/lulu0119/svg-whiteboard-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
