CNAPS.ai MCP Server

update_flow

DestructiveIdempotent

Change an existing flow: rename it, replace its tags, and/or update node parameters. Provide any combination — one call can do all three. Node parameters are merged with existing values, so specify only what changes; tags replace the existing set. Cannot update a flow that is currently running. This tool does NOT change the graph: to add or remove a node, swap a node's model, or rewire ports, use edit_flow — never create a new flow to restructure an existing one.

Input Schema

TableJSON Schema

Name	Required	Description
`name`	No	New name for the flow.
`tags`	No	Tags to replace all existing manual tags with. JSON array or comma-separated, e.g. '["upscale","4k"]' or 'upscale,4k'. Entries are trimmed.
`flow_id`	Yes	The unique identifier of the flow to update.
`node_updates`	No	JSON array of node parameter updates. Each entry has node_id (number) and parameters (object with key-value pairs to set/override). Example: [{"node_id": 1, "parameters": {"scale_factor": 4, "steps": 50}}]. Unspecified parameters keep their current values. An entry for an input node may also (or instead) set include_in_fork (boolean): whether people who fork the flow from a community post or shared link get this input's value. Text inputs are included by default; image, video, audio and file inputs are not, so a fork starts with them empty. Example: [{"node_id": 101, "include_in_fork": true}]. An entry for a model node may also set locked (boolean), the same pin as Studio's result lock: locked=true keeps that node's current result on later runs instead of re-generating it, and also stops the re-run from spreading to what depends only on it. Use it to redo some outputs and keep the rest — lock the nodes whose results are final, then run_flow. A locked node also ignores new inputs and upstream changes: unlock it before running with new input files if its output should follow them. Only a node whose last run finished cleanly with its current parameters can be locked, and update_flow will not change a locked node's parameters: set locked=false in the same entry to unlock and edit it. Put everything for one node in a single entry. get_flow shows locked per node. Example: [{"node_id": 3, "locked": true}].

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 8, 2026

changedInput schema / properties / node_updates / description

Previous value: -"JSON array of node parameter updates. Each entry has node_id (number) and parameters (object with key-value pairs to set/override). Example: [{\"node_id\": 1, \"parameters\": {\"scale_factor\": 4, \"steps\": 50}}]. Unspecified parameters keep their current values. An entry for an input node may also (or instead) set include_in_fork (boolean): whether people who fork the flow from a community post or shared link get this input's value. Text inputs are included by default; image, video, audio and file inputs are not, so a fork starts with them empty. Example: [{\"node_id\": 101, \"include_in_fork\": true}]."New value: +"JSON array of node parameter updates. Each entry has node_id (number) and parameters (object with key-value pairs to set/override). Example: [{\"node_id\": 1, \"parameters\": {\"scale_factor\": 4, \"steps\": 50}}]. Unspecified parameters keep their current values. An entry for an input node may also (or instead) set include_in_fork (boolean): whether people who fork the flow from a community post or shared link get this input's value. Text inputs are included by default; image, video, audio and file inputs are not, so a fork starts with them empty. Example: [{\"node_id\": 101, \"include_in_fork\": true}]. An entry for a model node may also set locked (boolean), the same pin as Studio's result lock: locked=true keeps that node's current result on later runs instead of re-generating it, and also stops the re-run from spreading to what depends only on it. Use it to redo some outputs and keep the rest — lock the nodes whose results are final, then run_flow. A locked node also ignores new inputs and upstream changes: unlock it before running with new input files if its output should follow them. Only a node whose last run finished cleanly with its current parameters can be locked, and update_flow will not change a locked node's parameters: set locked=false in the same entry to unlock and edit it. Put everything for one node in a single entry. get_flow shows locked per node. Example: [{\"node_id\": 3, \"locked\": true}]."

Changed1 schema field changedOct 5, 2026

changedInput schema / properties / node_updates / description

Previous value: -"JSON array of node parameter updates. Each entry has node_id (number) and parameters (object with key-value pairs to set/override). Example: [{\"node_id\": 1, \"parameters\": {\"scale_factor\": 4, \"steps\": 50}}]. Unspecified parameters keep their current values."New value: +"JSON array of node parameter updates. Each entry has node_id (number) and parameters (object with key-value pairs to set/override). Example: [{\"node_id\": 1, \"parameters\": {\"scale_factor\": 4, \"steps\": 50}}]. Unspecified parameters keep their current values. An entry for an input node may also (or instead) set include_in_fork (boolean): whether people who fork the flow from a community post or shared link get this input's value. Text inputs are included by default; image, video, audio and file inputs are not, so a fork starts with them empty. Example: [{\"node_id\": 101, \"include_in_fork\": true}]."

Changed3 schema fields changedAug 9, 2026

addedInput schema / properties / name

Added value: +{
+  "description": "New name for the flow.",
+  "type": "string"
+}

addedInput schema / properties / tags

Added value: +{
+  "description": "Tags to replace all existing manual tags with. JSON array or comma-separated, e.g. '[\"upscale\",\"4k\"]' or 'upscale,4k'. Entries are trimmed.",
+  "type": "string"
+}

changedInput schema / required

Previous value: -[
-  "flow_id",
-  "node_updates"
-]New value: +[
+  "flow_id"
+]

First observedAug 1, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Annotations declare destructive+idempotent, and the description adds real behavioral context beyond them: node parameters merge rather than replace, tags overwrite the whole set, running flows are ineligible, locked nodes cannot have parameters changed, and locked-mode semantics (result pinning, re-run propagation) are explained. This is exactly the extra context the annotations cannot carry.

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 the change scope followed by constraints and the edit_flow routing warning. The locked-node explanation is lengthy and partly duplicates the node_updates schema text, but every sentence carries operational meaning; no filler.

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 mutation tool with no output schema, the description covers mutation semantics, eligibility constraints, sibling routing, and node-lock edge cases thoroughly enough that an agent can call it correctly without further inspection.

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% and the schema already documents tags-replace and parameter-merge behavior, so those restatements earn little. The description does add cross-parameter interaction semantics not in the schema (a locked node rejects parameter changes unless unlocked in the same entry, all edits for one node must be one entry), which pushes it above the 3 baseline.

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 ('Change an existing flow') and enumerates exactly which aspects can be changed (name, tags, node parameters). It then explicitly names the sibling edit_flow and states what update_flow does NOT do (change the graph), making separation from siblings unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives explicit when-to-use ('one call can do all three'), an explicit when-not ('Cannot update a flow that is currently running'), and routes graph-structure work to edit_flow with the additional warning not to create a new flow to restructure an existing one.

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

All CNAPS.ai MCP Server tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?