MCP server
Let AI agents drive Duraton - list runs, trigger events, and control runs - through the MCP server.
Duraton runs a Model Context Protocol server, so an AI assistant (Claude, Cursor, and others) can list runs, trigger events, and control runs as tools - the same operations as the REST API, over one endpoint.
Connect to Duraton's MCP server
The server is a remote MCP server over Streamable HTTP, at:
https://api.duraton.dev/mcpIt uses OAuth. The first time your client connects it opens a browser to Duraton, where you sign in and choose the workspace the assistant can reach; access is scoped to that workspace. Add it to your client:
claude mcp add --transport http duraton https://api.duraton.dev/mcpThen run /mcp in a session and follow the OAuth flow.
Add it to ~/.cursor/mcp.json (global) or .cursor/mcp.json (one project):
{
"mcpServers": {
"duraton": {
"url": "https://api.duraton.dev/mcp"
}
}
}Add it to .vscode/mcp.json. VS Code nests servers under a servers key:
{
"servers": {
"duraton": {
"type": "http",
"url": "https://api.duraton.dev/mcp"
}
}
}Add it to ~/.codeium/windsurf/mcp_config.json. Windsurf names the field serverUrl:
{
"mcpServers": {
"duraton": {
"serverUrl": "https://api.duraton.dev/mcp"
}
}
}Most other MCP clients read a mcpServers map with an http server:
{
"mcpServers": {
"duraton": {
"type": "http",
"url": "https://api.duraton.dev/mcp"
}
}
}Claude Desktop adds a remote server through Settings -> Connectors -> Add custom connector, pointed at the URL above. Codex authenticates a remote server with a bearer token rather than the interactive OAuth flow, so it cannot sign in to this server from config alone.
Choose a workspace
The workspace you pick when you authorize is the default. Two tools let an assistant list and switch workspaces during a session:
| Tool | What it does |
|---|---|
list_workspaces | List the workspaces you can access. |
select_workspace | Set the active workspace for later tool calls, by its id. |
Tools
Every tool is scoped to the active workspace, so a run or event id from another workspace reads back as not-found.
Read tools
| Tool | What it does |
|---|---|
list_runs | List runs, newest first, filtered by app, workflow, and status. |
get_run | One run, with its input, result or error, and step progress. |
run_stats | Run counts by status, optionally scoped to an app or workflow. |
list_steps | A run's steps, in order, with each step's input and output. |
list_run_logs | A run's structured ctx.log output. |
list_workflows | The registered workflows, with triggers, retries, schedules, and flow control. |
list_apps | The registered apps. |
list_runners | The registered runner endpoints, with metadata and liveness. |
flow_state | Live debounce and batch backlogs for flow-controlled workflows. |
list_events | The event log, newest first, filtered by app and event name. |
get_event | One event, with its payload and what it triggered. |
list_control_actions | The control-action audit log, optionally scoped to one run. |
list_webhook_deliveries | The outbound webhook delivery log, newest first, filtered by app and status, paginated. |
get_webhook_delivery | One outbound delivery, with its full attempt log. |
list_webhook_endpoints | The registered outbound webhook endpoints (subscription config, no secrets). |
list_webhook_receivers | The registered inbound webhook receivers (routing config, no secrets). |
webhook_endpoint_stats | Per-endpoint delivery health (delivered, succeeded, failed) over a recent window. |
Write tools
Write tools need write access to the active workspace.
| Tool | What it does |
|---|---|
trigger_event | Emit an event, triggering any matching workflows. |
cancel_run | Cancel a run. |
pause_run | Pause a run. |
resume_run | Resume a paused run. |
replay_run | Replay a run as a new forked run, optionally overriding its input. |
retry_from_step | Retry a run from a named step as a new forked run. |
bulk_replay | Replay every run matching a filter (at least one filter required). |