Skip to main content
Glama
Sign In
xuanshang-canvas

xuanshang-canvas

by pencil102411-cell
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

submit_generation

Destructive

Starts a video generation task for a project node, requiring explicit user confirmation before spending credits. Returns only the task ID and rejects requests when the node is already running.

Instructions

提交生成任务（花积分）。每次都要用户单独确认：插件会弹确认框/确认窗口，用户点确认才提交。 同一节点已有任务在跑时直接拒绝。提交后只返回任务 ID，不会自动盯进度。

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": {
      "project": "<project>",
      "node": "<node>"
    },
    "name": "submit_generation"
  }
}

Input Schema

NameRequiredDescriptionDefault
nodeYes要提交的视频节点（节点名或 ID）
projectYes项目名称或项目 ID（用 list_projects 查）
confirm_codeNo两步确认码。只有上一次调用返回了确认码、并且用户已经明确同意时才填；平时不要填

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.2.0

TDQS

A4.4/5.0
Behavior5/5

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

Annotations already declare write/destructive/non-idempotent/openWorld, and the description adds genuinely new behavior: it consumes credits, requires an explicit user confirmation step, hard-rejects concurrent tasks on the same node, and returns only a task ID without tracking progress. That last point is important because it tells the agent to poll elsewhere rather than wait.

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?

Four short, front-loaded sentences covering cost, confirmation requirement, concurrency rejection, and return behavior. Zero filler; the most decision-relevant information (costs credits, needs confirmation) comes first.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a destructive, non-idempotent submission tool, the description covers cost, the mandatory confirmation gate, the rejection rule, and the fact that progress is not tracked (implying the agent must poll get_task). An output schema exists, so return-value detail is not required of the description.

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%, so the baseline is 3, but the description supplies the two-step confirmation narrative that gives confirm_code its meaning (a code returned by a prior call that the user must approve). It does not add syntax or format detail beyond the schema, so it is not a full 5.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb+resource (提交生成任务 = submit generation task) and adds the cost signal (花积分), so an agent knows at a glance this initiates a paid render. It does not explicitly distinguish itself from sibling creation tools like create_video_node or create_final_video, so it stops short of a 5.

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 operating conditions: every submission requires per-user confirmation through a dialog, and submission is rejected outright if a task is already running on the node. It stops short of naming an alternative tool for any scenario, so 4 rather than 5.

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