Skip to main content
Glama
conductor-oss

Conductor MCP Server

workflow_create_workflow_definition

Creates a workflow definition from a dictionary, enabling automated execution of tasks like conditional branching and loops.

Instructions

Creates a workflow definition from the provided workflow_definition dict param.

These are the main constructs that should be considered:

  1. Do_while : to run through a list (input _items as the input parameters to iterate)

  2. Switch: decision task

  3. Inline: Executes javascript inline

In order to access workflow variables in javascript functions, they must first be assigned a value via inputParameters, for example: if there's a task named "analyze_market_data" then to access its output in javascript you need to create an inputParameter to assign it a value that can be used: "inputParameters": { "marketData": "${analyze_market_data.output}" } Then the "${analyze_market_data.output}" value can be accessed in javascript as "marketData" like so: "(function () {\n console.log("Market Data: " + $.marketData);\n})();"

In switch cases, an expression field must be defined using the same input method as above. You can construct the expression field like this: "inputParameters": { "marketData": "${analyze_market_data.output}" } "expression": "(function () {\n $.marketData.includes("NASDAQ");\n})();"

Here are some examples to help: ## Example of a switch task to run conditional tasks { "name": "switch_case_example", "description": "switch_case_example", "version": 1, "tasks": [ { "name": "switch", "taskReferenceName": "switch_ref", "inputParameters": { "switchCaseValue": "${workflow.input.case_param}" }, "type": "SWITCH", "decisionCases": { "case_a": [ { "name": "simple_1", "taskReferenceName": "simple_ref_1", "type": "SIMPLE" } ], "case_b": [ { "name": "simple", "taskReferenceName": "simple_ref", "type": "SIMPLE" } ] }, "defaultCase": [ { "name": "simple_2", "taskReferenceName": "simple_ref_2", "type": "SIMPLE" } ], "evaluatorType": "value-param" } ] }

## Example of a do_while for iterating over a list
{
  "createTime": 1740724130693,
  "name": "for_each_example",
  "description": "for_each_example",
  "version": 1,
  "tasks": [
    {
      "name": "do_while",
      "taskReferenceName": "do_while_ref",
      "inputParameters": {
        "items": "$ {workflow.input.items_list}"
      },
      "type": "DO_WHILE",
      "loopOver": [
        {
          "name": "simple",
          "taskReferenceName": "simple_ref",
          "inputParameters": {
            "item": "$ {do_while_ref.output.item}"
          },
          "type": "SIMPLE"
        },
        {
          "name": "simple_1",
          "taskReferenceName": "simple_ref_1",
          "inputParameters": {
            "item_to_process": "$ {do_while_ref.output.item}"
          },
          "type": "SIMPLE"
        }
      ],
      "evaluatorType": "value-param"
    }
  ]
}

## Example of an inline javascript execution
{
  "name": "inline_javascript_execution",
  "version": 1,
  "tasks": [
    {
      "name": "inline",
      "taskReferenceName": "inline_ref",
      "type": "INLINE",
      "inputParameters": {
        "invoker": "$ {workflow.input.invoker_name}"
      },
      "inputParameters": {
        "expression": "(function () {\n  return "Hello " + $.invoker;\n})();",
        "evaluatorType": "graaljs",
        "value1": 1,
        "value2": 2
      }
    }
  ]
}

notice, that the javscript function is written as:
(function () {
  return $.value1 + $.value2;
})();
and value1 and value2 are the input to the task.

## Important Rules
taskReferenceName MUST be unique in the workflow JSON.
When using INLINE task, all the variables in the script MUST be the input parameters to the task.  Only task's input parameters can be accessed inside the script.
When trying to update a workflow that's already been created you must increment the version number, otherwise you need to pick a unique name for the workflow.
It's best not to use loopCondition, instead, iterate over the list of items using items input parameter. Nest SWITCH task if you want to do conditional processing.

### SWITCH task rules:
When using SWITCH task, the switchCaseValue _cannot_ contain expressions, scripts or methods.  It has to be simple map.  Use expression field to execute a script if required.
Remember, switchCaseValue and expression fields in SWITCH are mutually exclusive.  ONLY one of them can be used. expression is NOT an input field, it is set as a property to the task.
expression MUST be a javascript function that returns a single string.  Similar to INLINE task.  The function is IIFE type, which is a JavaScript function that is defined and executed immediately.
When writing SWITCH task remember to consider all the cases, if required use defaultCase to handle default cases and the ones for which no clear branches are defined.
one more thing -- SWITCH task does not produce output, so do not use the output of a switch as an input to any task.

## Inline javascript rules
We use GraalVM to evaluate javascript code.
It's best not to use concat function to merge arrays or maps etc.
You can ONLY use the variables defined as input to the task in the javascript code.  Access them as $.var.
Note, you _CANNOT_ use ${task.output.var} in javascript. neither in inline or Switch task expressions. Only $.var and var MUST be an input parameter to the task.
In order to address any inputs to the workflow or tasks, you must be sure to first assign that input to an input parameter, which then can be referenced -
    for instance, in order to use ${workflow.input.case_param} in javascript, you must make sure the inputParameters assigns that to a variable in the task definition,
    such as:
      "inputParameters": {
        "switchCaseValue": "${workflow.input.case_param}"
      },
    once that value is assigned to switchCaseValue via the inputParameters section of the task definition, it can be addressed in javascript as $.switchCaseValue

## Input mapping rules
* The task's input and output is always a Map data type.  If a task's schema returns List or a single value as output, it is wrapped in a map with key "result"
* For HTTP task's the output is in "response" key

Args: workflow_definition: A nested dictionary representing a workflow definition

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
workflow_definitionYes

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes
Behavior5/5

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

No annotations exist, so the description carries full burden. It discloses key behaviors: workflow creation versioning rules, task input/output mapping (always a Map, output wrapped in 'result'), SWITCH task produces no output, constraints on expressions and input parameters. This provides comprehensive transparency beyond 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.

Conciseness3/5

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

The description is very long due to multiple full examples and extensive rules. While well-structured with sections and bullet points, it could be more concise by summarizing key points and moving examples to a separate reference. Many sentences repeat similar concepts (e.g., input parameter assignments).

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 the workflow_definition parameter and the presence of an output schema (not shown but indicated), the description covers all necessary aspects: constructs, rules, examples, and error-prone behaviors. No gaps are apparent for an agent to correctly invoke the tool.

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 schema only defines 'workflow_definition' as an object with additionalProperties, offering no semantic detail. The description fully compensates with detailed examples, rules, and documentation of constructs (do_while, switch, inline), input parameter referencing via $.var, and expression syntax. It adds immense meaning beyond the 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 clearly states 'Creates a workflow definition from the provided workflow_definition dict param.' The verb ('creates') and resource ('workflow definition') are specific, and the tool is easily distinguished from sibling tools like workflow_get_workflow_by_id or workflow_start_workflow_by_name.

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 extensive guidance on when to use constructs (do_while, switch, inline) and important rules (unique taskReferenceName, version increment for updates, input mapping). While it doesn't explicitly compare with sibling tools, it effectively tells the agent how to use the tool correctly and highlights common pitfalls.

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/conductor-oss/conductor-mcp'

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