Which integrations are available for this server?

Supports exporting canvas data to SVG format through the export_canvas tool, allowing visualization of JSON Canvas content.

How do I use JSON Canvas MCP Server?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@JSON Canvas MCP Server create a text node for brainstorming ideas at position 200,300" 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.

en es ja ko zh

JSON Canvas MCP Server

by Cam10001110101

Overview Schema Source Related Servers Score Discussions Admin

Hybrid

JSON Canvas MCP Server

A Model Context Protocol (MCP) server for working with JSON Canvas files — the open infinite-canvas format used by Obsidian. It lets an MCP client create, validate, read, and list .canvas files.

Built on the official mcp Python SDK (>=1.27), which negotiates the 2025-11-25 MCP protocol revision. Runs over stdio by default and optionally over the Streamable HTTP transport.

Hosts that support the MCP Apps UI extension render an interactive canvas viewer inline when you read or create a canvas — a pan/zoom, Obsidian-style preview of the nodes and edges. Text-only clients are unaffected and keep receiving the canvas as text/structured output.

Components

Tools

create_canvas — Create a canvas from nodes (and optional edges) and write it to a date-prefixed .canvas file under OUTPUT_PATH.
- Input: nodes (array of JSON Canvas node objects), filename (string, no extension), edges (optional array of edge objects).
- Returns (structured): { path, node_count, edge_count }.
validate_canvas — Validate canvas data against the JSON Canvas 1.0 specification.
- Input: canvas (object with optional nodes and edges).
- Returns (structured): { valid, error }.
read_canvas — Read a stored .canvas file and return its nodes and edges.
- Input: filename (string, with or without the .canvas extension).
- Returns (structured): { nodes, edges } (also rendered by the canvas viewer; text fallback is the canvas JSON).
list_canvases — List the .canvas files available in OUTPUT_PATH.
- Returns: array of filenames.
edit_canvas — Add, update, and/or remove nodes and edges on a stored canvas in one atomic write (a failed operation leaves the file unchanged).
- Input: filename, plus optional add_nodes, update_nodes (partial, must include id), remove_node_ids (cascades connected edges), add_edges, update_edges, remove_edge_ids.
- Returns (structured): { path, node_count, edge_count, canvas } — the updated canvas, so UI-capable hosts re-render it inline.
export_canvas — Export a stored canvas to another format.
- Input: filename, format (markdown | svg).
- Returns (structured): { format, mime_type, content }. Markdown is an edge-ordered outline; SVG is a standalone vector image (node title lines only — plain SVG can't render Markdown).
search_canvases — Case-insensitive substring search across stored canvases.
- Input: query, optional filename to scope to one canvas.
- Returns (structured): { matches: [{ filename, kind, id, field, snippet }] }.

create_canvas, read_canvas, and edit_canvas are linked to the canvas viewer via _meta.ui.resourceUri, so UI-capable hosts render the result inline.

Node objects use the JSON Canvas shape: id, type (text | file | link | group), x, y, width, height, optional color, plus type-specific fields (text, file/subpath, url, label/background/backgroundStyle). Edge objects use id, fromNode, toNode, and optional fromSide/toSide/fromEnd/toEnd/color/label.

Resources

canvas://schema — JSON Schema for validating canvas files.
canvas://examples/basic — A simple example canvas (two text nodes joined by an edge).
ui://canvas/viewer.html — The interactive canvas viewer (MCP Apps UI), served with MIME type text/html;profile=mcp-app. Referenced by create_canvas and read_canvas.

Interactive canvas viewer (MCP Apps UI)

The viewer is a single self-contained HTML bundle built from the ui/ source with Vite and the official @modelcontextprotocol/ext-apps client. It renders nodes (with markdown, colors, and groups) and edges (sides, arrows, labels) in a pan/zoom view, themed via the host's CSS variables.

The built bundle is committed at jsoncanvas/_ui/viewer.html and ships in the package, so running the server needs only Python. Rebuild it after changing ui/:

make build-ui     # cd ui && npm install && npm run build  (requires Node.js)

To preview the renderer standalone (no MCP host), run cd ui && npm run dev and open /preview.html.

Related MCP server: MCP REST API Server

Usage with Claude Desktop

Docker (stdio)

docker build -t mcp/jsoncanvas .

Add to your claude_desktop_config.json:

{
  "mcpServers": {
    "jsoncanvas": {
      "command": "docker",
      "args": ["run", "-i", "--rm", "-v", "canvas-data:/data", "mcp/jsoncanvas"],
      "env": { "OUTPUT_PATH": "/data/output" }
    }
  }
}

uv (stdio)

{
  "mcpServers": {
    "jsoncanvas": {
      "command": "uv",
      "args": ["--directory", "/path/to/jsoncanvas", "run", "mcp-server-jsoncanvas"],
      "env": { "OUTPUT_PATH": "./output" }
    }
  }
}

Streamable HTTP transport

To serve over Streamable HTTP instead of stdio:

mcp-server-jsoncanvas --transport streamable-http --host 127.0.0.1 --port 8000

The MCP endpoint is then http://127.0.0.1:8000/mcp. The transport binds to localhost and, per the 2025-11-25 spec, validates the Origin header with DNS-rebinding protection enabled (localhost Origins only by default). To accept connections from outside the host (e.g. when running the container with HTTP), bind --host 0.0.0.0 and configure your allowed Origins accordingly.

Browser-based MCP hosts (the kind that render the canvas viewer) connect cross-origin and must read the mcp-session-id response header, so the Streamable HTTP transport serves permissive CORS headers. Restrict the allowed origins with MCP_CORS_ORIGINS (comma-separated; default *).

Security note. The HTTP transport is unauthenticated — anyone who can reach the port can read and write .canvas files under OUTPUT_PATH. The server is intended for local use; keep it bound to 127.0.0.1 (the default). DNS-rebinding/Origin protection is fixed to localhost Origins and Hosts at startup, so binding --host 0.0.0.0 exposes the port on the network but still rejects non-localhost Host/Origin headers — to safely expose it remotely, front it with an authenticating reverse proxy rather than publishing it directly, and set MCP_CORS_ORIGINS to the specific origins you trust (never *).

Configuration

Environment variables:

OUTPUT_PATH — Directory where .canvas files are written/read (default ./output).
MCP_TRANSPORT — stdio (default) or streamable-http.
MCP_HOST / MCP_PORT — Host/port for the Streamable HTTP transport (default 127.0.0.1:8000).
MCP_CORS_ORIGINS — Comma-separated allowed CORS origins for the HTTP transport (default *).

Development

# Install uv: https://docs.astral.sh/uv/getting-started/installation/
make setup        # uv venv && uv sync --extra dev
make build-ui     # rebuild the canvas viewer bundle (requires Node.js)
make test         # run the test suite
make lint         # ruff check + format check
make audit        # scan dependencies for known vulnerabilities (pip-audit)
make run          # run the server over stdio

Run the bundled library example:

make example      # writes example.canvas to OUTPUT_PATH (default ./output)

Library example

The jsoncanvas package can also be used directly:

from jsoncanvas import Canvas, TextNode, Edge

title = TextNode(id="title", x=100, y=100, width=400, height=100,
                 text="# Hello Canvas", color="#4285F4")
info = TextNode(id="info", x=600, y=100, width=300, height=100,
                text="More information here", color="2")  # preset color

canvas = Canvas()
canvas.add_node(title)
canvas.add_node(info)
canvas.add_edge(Edge(id="edge1", from_node="title", to_node="info",
                     from_side="right", to_side="left", label="Connection"))

import json
print(json.dumps(canvas.to_dict(), indent=2))

License

MIT. See LICENSE.

Available Tools

7 tools

create_canvasCreate CanvasC

Create a JSON Canvas from nodes (and optional edges) and write it as a date-prefixed .canvas file under OUTPUT_PATH.

ParametersJSON Schema

Name	Required	Description	Default
`nodes`	Yes
`filename`	Yes
`edges`	No

Output Schema

ParametersJSON Schema

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

TDQS

C2.9/5.0

Behavior2/5

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.

Conciseness4/5

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.

Completeness2/5

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.

Parameters2/5

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.

Purpose5/5

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.

Usage Guidelines2/5

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_canvasEdit CanvasA

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.

ParametersJSON Schema

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

Output Schema

ParametersJSON Schema

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

TDQS

A4.6/5.0

Behavior5/5

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.

Conciseness5/5

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.

Completeness4/5

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.

Parameters4/5

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.

Purpose5/5

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.

Usage Guidelines4/5

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_canvasExport CanvasA

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.

ParametersJSON Schema

Name	Required	Description	Default
`filename`	Yes
`format`	Yes

Output Schema

ParametersJSON Schema

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

TDQS

A4/5.0

Behavior3/5

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.

Conciseness5/5

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.

Completeness4/5

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.

Parameters4/5

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.

Purpose5/5

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.

Usage Guidelines3/5

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_canvasesList CanvasesA

List the .canvas files available in OUTPUT_PATH.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.8/5.0

Behavior3/5

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.

Conciseness5/5

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.

Completeness4/5

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.

Parameters4/5

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.

Purpose5/5

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.

Usage Guidelines2/5

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_canvasRead CanvasB

Read a .canvas file from OUTPUT_PATH and return its nodes and edges.

ParametersJSON Schema

Name	Required	Description	Default
`filename`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`nodes`	No	JSON Canvas node objects
`edges`	No	JSON Canvas edge objects

TDQS

B3.1/5.0

Behavior2/5

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.

Conciseness4/5

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.

Completeness3/5

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.

Parameters1/5

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.

Purpose5/5

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.

Usage Guidelines3/5

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.

search_canvasesSearch CanvasesA

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.

ParametersJSON Schema

Name	Required	Description	Default
`query`	Yes
`filename`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`matches`	No	Matching nodes and edges

TDQS

A4/5.0

Behavior4/5

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.

Conciseness5/5

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.

Completeness4/5

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.

Parameters3/5

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.

Purpose5/5

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.

Usage Guidelines3/5

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_canvasValidate CanvasB

Validate canvas data against the JSON Canvas 1.0 specification.

ParametersJSON Schema

Name	Required	Description	Default
`canvas`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`valid`	Yes	True when the canvas conforms to the spec
`error`	No	Validation error message when invalid

TDQS

B3.2/5.0

Behavior2/5

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.

Conciseness5/5

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.

Completeness3/5

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.

Parameters2/5

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.

Purpose5/5

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.

Usage Guidelines2/5

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.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

7 tool updatesv0.2.0May 25, 2026
- First observedcreate_canvas
- First observededit_canvas
- First observedexport_canvas
- First observedlist_canvases
- First observedread_canvas
- First observedsearch_canvases
- First observedvalidate_canvas

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.8/5.0

Disambiguation5/5

Each tool has a clearly distinct purpose: create, edit, export, list, read, search, validate. There is no overlap or ambiguity between them.

Naming Consistency5/5

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.

Tool Count5/5

With 7 tools, the server is well-scoped for managing JSON Canvas files. Each tool earns its place, covering essential operations without excess.

Completeness4/5

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.

Maintenance

ActivityInactive

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Reddit Discussion

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

l0-py-blocks-mcp A
io.github.SELISEdigitalplatforms
A Model Context Protocol (MCP) server for Selise Blocks Cloud integration
Cloud Platforms Developer Tools App Automation
362
mcp-spec-compliance-mcp
io.github.CSOAI-ORG
MCP Spec Compliance MCP — audits any MCP server.json against the official Model Context Protocol
Testing & QA Tools Developer Tools
2
Apideck MCP A
dev.apideck.mcp
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
Developer Tools
42
mcp COAuth
com.wix
A Model Context Protocol server for Wix AI tools
Developer Tools Content Management Systems App Automation
216

Related MCP Servers

Canvas MCP Server V2.0
App Automation Education & Learning Tools
DMontgomery40
A
license
B
quality
D
maintenance
A Model Context Protocol server that enables interaction with the Canvas Learning Management System API, allowing users to manage courses, assignments, enrollments, and grades within Canvas.
Updated 3 months ago (2026-05-31 23:10 UTC)
54
44
103
JavaScript
MIT
MCP REST API Server
Developer Tools Code Execution
vinaykp
F
license
Not graded
quality
D
maintenance
A server implementation of the Model Context Protocol (MCP) that provides REST API endpoints for managing and interacting with MCP resources.
Updated a year ago (2025-06-01 03:08 UTC)
-
Example MCP SSE Server
Autonomous Agents Developer Tools
keepview
F
license
Not graded
quality
D
maintenance
A Model Context Protocol server that enables real-time communication using Server-Sent Events (SSE), providing standardized model management and resource templating capabilities.
Updated a year ago (2025-06-11 04:42 UTC)
-
MCP Communication Server
Communication
FuzzyCZX
A
license
C
quality
D
maintenance
A Model Context Protocol server implementation that enables real-time data communication between web pages and client applications through WebSocket connections.
Updated a year ago (2025-06-22 16:29 UTC)
2
867
MIT

Appeared in Searches

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/Cam10001110101/obsidian-jsoncanvas'

If you have feedback or need assistance with the MCP directory API, please join our Discord server