workflows-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Server capabilities have not been inspected yet.
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| create_workflowA | Create a new workflow with specified steps and configuration. WORKFLOW STRUCTURE:
AVAILABLE ACTIONS:
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:
EXAMPLES:
DEPENDENCY MANAGEMENT:
PERFORMANCE FEATURES:
BEST PRACTICES:
|
| list_workflowsC | List all workflows with optional filtering and sorting |
| get_workflowC | Get a specific workflow by ID |
| update_workflowC | Update an existing workflow with optional version increment |
| delete_workflowA | Soft delete a workflow (can be recovered) |
| start_workflowC | Start a workflow execution session with step-by-step control |
| run_workflow_stepA | Execute the next step in an active workflow session. IMPORTANT: When executing workflow steps, follow these rules:
The tool will provide step-by-step instructions that should be followed exactly. |
| get_workflow_versionsC | List all available versions of a workflow |
| rollback_workflowC | Rollback a workflow to a previous version |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 9 tools
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.
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.
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.
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.