Extend MCP

Update a workflow's draft

update_workflow

DestructiveIdempotent

Update a workflow's mutable draft (workflows group): rename it and/or replace the entire draft step graph (hand-editing steps? call get_documentation with https://docs.extend.ai/workflows/configuring-workflows.md first). Deployed versions are immutable and unaffected — runs pinned to them keep working.

Input Schema

TableJSON Schema

Name	Required	Description
`id`	Yes	Workflow ID (workflow_...).
`name`	No	New display name.
`steps`	No	Replaces the whole DRAFT step graph. Step graph (max 125 steps), TRIGGER → PARSE first. Every step needs { type, name }; "name" is REQUIRED and is what other steps route to. Route via next, an ARRAY of objects: linear steps (TRIGGER/PARSE/EXTRACT) use next: [{ step: "<target name>" }]; CLASSIFY/SPLIT branch with next: [{ step, classificationId }] (classificationId = a classification id from the config, not its type). TRIGGER routes to exactly one PARSE. Types: TRIGGER, PARSE, EXTRACT, CLASSIFY, SPLIT, MERGE_EXTRACT, CONDITIONAL, CONDITIONAL_EXTRACT, EXTERNAL_DATA_VALIDATION, WEBHOOK_RESPONSE, RULE_VALIDATION, VALIDATION, ROUTER, HUMAN_REVIEW, COLLECT, FILE_CONVERSION. EXTRACT/CLASSIFY/SPLIT need a config with exactly one of a saved ref or inline config (EXTRACT: config.extractor {id,version} or config.extractorConfig with REQUIRED schema; CLASSIFY: config.classifier {id,version} or config.classifierConfig); next is only allowed once config is set. Classifier/splitter refs can't be "latest" — use semver or "draft". The rules here are a summary — before authoring a step graph by hand, call get_documentation with https://docs.extend.ai/workflows/configuring-workflows.md and follow it.
`environment`	Yes	"TEST" = the Test (development) environment, "PRODUCTION" = live. Must match a granted target from get_me (an API key pins one environment).
`workspaceId`	Yes	Target workspace (ws_...). Must be a granted workspace — get_me lists the accepted values.

Output Schema

TableJSON Schema

Name	Required	Description	Default
`id`	Yes
`name`	Yes
`createdAt`	No
`updatedAt`	No
`draftVersion`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 2, 2026

changedInput schema / properties / steps / description

Previous value: -"Replaces the whole DRAFT step graph. Step graph (max 500 steps), TRIGGER → PARSE first. Every step needs { type, name }; \"name\" is REQUIRED and is what other steps route to. Route via next, an ARRAY of objects: linear steps (TRIGGER/PARSE/EXTRACT) use next: [{ step: \"<target name>\" }]; CLASSIFY/SPLIT branch with next: [{ step, classificationId }] (classificationId = a classification id from the config, not its type). TRIGGER routes to exactly one PARSE. Types: TRIGGER, PARSE, EXTRACT, CLASSIFY, SPLIT, MERGE_EXTRACT, CONDITIONAL, CONDITIONAL_EXTRACT, EXTERNAL_DATA_VALIDATION, WEBHOOK_RESPONSE, RULE_VALIDATION, VALIDATION, ROUTER, HUMAN_REVIEW, COLLECT, FILE_CONVERSION. EXTRACT/CLASSIFY/SPLIT need a config with exactly one of a saved ref or inline config (EXTRACT: config.extractor {id,version} or config.extractorConfig with REQUIRED schema; CLASSIFY: config.classifier {id,version} or config.classifierConfig); next is only allowed once config is set. Classifier/splitter refs can't be \"latest\" — use semver or \"draft\". The rules here are a summary — before authoring a step graph by hand, call get_documentation with https://docs.extend.ai/workflows/configuring-workflows.md and follow it."New value: +"Replaces the whole DRAFT step graph. Step graph (max 125 steps), TRIGGER → PARSE first. Every step needs { type, name }; \"name\" is REQUIRED and is what other steps route to. Route via next, an ARRAY of objects: linear steps (TRIGGER/PARSE/EXTRACT) use next: [{ step: \"<target name>\" }]; CLASSIFY/SPLIT branch with next: [{ step, classificationId }] (classificationId = a classification id from the config, not its type). TRIGGER routes to exactly one PARSE. Types: TRIGGER, PARSE, EXTRACT, CLASSIFY, SPLIT, MERGE_EXTRACT, CONDITIONAL, CONDITIONAL_EXTRACT, EXTERNAL_DATA_VALIDATION, WEBHOOK_RESPONSE, RULE_VALIDATION, VALIDATION, ROUTER, HUMAN_REVIEW, COLLECT, FILE_CONVERSION. EXTRACT/CLASSIFY/SPLIT need a config with exactly one of a saved ref or inline config (EXTRACT: config.extractor {id,version} or config.extractorConfig with REQUIRED schema; CLASSIFY: config.classifier {id,version} or config.classifierConfig); next is only allowed once config is set. Classifier/splitter refs can't be \"latest\" — use semver or \"draft\". The rules here are a summary — before authoring a step graph by hand, call get_documentation with https://docs.extend.ai/workflows/configuring-workflows.md and follow it."

