devflows-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| DEVFLOWS_BPMN_PATH | No | Path to the BPMN file(s) used by the MCP server, typically found next to the package. | found next to the package |
| DEVFLOWS_ENGINE_URL | No | The base URL of the CIB seven engine REST API. | http://localhost:8080/engine-rest |
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
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| engine_statusA | Check that the local CIB seven engine is reachable and report its version. |
| deploy_processC | Deploy the release process to the engine. Deploying it twice is harmless. |
| list_processesA | List the process definitions the engine currently knows about. |
| start_releaseA | Start a release run for a repository. |
| get_runB | Report the state, the current activity, the gate report and the variables of a run. |
| list_gatesB | List the gates a release of this repository would run. Does not touch the engine. |
| approve_gateB | Approve or reject a waiting release. This is the human decision in the process. |
| list_runsB | List the most recent release runs, newest first, with their state. |
| retry_runC | Give a run that is stuck on an incident another attempt. |
| cancel_runB | Stop a running release. The reason is kept in the engine history. |
| doctorC | Check whether a release can run: engine, process, decision, config. |
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 11 tools
Each tool targets a distinct resource and action: engine health, process deployment/listing, release run lifecycle, gate approval, and diagnostics. There is no meaningful overlap or risk of selecting the wrong tool for a given intent.
Most tools follow a clear verb_noun pattern (deploy_process, list_processes, start_release, approve_gate, cancel_run). The deviations are minor: engine_status reverses the order and doctor is a bare noun, but the names remain intuitive and predictable.
Eleven tools is well-scoped for a release automation server. Each tool covers a distinct aspect of the release workflow without unnecessary bloat or noticeable duplication.
The tool surface covers the core release lifecycle well: checking the engine, deploying processes, starting runs, monitoring runs, approving gates, retrying, canceling, and running diagnostics. There is no explicit process update/delete, but that is a minor gap since the workflow does not clearly require it.