Skip to main content
Glama

run_flow

Execute Langflow flows with custom inputs and retrieve results. Supports synchronous execution for testing, integration, and automation.

Instructions

Execute a Langflow flow with inputs and retrieve execution results.

Purpose: Run a workflow and receive its outputs. Essential for testing flows, integrating workflows into applications, and automating tasks. Supports both synchronous execution and streaming for real-time responses from LLM-based flows.

Parameters:

  • flow_id_or_name (required, string): Flow identifier (UUID) or flow name (case-sensitive)

  • input_request (required, object): Execution configuration containing:

    • input_value (optional, string): Primary input data for the flow (e.g., user message, data to process)

    • output_component (optional, string): Specific output component to return

    • output_type (optional, string): Expected output format (e.g., "chat", "text", "json")

    • input_type (optional, string): Type of input being provided (e.g., "chat", "text", "json")

    • session_id (optional, string): Session ID for conversation continuity

    • tweaks (optional, object): Component-specific parameter overrides (key: component_id, value: parameter object)

  • context (optional, object): Request context passed alongside the input request

  • stream (optional, boolean, default: false): Streaming is currently rejected by this MCP client because streamed responses are not JSON serializable

Returns: RunResponse object containing:

  • outputs (array): Flow execution results from output components

  • session_id (string): Unique session identifier for conversation continuity

  • Additional fields vary by flow configuration (message, data, artifacts)

Usage Examples:

  1. Simple execution: { flow_id_or_name: "my-chatbot", input_request: { input_value: "Hello" } }

  2. With output type: { flow_id_or_name: "data-processor", input_request: { input_value: "data", output_type: "json" } }

  3. With context: { flow_id_or_name: "llm-chat", input_request: { input_value: "Explain AI" }, context: { tenant: "acme" } }

  4. With tweaks: { flow_id_or_name: "flow-uuid", input_request: { input_value: "test", tweaks: { "component-id": { temperature: 0.7 } } } }

Best Practices:

  • Use flow ID (UUID) for production; names may change or conflict

  • Build flow first with build_flow to ensure it's valid before execution

  • Leave stream false; this MCP client currently returns JSON tool responses only

  • Cache session_id for multi-turn conversations to maintain context

  • Set appropriate timeout values for long-running flows

  • Test flows with various inputs before production deployment

  • Use tweaks sparingly; prefer configuring flows in Langflow UI

Common Errors:

  • "Flow not found": Verify flow_id_or_name exists using list_flows

  • "Flow has not been built": Run build_flow before executing

  • "Invalid input configuration": Ensure input_request matches flow's expected inputs

  • "Component configuration error": Check tweaks object matches component IDs and parameter names

  • "Execution timeout": Flow took too long; increase timeout or optimize flow

  • "Missing required input": Flow expects input_value but none provided

Related Tools:

  • build_flow: Compile flow before execution to validate structure

  • get_flow: Inspect flow structure to understand required inputs

  • get_build_status: Check build completion before running flow

  • trigger_webhook: Alternative execution method via webhook endpoint

  • list_flows: Find available flows to execute

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
streamNoStreaming is currently rejected by this MCP client
contextNoRequest context passed alongside the input request
input_requestYesInput request configuration
flow_id_or_nameYesFlow ID (UUID) or flow name
Behavior4/5

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

Without annotations, the description carries the full burden. It explains synchronous and streaming modes (noting stream rejection), what returns (RunResponse object), and lists common errors. However, it doesn't discuss side effects, state changes, or idempotency.

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?

The description is well-structured with clear sections (Purpose, Parameters, Returns, Usage Examples, Best Practices, Common Errors, Related Tools). It is front-loaded with the purpose. However, it is somewhat verbose; could be trimmed without losing clarity.

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 the complexity of 4 parameters including a nested object and no output schema, the description is very complete. It covers inputs, behavior, limitations (streaming), error handling, and related tools. The agent has sufficient information to use the tool correctly.

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?

The input schema has 100% coverage but the description adds significant value by explaining each sub-parameter of input_request in detail and providing usage examples. This goes beyond the schema's brief descriptions.

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 tool's purpose: 'Execute a Langflow flow with inputs and retrieve execution results.' It uses a specific verb (execute) and resource (flow), and distinguishes it from siblings like build_flow, get_flow, and trigger_webhook.

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?

The description provides explicit guidance on when to use the tool (e.g., testing flows, integrating workflows) and when not to (e.g., build first with build_flow, verify flow existence with list_flows). It includes best practices, common errors, and related tools.

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