Skip to main content
Glama
FiveOhhWon

workflows-mcp

by FiveOhhWon
OverviewSchemaRelated ServersScoreDiscussions
JavaScript
Hybrid

workflows-mcp

🤖 Co-authored with Claude Code - Building workflows so LLMs can finally follow a recipe without burning the kitchen! 🔥

A powerful Model Context Protocol (MCP) implementation that enables LLMs to execute complex, multi-step workflows with cognitive actions and tool integrations.

🌟 Overview

workflows-mcp transforms how AI assistants handle complex tasks by providing structured, reusable workflows that combine tool usage with cognitive reasoning. Instead of ad-hoc task execution, workflows provide deterministic, reproducible paths through multi-step processes.

Related MCP server: Pure Agentic MCP Server

🚀 Key Features

  • 📋 Structured Workflows: Define clear, step-by-step instructions for LLMs

  • 🧠 Cognitive Actions: Beyond tool calls - analyze, consider, validate, and reason

  • 🔀 Advanced Control Flow: Branching, loops, parallel execution

  • 💾 State Management: Track variables and results across workflow steps

  • 🔍 Comprehensive Validation: Ensure workflow integrity before execution

  • 📊 Execution Tracking: Monitor success rates and performance metrics

  • 🛡️ Type-Safe: Full TypeScript support with Zod validation

  • 🎯 Dependency Management: Control variable visibility to reduce token usage

  • ⚡ Performance Optimized: Differential updates and progressive step loading

📦 Installation

Using npx (recommended)

npx @fiveohhwon/workflows-mcp

From npm

npm install -g @fiveohhwon/workflows-mcp

From Source

git clone https://github.com/FiveOhhWon/workflows-mcp.git
cd workflows-mcp
npm install
npm run build

🏃 Configuration

Claude Desktop

Add this configuration to your Claude Desktop config file:

macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Windows: %APPDATA%\Claude\claude_desktop_config.json

Using npx (recommended):

{
  "mcpServers": {
    "workflows": {
      "command": "npx",
      "args": ["-y", "@fiveohhwon/workflows-mcp"]
    }
  }
}

Using global install:

{
  "mcpServers": {
    "workflows": {
      "command": "workflows-mcp"
    }
  }
}

Using local build:

{
  "mcpServers": {
    "workflows": {
      "command": "node",
      "args": ["/absolute/path/to/workflows-mcp/dist/index.js"]
    }
  }
}

Development Mode

For development with hot reload:

npm run dev

📖 Workflow Structure

Workflows are JSON documents that define a series of steps for an LLM to execute:

{
  "name": "Code Review Workflow",
  "description": "Automated code review with actionable feedback",
  "goal": "Perform comprehensive code review",
  "version": "1.0.0",
  "inputs": {
    "file_path": {
      "type": "string",
      "description": "Path to code file",
      "required": true
    }
  },
  "steps": [
    {
      "id": 1,
      "action": "tool_call",
      "tool_name": "read_file",
      "parameters": {"path": "{{file_path}}"},
      "save_result_as": "code_content"
    },
    {
      "id": 2,
      "action": "analyze",
      "description": "Analyze code quality",
      "input_from": ["code_content"],
      "save_result_as": "analysis"
    }
  ]
}

🎯 Action Types

Tool Actions

  • tool_call: Execute a specific tool with parameters

Cognitive Actions

  • analyze: Examine data and identify patterns

  • consider: Evaluate options before deciding

  • research: Gather information from sources

  • validate: Check conditions or data integrity

  • summarize: Condense information to key points

  • decide: Make choices based on criteria

  • extract: Pull specific information from content

  • compose: Generate new content

Control Flow

  • branch: Conditional execution paths

  • loop: Iterate over items or conditions

  • parallel: Execute multiple steps simultaneously

  • wait_for_input: Pause for user input

Utility Actions

  • transform: Convert data formats

  • checkpoint: Save workflow state

  • notify: Send updates

  • assert: Ensure conditions are met

  • retry: Attempt previous step again

🛠️ Available Tools

