How do I use Conductor MCP Server?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Conductor MCP Server Create a scheduled workflow to check stock prices daily." That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

Conductor MCP Server

by conductor-oss

Overview Schema Related Servers Score Discussions

Python

Remote

Conductor mcp server

Model Context Protocol server for Conductor.

This package is used to run an MCP server that is capable of interacting with a Conductor instance. It provides tools for the basic operations that may be needed by an MCP client for Workflow creation, execution, and analysis.

PyPi Quickstart

Install package

pip install conductor-mcp

Related MCP server: ComfyUI MCP Server

Create a JSON config with your Conductor keys

{
  "CONDUCTOR_SERVER_URL": "https://developer.orkescloud.com/api",
  "CONDUCTOR_AUTH_KEY": "<YOUR_APPLICATION_AUTH_KEY>",
  "CONDUCTOR_AUTH_SECRET": "<YOUR_APPLICATION_SECRET_KEY>"
}

Note: the /api path is required as part of the CONDUCTOR_SERVER_URL for most applications

Plug the server into an AI Agent, such as Claude or Cursor

{
  "mcpServers": {
    "conductor": {
      "command": "conductor-mcp",
      "args": [
        "--config",
        "<ABSOLUTE PATH TO A JSON CONFIG FILE>"
      ]
    }
  }
}

You should now be able to interact with Conductor via your AI Agent.

Adding to Claude

