Devpipe MCP Server
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 |
|---|---|
| list_tasksA | Parse and list all tasks from a devpipe config.toml file. Shows task IDs, names, types, commands, and enabled status. |
| run_pipelineC | Execute devpipe with specified configuration and flags. Runs the development pipeline and returns results. |
| validate_configB | Validate one or more devpipe config.toml files for syntax and structure errors. |
| get_last_runC | Get results and metadata from the most recent devpipe run, including task results, duration, and success status. |
| view_run_logsC | Read logs from a specific task or the entire pipeline from the most recent run. |
| parse_metricsB | Parse JUnit or SARIF metrics from a devpipe run to analyze test results or security findings. |
| get_dashboard_dataC | Extract aggregated data from summary.json or the HTML dashboard, including overall run statistics and metrics. |
| check_devpipeB | Check if devpipe is installed and get version information. |
| list_tasks_verboseC | List tasks using devpipe list --verbose command. Shows task execution statistics and averages. |
| analyze_projectC | Analyze project directory to detect technologies and suggest missing tasks. |
| generate_taskB | Generate task configuration from template for a specific technology and task type. Use technology="phase" to create phase headers. |
| generate_ci_configC | Generate CI/CD configuration file (GitHub Actions or GitLab CI) from devpipe config. |
| create_configB | Create a complete config.toml file from scratch with auto-detected tasks based on project technologies. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
| analyze-config | Analyze the devpipe configuration and suggest improvements |
| debug-failure | Help debug why a specific task failed |
| optimize-pipeline | Suggest optimizations for the pipeline configuration |
| create-task | Help create a new task for a specific technology or tool |
| security-review | Review SARIF security findings and provide recommendations |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
| Current devpipe configuration | Contents of config.toml |
| Task definitions | All task definitions from config.toml |
| Last run results | Results from the most recent pipeline run |
| Pipeline summary | Aggregated pipeline summary data |
| Configuration schema | JSON Schema for devpipe config.toml validation |
TDQS
Scored across 13 tools
Most tools have distinct purposes, but list_tasks and list_tasks_verbose overlap significantly, as both list tasks with the latter providing more detail. This could cause confusion for an agent deciding which to use. Otherwise, tools like analyze_project, create_config, and run_pipeline are clearly differentiated.
All tool names follow a consistent snake_case pattern with clear verb_noun structures, such as analyze_project, create_config, and run_pipeline. There are no deviations in naming conventions, making the set predictable and easy to understand.
With 13 tools, the count is well-scoped for a devpipe server covering configuration, execution, monitoring, and analysis. Each tool serves a specific role in the pipeline lifecycle, from setup to reporting, without feeling excessive or insufficient.
The tool set provides comprehensive coverage for devpipe operations, including configuration creation, validation, task listing, pipeline execution, and result analysis. There are no obvious gaps; it supports the full lifecycle from setup to post-run diagnostics and reporting.