Workflow Management

  1. create_workflow - Create a new workflow

    {
  "workflow": {
    "name": "My Workflow",
    "description": "What it does",
    "goal": "Desired outcome",
    "steps": [...]
  }
}

  2. list_workflows - List all workflows with filtering

    {
  "filter": {
    "tags": ["automation"],
    "name_contains": "review"
  },
  "sort": {
    "field": "created_at",
    "order": "desc"
  }
}

  3. get_workflow - Retrieve a specific workflow

    {
  "id": "workflow-uuid"
}

  4. update_workflow - Modify existing workflow

    {
  "id": "workflow-uuid",
  "updates": {
    "description": "Updated description"
  },
  "increment_version": true
}

  5. delete_workflow - Soft delete (recoverable)

    {
  "id": "workflow-uuid"
}

  6. start_workflow - Start a workflow execution session

    {
  "id": "workflow-uuid",
  "inputs": {
    "param1": "value1"
  }
}

    Returns execution instructions for the first step and an execution_id.

  7. run_workflow_step - Execute the next step in the workflow

    {
  "execution_id": "execution-uuid",
  "step_result": "result from previous step",
  "next_step_needed": true
}

    Call this after completing each step to proceed through the workflow.

  8. get_workflow_versions - List all available versions of a workflow

    {
  "workflow_id": "workflow-uuid"
}

    Returns list of all saved versions for version history tracking.

  9. rollback_workflow - Rollback a workflow to a previous version

    {
  "workflow_id": "workflow-uuid",
  "target_version": "1.0.0",
  "reason": "Reverting breaking changes"
}

    Restores a previous version as the active workflow.

🔄 Step-by-Step Execution

The workflow system supports interactive, step-by-step execution similar to the sequential thinking tool:

  1. Start a workflow with start_workflow - returns the first step instructions

  2. Execute the step following the provided instructions

  3. Continue to next step with run_workflow_step, passing:

    • The execution_id from start_workflow

    • Any step_result from the current step

    • next_step_needed: true to continue (or false to end early)

  4. Repeat until the workflow completes

Each step provides:

  • Clear instructions for what to do

  • Current variable state

  • Expected output format

  • Next step guidance

Template Variables

The workflow system supports template variable substitution using {{variable}} syntax:

  • In parameters: "path": "output_{{format}}.txt" → "path": "output_csv.txt"

  • In descriptions: "Processing {{count}} records" → "Processing 100 records"

  • In prompts: "Enter value for {{field}}" → "Enter value for email"

  • In transformations: Variables are automatically substituted

Template variables are resolved from the current workflow session variables, including:

  • Initial inputs provided to start_workflow

  • Results saved from previous steps via save_result_as

  • Any variables set during workflow execution

🎯 Dependency Management & Performance Optimization

The workflow system includes advanced features to minimize token usage and improve performance for complex workflows:

Dependency-Based Variable Filtering

Control which variables are visible to each step to dramatically reduce context size:

{
  "name": "Optimized Workflow",
  "strict_dependencies": true,  // Enable strict mode
  "steps": [
    {
      "id": 1,
      "action": "tool_call",
      "tool_name": "read_large_file",
      "save_result_as": "large_data"
    },
    {
      "id": 2,
      "action": "analyze",
      "input_from": ["large_data"],
      "save_result_as": "summary",
      "dependencies": []  // In strict mode, sees NO previous variables
    },
    {
      "id": 3,
      "action": "compose",
      "dependencies": [2],  // Only sees 'summary' from step 2
      "save_result_as": "report"
    },
    {
      "id": 4,
      "action": "validate",
      "show_all_variables": true,  // Override to see everything
      "save_result_as": "validation"
    }
  ]
}

Workflow-Level Settings

  • strict_dependencies (boolean, default: false)

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

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

Step-Level Settings

  • dependencies (array of step IDs)

    • Lists which previous steps' outputs this step needs

    • Step only sees outputs from listed steps plus workflow inputs

    • Empty array in strict mode means NO variables visible

  • show_all_variables (boolean)

    • Override for specific steps that need full visibility

    • Useful for validation or debugging steps

Performance Features

  1. Differential State Updates: Only shows variables that changed

    • + variable_name: Newly added variables

    • ~ variable_name: Modified variables

    • Unchanged variables are not displayed

  2. Progressive Step Loading: Only shows next 3 upcoming steps

    • Reduces context for long workflows

    • Shows "... and X more steps" for remaining

  3. Selective Variable Display: Based on dependencies

    • Dramatically reduces tokens for workflows with verbose outputs

    • Maintains full state internally for branching/retry

