Skip to main content
Glama
0langa

devflows-mcp

by 0langa

Server Configuration

Describes the environment variables required to run the server.

NameRequiredDescriptionDefault
DEVFLOWS_BPMN_PATHNoPath to the BPMN file(s) used by the MCP server, typically found next to the package.found next to the package
DEVFLOWS_ENGINE_URLNoThe 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

CapabilityDetails
tools
{
  "listChanged": false
}
prompts
{
  "listChanged": false
}
resources
{
  "subscribe": false,
  "listChanged": false
}
experimental
{}

Tools

Functions exposed to the LLM to take actions

NameDescription
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.

Runs the gates, drafts release notes, then asks the policy whether a human
is needed. With dry_run true, which is the default, nothing is tagged or
published. approval_timeout is an ISO 8601 duration after which an
unanswered approval expires.
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

NameDescription

No prompts

Resources

Contextual data attached and managed by the client

NameDescription

No resources

TDQS

B3.4/5.0

Scored across 11 tools

Disambiguation5/5

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.

Naming Consistency4/5

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.

Tool Count5/5

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.

Completeness4/5

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.

Maintenance

ActivityMaintained
ResponsivenessNo issues