Activate when requests involve workflow execution, CI/CD pipelines, git automation, or multi-step task orchestration...
Activate when requests involve workflow execution, multi-step task orchestration, or CI/CD automation using the workflows-mcp MCP server.
Activate when user requests mention:
Common user phrases: "run tests before deploying", "create build pipeline", "execute only if previous succeeds", "run tasks in parallel"
Always use tag-based discovery instead of guessing workflow names. Inspect workflows before execution to understand required inputs.
Use list_workflows with tags (AND logic - workflows must have ALL tags):
Tool: list_workflows
Parameters:
tags: ['python', 'ci']
format: 'markdown'
Common tag combinations:
['python'], ['python', 'testing'], ['python', 'ci']['git'], ['git', 'commit'], ['git', 'checkout']['ci'], ['ci', 'deployment']['tdd'], ['tdd', 'phase1']Call get_workflow_info before executing to understand inputs, outputs, and structure:
Tool: get_workflow_info
Parameters:
workflow: 'python-ci-pipeline'
format: 'markdown'
Tool: execute_workflow
Parameters:
workflow: 'python-ci-pipeline'
inputs: {project_path: '/path/to/project'}
response_format: 'minimal'
Response status values:
success - Workflow completed successfullyfailure - Workflow failed (check error field)paused - Workflow paused for user input (use resume_workflow)list_workflows(tags, format) - Discover workflows by tags
tags=['python', 'testing']get_workflow_info(workflow, format) - Get detailed workflow metadata
execute_workflow(workflow, inputs, response_format) - Execute registered workflow
get_workflow_inforesponse_format: 'minimal' (default) or 'detailed' (debugging only)execute_inline_workflow(workflow_yaml, inputs, response_format) - Execute YAML directly
validate_workflow_yamlvalidate_workflow_yaml(yaml_content) - Validate workflow before execution
resume_workflow(checkpoint_id, response, response_format) - Resume paused workflow
list_checkpoints(workflow_name, format) - View saved checkpoints
get_checkpoint_info(checkpoint_id, format) - Inspect checkpoint details
delete_checkpoint(checkpoint_id) - Clean up old checkpoints
All variables use four-namespace architecture:
Inputs: {{inputs.project_name}}, {{inputs.workspace}}
Metadata: {{metadata.workflow_name}}, {{metadata.start_time}}
Blocks: {{blocks.run_tests.outputs.exit_code}}, {{blocks.test.succeeded}}
Status shortcuts (use for 90% of conditionals):
{{blocks.test.succeeded}} - True if completed successfully{{blocks.build.failed}} - True if failed{{blocks.optional.skipped}} - True if skippedFor detailed variable syntax, load ./references/variable-syntax.md.
blocks:
- id: run_tests
type: Shell
inputs:
command: pytest tests/
- id: deploy
type: Shell
inputs:
command: ./deploy.sh
condition: "{{blocks.run_tests.succeeded}}"
depends_on: [run_tests]
blocks:
- id: ci_pipeline
type: Workflow
inputs:
workflow: "python-ci-pipeline"
inputs:
project_path: "{{inputs.workspace}}"
Blocks without dependencies run in parallel automatically.
list_workflows(tags=[...]) instead of guessing namesget_workflow_info() to understand requirements.succeeded over .outputs.exit_code == 0response_format='minimal' unless debuggingvalidate_workflow_yaml() before execute_inline_workflow()inputs.*, blocks.*, metadata.*Load these files as needed using the Read tool:
./references/variable-syntax.md
Load when: Resolving variable syntax errors, understanding namespace architecture, debugging variable resolution, or learning advanced patterns.
Contains: Complete variable resolution rules, recursive resolution, cross-block references, common mistakes, debugging techniques.
./references/block-executors.md
Load when: Understanding available block types (Shell, Workflow, CreateFile, ReadFile, etc.), checking input/output specs, learning execution patterns, troubleshooting block issues.
Contains: Complete block type reference, input/output specifications, execution states, status vs outcome distinction, patterns and troubleshooting.
Load when: Implementing complex multi-stage workflows, building parallel execution pipelines, creating file processing workflows, designing interactive approval workflows, learning advanced patterns.
Contains: Full workflow examples with documentation, multi-stage deployments, parallel testing with aggregation, file processing pipelines, interactive deployments.
Directory: ./examples/
Available templates:
./examples/simple-ci-pipeline.yaml - Basic CI pipeline with sequential execution./examples/conditional-deploy.yaml - Environment-based deployment with conditions./examples/parallel-testing.yaml - Parallel test execution with result aggregationUsage: Copy and modify YAML templates for custom workflows. Execute using execute_inline_workflow tool.
Variable errors: Verify namespace (inputs.*, blocks.*, metadata.*), check block ID case-sensitivity, ensure depends_on for output references
Execution failures: Check error field, use response_format: "detailed" for debugging, verify required inputs, validate condition syntax
Workflow not found: Use list_workflows() to see available workflows, check name spelling (case-sensitive), verify MCP connection
The workflows-mcp server enables workflow orchestration through:
Always follow: Discover → Inspect → Execute