Best Practices for Token Optimization

  1. Use strict_dependencies: true for workflows with large intermediate outputs

  2. Explicitly declare dependencies to minimize variable visibility

  3. Place verbose outputs early in the workflow and filter them out in later steps

  4. Use meaningful variable names to make dependencies clear

  5. Group related steps to minimize cross-dependencies

Example: Data Processing with Filtering

{
  "name": "Large Data Processing",
  "strict_dependencies": true,
  "inputs": {
    "file_path": { "type": "string", "required": true }
  },
  "steps": [
    {
      "id": 1,
      "action": "tool_call",
      "tool_name": "read_csv",
      "parameters": { "path": "{{file_path}}" },
      "save_result_as": "raw_data"
    },
    {
      "id": 2,
      "action": "transform",
      "transformation": "Extract key metrics only",
      "dependencies": [1],  // Only sees raw_data
      "save_result_as": "metrics"
    },
    {
      "id": 3,
      "action": "analyze",
      "criteria": "Identify trends and anomalies",
      "dependencies": [2],  // Only sees metrics, not raw_data
      "save_result_as": "analysis"
    },
    {
      "id": 4,
      "action": "compose",
      "criteria": "Create executive summary",
      "dependencies": [2, 3],  // Sees metrics and analysis only
      "save_result_as": "report"
    }
  ]
}

In this example:

  • Step 2 processes large raw data but only outputs key metrics

  • Step 3 analyzes metrics without seeing the large raw data

  • Step 4 creates a report from metrics and analysis only

  • Token usage is minimized by filtering out verbose intermediate data

📚 Example Workflows

Code Review Workflow

Analyzes code quality, identifies issues, and provides improvement suggestions.

  • Sample data: /workflows/examples/sample-data/sample-code-for-review.js

Data Processing Pipeline

ETL workflow with validation, quality checks, and conditional branching.

  • Sample data: /workflows/examples/sample-data/sample-data.csv

Research Assistant

Gathers information, validates sources, and produces comprehensive reports.

Simple File Processor

Basic example showing file operations, branching, and transformations.

See the /workflows/examples directory for complete workflow definitions.

📁 Manual Workflow Import

You can manually add workflows by placing JSON files in the imports directory:

  1. Navigate to ~/.workflows-mcp/imports/

  2. Place your workflow JSON files there (any filename ending in .json)

  3. Start or restart the MCP server

  4. The workflows will be automatically imported with:

    • A new UUID assigned if missing or invalid

    • Metadata created if not present

    • Original files moved to imports/processed/ after successful import

Example workflow file structure:

{
  "name": "My Custom Workflow",
  "description": "A manually created workflow",
  "goal": "Accomplish something specific",
  "version": "1.0.0",
  "steps": [
    {
      "id": 1,
      "action": "tool_call",
      "description": "First step",
      "tool_name": "example_tool",
      "parameters": {}
    }
  ]
}

🏗️ Architecture

workflows-mcp/
├── src/
│   ├── types/          # TypeScript interfaces and schemas
│   ├── services/       # Core services (storage, validation)
│   ├── utils/          # Utility functions
│   └── index.ts        # MCP server implementation
├── workflows/
│   └── examples/       # Example workflows
│       └── sample-data/  # Sample data files for testing
└── tests/              # Test suite

🧪 Development

# Install dependencies
npm install

# Run in development mode
npm run dev

# Build for production
npm run build

# Run tests
npm test

# Type checking
npm run typecheck

📝 Changelog

v0.3.3 (Latest)

  • ⚡ Added dependency-based variable filtering for token optimization

  • ✨ Added strict_dependencies workflow flag for explicit variable control

  • ✨ Added dependencies array to steps for selective variable visibility

  • ✨ Added show_all_variables step override for full visibility when needed

  • 🎯 Implemented differential state updates (shows only changed variables)

  • 📊 Added progressive step loading (shows only next 3 steps)

  • 🐛 Fixed UUID validation error in update_workflow tool

  • 📝 Added explicit instructions to prevent commentary during workflow execution

