공식 사양 에 따라 JSON Canvas 파일을 처리하는 도구를 제공하는 모델 컨텍스트 프로토콜(MCP) 서버 구현입니다. 이 서버를 사용하면 무한한 Canvas 데이터 구조를 생성, 수정 및 검증할 수 있습니다.
JSON Canvas MCP 서버는 JSON Canvas 1.0 사양의 완전한 구현을 제공하여 다음을 가능하게 합니다.
무한 캔버스 데이터의 생성 및 조작
모든 노드 유형(텍스트, 파일, 링크, 그룹) 지원
스타일링 및 라벨을 사용한 엣지 연결
사양에 대한 검증
구성 가능한 출력 경로
Related MCP server: MCP REST API Server
서버는 다음과 같은 리소스를 제공합니다.
canvas://schema : 캔버스 파일 검증을 위한 JSON 스키마
canvas://examples : 다양한 기능을 보여주는 예시 캔버스 파일
canvas://templates : 새로운 캔버스를 생성하기 위한 템플릿
노드 생성
지원되는 모든 유형의 새 노드를 만듭니다.
입력:
type (문자열): 노드 유형("텍스트", "파일", "링크", "그룹")
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 (선택적 문자열): Edge 레이블
반환: 생성된 에지 객체
업데이트_에지
기존 모서리 속성 업데이트
입력:
id (문자열): 업데이트할 Edge ID
properties (객체): 업데이트할 속성
반환: 업데이트된 에지 객체
삭제_가장자리
모서리 제거
입력:
id (문자열): 삭제할 Edge ID
반환: 성공 확인
유효성 검사_캔버스
사양에 맞춰 캔버스 검증
입력:
canvas (객체): 검증할 Canvas 데이터
반환: 오류가 있는 검증 결과
내보내기_캔버스
캔버스를 다양한 형식으로 내보내기
입력:
format (문자열): 대상 형식("json", "svg", "png")
canvas (객체): 내보낼 캔버스 데이터
반환: 요청된 형식으로 캔버스를 내보냈습니다.
claude_desktop_config.json 에 다음을 추가하세요:
지엑스피1
{
"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