Workflows

Workflows is designed to let an operator compose a named, multi-step sequence of MCP tool calls: each step targets a specific server and action, with input and output mappings between steps, an optional per-step condition, and dependencies on other steps. A workflow as a whole has an execution mode (sequential or parallel) and a failure-handling policy — stop on error, continue on error, or retry up to a configured maximum.

That's the shape the builder UI collects, and the UI itself is real and substantial — a workflow list page, a create dialog with simple and advanced modes, and a dedicated step builder. But nothing typed into it is currently saved or run: the two backend routes the frontend calls to list and create workflows, GET/POST /api/workflows and GET /api/workflows/stats, are hardcoded in the Data Plane router to return an empty list and zero counts on every call. There is no persistence for a created workflow and no execution engine behind the "run" action — a submitted workflow has nowhere to go.

Status is partial for exactly that reason: the UI for composing and configuring a workflow is implemented, but the capability it names — actually running a governed multi-step workflow — is not, and nothing here should be read as describing working end-to-end behavior yet.