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/mcp

It 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/mcp

Then run /mcp in a session and follow the OAuth flow.

Add it to ~/.cursor/mcp.json (global) or .cursor/mcp.json (one project):

~/.cursor/mcp.json
{
  "mcpServers": {
    "duraton": {
      "url": "https://api.duraton.dev/mcp"
    }
  }
}

Add it to .vscode/mcp.json. VS Code nests servers under a servers key:

.vscode/mcp.json
{
  "servers": {
    "duraton": {
      "type": "http",
      "url": "https://api.duraton.dev/mcp"
    }
  }
}

Add it to ~/.codeium/windsurf/mcp_config.json. Windsurf names the field serverUrl:

~/.codeium/windsurf/mcp_config.json
{
  "mcpServers": {
    "duraton": {
      "serverUrl": "https://api.duraton.dev/mcp"
    }
  }
}

Most other MCP clients read a mcpServers map with an http server:

.mcp.json
{
  "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:

ToolWhat it does
list_workspacesList the workspaces you can access.
select_workspaceSet 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

ToolWhat it does
list_runsList runs, newest first, filtered by app, workflow, and status.
get_runOne run, with its input, result or error, and step progress.
run_statsRun counts by status, optionally scoped to an app or workflow.
list_stepsA run's steps, in order, with each step's input and output.
list_run_logsA run's structured ctx.log output.
list_workflowsThe registered workflows, with triggers, retries, schedules, and flow control.
list_appsThe registered apps.
list_runnersThe registered runner endpoints, with metadata and liveness.
flow_stateLive debounce and batch backlogs for flow-controlled workflows.
list_eventsThe event log, newest first, filtered by app and event name.
get_eventOne event, with its payload and what it triggered.
list_control_actionsThe control-action audit log, optionally scoped to one run.
list_webhook_deliveriesThe outbound webhook delivery log, newest first, filtered by app and status, paginated.
get_webhook_deliveryOne outbound delivery, with its full attempt log.
list_webhook_endpointsThe registered outbound webhook endpoints (subscription config, no secrets).
list_webhook_receiversThe registered inbound webhook receivers (routing config, no secrets).
webhook_endpoint_statsPer-endpoint delivery health (delivered, succeeded, failed) over a recent window.

Write tools

Write tools need write access to the active workspace.

ToolWhat it does
trigger_eventEmit an event, triggering any matching workflows.
cancel_runCancel a run.
pause_runPause a run.
resume_runResume a paused run.
replay_runReplay a run as a new forked run, optionally overriding its input.
retry_from_stepRetry a run from a named step as a new forked run.
bulk_replayReplay every run matching a filter (at least one filter required).

On this page