canvaskeep-mcp
OfficialServer Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| CANVASKEEP_API_KEY | Yes | Your API key from the CanvasKeep dashboard | |
| CANVASKEEP_API_URL | No | API base URL (override for local dev) | https://canvaskeep.com |
| CANVASKEEP_MASTER_KEY | No | Needed to read or edit encrypted diagrams. Copy it from https://canvaskeep.com/dashboard/encryption (Key for the MCP server) |
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_workspacesA | List all workspaces in your CanvasKeep account. Returns each workspace's id and name. Use this first to find the workspace_id needed by other tools. |
| create_workspaceB | Create a new workspace. Returns the new workspace's id and name. |
| list_foldersA | List all folders in a workspace. Returns each folder's id, name, and parent_folder_id. Use folder ids when creating diagrams inside a specific folder. |
| create_folderA | Create a new folder in a workspace. Returns the new folder's id and name. Optionally nest it inside an existing folder. |
| list_diagramsA | List all diagrams in a workspace. Returns each diagram's id, title, and last updated timestamp. |
| create_diagramA | Create a new empty diagram in a workspace, optionally inside a folder. Returns the new diagram's id. Use generate_diagram afterward to populate it with content. Use list_folders first to find the folder_id if you want to place it in a specific folder. |
| update_diagramB | Update a diagram's title (rename it). |
| delete_diagramA | Permanently delete a diagram and its content. This cannot be undone. |
| get_diagram_summaryA | Get a summary of an existing diagram: its title, workspace, element count, and when it was last updated. Does NOT return the raw scene data. |
| get_diagram_sceneA | Read the raw Excalidraw scene of a diagram: the full elements array (with ids, x/y, width/height, styles, text, arrow bindings) and appState. Use this before save_diagram_scene to make precise edits: read the scene, modify the elements you need, then write the complete array back. Embedded image data (files) is omitted by default because it can be very large; set include_files to true only if you need it. |
| save_diagram_sceneA | Overwrite a diagram's scene with a full Excalidraw elements array. Use this for manual layout and precise edits (moving, restyling, relabeling, adding or removing specific elements). IMPORTANT: this REPLACES the entire scene. Always call get_diagram_scene first, modify that array, and send back EVERY element you want to keep. Any element missing from the array is deleted. To remove an element you may also set "isDeleted": true on it. When changing an element, bump its "version" and set a new random "versionNonce" so open editors pick up the change. Text inside a shape is a separate text element with "containerId" set to the shape id; arrows reference shapes via startBinding/endBinding and shapes list them in boundElements. Existing embedded images (files) and appState are kept unless you pass new ones. If the diagram is open in a browser tab, unsaved edits there may overwrite this save. |
| generate_diagramA | Generate a visual diagram from a structured graph of nodes and edges, and save it to an existing CanvasKeep diagram. You provide the logical structure (what components exist and how they connect), and CanvasKeep handles all visual layout automatically - do NOT try to compute x/y positions. NODES: Create one node for every distinct component, actor, system, service, or data store mentioned in the user's request. Give each a short, clear label (under 30 chars). Choose the right type for visual distinction. EDGES: Create one edge for every meaningful interaction, data flow, API call, or dependency between nodes. Label edges with the nature of the interaction (e.g. 'REST API', 'SQL query', 'WebSocket', 'publishes'). Every important relationship should be an edge. MODE: Use 'replace' (default) to create a fresh diagram. Use 'append' to add new elements alongside existing content in the diagram. |
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 12 tools
Most tools have clearly distinct purposes (list/create/update/delete per resource, summary vs raw scene reads). The only mild overlap is between generate_diagram and save_diagram_scene, since both write diagram content, but their descriptions clearly separate auto-layout from manual element editing.
Every tool follows a predictable snake_case verb_noun pattern (list_folders, create_diagram, update_diagram, get_diagram_scene, save_diagram_scene, generate_diagram). No mixed conventions or vague verbs.
12 tools is well-scoped for a workspace/folder/diagram management server, with reads and writes balanced across the three resources. Each tool earns its place without redundancy.
Diagrams have strong lifecycle coverage (create, list, update, delete, get scene/summary, save, generate), but folders and workspaces can only be created and listed — no delete, rename, update, or move operations exist. These asymmetric gaps will cause agent dead ends when cleaning up or reorganizing workspaces/folders.