Why it matters
An agent that writes code needs somewhere real to run it. Local sandboxes lie: a different kernel, a different libc, half your environment, none of your data. The bug only shows up after merge. Slipway hands the agent a real, isolated, internet-reachable environment, so it can close the loop itself: make a change, deploy it, hit the URL, read the logs, and verify the fix before it calls the task done. No tunnels, no local setup, no waiting on a shared staging queue.What an agent can do
Over the MCP server, an agent drives the same lifecycle a human does:- Spin up an isolated environment from any branch or PR, and get a public URL back to hit.
- Inspect environments, deployments, and repositories, and read a repo’s resolved spec.
- Debug by streaming logs and running commands inside a running service (for example, run your tests).
- Check capacity before it brings things up, so it doesn’t hit your plan’s concurrency cap.
- Redeploy, cancel, and tear down the whole environment when the task is done.
- Configure variables and secrets, when its token has the role for it.
Set it up
Connect an agent
Create an org-scoped token, point your agent at the endpoint, and you’re driving environments in two steps.
https://<your-slipway-host>/mcp with an Authorization: Bearer header. For Claude Code:
Access is scoped
Every token carries a role, from viewer through admin, and each tool requires a minimum role. Give an agent the lowest role that lets it do its job: a read-only agent that just inspects builds needs onlyviewer, while one that writes secrets needs admin. Tokens are scoped to a single organization, stored hashed, and revocable at any time. See roles and security.