Skip to main content
Glama

create_workflow

Define structured multi-step workflows that combine tool execution with cognitive reasoning for complex tasks, enabling reusable task automation with advanced control flow.

Instructions

Create a new workflow with specified steps and configuration.

WORKFLOW STRUCTURE:

  • name: Descriptive workflow name

  • description: What the workflow accomplishes

  • goal: The end result or outcome

  • version: Semantic version (default: "1.0.0")

  • tags: Array of categorization tags

  • inputs: Object defining input parameters with type, description, required, and optional default

  • outputs: Array of expected output variable names

  • required_tools: Array of MCP tools this workflow needs

  • steps: Array of workflow steps (see below)

  • strict_dependencies: Boolean to enable strict dependency mode (default: false)

    • false: Steps without dependencies see all variables (backward compatible)

    • true: Steps without dependencies see NO variables (must explicitly declare dependencies)

AVAILABLE ACTIONS:

  • tool_call: Execute an MCP tool (requires tool_name and parameters)

  • analyze: Analyze data and extract insights

  • consider: Evaluate options or possibilities

  • research: Gather information on a topic

  • validate: Check data quality or correctness

  • summarize: Create a summary of information

  • decide: Make a decision based on criteria

  • wait_for_input: Request user input (requires prompt)

  • transform: Transform data (requires transformation description)

  • extract: Extract specific information

  • compose: Create new content

  • branch: Conditional branching (requires conditions array)

  • checkpoint: Save progress checkpoint

  • notify: Send a notification (requires message)

  • assert: Verify a condition (requires condition)

  • retry: Retry a previous step (requires step_id)

