MCP server

Let AI agents drive Duraton - operate runs, events, evals, and your projects - through the MCP server.

Duraton runs a Model Context Protocol server, so an AI assistant (Claude, Cursor, Codex, and others) can drive Duraton with tools - the same operations as the REST API, over one endpoint. An agent is a first-class user here, not a read-only observer: what the console lets you do to your runs, events, approvals, datasets and evals, and webhooks, the agent can do too.

Ways to connect

There are two ways to connect, and the difference is only which projects the agent can reach. Both authenticate the same way - OAuth: the first time your client connects it opens a browser to Duraton, you sign in, and access is bound to your account and the scopes you grant.

Workspace - the whole account

https://mcp.duraton.dev

The agent can reach every project you can access, list and switch between them, and create new ones. This is the default and the right choice for interactive work: developing against a project, moving across a dev / staging / prod set of projects, or letting an agent set a workspace up from scratch.

Single project - pinned by URL

https://mcp.duraton.dev/<projectId>

The same sign-in, but the project in the URL is fixed: the agent can only ever touch that one project. Reach for this for an unattended or narrowly-scoped agent - a runner, a CI job, or an assistant you want locked to one environment - so it can never wander into another project. Copy the URL for a project from its API keys page in the console.

Whichever you use, access is enforced per request against your live workspace membership and role - losing access to a project immediately closes it off, even mid-session.

Add it to your client

claude mcp add --transport http duraton https://mcp.duraton.dev

Then run /mcp in a session and follow the OAuth flow. Append /<projectId> to the URL to pin the connection to a single project.

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

~/.cursor/mcp.json

{
  "mcpServers": {
    "duraton": {
      "url": "https://mcp.duraton.dev"
    }
  }
}

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

.vscode/mcp.json

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

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

~/.codeium/windsurf/mcp_config.json

{
  "mcpServers": {
    "duraton": {
      "serverUrl": "https://mcp.duraton.dev"
    }
  }
}

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

.mcp.json

{
  "mcpServers": {
    "duraton": {
      "type": "http",
      "url": "https://mcp.duraton.dev"
    }
  }
}

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.

Working with projects

Every other tool is scoped to one active project, so a run or event id from another project reads back as not-found. In workspace mode the agent manages that itself:

Tool	What it does
`list_projects`	List the projects you can access.
`select_project`	Set the active project for later tool calls, by its id (`projectId`).
`create_project`	Create a new project - an isolated environment such as `dev`, `staging`, or `prod` - then activate it with `select_project`. Needs write access and a workspace owner/admin role.

In single-project mode the active project is fixed by the URL, so select_project has no effect there.

What an agent can do

The full, current set of tools is whatever the server advertises to your client on connect (tools/list) - that is the source of truth, and it grows as Duraton does. At a high level the tools cover:

Runs - list and inspect runs and their steps; cancel, pause, resume, replay, or retry from a step; bulk-cancel or bulk-replay by filter; fork a finished run with one AI change; and get a model-written diagnosis of a failure.
Events - browse the event log and emit events to trigger workflows.
Workflows, apps, and runners - inspect what is registered, the live flow-control state, and trigger a run manually - works even for a cron-only workflow.
Approvals - list human-in-the-loop approvals and approve or deny them.
Datasets and evals - build datasets, run a dataset through a workflow as an eval, record scores, and read the results back.
Webhooks - manage inbound and outbound webhook endpoints and sources, inspect outbound delivery health, and browse the inbound source delivery log and replay a verified delivery.
Metrics - run counts, timeseries, AI spend, and session rollups.

The exact tool set is deployment- and access-dependent. Write tools appear only when you connect with write access; some tools (a run explainer, the webhook tools) are registered only when the engine is wired for them. Your client always shows what is actually available rather than offering a capability that would only answer "unavailable".

Signing secrets are never returned over MCP. In the console, creating or rotating a webhook secret shows it to you exactly once. A tool result would put that secret in an assistant's transcript and logs, so the MCP tools never emit one: the webhook create tools take the secret as an argument (supply your own, and configure the same value on the sender or receiver), and rotating a secret stays a console and REST action.