v0.3.0

  • ✨ Added workflow versioning with automatic version history

  • ✨ Added get_workflow_versions tool to list all versions

  • ✨ Added rollback_workflow tool to restore previous versions

  • 📁 Version history stored in ~/.workflows-mcp/versions/

v0.2.1

  • ✨ Added template variable resolution ({{variable}} syntax)

  • ✨ Fixed branching logic to properly handle conditional steps

  • ✨ Enhanced create_workflow tool with comprehensive embedded documentation

  • 🐛 Fixed ES module import issues

  • 📁 Improved file organization with sample-data folder

v0.2.0

  • ✨ Implemented step-by-step workflow execution

  • ✨ Added start_workflow and run_workflow_step tools

  • ✨ Session management for workflow state

  • 🔄 Replaced run_workflow with interactive execution

v0.1.0

  • 🎉 Initial release

  • ✨ Core workflow engine

  • ✨ 16 action types

  • ✨ Import/export functionality

  • ✨ Example workflows

🔮 Roadmap

  • Core workflow engine

  • Basic action types

  • Workflow validation

  • Example workflows

  • Step-by-step execution

  • Variable interpolation

  • Branching logic

  • Import/export system

  • Advanced error handling and retry logic

  • Loop and parallel execution

  • Workflow marketplace

  • Visual workflow builder

  • Performance optimizations

  • Workflow versioning and rollback

🤝 Contributing

We welcome contributions! Please see our Contributing Guidelines for details.

📄 License

This project is licensed under the MIT License - see the LICENSE file for details.

🙏 Acknowledgments

Built on the Model Context Protocol specification by Anthropic.

Available Tools

9 tools
create_workflowA

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

ParametersJSON Schema
NameRequiredDescriptionDefault
workflowYes

TDQS

A4/5.0
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.

delete_workflowA

Soft delete a workflow (can be recovered)

ParametersJSON Schema
NameRequiredDescriptionDefault
idYes

TDQS

A3.6/5.0
Behavior3/5

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

With no annotations provided, the description carries the full burden. It discloses that the deletion is 'soft' and reversible, which is a key behavioral trait beyond basic function. However, it lacks details on permissions, side effects, or error conditions, making it adequate but incomplete for a mutation tool.

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, efficient sentence that front-loads the key information ('soft delete a workflow') and adds necessary context ('can be recovered') without any waste. It's appropriately sized for the tool's complexity.

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 no annotations, 0% schema coverage, and no output schema, the description is incomplete. It covers the soft delete behavior but misses parameter details, return values, and full usage context. For a mutation tool with siblings, more information would be needed for full completeness.

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 doesn't mention the 'id' parameter at all, leaving it undocumented. However, with only one parameter and no schema details, the baseline is high; the description adds value by explaining the soft delete nature, but doesn't clarify parameter usage.

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 action ('soft delete') and resource ('a workflow'), distinguishing it from siblings like 'delete_workflow' (if it existed) by specifying it's a soft delete. However, it doesn't explicitly differentiate from all siblings (e.g., 'update_workflow' or 'rollback_workflow'), which slightly reduces clarity.

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 mentioning 'can be recovered,' suggesting this tool should be used when temporary removal is needed versus permanent deletion. However, it doesn't explicitly state when to use this tool over alternatives like 'update_workflow' or provide clear exclusions, leaving some ambiguity.

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

get_workflowC

Get a specific workflow by ID

ParametersJSON Schema
NameRequiredDescriptionDefault
idYes

TDQS

C2.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 'get' but doesn't disclose behavioral traits such as whether this is a read-only operation, if it requires authentication, error handling for invalid IDs, or rate limits. The description is minimal and lacks critical context for safe invocation.

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, efficient sentence that's front-loaded with the core purpose. There's no wasted verbiage, making it highly concise and well-structured for quick understanding.

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

Completeness2/5

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

Given no annotations, no output schema, and low schema coverage, the description is incomplete. It doesn't cover what the tool returns, error conditions, or behavioral nuances. For a tool with siblings and potential complexity, this leaves significant gaps for an AI agent.

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%, so the description must compensate. It mentions 'by ID', which adds meaning to the 'id' parameter, but doesn't explain the ID format, where to obtain it, or constraints. With 1 undocumented parameter, this is insufficient to guide effective use.

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

