Skip to main content
Glama

create_flow

Create a flow. Provide the models in order — input/output nodes and connections are generated automatically by matching output→input port types, and the original input is shared (fan-out) when several models need it. Set run=true to start it immediately in the same call.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
runNoStart the flow immediately after creating it. Requires input_files when the flow has input nodes. On success the response carries run_status — poll get_flow(view="status") from there. The flow is created either way: if the run cannot start, next_step explains why.
nameNoName for the new flow. Defaults to the model chain (e.g. 'ModelA → ModelB').
nodesYesJSON array of models IN ORDER. Two formats: (1) SHORTHAND — a string array of model IDs, e.g. '["ModelA","ModelB"]'. Use this unless you need explicit connections. (2) FULL — node objects with id, type, model_id and optional parameters, e.g. [{"id":1,"type":"ai_model","model_id":"ModelA","parameters":{"steps":50}}]. Use get_model_parameters to discover parameters; anything omitted is filled with defaults. FULL nodes may also declare the input and output nodes themselves — {"id":1,"type":"input","model_id":"Image-Loader"} or {"id":9,"type":"output","model_id":"Image-Viewer"} — which is how you give several models the SAME source (e.g. three editors comparing one image) instead of chaining them. Declaring any input/output node turns auto-generation off: the graph is then exactly what you pass.
parametersNoJSON object of parameter overrides keyed by model_id, or by node id (the node's id field, NOT its position; shorthand numbers models from 1) to target one node in a chain that repeats a model. Node-id keys win over model_id keys. Dropdown parameters take one of their listed values (the label, e.g. "Image to Video"). A key matching no node, a parameter the model does not declare, or a value outside a dropdown is refused and nothing is created. Example: {"PiSA-SR":{"steps":50,"seed":123}} or {"2":{"resolution":"1080p"}}.
connectionsNoJSON array of explicit connections, e.g. [{"out_node_id":1,"out_port_index":0,"in_node_id":2,"in_port_index":0}]. Port indices are positions in the model's own input/output list, and the order is NOT the same across models — some image editors take the image on port 0, others take the text prompt there. Read the ports from get_model before writing indices; a wrong index is rejected with the correct layout in the message. Connections you pass are kept: only the ports you leave open get wired automatically.
input_filesNoJSON array of inputs for the generated input nodes, matched in order. For image/video/sound inputs: file URLs from upload_file. For text inputs (Text-Input nodes): text content directly — it will be auto-uploaded as a text file. Example: ["https://storage.googleapis.com/.../image.png", "Change the color to blue"]
include_optionalNoWhether to auto-generate input nodes for OPTIONAL model input ports. Default true: every optional port also gets its own loader node (e.g. a multimodal model with an optional image input gets an Image-Loader). Set false to scaffold only REQUIRED inputs. DECIDE this yourself from the task — you do not need the user to ask: set false when the goal clearly uses only some modalities (e.g. 'summarize this text' on a text+optional-image model → skip the image loader), or when the user's input_files cover only the required ports. Keep true when the goal is genuinely multimodal, when the user supplied inputs for optional ports, or when you are unsure — so no modality is silently dropped. When in doubt, leave it true (or omit).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / parameters / description
      Previous value: -"JSON object of parameter overrides keyed by model_id, or by node index to target one position in a chain that repeats a model. Index keys win over model_id keys. Example: {\"PiSA-SR\":{\"steps\":50,\"seed\":123}}."New value: +"JSON object of parameter overrides keyed by model_id, or by node id (the node's id field, NOT its position; shorthand numbers models from 1) to target one node in a chain that repeats a model. Node-id keys win over model_id keys. Dropdown parameters take one of their listed values (the label, e.g. \"Image to Video\"). A key matching no node, a parameter the model does not declare, or a value outside a dropdown is refused and nothing is created. Example: {\"PiSA-SR\":{\"steps\":50,\"seed\":123}} or {\"2\":{\"resolution\":\"1080p\"}}."
  2. Changed2 schema fields changed
    • changedInput schema / properties / connections / description
      Previous value: -"JSON array of explicit connections. Only needed to override the automatic port-type wiring."New value: +"JSON array of explicit connections, e.g. [{\"out_node_id\":1,\"out_port_index\":0,\"in_node_id\":2,\"in_port_index\":0}]. Port indices are positions in the model's own input/output list, and the order is NOT the same across models — some image editors take the image on port 0, others take the text prompt there. Read the ports from get_model before writing indices; a wrong index is rejected with the correct layout in the message. Connections you pass are kept: only the ports you leave open get wired automatically."
    • changedInput schema / properties / nodes / description
      Previous value: -"JSON array of models IN ORDER. Two formats: (1) SHORTHAND — a string array of model IDs, e.g. '[\"ModelA\",\"ModelB\"]'. Use this unless you need explicit connections. (2) FULL — node objects with id, type, model_id and optional parameters, e.g. [{\"id\":1,\"type\":\"ai_model\",\"model_id\":\"ModelA\",\"parameters\":{\"steps\":50}}]. Use get_model_parameters to discover parameters; anything omitted is filled with defaults."New value: +"JSON array of models IN ORDER. Two formats: (1) SHORTHAND — a string array of model IDs, e.g. '[\"ModelA\",\"ModelB\"]'. Use this unless you need explicit connections. (2) FULL — node objects with id, type, model_id and optional parameters, e.g. [{\"id\":1,\"type\":\"ai_model\",\"model_id\":\"ModelA\",\"parameters\":{\"steps\":50}}]. Use get_model_parameters to discover parameters; anything omitted is filled with defaults. FULL nodes may also declare the input and output nodes themselves — {\"id\":1,\"type\":\"input\",\"model_id\":\"Image-Loader\"} or {\"id\":9,\"type\":\"output\",\"model_id\":\"Image-Viewer\"} — which is how you give several models the SAME source (e.g. three editors comparing one image) instead of chaining them. Declaring any input/output node turns auto-generation off: the graph is then exactly what you pass."
  3. Changed7 schema fields changed
    • changedInput schema / properties / connections / description
      Previous value: -"JSON array of explicit connections. Usually not needed — auto-generated when only ai_model nodes are provided."New value: +"JSON array of explicit connections. Only needed to override the automatic port-type wiring."
    • changedInput schema / properties / input_files / description
      Previous value: -"JSON array of inputs for auto-generated input nodes, matched in order. For image/video/sound inputs: file URLs from upload_file. For text inputs (Text-Input nodes): text content directly — it will be auto-uploaded as a text file. Example: [\"https://storage.googleapis.com/.../image.png\", \"Change the color to blue\"]"New value: +"JSON array of inputs for the generated input nodes, matched in order. For image/video/sound inputs: file URLs from upload_file. For text inputs (Text-Input nodes): text content directly — it will be auto-uploaded as a text file. Example: [\"https://storage.googleapis.com/.../image.png\", \"Change the color to blue\"]"
    • changedInput schema / properties / name / description
      Previous value: -"Name for the new flow."New value: +"Name for the new flow. Defaults to the model chain (e.g. 'ModelA → ModelB')."
    • changedInput schema / properties / nodes / description
      Previous value: -"JSON array of nodes IN PIPELINE ORDER. Supports two formats: (1) SHORTHAND: a simple string array of model IDs — e.g., '[\"ModelA\",\"ModelB\"]' — auto-expanded to ai_model nodes. (2) FULL: array of node objects with id, type, model_id, and optional parameters. Use get_model_parameters to discover available parameters. Parameters not provided are auto-filled with defaults. Shorthand example: '[\"ModelA\",\"ModelB\"]'. Full example: [{\"id\":1,\"type\":\"ai_model\",\"model_id\":\"ModelA\",\"parameters\":{\"steps\":50}}]. TIP: For simple pipelines, prefer create_pipeline which is designed for model ID arrays."New value: +"JSON array of models IN ORDER. Two formats: (1) SHORTHAND — a string array of model IDs, e.g. '[\"ModelA\",\"ModelB\"]'. Use this unless you need explicit connections. (2) FULL — node objects with id, type, model_id and optional parameters, e.g. [{\"id\":1,\"type\":\"ai_model\",\"model_id\":\"ModelA\",\"parameters\":{\"steps\":50}}]. Use get_model_parameters to discover parameters; anything omitted is filled with defaults."
    • addedInput schema / properties / parameters
      Added value: +{
      +  "description": "JSON object of parameter overrides keyed by model_id, or by node index to target one position in a chain that repeats a model. Index keys win over model_id keys. Example: {\"PiSA-SR\":{\"steps\":50,\"seed\":123}}.",
      +  "type": "string"
      +}
    • addedInput schema / properties / run
      Added value: +{
      +  "description": "Start the flow immediately after creating it. Requires input_files when the flow has input nodes. On success the response carries run_status — poll get_flow(view=\"status\") from there. The flow is created either way: if the run cannot start, next_step explains why.",
      +  "type": "boolean"
      +}
    • changedInput schema / required
      Previous value: -[
      -  "name",
      -  "nodes"
      -]New value: +[
      +  "nodes"
      +]
  4. First observed

TDQS

A3.8/5.0
Behavior4/5

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

Annotations already declare the safety profile (readOnly=false, destructive=false, idempotent=false, openWorld=true). The description adds meaningful behavior beyond them: auto-generation of nodes/connections by port-type matching and fan-out sharing of the original input when multiple models need it. It stops short of covering failure/ordering edge cases, which live in 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.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three dense sentences, front-loaded with the core action, then the auto-generation rule, then the immediate-run flag. No filler and every clause carries actionable information.

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 7-parameter mutation with no output schema, the description plus the exhaustive schema descriptions cover the contract adequately: what to pass, what gets generated, and how to run immediately. It omits return/next_step behavior, but that is handled in the parameter schema.

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 each of the 7 parameters is already documented in depth in the schema. The description only echoes two of them (ordered models, run=true), adding little semantics beyond what the schema provides, so the baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb+resource ('Create a flow') and immediately scopes the core behavior: models are provided in order, and input/output nodes and connections are auto-generated by port-type matching. This lets an agent distinguish it from edit_flow or duplicate_flow by the auto-generation contract, though it never names a sibling explicitly.

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

Usage Guidelines3/5

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

The description gives one concrete usage cue ('Set run=true to start it immediately in the same call'), which is really about a parameter rather than tool selection. It offers no explicit when-to-use guidance against alternatives such as suggest_flow, preview_flow, or edit_flow, so routing is left to inference.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources