Skip to main content
Glama
Sign In
dify-canvas-mcp

dify-canvas-mcp

by elegant01
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

dify_canvas_patch

Patch existing Dify canvas draft nodes by ID to merge or replace data and update coordinates. Preview changes as a diff by default, then write back after validation and backup.

Instructions

修改草稿中的已有节点（按 id 合并 data、整块替换 data、改坐标）。默认 dry-run 只返回 diff；apply=true 才写回。写回前自动备份并自检（悬空边、自环、default_value 类型、Code 节点参数一致），写后刷新页面并核对渲染。

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "app": "<app>",
      "changes": "<changes>"
    },
    "name": "dify_canvas_patch"
  }
}

Input Schema

NameRequiredDescriptionDefault
appYes应用名称或 id。
aliasNo可选。实例别名。
applyNo默认 false（dry-run）；true 才写回。
changesYes改动数组：[{ "id": "节点id", "data": {字段补丁}, "replaceData": {整块替换}, "position": {"x":0,"y":0} }]
expectedHashNo可选。乐观锁：草稿 hash 不一致时拒绝写入。

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.3

TDQS

A4.2/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations exist, so the description carries the full burden, and it does substantial work: dry-run diff, automatic backup before writing, a named set of self-checks (dangling edges, self-loops, default_value types, Code node parameter consistency), and post-write page refresh plus render verification. It does not cover permission requirements or what happens on failed validation, so it falls short of a 5.

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?

Three compact clauses, front-loaded with the mutation scope, then the dry-run default, then the safety behavior. Every sentence contributes and nothing is padded.

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?

With no output schema, the description correctly notes that dry-run returns a diff, and it explains the write-back safeguards, so an agent knows what to expect on both paths. Minor gaps remain around error/failure reporting and required permissions.

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 100%, so all five parameters are already documented in the schema, including the changes array shape and expectedHash's optimistic-lock role. The description restates the dry-run/apply semantics and the merge-vs-replace distinction but adds no syntax or format detail beyond what the schema provides; baseline 3 applies.

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 gives a specific verb plus resource (修改草稿中的已有节点) and enumerates the three mutation modes: id-merge, whole-block replace, coordinate change. It also explicitly scopes the tool to existing nodes, which separates it from creation/publish siblings like dify_canvas_publish.

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?

It clearly states the default dry-run behavior and that apply=true is required to actually write, which is the main usage decision an agent must make. The 'existing nodes only' phrasing implicitly excludes node creation, but there is no explicit comparison with dify_canvas_get or dify_canvas_publish.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server

Other Tools