Purpose3/5

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

The description 'Get a specific workflow by ID' clearly states the action (get) and resource (workflow), but it's vague about what 'get' entails (e.g., retrieve metadata, fetch details). It distinguishes from siblings like 'list_workflows' by specifying 'by ID', but lacks specificity on the scope of information returned.

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. It implies usage when a specific workflow ID is known, but doesn't mention prerequisites, when not to use it (e.g., for listing workflows), or compare to siblings like 'get_workflow_versions' for version-specific details.

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

get_workflow_versionsC

List all available versions of a workflow

ParametersJSON Schema
NameRequiredDescriptionDefault
workflow_idYes

TDQS

C2.9/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 burden of behavioral disclosure. It states 'List all available versions', implying a read-only operation, but doesn't specify whether it returns metadata, pagination details, error conditions, or permissions required. This is a significant gap for a tool with zero annotation coverage.

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, efficient sentence that directly states the tool's function without unnecessary words. It's appropriately sized and front-loaded, making it easy to parse quickly.

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

Completeness2/5

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

Given the complexity of listing versions (which may involve metadata, ordering, or access controls), no annotations, no output schema, and low schema coverage, the description is incomplete. It doesn't address what 'versions' entail, the return format, or potential limitations, leaving critical gaps for the agent.

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?

