> ## Documentation Index > Fetch the complete documentation index at: https://docs.duraton.ai/llms.txt > Use this file to discover all available pages before exploring further. # MCP server > Let AI agents drive Duraton - operate runs, events, approvals, and your projects - through the MCP server. Duraton runs a [Model Context Protocol](https://modelcontextprotocol.io) server, so an AI assistant (Claude, Cursor, Codex, and others) can drive Duraton with tools - the same operations as the [REST API](/reference/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, 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.ai ``` 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.ai/ ``` 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 ```sh theme={null} claude mcp add --transport http duraton https://mcp.duraton.ai ``` Then run `/mcp` in a session and follow the OAuth flow. Append `/` to the URL to pin the connection to a single project. Add it to `~/.cursor/mcp.json` (global) or `.cursor/mcp.json` (one project): ```json title="~/.cursor/mcp.json" theme={null} { "mcpServers": { "duraton": { "url": "https://mcp.duraton.ai" } } } ``` Add it to `.vscode/mcp.json`. VS Code nests servers under a `servers` key: ```json title=".vscode/mcp.json" theme={null} { "servers": { "duraton": { "type": "http", "url": "https://mcp.duraton.ai" } } } ``` Add it to `~/.codeium/windsurf/mcp_config.json`. Windsurf names the field `serverUrl`: ```json title="~/.codeium/windsurf/mcp_config.json" theme={null} { "mcpServers": { "duraton": { "serverUrl": "https://mcp.duraton.ai" } } } ``` Most other MCP clients read a `mcpServers` map with an `http` server: ```json title=".mcp.json" theme={null} { "mcpServers": { "duraton": { "type": "http", "url": "https://mcp.duraton.ai" } } } ``` **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; 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](/core/triggers#trigger-a-run-manually) - works even for a cron-only workflow. * **Approvals** - list human-in-the-loop approvals and approve or deny them. Reading is always available; deciding can be restricted above a [risk floor](/ai/approvals#who-may-decide-what) that only a person can clear. * **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 (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.