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., "@Canvas-MCP Render my system diagram from system.yaml"
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.
An MCP server that renders hierarchical canvas diagrams as PNGs. Define your system as a hierarchy of networks, factories, machines, and nodes — Canvas-MCP handles layout, styling, and rendering.
Built with Python, Pillow, and the Model Context Protocol.
Canvas-MCP uses a four-level hierarchical ontology. Every diagram is a tree of nested containers, from the broadest scope down to the atomic unit:
Canvas
└── Network ← system boundary
└── Factory ← functional domain
└── Machine ← pipeline
└── Node ← atomic operationMost diagramming tools give you boxes and arrows. Canvas-MCP gives you semantic containers — each level carries meaning about the scope and role of what it contains:
Network — the broadest boundary. Think of it as a service, a deployment, or an entire subsystem. A complex architecture might have multiple networks.
Factory — a functional domain within a network. "Data Ingestion", "Analysis", "Output Generation" — a factory groups the pipelines that serve a common purpose.
Machine — a single pipeline or processing chain. A connected sequence of operations that transforms data from input to output.
Node — the atomic unit. A single operation: an API call, a transformation, a decision gate, an AI inference step.
This isn't arbitrary nesting — it mirrors how real systems are organized. The hierarchy lets you express both the micro (individual operations) and the macro (system architecture) in one diagram.
Every level of the ontology follows the same labeling pattern:
Field | Required | Purpose |
| Yes | Unique identifier used for connections and lookups |
| No | Human-readable display name |
| No | Optional longer description (for documentation) |
The rule is simple: get_label() returns the label if set, otherwise falls back to the id.
This keeps YAML recipes concise. You only need a label when you want a display name that differs from the id:
# No label needed — "preprocess" is clear enough
- id: preprocess
type: process
content: "Clean and normalize data"
# Label overrides the id for display
- id: llm-gpt4o-analysis
type: ai
label: "AI Analysis"
content: "Run GPT-4o on cleaned data"The same applies to containers:
machines:
- id: machine-1 # Renders as "machine-1" (fine for auto-generated)
nodes: [...]
- id: src-pipeline # Renders as "Data Sources"
label: "Data Sources"
nodes: [...]Related MCP server: MCP SVG Animator
Nodes are the atomic units of the ontology. Each node has a type that determines its color and carries semantic meaning:
Type | Color | Hex | Meaning |
| Blue |
| User-provided data entering the system |
| Amber |
| Final results leaving the system |
| Cyan |
| A transformation or computation step |
| Red |
| A branching point or conditional gate |
| Purple |
| An AI/LLM processing step |
| Orange |
| An external data source (API, database, file) |
| Green |
| Immutable seed content or constants |
| Gray |
| Generic / unspecified |
When rendered, each node displays:
Type bar — a colored stripe at the top matching the type's accent color
Label — bold text below the type bar (from get_label())
Content — word-wrapped body text describing what the node does
Type badge — small tag in the bottom-right corner showing the type name
- id: analyze # Required. Globally unique identifier.
type: ai # Optional. One of the 8 types above. Default: "default"
label: "AI Analysis" # Optional. Display name. Default: uses id
content: "Run inference" # Optional. Body text describing the operation
x: 800 # Optional. Horizontal position. Default: 0 (auto-layout)
y: 180 # Optional. Vertical position. Default: 0 (auto-layout)
width: 250 # Optional. Node width in pixels. Default: 250
height: 120 # Optional. Node height in pixels. Default: 120
inputs: [preprocess] # Optional. IDs of upstream nodes
outputs: [report] # Optional. IDs of downstream nodes
style: # Optional. Override default NodeStyle
border_color: "#FF00FF"
fill_color: "#1e1e2e"
text_color: "#cdd6f4"
label_color: "#FF00FF"
corner_radius: 12Machines and factories can be styled with ContainerStyle to customize their visual container:
machines:
- id: my-pipeline
label: "Custom Pipeline"
style:
border_color: "#89b4fa" # Outline color
fill_color: "#1e1e2e" # Background fill
label_color: "#89b4fa" # Label text color
alpha: 100 # Fill opacity (0-255)
corner_radius: 12 # Border radius
border_width: 2 # Outline thicknessAll ContainerStyle fields are optional — unset fields fall back to defaults:
Field | Machine Default | Factory Default |
|
|
|
|
| none (transparent) |
|
|
|
| 120 | 0 |
| 8 | 12 |
| 1 | 1 |
Connections are declared on nodes via inputs and outputs — lists of other node IDs:
- id: source
type: input
outputs: [transform] # "I feed into transform"
- id: transform
type: process
inputs: [source] # "I receive from source"
outputs: [result]Connections are bidirectionally deduped — declaring a connection on either end is sufficient. Declaring both is harmless (and often clearer).
Canvas-MCP automatically selects connection ports based on the spatial relationship between nodes:
Horizontal flow (default): Connections exit from the right edge and enter from the left edge. This creates left-to-right diagrams.
Vertical flow (automatic): When a target node sits significantly below or above its source (beyond a "horizon" threshold of 1.5x the source node's height), the connection switches to bottom/top ports. This creates vertical tree structures.
The switching is emergent from geometry — you don't configure it. Place nodes side by side and you get horizontal flow. Stack them vertically and you get vertical flow. Mix both and each connection picks the right ports independently.
Connections are drawn as smooth cubic bezier curves with:
Directional S-bend control points (horizontal or vertical)
Color derived from the source node's type (darkened to 70%)
Arrowhead at the endpoint
Canvas-MCP supports two YAML formats. Use whichever fits your needs.
The simplified format is a flat list of nodes. Canvas-MCP auto-wraps them in the hierarchy (one network > one factory > auto-detected machines) and handles layout:
title: My Pipeline
nodes:
- id: ingest
type: input
label: "Data Ingest"
content: "Accept incoming data"
outputs: [clean]
- id: clean
type: process
label: "Clean"
content: "Normalize and validate"
inputs: [ingest]
outputs: [analyze]
- id: analyze
type: ai
label: "AI Analysis"
content: "Run LLM inference"
inputs: [clean]
outputs: [report]
- id: report
type: output
label: "Report"
content: "Generated summary"
inputs: [analyze]Auto-layout: When all node coordinates are (0, 0) (or omitted), Canvas-MCP arranges them automatically. Use the organize flag for intelligent topological layout.
Auto-machines: Connected components of nodes are automatically grouped into machines.
The full format gives you explicit control over the entire hierarchy:
canvas:
version: "2.0"
title: AI Pipeline
networks:
- id: main-system
label: "Production System"
factories:
- id: ingestion
label: "Data Ingestion"
machines:
- id: sources
label: "Data Sources"
nodes:
- id: api-feed
type: source
x: 100
y: 100
label: "API Feed"
content: "External API data"
outputs: [preprocess]
- id: db-source
type: source
x: 100
y: 260
label: "Database"
content: "Historical records"
outputs: [preprocess]
- id: processing
label: "Processing"
nodes:
- id: preprocess
type: process
x: 450
y: 180
label: "Preprocess"
content: "Clean and normalize"
inputs: [api-feed, db-source]
outputs: [analyze]
- id: analysis
label: "Analysis"
machines:
- id: ai-stage
label: "AI Stage"
nodes:
- id: analyze
type: ai
x: 800
y: 180
label: "AI Analysis"
content: "Run LLM analysis"
inputs: [preprocess]
outputs: [output]
- id: output
type: output
x: 1150
y: 180
label: "Report"
content: "Generated report"
inputs: [analyze]Canvas-MCP includes a built-in topological layout engine.
When all nodes have coordinates at (0, 0), the basic auto-layout arranges them:
Left-to-right within machines (80px horizontal spacing)
Top-to-bottom between machines (200px vertical spacing)
Extra gap between factories (60px)
Enable with organize: true for intelligent hierarchical layout:
Topological sort (Kahn's algorithm) assigns hierarchical levels
Parent-center alignment vertically centers children on their parents
Overlap prevention enforces minimum spacing
Cycle handling gracefully positions nodes in cyclic graphs
Grid fallback arranges disconnected components in a grid
Control breathing room with the spacing_level parameter:
Level | Horizontal | Vertical | Best For |
| 60px | 110px | Small, tight diagrams |
| 150px | 190px | Architecture diagrams (default) |
| 190px | 250px | Large system overviews |
Canvas-MCP uses the Catppuccin Mocha dark theme:
Element | Color | Hex |
Canvas background | Dark base |
|
Node fill | Base |
|
Node label text | Light text |
|
Node content text | Muted text |
|
Machine container fill | Surface |
|
Machine container border | Overlay |
|
Machine label | Subtext |
|
Factory container border | Surface 2 |
|
Factory label | Subtext 1 |
|
Canvas-MCP exposes four tools via the Model Context Protocol:
render_canvasRender a YAML recipe string to PNG.
Parameter | Type | Default | Description |
| string | required | YAML in simplified or hierarchical format |
| number |
| Render scale (2.0 = crisp retina output) |
| string | auto-UUID | Output filename (without extension) |
| boolean |
| Apply hierarchical layout algorithm |
| string |
| One of: |
create_canvasCreate a diagram from structured input (title + nodes + optional machines).
Parameter | Type | Default | Description |
| string | required | Canvas title |
| array | required | List of node definitions |
| array | optional | Group nodes into named machines |
| number |
| Render scale |
| boolean |
| Apply layout algorithm |
| string |
| Spacing preset |
Returns both a PNG and a saved YAML recipe.
list_templatesList available starter templates. Returns template names and file paths.
get_templateRetrieve the YAML content of a specific template by name.
Add to your MCP client configuration (e.g., .mcp.json):
{
"mcpServers": {
"canvas-mcp": {
"command": "uv",
"args": [
"run",
"--directory", "/path/to/Canvas-MCP",
"canvas-mcp"
]
}
}
}uv run canvas-mcp # Starts the MCP stdio serveruv run python test_render.py # Renders test PNGs to output/Canvas-MCP/
├── src/canvas_mcp/
│ ├── models.py # Ontology: Canvas > Network > Factory > Machine > Node
│ ├── parser.py # YAML parser (simplified + hierarchical formats)
│ ├── renderer.py # Pillow-based PNG renderer
│ ├── organize.py # Hierarchical layout algorithm (topological sort)
│ └── server.py # MCP server with 4 tools
├── templates/
│ ├── simple-flow.yaml # 3-node linear pipeline
│ ├── decision-tree.yaml # Branching decision flow
│ └── ai-pipeline.yaml # Full hierarchical example
├── pyproject.toml
└── test_render.pyPNGs are saved to ~/.rhode/canvas/ by default. Set the CANVAS_OUTPUT_DIR environment variable to change this.
MIT
Create a canvas diagram from a structured description. Provide a title, nodes, and connections — the tool handles layout and rendering. Returns the path to the rendered PNG and the generated YAML recipe.
| Name | Required | Description | Default |
|---|---|---|---|
| nodes | Yes | List of nodes to place on the canvas. | |
| scale | No | Render scale factor (default 2.0) | |
| title | Yes | Title for the canvas diagram. | |
| machines | No | Optional: group nodes into machines. Each item is a list of node IDs. | |
| organize | No | Apply the organize algorithm for automatic layout. Default: true. | |
| orientation | No | Layout direction: 'horizontal' (left→right, default) or 'vertical' (top→bottom tree). | horizontal |
| spacing_level | No | Spacing level for organize layout. Default: 'container'. | container |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description discloses that the tool handles layout and rendering and returns PNG path and YAML recipe. However, it omits behavioral traits such as idempotency, authentication needs, error handling, or side effects, which are important for safe invocation.
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: the first states the primary action, the second specifies required inputs and outputs. It is front-loaded and contains no superfluous words, earning its place efficiently.
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 7 parameters and no output schema, the description covers the main inputs and return values. It lacks details on constraints (e.g., node count limits) and explicit comparison to siblings, but is sufficient for a straightforward creation 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?
Schema description coverage is 100%, so the baseline is 3. The description adds little beyond summarizing parameters ('title, nodes, and connections'). It does not enhance understanding of parameter formats or constraints beyond what the schema already provides.
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 creates a canvas diagram from a structured description, specifying the verb 'create' and resource 'canvas diagram'. It distinguishes from siblings like 'get_template' and 'list_templates', which deal with templates, and 'render_canvas', which likely renders an existing 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 tells users to provide title, nodes, and connections, implying inputs, but does not explicitly state when to use this tool versus alternatives like 'render_canvas'. No when-not or alternative guidance is provided, leaving usage context implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the YAML content of a specific template by name.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Template name (from list_templates output) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description must convey behavioral traits. 'Get' implies read-only, but there is no mention of behavior on missing template, rate limits, or other side effects. Adequate for a simple read operation but lacks completeness.
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, clear sentence with no wasted words. It front-loads the 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?
Given low complexity (1 parameter, no output schema), the description sufficiently explains the tool's purpose and input. It could mention the output format more explicitly, but 'YAML content' is adequate.
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% and the single parameter is well-described in the schema. The tool description adds no additional meaning beyond what the schema provides, so baseline 3 is appropriate.
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 verb 'Get' and the resource 'YAML content of a specific template by name'. It distinguishes from siblings: list_templates lists templates, create_canvas and render_canvas deal with canvases, not templates.
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 does not explicitly state when to use this tool over alternatives. The parameter description (from list_templates output) hints at a prerequisite, but no clear guidance on conditions for use is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List available canvas recipe templates that can be used as starting points.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Describes the operation as listing (read-only), but does not disclose authentication requirements, pagination, or scope of templates returned. Without annotations, more behavioral context would be beneficial.
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 clear front-loaded structure. No unnecessary words. Perfectly 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?
Describes the core function but omits details about return format or expected output, especially given the absence of an 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?
With zero parameters, the description adds no parameter semantics, but the baseline score of 4 is appropriate since parameters are absent and schema coverage is 100%.
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 the action (List) and resource (canvas recipe templates). Distinguishes from sibling tools create_canvas, get_template, render_canvas by focusing on listing available templates.
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 for discovering available templates before creating a canvas, but lacks explicit when-to-use or when-not-to-use guidance compared to alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Render a canvas diagram from a YAML recipe string. Supports hierarchical format (networks/factories/machines/nodes) or a simplified format (flat list of nodes with inputs/outputs). Returns the path to the rendered PNG file.
| Name | Required | Description | Default |
|---|---|---|---|
| scale | No | Render scale factor (default 2.0 for crisp, legible output) | |
| filename | No | Output filename (without extension). Default: auto-generated UUID. | |
| organize | No | Apply the hierarchical organize algorithm for automatic layout with proper breathing room. Organizes nodes within machines, machines within factories, factories within networks — each with appropriate spacing. Default: true. | |
| orientation | No | Layout direction: 'horizontal' (left→right, default) or 'vertical' (top→bottom tree). Applied at all hierarchy levels. | horizontal |
| yaml_recipe | Yes | YAML string defining the canvas. Simplified format example: title: My Diagram nodes: - id: start type: input content: 'Begin here' - id: process type: process content: 'Do work' inputs: [start] Node types: static, input, ai, source, output, decision, process, default Coordinates (x, y) are optional — auto-layout is applied if all are 0. | |
| spacing_level | No | Spacing level for organize layout: 'node' (tight: 60h/110v), 'container' (medium: 150h/190v, default), 'network' (spacious: 190h/250v). | container |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite no annotations, the description transparently states the output (PNG file path) and mentions format support. It doesn't contradict any annotations, but could detail side effects like file saving behavior.
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-loading the core action. It's concise and includes necessary details like format types and output. Slightly more structure could improve scannability.
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 6 parameters, 1 required, and full schema coverage, the description adequately covers purpose, input format, and output. Lacks error handling info but overall sufficient.
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 with a concrete example of the simplified YAML format. It complements the schema without redundancy.
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 renders a canvas diagram from a YAML recipe and returns a PNG path, with specific mention of supported formats. This distinguishes it from siblings like create_canvas, get_template, and list_templates.
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 usage when you have a YAML recipe and want an output image, but does not explicitly state when not to use or provide direct alternatives. Still clear enough for most scenarios.
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.0create_canvasget_templatelist_templatesrender_canvasEach tool has a distinct purpose: creating a canvas from description, rendering from YAML, and managing templates. No overlap between tools.
All tool names consistently follow the verb_noun pattern with appropriate singular/plural forms (create_canvas, get_template, list_templates, render_canvas).
4 tools is well-scoped for a canvas diagramming server, covering creation, rendering, and template management without being too few or too many.
Core workflows are covered, but missing template creation/deletion and canvas retrieval by name are minor gaps that agents can work around.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Render 47 chart types and tiled dashboards as PNG/SVG. Deterministic, no headless browser.
Render, validate, encode/decode PlantUML diagram-as-code; 22 diagram types. Free, no auth.
Generate cloud architecture diagrams, flowcharts, and sequence diagrams.
Deterministic image rendering for agents: JSON template in, on-brand PNG out.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/jdlongmire/ThinxAI-Canvas-MCP'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
