Canvs
Server Details
AI-powered diagrams, mind maps, flowcharts on a free unlimited collaborative whiteboard
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 4.6/5 across 6 of 6 tools scored.
Each tool has a distinct purpose: get_guide is mandatory first step, add_elements for manual canvas, add_elements_from_mermaid for diagrams, delete/query/update for element manipulation. No overlapping functionality.
All tool names follow a clear verb_noun pattern in snake_case (add_elements, delete_elements, query_elements, update_elements, get_guide, add_elements_from_mermaid). Consistent and predictable.
6 tools is well-scoped for a canvas/diagram server, covering creation, deletion, query, update, and a guide. Not bloated nor insufficient.
Covers core CRUD plus guide and diagram import. Minor gap: no explicit tool to list existing canvases/rooms, but implicit via room_id reuse. Otherwise complete.
Available Tools
6 toolsadd_elementsAInspect
Manual fallback for creating canvas and adding elements. ⚠️ IMPORTANT: Call get_guide first and follow its instructions! Use this tool only when the user's request is not a good fit for Mermaid. If the request can be represented in Mermaid, use add_elements_from_mermaid instead. If room_id is NOT provided - creates a NEW canvas and returns url plus room_id. If the user did not explicitly mention an existing board/canvas/room, do NOT ask for a room_id; create a new canvas instead. If a previous Canvs tool result or assistant message in the same conversation contains a room_id, reuse it for follow-up requests like 'add to it' or 'same board'. If you only have a room URL, extract room_id from https://[host]/?room=[room_id] or https://[host]/gdrive?id=[room_id]. If the user refers to a previous board but no usable room_id is available, create a new canvas instead of asking for the URL by default. If room_id IS provided - adds elements to that canvas. If the canvas is displayed as an inline widget in the interface, do NOT include the url in your reply. If no widget is shown, share the url so the user can open the canvas.Use cases: wireframes, UI mockups, freeform illustrations, standalone shapes, and manual layouts that Mermaid does not cover well. Do not use this tool for diagrams that Mermaid can express. Element types: rectangle, ellipse, diamond, arrow, line, freedraw, text, image. Rich text: the text field supports limited HTML for text elements and rectangle/ellipse/diamond shape labels. Supports the rich-text plugin HTML subset: /, /, , , /, //, , , and . Use textAlign for left/center/right alignment; avoid unsupported HTML/CSS. TEXT IN SHAPES: use containerId on text element pointing to shape id. ARROWS: Position at EDGE of source shape. Auto-bound within 30px. Colors: strokeColor, backgroundColor (hex).
| Name | Required | Description | Default |
|---|---|---|---|
| room_id | No | Room ID. If not provided, creates a new canvas. Extract from URLs as ?room=[room_id] or /gdrive?id=[room_id]. | |
| elements | Yes | Array of element definitions to create |
Output Schema
| Name | Required | Description |
|---|---|---|
| url | Yes | Canvas room URL |
| isNew | Yes | Whether a new canvas was created |
| room_id | No | Canvas room ID |
| appState | Yes | Canvas app state (viewBackgroundColor, etc.) |
| elements | Yes | All elements currently on the canvas |
| collabUrl | Yes | Collaboration server URL for Socket.IO |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses key behaviors: it creates a new canvas if no room_id is provided, otherwise adds elements to an existing canvas. It mentions auto-bound arrows within 30px, rich text support, and type inference. While it doesn't explicitly state that the operation is additive and non-destructive, the annotations (readOnlyHint=false, destructiveHint=false) already indicate mutation, and the description provides sufficient detail for safe usage.
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 long but well-structured: it starts with the most critical instruction (call get_guide), then differentiates from the sibling tool, explains room_id logic, and provides structured details on element types and rich text. Every section contributes to usability, though some details could be moved to the schema to reduce verbosity.
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 description covers the tool's core functionality, return values (URL and room_id for new canvases), and includes guidance on sharing the URL. It accounts for common scenarios like reusing room_id and extracting from URLs. Given that an output schema exists, the description complements it well, though it could address potential errors or limits.
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 descriptions provide 100% coverage of parameters, but the description adds valuable context beyond the schema, such as guidelines for arrow positioning, text alignment, and containerId usage for text in shapes. It also explains the behavior of room_id (create vs add) in detail, which is not fully captured in the schema alone.
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 is a 'Manual fallback for creating canvas and adding elements', providing a specific verb ('create' and 'add') and resource ('canvas', 'elements'). It distinguishes itself from the sibling tool add_elements_from_mermaid by specifying that this tool is for non-Mermaid use cases like wireframes, UI mockups, and freeform illustrations.
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?
Explicitly advises to 'call get_guide first', and provides a clear condition: 'Use this tool only when the user's request is not a good fit for Mermaid. If the request can be represented in Mermaid, use add_elements_from_mermaid instead.' It also details when to create a new canvas versus add to an existing one based on room_id, including instructions on reusing room_id from conversation and extracting it from URLs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
add_elements_from_mermaidAInspect
Preferred method for creating diagram elements from Mermaid. ⚠️ IMPORTANT: Call get_guide first and follow its instructions! Use this tool for NEW diagrams and LARGE changes to existing diagrams whenever the request can be represented in Mermaid. Prefer translating the request into Mermaid instead of manually recreating it with add_elements. If room_id is NOT provided - creates a NEW canvas and returns url plus room_id. If the user did not explicitly mention an existing board/canvas/room, do NOT ask for a room_id; create a new canvas instead. If a previous Canvs tool result or assistant message in the same conversation contains a room_id, reuse it for follow-up requests like 'add to it' or 'same board'. If you only have a room URL, extract room_id from https://[host]/?room=[room_id] or https://[host]/gdrive?id=[room_id]. If the user refers to a previous board but no usable room_id is available, create a new canvas instead of asking for the URL by default. If room_id IS provided - adds diagram elements to that canvas. If the canvas is displayed as an inline widget in the interface, do NOT include the url in your reply. If no widget is shown, share the url so the user can open the canvas.Supports: flowchart, graph, flowchart-elk, sequenceDiagram, classDiagram, classDiagram-v2, stateDiagram, stateDiagram-v2, erDiagram, journey, gantt, pie, gitGraph, mindmap, timeline, C4Context, C4Container, C4Component, C4Dynamic, C4Deployment, sankey, sankey-beta, quadrantChart, xychart, xychart-beta, requirement, requirementDiagram, kanban, architecture, block, block-beta, packet, packet-beta, radar-beta, treemap, info. Example: "flowchart TD\n A[Start] --> B{Decision}\n B -->|Yes| C[OK]\n B -->|No| D[Cancel]"
| Name | Required | Description | Default |
|---|---|---|---|
| config | No | Optional Mermaid rendering config. flowchart.curve is handled automatically. | |
| mermaid | Yes | Mermaid diagram definition. Prefer converting compatible user requests into Mermaid instead of using add_elements. | |
| room_id | No | Room ID. If not provided, creates a new canvas. Extract from URLs as ?room=[room_id] or /gdrive?id=[room_id]. | |
| timeout | No | Room lifetime in seconds (default: 3600, max: 86400). Only used when creating new canvas |
Output Schema
| Name | Required | Description |
|---|---|---|
| url | Yes | Canvas room URL |
| isNew | Yes | Whether a new canvas was created |
| room_id | No | Canvas room ID |
| appState | Yes | Canvas app state (viewBackgroundColor, etc.) |
| elements | Yes | All elements currently on the canvas |
| collabUrl | Yes | Collaboration server URL for Socket.IO |
| pendingMermaid | No | Mermaid definition pending client-side rendering |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (which already indicate non-read-only), the description clarifies creation vs. addition behavior based on room_id, widget display rules, and that config.curve is handled server-side. No contradictions.
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 richly detailed but somewhat repetitive (e.g., room_id behavior explained in multiple places). It could be more concise while retaining all essential 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?
Covers purpose, parameter semantics, behavioral rules, usage guidelines, and edge cases (room_id reuse, widget display, supported diagram types with example). Output schema exists, so return value details are not needed. Complete for a complex 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?
All parameters have schema descriptions, so baseline is 3. The description adds value by explaining mermaid as preferred over add_elements, describing room_id extraction from URLs, noting timeout only for new canvas, and clarifying automatic handling of config.
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 'Preferred method for creating diagram elements from Mermaid' and distinguishes from sibling tool add_elements by recommending Mermaid translation over manual recreation.
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 comprehensive when-to-use guidance: for new diagrams and large changes, when request can be in Mermaid. Also includes when-not-to: do not ask for room_id unless user explicitly mentioned, reuse from context, extract from URLs. Includes call to get_guide first.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
delete_elementsADestructiveInspect
Delete elements from a canvas. Requires room_id from a previous Canvs tool result. Pass ids array of element IDs to delete.
| Name | Required | Description | Default |
|---|---|---|---|
| ids | Yes | Array of element IDs to delete | |
| room_id | Yes | Room ID from a previous Canvs tool result. If you only have a URL, extract it from https://[host]/?room=[room_id] or https://[host]/gdrive?id=[room_id]. |
Output Schema
| Name | Required | Description |
|---|---|---|
| url | Yes | Canvas room URL |
| isNew | Yes | Whether a new canvas was created |
| room_id | No | Canvas room ID |
| appState | Yes | Canvas app state (viewBackgroundColor, etc.) |
| elements | Yes | All elements currently on the canvas |
| collabUrl | Yes | Collaboration server URL for Socket.IO |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already set destructiveHint=true, so the description adds only minor context (room_id extraction). It does not elaborate on the irreversibility of deletion or any side effects beyond the annotation's warning.
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, front-loaded with the primary action, and each sentence adds necessary information without redundancy or fluff.
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?
With output schema present and destructiveHint in annotations, the description adequately covers the tool's usage. It is complete for a deletion tool with two parameters.
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 100%, but the description adds value by explaining the room_id parameter's source and URL extraction method, which is not in the schema description. The ids parameter description merely restates 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 'Delete elements from a canvas' which is a specific verb+resource pair. It distinguishes from sibling tools like add_elements, update_elements, and query_elements by focusing solely on deletion.
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 specifies that a room_id is required from a previous Canvs tool result and explains how to extract it from URLs. However, it does not provide guidance on when not to use this tool or mention alternatives for similar operations, such as update_elements.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_guideARead-onlyInspect
⚠️ MANDATORY FIRST STEP - Call this tool BEFORE using any other Canvs tools! Returns comprehensive instructions for creating whiteboards: tool selection strategy, iterative workflow, and examples. Following these instructions ensures correct diagrams.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
| guide | Yes | Tool usage instructions text |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true, consistent with a guide tool. The description adds value by explaining it returns instructions and that following them ensures correct diagrams, providing context beyond annotations.
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?
Two sentences with an emoji warning, no wasted words. Information is front-loaded and every sentence serves a purpose: mandatory step indication, return description, and assurance of correctness.
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?
Complete for a guide tool with no parameters and an output schema. The description covers its role, return content, and usage context, leaving no gaps for the AI agent.
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, and schema coverage is 100%. The description adds meaning by explaining the tool's purpose and usage, satisfying the baseline of 4 and earning a 5 for its clear, helpful context.
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 returns comprehensive instructions for creating whiteboards and is the mandatory first step. The verb 'get' and resource 'guide' are specific, and it distinguishes itself from sibling tools which focus on manipulating elements.
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?
Explicitly states 'MANDATORY FIRST STEP - Call this tool BEFORE using any other Canvs tools!' which provides unambiguous guidance on when to use this tool versus alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
query_elementsARead-onlyInspect
Query elements on a canvas. Requires room_id from a previous Canvs tool result. Returns elements matching optional filters. Use this before update_elements when making small edits to existing diagrams. If no browser has the canvas open, returns an error — ask the user to open the canvas URL in their browser and retry.
| Name | Required | Description | Default |
|---|---|---|---|
| type | No | Filter by element type | |
| filter | No | Additional key-value filters (e.g., {locked: true}) | |
| room_id | Yes | Room ID from a previous Canvs tool result. If you only have a URL, extract it from https://[host]/?room=[room_id] or https://[host]/gdrive?id=[room_id]. |
Output Schema
| Name | Required | Description |
|---|---|---|
| count | Yes | Number of matching elements |
| elements | Yes | Matching elements |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only and non-destructive behavior. The description adds valuable context: the error condition when no browser has the canvas open and the requirement for a prior tool result. No contradictions with annotations.
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 three sentences, front-loaded with the main action, and every sentence earns its place by providing essential information. No redundancy.
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 rich annotations and complete schema coverage, the description fully covers prerequisites, usage context, error handling, and alignment with sibling tools. The presence of an output schema obviates the need for return value details.
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 100%, so the schema already documents all parameters. The description adds minimal extra meaning, such as explaining how to extract room_id from a URL. This is acceptable but not exceptional, earning a baseline score of 3.
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 'Query elements on a canvas' with a specific verb and resource. It distinguishes itself from sibling tools like update_elements by mentioning when to use this tool before updates. The optional filters and return behavior are clearly defined.
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 explicitly states the prerequisite (room_id from a previous tool), when to use (before update_elements for small edits), and a specific error case (browser not open) with instructions for the user. This provides comprehensive guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
update_elementsADestructiveInspect
Update elements on a canvas. Requires room_id from a previous Canvs tool result. Pass elements array with id and fields to update. IMPORTANT: in each update object ONLY id is required; all other fields are optional patch fields. Include ONLY elements that need changes; elements omitted from the request remain unchanged on the board. Prefer this tool for SMALL edits to existing diagrams (rename/move/restyle a few elements), typically after query_elements.
| Name | Required | Description | Default |
|---|---|---|---|
| room_id | Yes | Room ID from a previous Canvs tool result. If you only have a URL, extract it from https://[host]/?room=[room_id] or https://[host]/gdrive?id=[room_id]. | |
| elements | Yes | Array of element updates (each must have id) |
Output Schema
| Name | Required | Description |
|---|---|---|
| url | Yes | Canvas room URL |
| isNew | Yes | Whether a new canvas was created |
| room_id | No | Canvas room ID |
| appState | Yes | Canvas app state (viewBackgroundColor, etc.) |
| elements | Yes | All elements currently on the canvas |
| collabUrl | Yes | Collaboration server URL for Socket.IO |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate destructiveHint=true, which the description aligns with ('Update elements'). It adds context beyond annotations: partial updates (patch behavior), elements omitted unchanged, and small edit preference.
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 and well-structured. It starts with the main action, then key behavior (patch semantics), then usage guidance. Every sentence is informative without redundancy.
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 tool complexity (elements array with many fields) and presence of annotations and output schema, the description covers purpose, prerequisites, patch behavior, and when to use. No gaps identified.
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 100%, so baseline is 3. The description adds value by reinforcing that only id is required and other fields are optional patch fields, and by explaining the purpose of the tool for small edits.
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 'Update elements on a canvas' with a specific verb and resource. It distinguishes from siblings like add_elements and delete_elements by noting it is for small edits after query_elements.
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: 'Prefer this tool for SMALL edits... typically after query_elements.' Also clarifies that only id is required and elements omitted remain unchanged. Prerequisite of room_id from a previous result is stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!