Skip to main content
Glama

update_flow

Modify existing flow metadata, structure, or folder organization to fix configurations and manage project workflows.

Instructions

Modify existing flow properties, configuration, or organization.

Purpose: Update flow metadata (name, description), modify flow structure (nodes, edges, components), or reorganize flows into different folders. Essential for maintaining flows, fixing configurations, renaming workflows, and managing project organization over time.

Parameters:

  • flow_id (required, UUID string): Unique identifier of flow to update (from list_flows or get_flow)

  • name (optional, string, max: 255 chars): New display name for the flow

  • description (optional, string): Updated purpose and functionality description

  • data (optional, object): New flow structure with nodes, edges, and component configurations

  • folder_id (optional, UUID string): Move flow to different folder (use list_folders for valid IDs, null for root level)

Returns: FlowRead object containing:

  • id (UUID): Flow's unique identifier (unchanged)

  • name (string): Updated flow name

  • description (string): Updated description

  • folder_id (UUID): New folder location

  • user_id (UUID): Owner identifier

  • created_at (ISO timestamp): Original creation time (unchanged)

  • updated_at (ISO timestamp): Timestamp of this update

  • data (object): Complete updated flow structure

Usage Examples:

  1. Rename flow: { flow_id: "flow-uuid", name: "Improved Customer Bot" }

  2. Update description: { flow_id: "flow-uuid", description: "Processes customer inquiries with sentiment analysis" }

  3. Move to folder: { flow_id: "flow-uuid", folder_id: "folder-uuid" }

  4. Move to root: { flow_id: "flow-uuid", folder_id: null }

  5. Update structure: { flow_id: "flow-uuid", data: { nodes: [...], edges: [...] } }

  6. Rename and move: { flow_id: "flow-uuid", name: "New Name", folder_id: "folder-uuid" }

Best Practices:

  • Get current flow data with get_flow before updating to avoid overwriting changes

  • Only specify fields you want to change (partial updates supported)

  • Rebuild flow with build_flow after data modifications to validate changes

  • Use descriptive names and descriptions for team collaboration

  • Update description when flow functionality changes significantly

  • Move flows to appropriate folders to maintain organization

  • Verify folder_id exists before moving (use list_folders)

  • Update flow name if purpose or functionality changes

Common Errors:

  • "Flow not found": flow_id doesn't exist or was deleted (verify with list_flows)

  • "Flow name already exists": Choose unique name within target folder

  • "Invalid folder ID": folder_id is not valid UUID (use list_folders to get valid IDs)

  • "Folder not found": Specified folder_id doesn't exist

  • "Invalid flow data structure": data object doesn't match Langflow schema

  • "Concurrent modification": Flow was updated by another user (re-fetch with get_flow)

  • "flow_id is required": Must provide flow_id parameter

  • "Unauthorized": API key lacks permission to modify this flow

Related Tools:

  • get_flow: Retrieve current flow state before updating

  • build_flow: Validate flow after data modifications

  • list_flows: Find flow_id for flows to update

  • list_folders: Get valid folder_id values for reorganization

  • create_flow: Create new flow instead of modifying existing one

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
dataNoNew flow data/configuration
nameNoNew name for the flow
flow_idYesThe ID of the flow to update
folder_idNoNew folder ID
descriptionNoNew description for the flow
Behavior4/5

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

No annotations provided, but the description covers mutation nature, partial updates, need for current data, and common errors like concurrent modification. Missing explicit mention of permissions or rate limits, but overall transparent enough.

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?

Description is lengthy but well-structured with sections: purpose, parameters, returns, examples, best practices, errors, related tools. Front-loaded with purpose. Some redundancy could be trimmed, but every section provides value.

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?

Given 5 parameters, nested objects, and no output schema, the description comprehensively covers prerequisites, effects, examples, error handling, and related tools. It ensures an agent can correctly invoke the tool without missing information.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, but the description adds crucial context: flow_id source, name max length, folder_id valid IDs and root usage, data structure details. This adds significant value beyond 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?

The description explicitly states it modifies flow properties, configuration, or organization. It lists specific updatable aspects (metadata, structure, folder) and clearly distinguishes from siblings like create_flow, get_flow, and delete_flow.

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?

Includes explicit 'Best Practices' (e.g., use get_flow before updating, partial updates, rebuild with build_flow) and 'Related Tools' section listing alternatives like get_flow, build_flow, and create_flow. Provides clear when-to-use guidance and error handling tips.

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

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/nobrainer-tech/langflow-mcp'

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