Skip to main content
Glama
spences10

mcp-n8n-builder

update_workflow

Modify and save entire workflows by providing the complete updated structure, including nodes, connections, and settings, after retrieving and editing an existing workflow.

Instructions

Updates an existing workflow with new configuration. Typically used after retrieving a workflow with get_workflow, modifying its structure, and then saving the changes. The entire workflow structure must be provided, not just the parts being changed.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
idYesID of the workflow to update - can be obtained from list_workflows
workflowYesComplete updated workflow structure - must include all nodes and connections, not just changes

Implementation Reference

  • Primary handler for update_workflow tool. Validates input (ID and workflow), parses workflow with Zod schema, validates nodes exist in n8n, calls API client to update, handles validation/node errors with guidance, returns formatted success/error response.
    export async function handle_update_workflow(
    	api_client: N8nApiClient,
    	args: any,
    ) {
    	if (!args.id || !args.workflow) {
    		throw new McpError(
    			ErrorCode.InvalidParams,
    			'Workflow ID and updated workflow data are required',
    		);
    	}
    
    	try {
    		// Validate workflow with Zod
    		const parsed_workflow = WorkflowSchema.parse(args.workflow);
    
    		// Validate that all nodes exist in n8n
    		const invalid_nodes =
    			await node_validator.validate_workflow_nodes(
    				parsed_workflow.nodes,
    			);
    
    		if (invalid_nodes.length > 0) {
    			// Format error message with suggestions
    			const error_messages = invalid_nodes.map((node) => {
    				const suggestion = node.suggestion
    					? `Did you mean '${node.suggestion}'?`
    					: 'No similar nodes found.';
    				return `- '${node.node_type}': Not a valid n8n node. ${suggestion}`;
    			});
    
    			// Include relevant sections from the workflow composition guide
    			const node_categories =
    				WORKFLOW_COMPOSITION_GUIDE.node_categories;
    
    			return {
    				content: [
    					{
    						type: 'text',
    						text:
    							`Workflow contains invalid node types:\n${error_messages.join(
    								'\n',
    							)}\n\nPlease correct these node types before updating the workflow.\n\n` +
    							`Here are the available node categories for reference:\n${node_categories}`,
    					},
    				],
    				isError: true,
    			};
    		}
    
    		const workflow = await api_client.update_workflow(
    			args.id,
    			parsed_workflow,
    		);
    
    		const activation_status = workflow.active ? 'active' : 'inactive';
    
    		return {
    			content: [
    				{
    					type: 'text',
    					text: `Successfully updated workflow "${workflow.name}" (ID: ${args.id}, Status: ${activation_status})`,
    				},
    			],
    		};
    	} catch (error: any) {
    		if (error.name === 'ZodError') {
    			return handle_validation_error(error);
    		}
    		return {
    			content: [
    				{
    					type: 'text',
    					text: `Error updating workflow: ${
    						error.message || String(error)
    					}`,
    				},
    			],
    			isError: true,
    		};
    	}
    }
  • Tool registration in MCP ListToolsRequestHandler, defining name, description, and input schema for update_workflow.
    	name: 'update_workflow',
    	description:
    		'Updates an existing workflow with new configuration. Typically used after retrieving a workflow with get_workflow, modifying its structure, and then saving the changes. The entire workflow structure must be provided, not just the parts being changed.',
    	inputSchema: {
    		type: 'object',
    		properties: {
    			id: {
    				type: 'string',
    				description:
    					'ID of the workflow to update - can be obtained from list_workflows',
    			},
    			workflow: {
    				type: 'object',
    				description:
    					'Complete updated workflow structure - must include all nodes and connections, not just changes',
    				properties: {
    					name: {
    						type: 'string',
    						description: 'Name of the workflow',
    					},
    					nodes: {
    						type: 'array',
    						description:
    							'Array of workflow nodes (triggers, actions, etc.)',
    						items: {
    							type: 'object',
    						},
    					},
    					connections: {
    						type: 'object',
    						description:
    							'Connections between nodes defining the workflow execution path',
    					},
    					settings: {
    						type: 'object',
    						description:
    							'Workflow settings like error handling, execution timeout, etc.',
    					},
    				},
    				required: ['name', 'nodes', 'connections'],
    			},
    		},
    		required: ['id', 'workflow'],
    	},
    },
  • Dispatch logic in MCP CallToolRequestHandler switch statement that routes to the handler.
    case 'update_workflow':
    	return await handle_update_workflow(api_client, args);
  • Zod schema for validating the workflow object structure used in the handler's input validation.
    export const WorkflowSchema = z.object({
    	id: z.string().optional(),
    	name: z.string(),
    	active: z.boolean().optional(),
    	nodes: z.array(NodeSchema),
    	connections: z.record(z.record(z.array(z.array(ConnectionSchema)))),
    	settings: WorkflowSettingsSchema,
    	staticData: z
    		.union([z.string().nullable(), z.record(z.any()).nullable()])
    		.optional(),
    });
  • API client method called by the handler to perform the actual HTTP PUT request to update the workflow in n8n.
    async update_workflow(id: string, workflow: any): Promise<any> {
    	return this.request<any>('PUT', `/workflows/${id}`, workflow);
    }
Behavior3/5

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

With no annotations provided, the description carries full burden. It discloses important behavioral traits: it's a mutation operation (implied by 'Updates'), requires the 'entire workflow structure' (not partial updates), and has a prerequisite relationship with get_workflow. However, it doesn't cover permissions, error handling, or what happens to existing executions, leaving some gaps.

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?

The description is perfectly concise with three sentences that each earn their place: first states the core purpose, second provides usage context, third clarifies a critical behavioral constraint. No wasted words, and the most important information (full-structure requirement) is appropriately emphasized at the end.

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 mutation tool with no annotations and no output schema, the description does well by explaining the update process, prerequisite relationship with get_workflow, and the full-structure requirement. It covers the essential context for proper use. The main gap is lack of information about what the tool returns or error conditions, but given the schema coverage and clear purpose, it's reasonably complete.

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 fully documents both parameters (id and workflow). The description adds minimal value beyond the schema by emphasizing that the workflow parameter must be 'complete' and 'not just the parts being changed', but this is essentially restating what's in the schema description for the workflow property. Baseline 3 is appropriate when schema does the heavy lifting.

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 clearly states the specific action ('Updates an existing workflow') and resource ('workflow'), distinguishing it from siblings like create_workflow (creation) and delete_workflow (deletion). It specifies the scope of updating 'with new configuration', making the purpose unambiguous.

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?

The description provides explicit context for when to use this tool: 'Typically used after retrieving a workflow with get_workflow, modifying its structure, and then saving the changes.' This gives clear guidance on the workflow process. However, it doesn't explicitly state when NOT to use it or mention alternatives like create_workflow for new workflows.

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

Install Server

Other Tools

Related Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/spences10/mcp-n8n-builder'

If you have feedback or need assistance with the MCP directory API, please join our Discord server