Changed1 schema field changedOct 1, 2026

changedInput schema / properties / steps / description

Previous value: -"Replaces the whole DRAFT step graph. Step graph (max 100 steps), TRIGGER → PARSE first. Every step needs { type, name }; \"name\" is REQUIRED and is what other steps route to. Route via next, an ARRAY of objects: linear steps (TRIGGER/PARSE/EXTRACT) use next: [{ step: \"<target name>\" }]; CLASSIFY/SPLIT branch with next: [{ step, classificationId }] (classificationId = a classification id from the config, not its type). TRIGGER routes to exactly one PARSE. Types: TRIGGER, PARSE, EXTRACT, CLASSIFY, SPLIT, MERGE_EXTRACT, CONDITIONAL, CONDITIONAL_EXTRACT, EXTERNAL_DATA_VALIDATION, WEBHOOK_RESPONSE, RULE_VALIDATION, VALIDATION, ROUTER, HUMAN_REVIEW, COLLECT, FILE_CONVERSION. EXTRACT/CLASSIFY/SPLIT need a config with exactly one of a saved ref or inline config (EXTRACT: config.extractor {id,version} or config.extractorConfig with REQUIRED schema; CLASSIFY: config.classifier {id,version} or config.classifierConfig); next is only allowed once config is set. Classifier/splitter refs can't be \"latest\" — use semver or \"draft\". The rules here are a summary — before authoring a step graph by hand, call get_documentation with https://docs.extend.ai/workflows/configuring-workflows.md and follow it."New value: +"Replaces the whole DRAFT step graph. Step graph (max 500 steps), TRIGGER → PARSE first. Every step needs { type, name }; \"name\" is REQUIRED and is what other steps route to. Route via next, an ARRAY of objects: linear steps (TRIGGER/PARSE/EXTRACT) use next: [{ step: \"<target name>\" }]; CLASSIFY/SPLIT branch with next: [{ step, classificationId }] (classificationId = a classification id from the config, not its type). TRIGGER routes to exactly one PARSE. Types: TRIGGER, PARSE, EXTRACT, CLASSIFY, SPLIT, MERGE_EXTRACT, CONDITIONAL, CONDITIONAL_EXTRACT, EXTERNAL_DATA_VALIDATION, WEBHOOK_RESPONSE, RULE_VALIDATION, VALIDATION, ROUTER, HUMAN_REVIEW, COLLECT, FILE_CONVERSION. EXTRACT/CLASSIFY/SPLIT need a config with exactly one of a saved ref or inline config (EXTRACT: config.extractor {id,version} or config.extractorConfig with REQUIRED schema; CLASSIFY: config.classifier {id,version} or config.classifierConfig); next is only allowed once config is set. Classifier/splitter refs can't be \"latest\" — use semver or \"draft\". The rules here are a summary — before authoring a step graph by hand, call get_documentation with https://docs.extend.ai/workflows/configuring-workflows.md and follow it."

First observedSep 3, 2026

TDQS

A4.1/5.0

Behavior4/5

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

Annotations already declare destructiveHint=true and idempotentHint=true, but the description adds meaningful context beyond them: that only the draft is mutated, deployed versions are immutable, and runs pinned to them keep working. That materially clarifies the scope of the destructive flag. It stops short of 5 since permission/auth nuances are left to the schema.

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-loads the core action and its scope in the first clause, then appends the docs pointer. The parenthetical is slightly awkward but useful, and there is little waste overall.

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 an output schema exists, return values need no explanation, and the description covers the draft-vs-deployed distinction plus the documentation escape hatch. What remains uncovered (auth requirements, behavior of individual step types) is delegated appropriately to the schema and docs.

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 description coverage is 100%, so the schema already documents every parameter in depth (steps graph, environment semantics, workspace scoping). The description paraphrases 'rename' and 'step graph' without adding syntax or format detail beyond the schema. Baseline 3 applies when the schema carries the load.

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 ('Update a workflow's mutable draft') and immediately scopes it ('rename it and/or replace the entire draft step graph'). This distinguishes it clearly from siblings like deploy_workflow_version or create_workflow without needing their schemas.

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 context on when to use it (renaming, replacing the draft graph) and routes the agent to get_documentation for the hand-authoring case. It does not explicitly contrast with the closest alternative, deploy_workflow_version, so it stops short of full when/when-not guidance.

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

All Extend MCP tools Inspect

Try in Browser

Shareable, User-Owned Context BackendPeople, applications, and agents read, write, and coordinate together in one context lake. Reach it over MCP, a CLI, a Python SDK, or REST.fulcradynamics.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?