You can find instructions for adding to Claude here. In general, you just add the mcpServers config (above) to your Claude config (or create it if it doesn't exist). For instance, on Mac it might be ~/Library/Application\ Support/Claude/claude_desktop_config.json.

Adding to Cursor

The main Cursor instructions are here. Go to Cursor -> Settings -> Cursor Settings -> MCP and select "+ Add new global MCP server".

Here you can add the exact same configuration file shown in the example for Claude (above). You can then access the AI chat feature and explore the MCP server in the sidebar with ⌘+L (Mac) or Ctrl+L (Windows/Linux).

Example prompts

Get Flight Risk Info

Create and execute a Conductor Workflow that calls any necessary http endpoints to gather current weather data around
Seattle and outputs the risk factors for flying a small airplane around the South Lake Union area using Visual Flight
Rules today. Only use publicly available endpoints that don't require an API key.

Notify Stocks

(May require API Keys)

Create a Conductor Workflow that runs on a daily schedule, accepts a list of email address and a stock symbol, checks
current stock prices, and sends an email to everyone on the list if they should be happy or sad today based on stock
performance. Name the workflow "NotifyStonks" and use schemaVersion 2.

GitHub Quickstart

Clone GitHub Repo

gh repo clone conductor-oss/conductor-mcp

This project relies on uv https://docs.astral.sh/uv/getting-started/

Create venv

(not entirely necessary, since uv automatically creates and uses the virtual environment on its own when running other commands)

uv sync
source .venv/bin/activate

Define Env Vars

You can continue to use a JSON config file and the --config flag, or if the server is running in an environment where you have control over the environment variables the MCP server will look for them there if a config file is not provided.

export CONDUCTOR_SERVER_URL="YOUR_CONDUCTOR_SERVER_URL"
export CONDUCTOR_AUTH_KEY="<YOUR_APPLICATION_AUTH_KEY>"
export CONDUCTOR_AUTH_SECRET="<YOUR_APPLICATION_SECRET_KEY>"

Configure Your AI Assistant

{
  "mcpServers": {
    "conductor": {
      "command": "uv",
      "args": [
        "--directory",
        "<ABSOLUTE_PATH_TO_THE_PROJECT>",
        "run",
        "conductor-mcp",
        "--config",
        "<ABSOLUTE PATH TO A JSON CONFIG FILE>"
      ]
    }
  }
}

Or Run Server Directly

cd <PROJECT_ROOT>
uv run conductor-mcp --config <ABSOLUTE PATH TO A JSON CONFIG FILE>

Note: a local_development.py also exists for setting env vars and will be used when the --local_dev flag is set.

Available Tools

19 tools

event_get_event_handlersA

Gets all event handlers or filters by event name and active status.

Event handlers define how Conductor responds to external events. They can trigger workflow executions or perform other actions when specific events occur.

Args: event: Optional event name to filter by active_only: If True, return only active event handlers (default: True)

ParametersJSON Schema

Name	Required	Description	Default
`event`	No
`active_only`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.2/5.0

Behavior3/5

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

No annotations are provided, so the description carries the full burden. It explains that event handlers define how Conductor responds to external events and can trigger workflows or actions. However, it does not disclose any side effects, authentication needs, or pagination behavior. As a read operation, it is fairly transparent.

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 concise, with a main sentence and an extra paragraph providing context. While the extra paragraph is helpful, it could be trimmed without losing essential information. The structure is clear and front-loaded.

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?

The tool has an output schema, so return values are covered. The description explains the tool's purpose and parameters adequately. For a simple get tool with two optional parameters, it is sufficiently complete, though it could mention that it returns a list of handlers.

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 description coverage is 0%, but the description adds clear plain-language explanations for both parameters: 'event' (optional filter by name) and 'active_only' (returns only active handlers, default True). This adds significant value 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 starts with 'Gets all event handlers or filters by event name and active status', which clearly specifies the action (get) and resource (event handlers). The sibling tools are all task and workflow-related, so this tool is distinct in purpose.

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 indicates filtering by event and active status, which helps with when to use. However, it does not explicitly state when not to use or mention alternatives, but given the tool's focus on event handlers vs sibling tools, the context is clear.

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

task_create_task_definitionA

Creates or updates a task definition.

The task definition should include at minimum:

name: The name/type of the task
description: A description of what the task does
retryCount: Number of retries (default: 3)
timeoutSeconds: Task timeout in seconds
responseTimeoutSeconds: Response timeout in seconds

Example task definition: { "name": "my_custom_task", "description": "A custom task that processes data", "retryCount": 3, "timeoutSeconds": 300, "responseTimeoutSeconds": 180, "inputKeys": ["input1", "input2"], "outputKeys": ["result"] }

Args: task_definition: A dictionary containing the task definition

ParametersJSON Schema

Name	Required	Description	Default
`task_definition`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.8/5.0

Behavior2/5

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

No annotations are provided, so the description carries full burden. It only states 'Creates or updates' without disclosing whether updates are partial or full replacements, idempotency, or required permissions. For a mutation tool, more detail is needed.

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 a clear header, bullet points of minimum fields, and an example. It is front-loaded with purpose, though slightly verbose with the 'Args' line.

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?

Given the presence of an output schema, the description does not need to explain return values. It adequately covers the parameter usage and provides a working example. However, it could mention that the tool can also update existing definitions.

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 coverage is 0%, and the description compensates fully by listing minimum fields (name, description, retryCount, etc.) and providing an example. This adds essential meaning beyond the generic object 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 or updates a task definition' with specific verb and resource. It distinguishes from sibling read-only tasks like task_get_all_task_definitions.

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 implies usage for creating/updating task definitions but does not explicitly state when to use vs. alternatives or provide exclusions. It lacks guidance on idempotency or prerequisites.

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

task_get_all_task_definitionsA

Gets all task definitions

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.5/5.0

Behavior3/5

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

With no annotations, the description must disclose behavioral traits. It states the tool retrieves all task definitions, which is straightforward. However, it does not mention potential impacts (e.g., performance with large datasets, pagination, or read-only nature). The behavior is adequately transparent but not enriched beyond the obvious.

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 a single sentence with zero wasted words. It is front-loaded and clearly communicates the tool's function.

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?

Given the tool's simplicity (no parameters, output schema present), the description is adequate. It tells exactly what the tool does. However, it could be slightly more complete by noting that it returns all definitions without any filtering, but this is not critical.

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

Parameters4/5

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

The tool has zero parameters, and schema description coverage is 100% (empty schema). Per guidelines, the baseline for 0 parameters is 4. The description adds no parameter info, but none is needed.

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?

The description 'Gets all task definitions' uses a clear verb and specifies the resource. It implicitly distinguishes from sibling tools like task_get_task_by_id (single) and task_get_task_definition_for_tasktype (filtered). However, it lacks any additional clarifying details, which prevents a perfect score.

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

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus alternatives such as task_get_task_by_id or task_get_task_definition_for_tasktype. There is no mention of use cases, prerequisites, or exclusions.

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

task_get_task_by_idA

Gets the metadata for a conductor workflow task in json format based on that task's id

Args: task_id: The uuid representing the task id

ParametersJSON Schema

Name	Required	Description	Default
`task_id`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.6/5.0

Behavior2/5

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

No annotations are provided, so the description carries the full burden. It states 'Gets metadata', implying a read operation, but fails to mention what happens if the task ID is invalid, authentication requirements, or rate limiting. This lack of detail reduces transparency.

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 highly concise with two sentences: the first defines the tool's purpose, the second details the input parameter. No superfluous 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 simple one-parameter retrieval tool with an output schema, the description covers the essential purpose and input. However, it lacks mention of error handling or edge cases, which would improve completeness given no annotations.

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

Parameters4/5

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

The description adds meaning beyond the input schema by specifying that task_id is 'The uuid representing the task id'. The schema only defines type string, so this clarification is valuable given the low schema coverage (0%). The single parameter is well-described.

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 'Gets the metadata for a conductor workflow task in json format based on that task's id', providing a specific verb (Gets) and resource (conductor workflow task metadata) with a clear scope (by id). This differentiates it from sibling tools like task_get_logs or task_get_all_definitions.

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

Usage Guidelines2/5

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

No guidance on when to use this tool versus alternatives. The description does not mention when not to use it or suggest companion tools like task_get_task_logs for further details. It only implies basic usage with a task ID.

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

task_get_task_definition_for_tasktypeA

Gets the task definition for the given taskType.

"taskType" is synonymous with "task name".

This API refers to only user-defined tasks.

Args: taskType: The string representing the desired tasks' taskType

ParametersJSON Schema

Name	Required	Description	Default
`taskType`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.7/5.0

Behavior2/5

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

No annotations provided, so description carries full burden. Only states basic read operation; no disclosure of side effects, permissions, or rate limits. Minimal beyond purpose.

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 mostly concise with purpose upfront. Minor redundancy in 'Args:' block that repeats schema. Still efficient overall.

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 simple one-parameter tool with output schema, description covers scope (user-defined tasks) and parameter meaning. Adequate given complexity.

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

Parameters4/5

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

Schema has 0% description coverage, but description adds meaning: 'taskType is synonymous with task name' and clarifies it's a string representing the desired taskType. Adds 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?

Description clearly states 'Gets the task definition for the given taskType', explains synonym, and restricts to user-defined tasks. Distinguishes from siblings like task_create_task_definition and task_get_all_task_definitions.

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?

Description implies usage context (user-defined tasks) but does not explicitly guide when to use this tool vs alternatives like task_get_task_by_id or task_get_all_task_definitions.

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

task_get_task_logsA

Gets execution logs for a specific task. Returns log entries generated during task execution.

Args: task_id: The uuid representing the task execution id

ParametersJSON Schema

Name	Required	Description	Default
`task_id`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.8/5.0

Behavior3/5

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

No annotations provided, so description carries the burden. It states it returns log entries, but does not disclose any behaviors like pagination, rate limits, or data freshness. It is basic but accurate.

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?

Very concise; two sentences front-loading the main action and then the parameter. No unnecessary words or repetition.

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?

Given the output schema exists to document return values, the description sufficiently covers the tool's purpose and parameter. However, it could note the scope (e.g., task execution logs only).

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

Parameters4/5

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

Schema coverage is 0%, but the description adds: 'task_id: The uuid representing the task execution id', clarifying the parameter's purpose beyond the schema's type-only definition.

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 'Gets execution logs for a specific task' with a specific verb and resource. It distinguishes from sibling tools that deal with task definitions, workflows, or status updates.

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

Usage Guidelines2/5

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

No guidance on when to use this tool versus alternatives, such as when to fetch logs vs. other task operations. There is no mention of prerequisites or exclusions.

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

task_get_task_queue_detailsA

Gets the current status details for all conductor workflow task queues

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.6/5.0

Behavior2/5

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

No annotations exist, so description carries full burden. It only states 'gets' (implying read-only) but lacks details on permissions, performance, or response size.

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?

One concise sentence with no extraneous words. Front-loaded and efficient.

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 no-parameter read tool with an output schema, the description is largely complete. Could elaborate on 'status details' but output schema likely fills gaps.

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

Parameters4/5

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

No parameters in input schema, so schema coverage is 100%. The description adds no parameter info but doesn't need to; baseline for 0 params is 4.

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 gets current status details for all conductor workflow task queues, using a specific verb ('Gets') and resource. It distinguishes from sibling tools which deal with individual tasks, task definitions, or workflows.

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

Usage Guidelines2/5

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

No guidance on when to use this tool vs alternatives. The description implies it's for viewing task queue status but does not provide context or exclusions.

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

task_update_task_statusA

Updates the status of a task execution. This is typically used by workers to update task status.

Args: task_id: The uuid representing the task execution id workflow_instance_id: The uuid representing the workflow instance id status: New task status (IN_PROGRESS, FAILED, FAILED_WITH_TERMINAL_ERROR, COMPLETED) output_data: Optional dictionary containing task output data logs: Optional list of log entries for the task

ParametersJSON Schema

Name	Required	Description	Default
`task_id`	Yes
`workflow_instance_id`	Yes
`status`	Yes
`output_data`	No
`logs`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.6/5.0

Behavior2/5

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

No annotations are provided, so the description must carry the full burden. It describes the update action but lacks details on side effects, authorization needs, rate limits, or behavior when updating to invalid statuses. The minimal disclosure leaves significant gaps.

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 efficient, with a clear opening sentence followed by a structured args list. Each sentence adds value, though the args list could be integrated more tightly. No wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity and the presence of an output schema (reducing the need to explain return values), the description provides adequate context. However, it could mention idempotency or partial update behavior to be fully complete for an update operation.

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

Parameters4/5

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

Schema description coverage is 0%, so the description must compensate. It provides meaningful explanations for all parameters, including the enum values for status and the optional nature of output_data and logs. This adds value beyond the bare 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 the tool updates the status of a task execution, with a specific verb ('Updates') and resource ('task execution status'). It distinguishes itself from sibling tools like task_get_task_by_id or task_create_task_definition by focusing on status updates.

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 mentions it's typically used by workers, providing context, but does not explicitly state when to use this tool over alternatives or when not to use it. No exclusions or alternative tool references are given.

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

workflow_create_workflow_definitionA

Creates a workflow definition from the provided workflow_definition dict param.

These are the main constructs that should be considered:

Do_while : to run through a list (input _items as the input parameters to iterate)
Switch: decision task
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

ParametersJSON Schema

Name	Required	Description	Default
`workflow_definition`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.6/5.0

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.

workflow_get_all_workflowsA

Gets a short description of all existing conductor workflows.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.1/5.0

Behavior3/5

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

No annotations are provided, so the description must convey behavioral traits. It states the tool is read-only ('Gets'), but does not disclose potential side effects, authentication needs, or rate limits. The description is adequate but lacks depth.

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 a single, front-loaded sentence that clearly communicates the action and result with no extraneous words.

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 that the tool has no parameters and an output schema exists (per context signals), the description is complete enough to convey the tool's purpose and behavior.

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

Parameters4/5

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

The tool has no parameters, so schema coverage is 100%. The description does not need to add parameter meaning. Baseline is 4.

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 retrieves a short description of all existing conductor workflows, using a specific verb ('Gets') and resource ('short description of all existing conductor workflows'). This distinguishes it from sibling tools that target specific workflows.

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 implies usage when you need to list all workflows, but it does not explicitly provide guidance on when to use this tool versus alternatives like workflow_get_workflow_by_id or workflow_get_workflow_by_name.

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

workflow_get_workflow_by_idB

Gets a conductor workflow execution in json format based on the workflow's execution id

Args: workflow_id: The uuid representing the execution of the workflow

ParametersJSON Schema

Name	Required	Description	Default
`workflow_id`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

B3.2/5.0

Behavior3/5

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

With no annotations, the description is the sole source of behavioral info. It states the output format but does not disclose idempotency, side effects, or error behavior. For a read-only get operation, this is passable but minimal.

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 very concise, using a single sentence plus an args line. It is front-loaded with the purpose, but lacks structured sections like use cases or examples.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple retrieval tool with an output schema, the description covers the core action. However, it omits important context such as prerequisites (execution ID must exist), error conditions, and differentiation from similar tools.

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 0%, so the description should compensate. It identifies the parameter as a 'uuid' which adds some meaning beyond the schema, but does not elaborate further. The parameter is simple, but the description adds little value.

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?

The description clearly states the verb 'Gets' and the resource 'workflow execution' with the key identifier 'execution id'. However, it does not distinguish from sibling getters like 'workflow_get_workflow_by_name' which retrieves the workflow definition rather than an execution.

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

Usage Guidelines2/5

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

No guidance is provided on when to use this tool versus alternatives. The description lacks any context about typical usage scenarios or exclusions.

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

workflow_get_workflow_by_nameB

Gets the metadata for a conductor workflow in json format based on that workflow's name

Args: workflow_name: The name of the workflow

ParametersJSON Schema

Name	Required	Description	Default
`workflow_name`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

B3.1/5.0

Behavior2/5

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

With no annotations, the description must disclose behavioral traits. It only states it gets metadata, but does not mention whether the operation is read-only, requires specific permissions, or has side effects. The name implies a read, but no explicit assurance.

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 concise, using two sentences. The first sentence provides the main purpose. However, the second sentence merely restates the parameter definition, which is redundant and could be omitted.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the presence of an output schema, the description need not detail return values. However, it lacks context such as whether the workflow must exist, or behavior if not found. For a simple tool, it is adequate but not thorough.

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

Parameters2/5

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

Schema description coverage is 0%, but the description adds minimal value beyond the schema: it repeats 'workflow_name' as 'the name of the workflow'. No format, constraints, or examples are provided for the single parameter.

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 function: retrieving metadata for a Conductor workflow by name, in JSON format. It distinguishes from sibling tools like 'workflow_get_workflow_by_id' which uses a different identifier.

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

Usage Guidelines2/5

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

No guidance is provided on when to use this tool versus alternatives (e.g., using ID instead of name). There is no mention of prerequisites or scenarios where this tool is inappropriate.

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

workflow_pause_workflowA

Pauses a running workflow execution. The workflow will pause and can be resumed later.

Args: workflow_id: The uuid representing the execution of the workflow to pause

ParametersJSON Schema

Name	Required	Description	Default
`workflow_id`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.7/5.0

Behavior2/5

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

With no annotations, the description bears full burden. It states the workflow will pause and can be resumed later, but lacks details on side effects (e.g., whether immediate or after current step), prerequisites, or behavior if already paused.

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 extremely concise with two sentences and an Args section. No wasted words, and the purpose is front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple tool with one parameter and an output schema, the description is adequate but leaves gaps: it doesn't reference the output, nor does it specify behavior for edge cases like pausing an already paused workflow.

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

Parameters4/5

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

The Args block explains workflow_id as 'the uuid representing the execution of the workflow to pause', which adds format and context beyond the schema's simple string type. Schema coverage is 0%, making this compensation valuable.

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 action ('Pauses a running workflow execution') and the resource. It also mentions that the workflow can be resumed later, distinguishing it from terminating tools.

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 implies when to use (pause a running execution) but does not explicitly compare with sibling tools like resume or terminate. No when-not or alternative guidance is provided.

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

workflow_query_workflow_executionsA

Search for workflow (executions) based on payload and other parameters. The query parameter accepts exact matches using = and AND operators on the following fields: workflowId, correlationId, workflowType, and status. Matches using = can be written as taskType = HTTP. Matches using IN are written as status IN (SCHEDULED, IN_PROGRESS). The 'startTime' and 'modifiedTime' field uses unix timestamps and accepts queries using < and >, for example startTime < 1696143600000. Queries can be combined using AND, for example taskType = HTTP AND status = SCHEDULED

If no query kwargs are provided, all workflow executions will be returned.

Example call to this function to query for a status of FAILED and start time after Thu May 01 2025 22:20:59 GMT+0000: query_workflow_executions('status="FAILED" AND startTime > 1746138025 ')

Searching for a range of time does not work, i.e. "startTime > 0 AND startTime < 1746138025"

Example call for FAILED or COMPLETED status and workflow named "SimpleWorkflow": query_workflow_executions('status IN (FAILED, COMPLETED) AND workflowType="SimpleWorkflow"')

Args: query: A query string, utilizing any of the following fields. workflowId: The id of a workflow execution. correlationId: The correlationId used to create any workflow executions. workflowType: Synonymous with workflow name. createTime: The creation unix timestamp of a workflow. startTime: The start unix timestamp of a workflow. status: The status of a workflow execution. One of [RUNNING, PAUSED, COMPLETED, TIMED_OUT, TERMINATED, FAILED]. endTime: The end unix timestamp of a workflow.

ParametersJSON Schema

Name	Required	Description	Default
`query`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.7/5.0

Behavior2/5

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

No annotations provided, so description carries full burden. It mentions the 'range of time' limitation but omits critical behavioral traits such as pagination, rate limits, authentication requirements, or result ordering.

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 fairly long but well-structured, starting with the purpose, then query syntax, examples, and parameter details. It could be slightly tighter but effectively communicates what is needed.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The input is thoroughly documented, and the output schema exists (not shown), so the description need not detail return values. However, it lacks behavioral information like pagination or result limits, which is needed for completeness.

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 a string 'query' parameter with no description (0% coverage). The description extensively explains the query format, supported fields, operators, and examples, adding substantial 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 it searches for workflow executions based on payload and other parameters, with a specific verb and resource. It distinguishes from siblings that retrieve by ID or list all workflows.

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 explains query syntax and that leaving query empty returns all executions, but does not explicitly guide when to use this tool versus other workflow retrieval tools like workflow_get_workflow_by_id.

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

workflow_restart_workflowA

Restarts a workflow execution from the beginning. This creates a new execution with the same input.

Args: workflow_id: The uuid representing the execution of the workflow to restart use_latest_definitions: If True, use the latest workflow definition instead of the original version

ParametersJSON Schema

Name	Required	Description	Default
`workflow_id`	Yes
`use_latest_definitions`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.7/5.0

Behavior2/5

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

No annotations are provided, so the description carries full burden. It mentions creating a new execution but does not disclose what happens to the original execution (e.g., status change, termination). Side effects and permission requirements are missing.

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?

Two sentences plus concise bullet-style Args. Front-loaded with the main purpose. Every sentence is necessary and no fluff.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Output schema exists but not shown; description covers basic purpose and parameters. However, it lacks behavioral context (e.g., idempotency, effect on original execution) which is important for a restart action. Not fully complete given the tool's complexity and absence of annotations.

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

Parameters4/5

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

Schema description coverage is 0%, so the description adds value by explaining both parameters: workflow_id as 'The uuid representing the execution' and use_latest_definitions as 'If True, use the latest workflow definition instead of the original version'. Brief but sufficient.

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 verb 'Restarts' and the resource 'workflow execution', and specifies it creates a new execution with the same input. It distinguishes from siblings like retry (which resumes from failure) and resume (from pause).

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 implies usage by stating it restarts from the beginning and creates a new execution with the same input, but does not explicitly state when to use this tool versus alternatives like retry or resume. No exclusions or comparisons are provided.

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

workflow_resume_workflowA

Resumes a paused workflow execution. The workflow will continue from where it was paused.

Args: workflow_id: The uuid representing the execution of the workflow to resume

ParametersJSON Schema

Name	Required	Description	Default
`workflow_id`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.7/5.0

Behavior2/5

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

No annotations provided, and the description only mentions continuing from where paused. It does not disclose behavioral traits like idempotency, prerequisites (must be paused), or side effects.

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?

Extremely concise: two sentences with no wasted words, front-loaded with the action.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Has output schema (though not shown) which might cover return values. However, description lacks prerequisites and error conditions, making it adequate but not complete.

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

Parameters4/5

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

With 0% schema description coverage, the description adds meaning by explaining workflow_id is the UUID of the execution to resume, compensating for missing schema 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 action 'Resumes' and the resource 'paused workflow execution', and distinguishes from sibling tools like pause_workflow and terminate_workflow.

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?

Usage is implied for paused workflows, but no explicit when-to-use, when-not-to-use, or alternatives are provided.

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

workflow_retry_workflowB

Retries a failed workflow execution from the last failed task.

Args: workflow_id: The uuid representing the execution of the workflow to retry resume_subworkflow_tasks: If True, resume any subworkflow tasks that were running

ParametersJSON Schema

Name	Required	Description	Default
`workflow_id`	Yes
`resume_subworkflow_tasks`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

B3.4/5.0

Behavior2/5

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

With no annotations provided, the description carries the full behavioral burden. It explains retrying from the last failed task and the resume_subworkflow_tasks parameter, but lacks details on side effects (e.g., new execution ID, re-running tasks) or prerequisites.

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 short and front-loaded, with no redundant information. The docstring format is efficient, though a bit more brevity could be achieved.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description covers core functionality and parameters. However, with an output schema present, it should mention the return type (e.g., a new execution ID). The presence of many sibling workflow tools suggests more complete guidance would be beneficial.

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

Parameters4/5

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

Despite 0% schema coverage, the description adds clear meaning: workflow_id is a uuid of the execution, and resume_subworkflow_tasks controls subworkflow resumption. This compensates for the schema's lack of 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 retries a failed workflow execution from the last failed task, using a specific verb and resource. This distinguishes it from siblings like workflow_restart_workflow or workflow_resume_workflow.

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

Usage Guidelines2/5

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

No guidance on when to use this tool versus alternatives (e.g., restart, resume). The description does not provide context for appropriate use or exclusions.

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

workflow_start_workflow_by_nameA

Starts a new execution of a conductor workflow by its name

Args: workflow_name: The name of the workflow definition to create a new execution for correlation_id: An integer used as unique identifier for the workflow execution, used to correlate the current workflow instance with other workflows. priority: A number starting at 0 representing the priority of the execution of the workflow. Lower numbers mean higher priority. idempotency_key: An arbitrary, user-provided string used to ensure idempotency when calling this endpoint multiple times. idempotency_strategy: A string representing one of the following three strategies: RETURN_EXISTING: Return the workflowId of the workflow instance with the same idempotency key. FAIL: Start a new workflow instance only if there are no workflow executions with the same idempotency key. FAIL_ON_RUNNING: Start a new workflow instance only if there are no RUNNING or PAUSED workflows with the same idempotency key. Completed workflows can run again. data: A dictionary containing any arguments to pass into the workflow for creation

ParametersJSON Schema

Name	Required	Default
`workflow_name`	Yes
`correlation_id`	No
`priority`	No
`idempotency_strategy`	No	RETURN_EXISTING
`idempotency_key`	No
`data`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.7/5.0

Behavior3/5

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

With no annotations, the description carries full burden. It explains idempotency strategies and parameter roles but does not explicitly state that this tool creates a new workflow execution (a mutation) or discuss side effects, permissions, or rate limits. The behavior is partially transparent but lacks depth.

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 structured as a docstring with a clear purpose sentence followed by an Args section. It is efficient, with each parameter receiving a single line. No redundant or unnecessary text, though it could be slightly more concise without losing value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description covers all parameters and the main action. However, it lacks guidance on when to use this tool versus other workflow tools (e.g., workflow_create_workflow_definition). Since an output schema exists, return values are not needed, but the absence of usage context reduces completeness.

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 0%, so the description adds substantial meaning. It explains each parameter: workflow_name as the definition name, correlation_id for uniqueness, priority with ordering, idempotency_key and idempotency_strategy with three strategies, and data as a dictionary of arguments. This goes far beyond the schema's type/default information.

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 'Starts a new execution of a conductor workflow by its name', providing a specific verb ('starts') and resource ('workflow execution'). This distinguishes it from sibling tools that read, pause, or terminate workflows, 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 Guidelines2/5

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

No explicit guidance on when to use this tool versus alternatives. The description does not mention any exclusions, prerequisites, or recommend scenarios. The agent must infer usage from the purpose statement alone.

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

workflow_terminate_workflowA

Terminates a workflow execution. This will stop the workflow and mark it as terminated.

Args: workflow_id: The uuid representing the execution of the workflow to terminate reason: Optional reason for termination

ParametersJSON Schema

Name	Required	Description	Default
`workflow_id`	Yes
`reason`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.8/5.0

Behavior2/5

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

No annotations provided. Description says it stops and marks as terminated, but does not disclose whether termination is irreversible, fails if already terminated, or triggers side effects. For a destructive action, more disclosure is needed.

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?

Two sentences with immediate purpose and parameter details. No filler; every word serves a purpose. Very efficient for an AI agent.

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?

Given output schema exists for return value, description adequately covers purpose and key parameters. Minor omission: no mention of error cases or prerequisites, but tool is simple enough.

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

Parameters4/5

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

Description explains workflow_id as UUID of execution and reason as optional, adding meaning beyond schema types. With 0% schema coverage, this compensates well, though constraints on workflow_id format are missing.

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?

Description clearly states it terminates a workflow execution and marks it as terminated. The verb 'terminates' and resource 'workflow execution' are specific. Among siblings like pause, resume, restart, this is distinct in action and finality.

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?

No explicit guidance on when to use vs. alternatives. The description implies termination is final, but doesn't contrast with pause or retry. Agent might need to infer context from sibling names.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

19 tool updatesv0.1.9Jun 21, 2026
- First observedevent_get_event_handlers
- First observedtask_create_task_definition
- First observedtask_get_all_task_definitions
- First observedtask_get_task_by_id
- First observedtask_get_task_definition_for_tasktype
- First observedtask_get_task_logs
- First observedtask_get_task_queue_details
- First observedtask_update_task_status
- First observedworkflow_create_workflow_definition
- First observedworkflow_get_all_workflows
- First observedworkflow_get_workflow_by_id
- First observedworkflow_get_workflow_by_name
- First observedworkflow_pause_workflow
- First observedworkflow_query_workflow_executions
- First observedworkflow_restart_workflow
- First observedworkflow_resume_workflow
- First observedworkflow_retry_workflow
- First observedworkflow_start_workflow_by_name
- First observedworkflow_terminate_workflow

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.8/5.0

Disambiguation5/5

Tools are clearly grouped by resource (event, task, workflow) and each tool has a distinct purpose. There is no overlap between tools, and descriptions make it easy to differentiate them.

Naming Consistency5/5

All tool names follow a consistent resource_verb_noun pattern (e.g., event_get_event_handlers, task_create_task_definition, workflow_get_workflow_by_id). This provides predictability and clarity.

Tool Count4/5

With 19 tools, the set is slightly above the typical 3-15 range but still reasonable for a comprehensive workflow orchestration server covering event handling, task management, and workflow lifecycle operations.

Completeness4/5

The tool surface covers major operations for event handlers, task definitions, and workflow executions. Minor gaps exist, such as explicit workflow definition update and task execution result retrieval, but the overall coverage is good.

Maintenance

ActivityInactive

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

mcp-serverOAuth
com.make
Give your AI agents the tools to build, manage, and run automation workflows.
App Automation Developer Tools Workplace & Productivity
2
DynamicEndpoints-autogen_mcpOAuth
ai.smithery
Create and manage AI agents that collaborate and solve problems through natural language interacti…
Autonomous Agents Agent Orchestration Developer Tools
215
KoreyOAuth
ai.korey
The AI orchestration agent for modern software teams.
Agent Orchestration Autonomous Agents
2
DobbyOAuth
io.github.gil-dobby
Connect, monitor, and control AI agents — tasks, approvals, schedules, and governance.
Agent Orchestration Autonomous Agents Monitoring
2

Related MCP Servers

Crew AI MCP Server
Agent Orchestration Autonomous Agents
MatthewLaw1
F
license
Not graded
quality
D
maintenance
Enables AI agent and task management using the CrewAI framework, allowing users to create and run agents and tasks in an automated workflow environment.
Updated 2 years ago (2025-02-02 22:08 UTC)
4
6
-
ComfyUI MCP Server
Image & Video Processing App Automation Developer Tools
christian-byrne
A
license
A
quality
D
maintenance
Enables AI agents to manage ComfyUI workflows using a human-readable Domain Specific Language (DSL), with automatic conversion to/from JSON format. Supports workflow creation, validation, execution, and monitoring through natural language interactions.
Updated 10 months ago (2025-10-28 03:00 UTC)
16
3
MIT
Conductor MCP Server
CI/CD & DevOps Workplace & Productivity App Automation
opensensor
A
license
B
quality
Not graded
maintenance
Enables AI assistants to interact with Netflix Conductor Workflow Engine for troubleshooting workflows, managing executions, and creating/updating workflow and task definitions through natural language.
Updated 8 months ago (2025-12-28 08:02 UTC)
19
2
-
Temporal MCP Server
Autonomous Agents Developer Tools
GethosTheWalrus
A
license
B
quality
A
maintenance
Enables AI assistants to manage Temporal workflows, schedules, and workflow executions through a standardized interface.
Updated 6 days ago (2026-08-31 19:32 UTC)
31
55
Apache 2.0

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

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