STEP STRUCTURE: { "id": 1, // Sequential number starting from 1 "action": "action_type", "description": "What this step does", "save_result_as": "variable_name", // Optional: save result "error_handling": "stop|continue|retry", // Default: "stop" "dependencies": [1, 3], // Optional: only show outputs from these step IDs "show_all_variables": true, // Optional: override to show all variables

// For tool_call: "tool_name": "mcp_tool_name", "parameters": { "param": "value" },

// For cognitive actions (analyze, consider, research, etc): "input_from": ["variable1", "variable2"], // Input variables "criteria": "Specific criteria or focus", // Optional

// For branch: "conditions": [ { "if": "variable.property > value", "goto_step": 5 } ],

// For wait_for_input: "prompt": "Question for the user", "input_type": "text|number|boolean|json",

// For transform: "transformation": "Description of transformation" }

TEMPLATE VARIABLES: Use {{variable_name}} in any string field to reference:

  • Input parameters from workflow inputs

  • Results saved from previous steps via save_result_as

  • Any variables in the workflow state

EXAMPLES:

  • "path": "output_{{format}}.txt"

  • "prompt": "Process {{count}} items?"

  • "description": "Analyzing {{filename}}"

DEPENDENCY MANAGEMENT:

  • Use "dependencies" array to specify which previous steps' outputs are needed

  • In strict_dependencies mode, steps without dependencies see NO variables

  • Steps with dependencies only see outputs from those specific steps + workflow inputs

  • Use "show_all_variables": true to override and see all variables for a specific step

PERFORMANCE FEATURES:

  • Only relevant variables are shown based on dependencies (reduces token usage)

  • Variable changes are highlighted (+ for new, ~ for modified)

  • Only next 3 steps are previewed (progressive loading)

BEST PRACTICES:

  1. Each step should have a single, clear responsibility

  2. Use descriptive variable names for save_result_as

  3. Consider error handling for each step (stop, continue, or retry)

  4. Branch conditions should cover all cases

  5. Order steps logically with proper dependencies

  6. Use strict_dependencies for workflows with large/verbose outputs

  7. Explicitly declare dependencies to minimize context and improve performance

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
workflowYes

Implementation Reference

  • The core handler function for the 'create_workflow' tool. Parses input arguments using the defined schema, generates a unique ID and metadata, constructs the Workflow object, validates it, persists it to storage, and returns a success response containing the new workflow ID.
    private async createWorkflow(args: unknown) {
      const parsed = CreateWorkflowSchema.parse(args);
      
      // Generate ID and add metadata
      const id = await this.storage.generateId();
      const now = new Date().toISOString();
      
      const workflow: Workflow = {
        id,
        name: parsed.workflow.name,
        description: parsed.workflow.description,
        goal: parsed.workflow.goal,
        version: parsed.workflow.version || '1.0.0',
        tags: parsed.workflow.tags || [],
        inputs: parsed.workflow.inputs || {},
        outputs: parsed.workflow.outputs,
        required_tools: parsed.workflow.required_tools,
        steps: parsed.workflow.steps,
        metadata: {
          created_at: now,
          updated_at: now,
          times_run: 0,
        },
        is_deleted: false,
      };
    
      // Validate the complete workflow
      const validation = WorkflowValidator.validateWorkflow(workflow);
      if (!validation.success) {
        throw new Error(`Validation failed: ${validation.error}`);
      }
    
      // Save to storage
      await this.storage.save(workflow);
    
      return {
        content: [
          {
            type: 'text',
            text: JSON.stringify({
              success: true,
              workflow_id: id,
              message: `Workflow "${workflow.name}" created successfully`,
            }, null, 2),
          },
        ],
      };
    }
  • Zod schema defining the expected input structure for the create_workflow tool, validating the workflow definition object containing name, description, goal, optional version/tags/inputs/outputs/required_tools, and required steps array.
    const CreateWorkflowSchema = z.object({
      workflow: z.object({
        name: z.string().describe('Descriptive name for the workflow'),
        description: z.string().describe('What this workflow accomplishes'),
        goal: z.string().describe('The end result or desired outcome'),
        version: z.string().optional().describe('Semantic version (default: "1.0.0")'),
        tags: z.array(z.string()).optional().describe('Categories for organization'),
        inputs: z.record(z.object({
          type: z.enum(['string', 'number', 'boolean', 'array', 'object']),
          description: z.string(),
          required: z.boolean().default(true),
          default: z.any().optional()
        })).optional().describe('Input parameters the workflow accepts'),
        outputs: z.array(z.string()).optional().describe('Names of output variables'),
        required_tools: z.array(z.string()).optional().describe('MCP tools needed'),
        steps: z.array(z.any()).describe('Workflow steps with actions'),
      }).describe('Complete workflow definition'),
    });
  • src/index.ts:158-256 (registration)
    Registers the 'create_workflow' tool in the MCP tools list returned by getTools(), providing the tool name, comprehensive usage description including workflow structure and actions, and the converted JSON input schema.
          {
            name: 'create_workflow',
            description: `Create a new workflow with specified steps and configuration.
    
    WORKFLOW STRUCTURE:
    - name: Descriptive workflow name
    - description: What the workflow accomplishes
    - goal: The end result or outcome
    - version: Semantic version (default: "1.0.0")
    - tags: Array of categorization tags
    - inputs: Object defining input parameters with type, description, required, and optional default
    - outputs: Array of expected output variable names
    - required_tools: Array of MCP tools this workflow needs
    - steps: Array of workflow steps (see below)
    - strict_dependencies: Boolean to enable strict dependency mode (default: false)
      * false: Steps without dependencies see all variables (backward compatible)
      * true: Steps without dependencies see NO variables (must explicitly declare dependencies)
    
    AVAILABLE ACTIONS:
    - tool_call: Execute an MCP tool (requires tool_name and parameters)
    - analyze: Analyze data and extract insights
    - consider: Evaluate options or possibilities  
    - research: Gather information on a topic
    - validate: Check data quality or correctness
    - summarize: Create a summary of information
    - decide: Make a decision based on criteria
    - wait_for_input: Request user input (requires prompt)
    - transform: Transform data (requires transformation description)
    - extract: Extract specific information
    - compose: Create new content
    - branch: Conditional branching (requires conditions array)
    - checkpoint: Save progress checkpoint
    - notify: Send a notification (requires message)
    - assert: Verify a condition (requires condition)
    - retry: Retry a previous step (requires step_id)
    
    STEP STRUCTURE:
    {
      "id": 1, // Sequential number starting from 1
      "action": "action_type",
      "description": "What this step does",
      "save_result_as": "variable_name", // Optional: save result
      "error_handling": "stop|continue|retry", // Default: "stop"
      "dependencies": [1, 3], // Optional: only show outputs from these step IDs
      "show_all_variables": true, // Optional: override to show all variables
      
      // For tool_call:
      "tool_name": "mcp_tool_name",
      "parameters": { "param": "value" },
      
      // For cognitive actions (analyze, consider, research, etc):
      "input_from": ["variable1", "variable2"], // Input variables
      "criteria": "Specific criteria or focus", // Optional
      
      // For branch:
      "conditions": [
        { "if": "variable.property > value", "goto_step": 5 }
      ],
      
      // For wait_for_input:
      "prompt": "Question for the user",
      "input_type": "text|number|boolean|json",
      
      // For transform:
      "transformation": "Description of transformation"
    }
    
    TEMPLATE VARIABLES:
    Use {{variable_name}} in any string field to reference:
    - Input parameters from workflow inputs
    - Results saved from previous steps via save_result_as
    - Any variables in the workflow state
    
    EXAMPLES:
    - "path": "output_{{format}}.txt"
    - "prompt": "Process {{count}} items?"
    - "description": "Analyzing {{filename}}"
    
    DEPENDENCY MANAGEMENT:
    - Use "dependencies" array to specify which previous steps' outputs are needed
    - In strict_dependencies mode, steps without dependencies see NO variables
    - Steps with dependencies only see outputs from those specific steps + workflow inputs
    - Use "show_all_variables": true to override and see all variables for a specific step
    
    PERFORMANCE FEATURES:
    - Only relevant variables are shown based on dependencies (reduces token usage)
    - Variable changes are highlighted (+ for new, ~ for modified)
    - Only next 3 steps are previewed (progressive loading)
    
    BEST PRACTICES:
    1. Each step should have a single, clear responsibility
    2. Use descriptive variable names for save_result_as
    3. Consider error handling for each step (stop, continue, or retry)
    4. Branch conditions should cover all cases
    5. Order steps logically with proper dependencies
    6. Use strict_dependencies for workflows with large/verbose outputs
    7. Explicitly declare dependencies to minimize context and improve performance`,
            inputSchema: zodToJsonSchema(CreateWorkflowSchema),
          },
Behavior4/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It thoroughly explains the workflow structure, available actions, step details, template variables, dependency management, performance features, and best practices. This covers creation behavior, error handling, and operational context, though it does not mention permissions, rate limits, or specific side effects like data persistence.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness2/5

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

The description is overly verbose and not front-loaded. While it starts with the purpose, it then includes extensive sections (WORKFLOW STRUCTURE, AVAILABLE ACTIONS, STEP STRUCTURE, etc.) that are more like documentation than a concise tool description. Many sentences, such as detailed examples and best practices, could be trimmed or moved elsewhere, reducing efficiency.

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 complexity (nested object parameter, no annotations, no output schema), the description is highly complete. It covers the purpose, parameter semantics, behavioral context, and usage guidelines thoroughly. However, it lacks information on return values or error responses, which is a minor gap given the absence of an output schema.

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 has 0% description coverage and 1 parameter (a nested object 'workflow'), so the description must fully compensate. It provides extensive semantics: it details the workflow structure (name, description, goal, version, tags, inputs, outputs, required_tools, steps, strict_dependencies), step structure with examples, and best practices. This adds significant meaning 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 starts with a clear, specific statement: 'Create a new workflow with specified steps and configuration.' This explicitly states the verb ('Create') and resource ('workflow'), distinguishing it from sibling tools like 'update_workflow' or 'delete_workflow'. The purpose is unambiguous and actionable.

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 through its detailed structure and best practices, but does not explicitly state when to use this tool versus alternatives like 'update_workflow' or 'start_workflow'. It provides context on workflow creation but lacks direct guidance on tool selection among siblings.

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/FiveOhhWon/workflows-mcp'

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