The schema has 0% description coverage, so the description must compensate. It implies the parameter 'workflow_id' is used to identify the workflow, but doesn't explain its format, constraints, or how it relates to the output. This adds minimal value beyond the schema, resulting in a baseline score.

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 action ('List') and resource ('all available versions of a workflow'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'get_workflow' or 'list_workflows', which might also retrieve workflow-related information, so it doesn't reach the highest 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 like 'get_workflow' or 'list_workflows'. It lacks context about prerequisites, such as needing an existing workflow, or exclusions, leaving the agent to infer usage from the name alone.

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

list_workflowsC

List all workflows with optional filtering and sorting

ParametersJSON Schema
NameRequiredDescriptionDefault
filterNo
sortNo

TDQS

C2.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 the full burden of behavioral disclosure. It mentions 'optional filtering and sorting', which hints at query capabilities, but fails to describe critical traits like pagination, rate limits, authentication needs, or what data is returned (e.g., workflow details, IDs). For a list operation with no annotation coverage, this is a significant gap in 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 a single, efficient sentence that front-loads the core action ('List all workflows') and adds key modifiers ('with optional filtering and sorting'). There is no wasted verbiage, making it appropriately sized and easy to parse.

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

Completeness2/5

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

Given the complexity (2 parameters with nested objects, no annotations, no output schema), the description is incomplete. It lacks details on behavioral aspects (e.g., pagination, error handling), parameter usage, and output format, which are crucial for an agent to invoke this tool effectively. The conciseness comes at the expense of necessary context.

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%, meaning parameters are undocumented in the schema. The description mentions 'optional filtering and sorting', which maps to the two parameters ('filter' and 'sort'), but adds minimal semantic value—it doesn't explain what fields can be filtered (e.g., tags, dates) or sorted (e.g., by name, success rate), leaving the agent to infer from the schema structure alone. This insufficiently compensates for the low coverage.

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 ('List') and resource ('workflows'), making the purpose evident. It also mentions optional filtering and sorting, which adds specificity. However, it doesn't explicitly distinguish this tool from sibling tools like 'get_workflow' or 'get_workflow_versions', which might also retrieve workflow information, so it falls short of 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. With siblings like 'get_workflow' (likely for single workflows) and 'get_workflow_versions' (for version history), there's no indication of context or exclusions, such as whether this is for bulk retrieval or initial exploration. This leaves the agent without clear usage direction.

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

rollback_workflowC

Rollback a workflow to a previous version

ParametersJSON Schema
NameRequiredDescriptionDefault
workflow_idYes
target_versionYes
reasonNo

TDQS

C2.8/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 burden of behavioral disclosure. It states the action ('rollback') but doesn't explain critical aspects like whether this requires admin permissions, if it's destructive to current workflow data, what happens to running instances, or if there are rate limits. This leaves significant gaps for an agent to understand the tool's behavior safely.

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, efficient sentence that front-loads the core action without unnecessary words. It earns its place by clearly stating the tool's purpose, though it could benefit from additional context given the complexity of the operation.

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

Completeness2/5

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

Given the complexity of a rollback operation (potentially destructive), no annotations, no output schema, and low schema coverage, the description is incomplete. It lacks details on prerequisites, side effects, error handling, or return values, making it inadequate for safe and effective use by an agent.

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%, so the description must compensate by explaining parameters, but it adds no meaning beyond what the schema provides. The three parameters (workflow_id, target_version, reason) are undocumented in both schema and description, leaving their semantics unclear—e.g., what format target_version expects or if reason is optional/logged.

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 action ('rollback') and resource ('workflow to a previous version'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'update_workflow' or 'get_workflow_versions', which could have overlapping functionality or be used in similar contexts.

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. For example, it doesn't specify if this should be used after detecting errors, for testing, or as an alternative to updating or deleting workflows. The presence of siblings like 'update_workflow' and 'get_workflow_versions' suggests potential overlap, but no explicit usage context is given.

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

run_workflow_stepA

Execute the next step in an active workflow session.

IMPORTANT: When executing workflow steps, follow these rules:

  1. DO NOT provide commentary between workflow steps unless explicitly requested

  2. Simply execute each step according to the workflow instructions

  3. Move immediately to the next step after completing the current one

  4. Only provide output when the workflow specifically requires it (e.g., notify actions, final results)

  5. Focus solely on executing the workflow actions as defined

The tool will provide step-by-step instructions that should be followed exactly.

ParametersJSON Schema
NameRequiredDescriptionDefault
execution_idYes
step_resultNo
next_step_neededYes

TDQS

A3.8/5.0
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 effectively describes key behavioral traits: it's an execution tool (implying mutation), requires following specific rules (e.g., no commentary, immediate progression), and outlines output behavior (only when required). It doesn't cover aspects like error handling or permissions, but provides substantial context.

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 purpose statement followed by bullet-point rules, making it front-loaded and easy to parse. It's appropriately sized, though the rule list could be slightly condensed without losing clarity.

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 complexity of workflow execution, no annotations, and no output schema, the description provides good behavioral rules but lacks parameter explanations and details on return values or error cases. It's partially complete but has notable gaps for a tool with 3 parameters and mutation implications.

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?

The schema description coverage is 0%, and the description provides no information about the 3 parameters (execution_id, step_result, next_step_needed). It mentions 'step-by-step instructions' but doesn't explain how parameters relate to execution, leaving semantics unclear and failing to compensate for the schema gap.

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 'execute' and resource 'next step in an active workflow session', making the purpose understandable. However, it doesn't explicitly differentiate from sibling tools like 'start_workflow' or 'rollback_workflow', which might handle workflow execution in different contexts.

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

Usage Guidelines5/5

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

The description provides explicit usage rules (e.g., 'DO NOT provide commentary between workflow steps', 'Move immediately to the next step after completing the current one'), specifying when and how to use this tool versus alternatives. This offers clear operational guidance beyond basic functionality.

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

start_workflowC

Start a workflow execution session with step-by-step control

ParametersJSON Schema
NameRequiredDescriptionDefault
idYes
inputsNo

TDQS

C2.8/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 burden of behavioral disclosure. It mentions 'step-by-step control', hinting at interactive or incremental execution, but fails to detail critical aspects such as permissions required, whether it's read-only or destructive, rate limits, session management, or what happens on errors. For a tool that likely involves execution state, this is a significant gap in 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 a single, efficient sentence that is front-loaded with the core purpose ('Start a workflow execution session') and adds a key feature ('with step-by-step control'). There is no wasted text, and it effectively communicates the essential idea without redundancy or fluff.

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

Completeness2/5

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

Given the complexity of starting a workflow (likely involving execution, state, and inputs), no annotations, no output schema, and 0% schema coverage, the description is incomplete. It lacks details on behavior, parameters, return values, and error handling, making it inadequate for an agent to use the tool confidently in varied contexts.

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%, so the schema provides no parameter details. The description adds no information about the 'id' (e.g., what it refers to, format) or 'inputs' (e.g., expected structure, examples). It doesn't compensate for the lack of schema documentation, leaving both parameters semantically unclear to the agent.

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 action ('Start') and resource ('workflow execution session'), specifying it provides 'step-by-step control'. It distinguishes from siblings like 'run_workflow_step' (single step) and 'create_workflow' (creation vs. execution). However, it doesn't explicitly differentiate from all siblings, such as 'rollback_workflow' or 'update_workflow', which keeps it from 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?

No explicit guidance on when to use this tool versus alternatives is provided. The description implies usage for starting workflows with control, but it doesn't specify prerequisites (e.g., needing an existing workflow), exclusions (e.g., when not to use it), or direct comparisons to siblings like 'run_workflow_step' or 'list_workflows'. This leaves the agent without clear decision-making criteria.

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

update_workflowC

Update an existing workflow with optional version increment

ParametersJSON Schema
NameRequiredDescriptionDefault
idYes
updatesYes
increment_versionNo

TDQS

C2.7/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 burden of behavioral disclosure. It mentions 'optional version increment,' hinting at mutability and version control, but lacks critical details: required permissions, whether updates are reversible, rate limits, or what happens to unspecified fields. For a mutation tool, this leaves significant gaps in understanding its behavior.

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 a single, efficient sentence that front-loads the core action ('Update an existing workflow') and adds a key feature ('optional version increment'). There's no wasted text, though it could be more structured with brief usage hints.

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

Completeness2/5

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

Given the tool's complexity (mutation with 3 parameters, nested objects, no output schema, and no annotations), the description is incomplete. It doesn't cover behavioral aspects like permissions or side effects, parameter details beyond basics, or output expectations, making it inadequate for safe and effective use by an AI agent.

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%, so the schema provides no parameter details. The description adds minimal semantics: it implies 'id' identifies the workflow and 'updates' contains modifications, and mentions 'increment_version' as optional. However, it doesn't explain the structure of 'updates' (a nested object with no schema), acceptable values, or the effect of version increment, failing to compensate for the low coverage.

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 ('Update') and resource ('an existing workflow'), specifying it modifies an existing entity rather than creating a new one. It distinguishes from siblings like 'create_workflow' by focusing on updates, though it doesn't explicitly contrast with other update-related tools like 'rollback_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?

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing an existing workflow ID), exclusions, or comparisons to siblings like 'rollback_workflow' for version management or 'create_workflow' for new workflows.

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.

  1. 9 tool updates
    • First observedcreate_workflow
    • First observeddelete_workflow
    • First observedget_workflow
    • First observedget_workflow_versions
    • First observedlist_workflows
    • First observedrollback_workflow
    • First observedrun_workflow_step
    • First observedstart_workflow
    • First observedupdate_workflow
Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.5/5.0
Disambiguation5/5

Each tool has a distinct purpose with no overlap: create_workflow, get_workflow, update_workflow, delete_workflow, list_workflows, get_workflow_versions, rollback_workflow, start_workflow, and run_workflow_step. The descriptions clearly differentiate between CRUD operations, version management, and execution control, making it easy for an agent to select the right tool.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern using snake_case, such as create_workflow, delete_workflow, and list_workflows. This predictability enhances readability and usability, with no deviations or mixed conventions across the set.

Tool Count5/5

With 9 tools, the server is well-scoped for workflow management, covering creation, retrieval, updating, deletion, listing, version control, and execution. Each tool serves a clear and necessary function without redundancy or excessive complexity, fitting the domain appropriately.

Completeness5/5

The tool set provides complete coverage for workflow lifecycle management, including CRUD operations (create, get, update, delete), version handling (get_versions, rollback), listing, and execution control (start, run_step). There are no obvious gaps, ensuring agents can perform all essential tasks without dead ends.

Maintenance

ActivityInactive
ResponsivenessSyncing

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

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

Related MCP Connectors

Related MCP Servers

  • MCP-Server

    chenshuai2144
    A
    license
    C
    quality
    D
    maintenance
    A Model Context Protocol implementation that enables large language models to call external tools (like weather forecasts and GitHub information) through a structured protocol, with visualization of the model's reasoning process.
    2
    225
    2
    MIT

Appeared in Searches

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