Workflow Tools
MCP tools for running durable, multi-step workflows. Workflows chain multiple tools (skills, connectors) into pipelines with durable, server-persisted state. They automatically handle execution queueing — when a step needs to wait for an execution slot, the run suspends and auto-resumes.
One workflow tool is exposed over MCP: start-workflow (run a workflow by ID). Discovering workflows and managing runs afterward (list, inspect, cancel, resume) is done through the REST API — see Workflows API.
For a walkthrough, see the Workflows Guide.
Finding workflow IDs
Workflow discovery is not exposed as an MCP tool. List available workflows over REST first to get a valid workflowId:
GET /api/v1/workflows
start-workflow
Start a workflow by ID. The client opens a workflow execution thread.
Parameters:
| Parameter | Type | Required | Description |
|---|---|---|---|
workflow_id | string | Yes | Workflow ID to start |
workflow_name | string | No | Human-readable name for display |
inputs | object | No | Input parameters for the workflow |
Response:
{
"success": true,
"data": {
"workflowId": "deep-research",
"workflowName": "Deep Research",
"inputs": {}
}
}
Managing runs (REST)
Run lifecycle isn’t exposed as MCP tools; use the REST endpoints:
| Action | Endpoint |
|---|---|
| List runs | GET /api/v1/workflows/runs |
| Get run details + step history | GET /api/v1/workflows/runs/:runId |
| Cancel a run | POST /api/v1/workflows/runs/:runId/cancel |
| Resume a suspended run | POST /api/v1/workflows/runs/:runId/resume |
See Workflows API for request/response shapes.
Workflow States
| Status | Description |
|---|---|
running | Actively executing steps |
suspended | Paused awaiting a free execution slot or human input (resume to continue) |
completed | All steps finished successfully |
failed | Execution failed |
cancelled | Cancelled by the user |