モデルコンテキストプロトコル（MCP）サーバー実装。公式仕様に従ってJSON Canvasファイルを操作するためのツールを提供します。このサーバーは、無限のCanvasデータ構造の作成、変更、検証を可能にします。
JSON Canvas MCP サーバーは、JSON Canvas 1.0 仕様の完全な実装を提供し、次のことを可能にします。
無限のキャンバスデータの作成と操作
すべてのノード タイプ (テキスト、ファイル、リンク、グループ) をサポート
スタイルとラベルによるエッジ接続
仕様に対する検証
設定可能な出力パス
Related MCP server: MCP REST API Server
サーバーは次のリソースを公開します。
canvas://schema : キャンバスファイルを検証するための JSON スキーマ
canvas://examples : さまざまな機能を示すサンプルキャンバスファイル
canvas://templates : 新しいキャンバスを作成するためのテンプレート
ノード作成
サポートされている任意のタイプの新しいノードを作成します
入力：
type (文字列): ノードタイプ ("text", "file", "link", "group")
properties （オブジェクト）：ノード固有のプロパティ
共通: id 、 x 、 y 、 width 、 height 、 color
タイプ固有: text 、 file 、 urlなど。
戻り値: 作成されたノードオブジェクト
ノードの更新
既存のノードのプロパティを更新する
入力：
id (文字列): 更新するノードID
properties (オブジェクト): 更新するプロパティ
戻り値: 更新されたノードオブジェクト
ノードの削除
ノードとそれに接続されたエッジを削除する
入力：
id (文字列): 削除するノードID
戻り値: 成功確認
エッジを作成する
ノード間に新しいエッジを作成する
入力：
id (文字列): 一意のエッジ識別子
fromNode (文字列): ソースノードID
toNode (文字列): ターゲットノードID
fromSide (オプションの文字列): 開始側 ("top", "right", "bottom", "left")
toSide (オプションの文字列): 終了側
color (オプションの文字列): エッジの色
label （オプションの文字列）：エッジラベル
戻り値: 作成されたエッジオブジェクト
更新エッジ
既存のエッジのプロパティを更新する
入力：
id (文字列): 更新するエッジID
properties (オブジェクト): 更新するプロパティ
戻り値: 更新されたエッジオブジェクト
削除エッジ
エッジを削除する
入力：
id (文字列): 削除するエッジID
戻り値: 成功確認
検証キャンバス
仕様に基づいてキャンバスを検証する
入力：
canvas （オブジェクト）：検証するキャンバスデータ
戻り値: エラーを含む検証結果
エクスポートキャンバス
キャンバスをさまざまな形式でエクスポートする
入力：
format (文字列): ターゲット形式 ("json", "svg", "png")
canvas (オブジェクト): エクスポートするキャンバスデータ
戻り値: 要求された形式でエクスポートされたキャンバス
これをclaude_desktop_config.jsonに追加します:
{
"mcpServers": {
"jsoncanvas": {
"command": "docker",
"args": [
"run",
"-i",
"--rm",
"-v",
"canvas-data:/data",
"mcp/jsoncanvas"
],
"env": {
"OUTPUT_PATH": "/data/output"
}
}
}
}{
"mcpServers": {
"jsoncanvas": {
"command": "uv",
"args": [
"--directory",
"/path/to/jsoncanvas",
"run",
"mcp-server-jsoncanvas"
],
"env": {
"OUTPUT_PATH": "./output"
}
}
}
}サーバーは環境変数を使用して設定できます。
OUTPUT_PATH : キャンバスファイルが保存されるディレクトリ（デフォルト: "./output"）
FORMAT : キャンバスファイルのデフォルトの出力形式 (デフォルト: "json")
docker build -t mcp/jsoncanvas .# Install uv if not already installed
curl -LsSf https://astral.sh/uv/install.sh | sh
# Create virtual environment and install dependencies
uv venv
source .venv/bin/activate # On Windows: .venv\Scripts\activate
uv pip install -e .
# Run tests
pytestfrom jsoncanvas import Canvas, TextNode, Edge
# Create nodes
title = TextNode(
id="title",
x=100,
y=100,
width=400,
height=100,
text="# Hello Canvas\n\nThis is a demonstration.",
color="#4285F4"
)
info = TextNode(
id="info",
x=600,
y=100,
width=300,
height=100,
text="More information here",
color="2" # Using preset color
)
# Create canvas
canvas = Canvas()
canvas.add_node(title)
canvas.add_node(info)
# Connect nodes
edge = Edge(
id="edge1",
from_node="title",
to_node="info",
from_side="right",
to_side="left",
label="Connection"
)
canvas.add_edge(edge)
# Save canvas
canvas.save("example.canvas")このMCPサーバーはMITライセンスに基づいてライセンスされています。つまり、MITライセンスの条件に従って、ソフトウェアを自由に使用、改変、配布することができます。詳細については、プロジェクトリポジトリのLICENSEファイルをご覧ください。
Create a JSON Canvas from nodes (and optional edges) and write it as a date-prefixed .canvas file under OUTPUT_PATH.
| Name | Required | Description | Default |
|---|---|---|---|
| nodes | Yes | ||
| filename | Yes | ||
| edges | No |
| Name | Required | Description |
|---|---|---|
| path | Yes | Absolute path to the written .canvas file |
| node_count | Yes | Number of nodes written |
| edge_count | Yes | Number of edges written |
| canvas | Yes | The full canvas document, for inline UI rendering |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must cover behavioral traits. It mentions file writing but does not disclose side effects (e.g., overwriting), required permissions, or what happens if the file already exists.
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. However, it is so concise that it omits useful detail; it could include more information without becoming verbose.
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 three parameters, no annotations, and no schema description coverage, the description is insufficient. It does not explain OUTPUT_PATH, the date prefix, or the expected format of nodes and edges.
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%, meaning the description should compensate. It only mentions nodes and optional edges without explaining their structure, format, or the filename parameter's requirements.
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 (create) and resource (JSON Canvas), and specifies it writes a date-prefixed .canvas file under OUTPUT_PATH. This distinguishes it from siblings like edit, list, and read.
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 like edit_canvas or validate_canvas. There is no explicit when-to-use or when-not-to-use context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Edit a stored .canvas file: add, update, and/or remove nodes and edges in one atomic write. Operations apply in order — add_nodes, update_nodes, add_edges, update_edges, remove_edge_ids, remove_node_ids — and removing a node also removes its connected edges. If any operation fails the file is left unchanged. Returns the updated canvas.
| Name | Required | Description | Default |
|---|---|---|---|
| filename | Yes | ||
| add_nodes | No | ||
| update_nodes | No | ||
| remove_node_ids | No | ||
| add_edges | No | ||
| update_edges | No | ||
| remove_edge_ids | No |
| Name | Required | Description |
|---|---|---|
| path | Yes | Absolute path to the written .canvas file |
| node_count | Yes | Number of nodes written |
| edge_count | Yes | Number of edges written |
| canvas | Yes | The full canvas document, for inline UI rendering |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses atomic write, operation order, cascading deletion of edges on node removal, and rollback on failure, providing strong behavioral transparency.
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 long, front-loaded with purpose, and every sentence adds value 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 7 parameters, no annotations, and an output schema, the description covers key behaviors but does not mention the structure of the returned canvas or edge cases. It is mostly complete but lacks some detail.
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%, so description must compensate. It adds meaning by listing operations in order and explaining cascading removal, but does not detail each parameter's structure or valid values beyond 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 the tool edits a .canvas file with atomic add, update, remove operations on nodes and edges. It distinguishes from sibling tools like create, read, validate by specifying it modifies existing 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?
The description implies use when modifying an existing canvas, mentions operation order and cascading edge removal, but does not explicitly state when not to use it or provide direct alternatives (e.g., for reading use read_canvas).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Export a stored canvas to another format: 'markdown' (an outline that follows the edges) or 'svg' (a standalone vector image). SVG renders each node's title line only.
| Name | Required | Description | Default |
|---|---|---|---|
| filename | Yes | ||
| format | Yes |
| Name | Required | Description |
|---|---|---|
| format | Yes | The export format (markdown or svg) |
| mime_type | Yes | MIME type of the exported content |
| content | Yes | The exported document text |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the full burden. It discloses that SVG renders only each node's title line, but does not mention other behavioral traits such as whether the operation is read-only, if it requires specific permissions, or the nature of the output. Partial but not comprehensive.
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, front-loaded with the main purpose, followed by format details. No redundant information; every sentence is necessary and efficient.
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 an output schema (not shown but indicated), the description does not need to explain return values. It adequately covers the two parameters and their behaviors. Minor omission: no mention of whether the file is saved or returned as a download, but still sufficient for a simple export 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 coverage is 0%, so the description must add value. It explains the format enum values ('markdown' as an outline following edges, 'svg' as a standalone vector image), enhancing understanding beyond the schema's enum list. However, the 'filename' parameter receives no additional 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 exports a stored canvas to another format, listing two specific formats with brief explanations. It distinguishes itself from sibling tools like create_canvas, edit_canvas, etc., as an export operation.
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 the tool is used for exporting but provides no explicit guidance on when to use it over alternatives, nor any exclusions or prerequisites. It's adequate but lacks comparative context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the .canvas files available in OUTPUT_PATH.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full transparency burden. It adequately conveys that the tool lists files from OUTPUT_PATH but does not disclose any behavioral traits like sorting, pagination, or file size limits. Given the tool's simplicity, a score of 3 is appropriate.
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 with no wasted words. It is front-loaded with the key 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 the tool has no parameters and an output schema exists, the description is sufficiently complete for a simple listing tool. It identifies the source (OUTPUT_PATH), though it could optionally mention the output structure briefly.
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 (schema coverage 100%), and the description adds no parameter information, which is acceptable. According to the rubric, 0 parameters yields a baseline score of 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 clearly states the tool lists .canvas files available in OUTPUT_PATH. It uses a specific verb ('List') and resource ('.canvas files'), and distinguishes itself from siblings like search_canvases by implying a full listing without filters.
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 provides no guidance on when to use this tool versus alternatives, such as search_canvases for filtered queries. No context about prerequisites or exclusions is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read a .canvas file from OUTPUT_PATH and return its nodes and edges.
| Name | Required | Description | Default |
|---|---|---|---|
| filename | Yes |
| Name | Required | Description |
|---|---|---|
| nodes | No | JSON Canvas node objects |
| edges | No | JSON Canvas edge objects |
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 describes the basic read operation but does not disclose error handling, file existence requirements, or permissions needed.
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 concise sentence that front-loads the verb and key object. It is not verbose, but could be more informative without sacrificing brevity.
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 (1 parameter, output schema exists), the description is minimally adequate but lacks context on file path conventions, error states, and typical use cases.
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 description adds no information about the 'filename' parameter beyond its name. Schema description coverage is 0%, and the description does not clarify the relationship to OUTPUT_PATH or expected file format.
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 (Read), the resource (.canvas file), and the output (nodes and edges). It distinguishes from siblings like create_canvas or edit_canvas which perform different operations.
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 needing to read a .canvas file, but does not provide explicit guidance on when to use this tool versus alternatives such as search_canvases or list_canvases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Case-insensitive substring search across stored canvases. Matches node text, labels, file paths, URLs, and IDs, plus edge labels. Searches every canvas in OUTPUT_PATH unless a filename is given.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | ||
| filename | No |
| Name | Required | Description |
|---|---|---|
| matches | No | Matching nodes and edges |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses case-insensitive behavior, target fields, and the global/default search scope (all canvases in OUTPUT_PATH unless filename specified). However, it does not describe the output format, though an output schema exists.
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 concise sentences front-load the core action and key behaviors. No redundant or extraneous information.
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 search scope, fields, and the filename parameter. It does not mention match handling (e.g., what if no matches) or pagination, but the output schema likely covers return structure. Given two parameters and a common tool pattern, it is mostly complete.
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%, but the description explains the optional filename parameter (limits search to a single canvas). The required query parameter is implied by the search action but not explicitly described. This adds some value beyond 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 the tool performs a case-insensitive substring search across stored canvases, specifying the fields matched (node text, labels, file paths, URLs, IDs, edge labels). It distinguishes this from siblings like list_canvases or read_canvas by emphasizing search across multiple fields and optional filename filtering.
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 for content-based search but does not explicitly contrast with siblings (e.g., when to use list_canvases vs search_canvases). It provides guidance on the filename parameter to limit scope, but lacks 'when not to use' or alternative scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Validate canvas data against the JSON Canvas 1.0 specification.
| Name | Required | Description | Default |
|---|---|---|---|
| canvas | Yes |
| Name | Required | Description |
|---|---|---|
| valid | Yes | True when the canvas conforms to the spec |
| error | No | Validation error message when invalid |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It does not disclose whether validation causes side effects, returns errors, or is read-only. The description merely states the action without behavioral context.
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 no redundancy. The description is concise and front-loaded with key information.
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?
An output schema exists, so the return value might be documented there, but the description does not explain what happens on validation (e.g., passes/fails output). It is minimally adequate but lacks completeness about behavior.
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%, and the description adds minimal meaning: 'canvas data' barely paraphrases the schema parameter. No details about expected fields or constraints are provided.
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?
Description clearly states the tool validates canvas data against a specific specification (JSON Canvas 1.0). Verb 'validate' and resource 'canvas data' are specific, and the tool is distinct from siblings like create_canvas or edit_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?
No guidance on when to use this tool versus alternatives, no prerequisites or exclusions mentioned. The description lacks any context about appropriate usage.
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.
v0.2.0create_canvasedit_canvasexport_canvaslist_canvasesread_canvassearch_canvasesvalidate_canvasScored across 7 tools
Each tool has a clearly distinct purpose: create, edit, export, list, read, search, validate. There is no overlap or ambiguity between them.
All tool names follow a consistent verb_noun pattern (e.g., create_canvas, list_canvases) using snake_case, making the set predictable and easy to navigate.
With 7 tools, the server is well-scoped for managing JSON Canvas files. Each tool earns its place, covering essential operations without excess.
The tool set covers create, read, update, list, search, export, and validate. However, a dedicated delete canvas tool is missing, which is a minor gap for full lifecycle management.
MCP Spec Compliance MCP — audits any MCP server.json against the official Model Context Protocol
Model Context Protocol server for the Apideck Unified API. Connect any MCP-compatible agent framework to 100+ accounting systems, HRIS platforms, file storage providers, and more through one integration. More information https://www.apideck.com/mcp-server
A Model Context Protocol server for Wix AI tools
Model Context Protocol server for Studex tools, notifications, and profile integrations