Una implementación de servidor del Protocolo de Contexto de Modelo (MCP) que proporciona herramientas para trabajar con archivos JSON Canvas según la especificación oficial . Este servidor permite crear, modificar y validar estructuras de datos Canvas infinitas.
El servidor JSON Canvas MCP proporciona una implementación completa de la especificación JSON Canvas 1.0, lo que permite:
Creación y manipulación de datos de lienzo infinitos
Soporte para todos los tipos de nodos (texto, archivo, enlace, grupo)
Conexiones de borde con estilo y etiquetas
Validación contra la especificación
Rutas de salida configurables
Related MCP server: MCP REST API Server
El servidor expone los siguientes recursos:
canvas://schema : Esquema JSON para validar archivos de lienzo
canvas://examples : Archivos de lienzo de ejemplo que demuestran diferentes funciones
canvas://templates : Plantillas para crear nuevos lienzos
crear_nodo
Crea un nuevo nodo de cualquier tipo compatible
Aporte:
type (cadena): Tipo de nodo ("texto", "archivo", "enlace", "grupo")
properties (objeto): Propiedades específicas del nodo
Común: id , x , y , width , height , color
Específico del tipo: text , file , url , etc.
Devuelve: objeto de nodo creado
nodo_de_actualización
Actualizar las propiedades de un nodo existente
Aporte:
id (cadena): ID del nodo a actualizar
properties (objeto): Propiedades a actualizar
Devuelve: objeto de nodo actualizado
eliminar_nodo
Eliminar un nodo y sus bordes conectados
Aporte:
id (cadena): ID del nodo a eliminar
Devoluciones: Confirmación de éxito
crear_borde
Crear un nuevo borde entre nodos
Aporte:
id (cadena): identificador de borde único
fromNode (cadena): ID del nodo de origen
toNode (cadena): ID del nodo de destino
fromSide (cadena opcional): Lado de inicio ("arriba", "derecha", "abajo", "izquierda")
toSide (cadena opcional): lado final
color (cadena opcional): color del borde
label (cadena opcional): etiqueta de borde
Devuelve: objeto de borde creado
actualizar_borde
Actualizar las propiedades de un borde existente
Aporte:
id (cadena): ID de borde que se actualizará
properties (objeto): Propiedades a actualizar
Devoluciones: objeto de borde actualizado
eliminar_borde
Quitar un borde
Aporte:
id (cadena): ID del borde que se eliminará
Devoluciones: Confirmación de éxito
validar_lienzo
Validar un lienzo contra la especificación
Aporte:
canvas (objeto): Datos del canvas a validar
Devuelve: Resultados de validación con cualquier error
lienzo_de_exportación
Exportar lienzo a diferentes formatos
Aporte:
format (cadena): Formato de destino ("json", "svg", "png")
canvas (objeto): Datos de Canvas para exportar
Devoluciones: Lienzo exportado en el formato solicitado
Agregue esto a su 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"
}
}
}
}El servidor se puede configurar mediante variables de entorno:
OUTPUT_PATH : Directorio donde se guardarán los archivos de lienzo (predeterminado: "./output")
FORMAT : Formato de salida predeterminado para archivos de lienzo (predeterminado: "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")Este servidor MCP cuenta con la licencia MIT. Esto significa que puede usar, modificar y distribuir el software libremente, sujeto a los términos y condiciones de la licencia MIT. Para más detalles, consulte el archivo de LICENCIA en el repositorio del proyecto.
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