Skip to main content
Glama
Sign In
duddy

duddy

by qu15501267889-sketch
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

duddy_plan_workflow

Plan ComfyUI canvas changes as granular, ordered steps, then send the plan to the user for approval before any node, connection, or widget is created or modified.

Instructions

【第一步·只规划，绝不动手】把你想在画布上做的事写成一个分步计划，推送给用户的 ComfyUI 界面，等待用户点击「同意」。

硬性要求： · 每个 step 只做一件事，粒度要细（一个节点一步、一条连线一步） · create_node 必须给 ref 别名，后续 connect/set_widget 用别名引用，不要猜 node_id · connect 用 from_ref/from_slot → to_ref/to_slot · 每步给 title（人类可读）和 why（为什么需要这一步）

调用后你会拿到 plan_id 和 state=proposed。此时什么都不会发生，直到用户在弹窗里点同意。 直接把 narration 字段念给用户听，然后停下来等。

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": {
      "title": "<title>",
      "summary": "<summary>",
      "steps": "<steps>"
    },
    "name": "duddy_plan_workflow"
  }
}

Input Schema

NameRequiredDescriptionDefault
notesNo风险提示/前置条件，可空
stepsYes按执行顺序排列的步骤
titleYes计划标题，一句话，人类可读
summaryYes这个计划要达成什么，2-3 句

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.3/5.0
Behavior4/5

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

With zero annotations, the description carries the safety burden well: it explicitly says the call performs no mutation and returns plan_id plus state=proposed, and it tells the agent to read the narration field back to the user and then halt. Prerequisites such as what happens on rejection or how a pending plan is aborted/expired are not covered.

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?

Front-loaded with a bracketed one-line summary, followed by a tight bullet list of hard rules — every line carries operational weight. The final line about reading the narration field slightly mixes return-handling with planning rules, but no sentence is filler.

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?

For a planning tool with no output schema, it covers the essential lifecycle: what is produced (plan_id, state=proposed), what the user must do, and how the agent should behave afterward. The gap is the downstream path — no mention of checking status, applying steps, or rolling back a proposed plan.

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 100% for the top-level fields, but the critical 'steps.args' object is untyped, so the description does real work: one action per step, create_node must carry a ref alias, connect uses from_ref/from_slot → to_ref/to_slot, and every step needs title and why. That convention detail exists nowhere in 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?

States a specific verb and resource: write a step-by-step plan for canvas actions and push it to the user's ComfyUI interface for approval, tagged as '只规划，绝不动手' (plan only, never act). That framing immediately separates it from mutation siblings like duddy_apply_step and duddy_rollback_plan.

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?

Gives clear when-to-use context ('第一步') and a strong implicit exclusion: nothing happens until the user clicks approve, after which the agent must stop and wait. What is missing is explicit routing to the siblings that follow approval (duddy_plan_status, duddy_apply_step, duddy_abort_plan) — the agent must infer the handoff.

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