> ## Documentation Index
> Fetch the complete documentation index at: https://docs.slipway.sh/llms.txt
> Use this file to discover all available pages before exploring further.

# MCP server

> Connect Claude Code, Cursor or Claude Desktop to slipway over MCP.

slipway ships a first-party [Model Context Protocol](https://modelcontextprotocol.io) server, so a coding agent can drive your projects directly. An agent can deploy a project, get a live URL, read logs, run commands to verify its work, check how much capacity is left, and tear it down.

On the hosted platform the endpoint is `https://mcp.slipway.sh/mcp`. **Settings → MCP** in the console shows the exact endpoint for your installation.

## Create a token

In the console, open **Settings → MCP**, which requires admin, and choose **New token**. Give it a name, a role and optionally an expiry.

The token is shown once, immediately after you create it. If you lose it, revoke it and make a new one.

Tokens are scoped to a single organization and can be revoked at any time from the same page.

## Connect Claude Code

```bash theme={"system"}
claude mcp add --transport http slipway https://mcp.slipway.sh/mcp \
  --header "Authorization: Bearer YOUR_TOKEN"
```

## Connect Cursor

Add the server to `.cursor/mcp.json` in the project, or to `~/.cursor/mcp.json` globally:

```json theme={"system"}
{
  "mcpServers": {
    "slipway": {
      "url": "https://mcp.slipway.sh/mcp",
      "headers": {
        "Authorization": "Bearer YOUR_TOKEN"
      }
    }
  }
}
```

## Connect Claude Desktop

Add an HTTP MCP server with the same URL and an `Authorization: Bearer YOUR_TOKEN` header. The same shape works for any MCP client that supports HTTP servers with custom headers.

## Roles

A token's role caps what its agent can do. Each tool requires at least the role shown.

| Role | Can do |
| - | - |
| `viewer` | Read projects, services, deployments, logs, repositories, config names and usage. |
| `developer` | Everything a viewer can, plus create projects and databases, install marketplace apps, add and remove services, deploy, roll back, cancel, edit specs, run commands in a container, and tear down. |
| `admin` | Everything, plus project and service settings, writing variables and secrets, edge settings, managed databases, object storage, and the escalated actions noted below. |

Give an agent the lowest role that lets it do its job. An agent that only inspects builds needs `viewer`. For a coding agent, `developer` is the usual choice and the default.

## Renamed and merged tools

The tool surface was reorganized around workspace / project / service. If you have prompts, scripts or saved instructions that name the old tools, this is the mapping:

| Old tool | Now |
| - | - |
| `lookup_repo` | Merged into `list_repos` — pass a `repository` name for the detailed answer. |
| `get_component_spec` | Merged into `get_project` — pass `include_specs`. |
| `check_capacity` | Merged into `get_usage`. |
| `deploy_project`, `deploy_component` | One `deploy` tool — pass a `service` to deploy just one. |
| `wait_for_project`, `wait_for_deployment` | One `wait_for_deploy` tool — takes a project id or a deployment id. |
| `add_component` | `add_service` (now `developer`). |
| `remove_component` | `remove_service` (now `developer`). |
| `teardown_project` | Same name, now `developer` rather than `admin`. |

## The tools

Every tool, with the minimum role each requires. The full reference, grouped and with each tool's arguments, is at [slipway.sh/agents/tools](https://slipway.sh/agents/tools).

### Discovery

| Tool | What it does | Role |
| - | - | - |
| `list_repos` | The repositories slipway knows about, with where each is deployed. Pass a repository name for that one in detail. | viewer |
| `list_projects` | Projects with their status and service count. | viewer |
| `get_project` | One project in full: settings, services with runtime state and URLs, live previews — optionally each repository's `slipway.yaml`. | viewer |
| `get_service` | One service in full: spec, compute, scaling, alerts, sleep, recent deployments, and every applicable settings section. | viewer |
| `get_usage` | Plan and usage against caps, plus whether another deployment can start right now. | viewer |
| `list_templates` | The one-click marketplace catalog, with what each app attaches to. | viewer |

### Create

| Tool | What it does | Role |
| - | - | - |
| `create_project` | Create a project from a repository and deploy it. | developer |
| `create_database` | A managed Postgres or Redis, in a new project or beside an existing service. | developer |
| `install_template` | Install a marketplace app wired to a database you already run, or one provisioned for it. | developer |

### Compose

| Tool | What it does | Role |
| - | - | - |
| `add_service` | Attach a repository to an existing project — every service its `slipway.yaml` declares joins the project. | developer |
| `remove_service` | Remove a service and tear down its workloads. Siblings keep running. | developer |

### Deploy and watch

| Tool | What it does | Role |
| - | - | - |
| `deploy` | Deploy the whole project, or just one service, at the head of its tracked branch. | developer |
| `wait_for_deploy` | Block until a project or one deployment finishes, then return status and public URLs. | viewer |
| `redeploy_deployment` | Re-run a deployment at the same commit. | developer |
| `rollback_deployment` | Return a service to a previous deployment's images, with no rebuild. | developer |
| `cancel_deployment` | Cancel an in-flight deployment. | developer |
| `teardown_project` | Destroy a project and everything it runs. History is retained. | developer |

### Manage

| Tool | What it does | Role |
| - | - | - |
| `update_project_settings` | Project-level settings: name, expiry, labels, default domain, PR-preview policy, build machine. | admin |
| `update_service_settings` | How a service runs: compute size, replicas or autoscaling, usage alerts, auto-sleep, subdomain, auto-deploy. | admin |
| `service_action` | Restart, pause, start, wake, or sleep a running service. Wake is developer; `restart`, `pause`, `start` and `sleep` require admin. | developer |
| `update_spec` | Write a repository's `slipway.yaml` — add or remove services, edit ports, env, health checks, disks, build config. | developer |

### Configuration

| Tool | What it does | Role |
| - | - | - |
| `list_config` | A project's — or the whole workspace's — variables with values, and secrets by name only. | viewer |
| `set_variable` | Set, delete, or preview-override a plaintext variable at project or workspace scope. | admin |
| `set_secret` | Set, delete, or preview-override an encrypted secret. Write-only, since no tool returns a secret value. | admin |

### Platform

| Tool | What it does | Role |
| - | - | - |
| `manage_snapshots` | A service's disk snapshots: take, restore, delete, set the default, note. `set_schedule` and `delete_volume` require admin. | developer |
| `manage_custom_domains` | The workspace's custom domains. Listing is developer; `claim`, `verify`, `delete` and `set_cluster` require admin. | developer |
| `update_service_edge` | A service's edge settings: the sign-in wall and its access token, edge caching, inbound IP rules. | admin |
| `manage_database` | A managed database's credentials, external access, high availability, and connection pooling. | admin |
| `manage_object_storage` | A bucket service's objects, credentials, and public access. Uploads and downloads go through the S3 API, not MCP. | admin |

### Logs and exec

| Tool | What it does | Role |
| - | - | - |
| `get_deployment` | A deployment's status, phase, failure reason and public URLs. | viewer |
| `get_deployment_logs` | Build and runtime logs, optionally filtered to one service. | viewer |
| `exec_in_service` | Run a command in a running container, capturing stdout, stderr and the exit code. | developer |

Saving a variable or secret does not restart anything: deploy afterwards for the change to reach the running pods. Both tools say so in their response.

`get_deployment_logs` is clamped by your plan's history window, the same as the console. See [Plans](/plans).

For a worked end-to-end session, see [How to let a coding agent deploy and test its own code](https://slipway.sh/blog/let-a-coding-agent-deploy-and-test-its-own-code).

## Security

* Tokens are stored hashed. The plaintext exists only at create time.
* Every tool is scoped to the token's organization, so an agent cannot reach another organization's data.
* `exec_in_service` runs arbitrary commands in your pods, and `set_secret` writes credentials. Keep tokens to the minimum role, use short expiries on shared machines, and revoke anything you are unsure about.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.