# Ship

> Twenty-one MCP tools cover ZopDay deployments: projects, environments, services, builds and rollbacks. Thirteen of them read, and eight sit at tier 2 (reversible), covering deploys, redeploys, rollbacks, environment variables and auto-deploy settings. No deployment tool ever reaches tier 3, the irreversible tier.

Source: https://zop.dev/integrations/mcp-server/tools/ship
Updated: 2026-08-20

---

## Common questions

### How does an assistant know a deploy actually succeeded?

By pairing deploy_service with wait_for_deploy. deploy_service returns once the deploy is accepted, not once it is live, so an assistant that reports success there is reporting the wrong thing. wait_for_deploy blocks until it finishes and yields a real outcome.

### Can an assistant read back my environment variables?

No. set_service_env_vars writes configuration and there is no tool that returns secret values, consistent with no MCP tool at any tier exposing credentials.

### Why is deploying only tier 2 when it changes what is running?

Because all eight write tools here are reversible: a deploy can be rolled back with rollback_service, an env var can be set again, auto-deploy can be switched off. No deployment tool reaches tier 3.

## What an assistant can see

Thirteen read tools cover the deployment estate: `list_projects`, `list_environments`,
`list_services`, `list_deploys`, `get_service_overview`, `get_service_config`,
`get_service_url`, `get_project_stats`, `list_repositories`, `list_branches`,
`list_integrations`, `connect_github`, and `wait_for_deploy`.

`wait_for_deploy` is worth calling out: it blocks until a deploy finishes, so an assistant can
deploy and then report the actual outcome rather than "deployment started".

## What it can change, at tier 2

`deploy_service`, `redeploy_service`, `rollback_service`, `create_project`, `create_environment`,
`set_service_env_vars`, `set_auto_deploy`, `update_service_config`.

All tier 2, and all reversible. A deploy can be rolled back, an env var can be set again, auto-deploy
can be switched off. That is why shipping sits a tier below `operate`'s irreversible group even
though it changes what is running.

## Rollback is a first-class tool

`rollback_service` exists as its own tool rather than as a redeploy of an older build, which
means an assistant asked to "roll back checkout" has an unambiguous action to take. Paired with
`wait_for_deploy`, it can confirm the rollback landed before saying so.

## Env vars are set, never read back

`set_service_env_vars` writes configuration. There is no corresponding tool that returns secret
values, consistent with the platform-wide rule that no MCP tool at any tier exposes
credentials.

## Deploys are asynchronous

`deploy_service` returns once the deploy is accepted, not once it is live. An assistant that
reports success at that point is reporting the wrong thing. Pairing it with `wait_for_deploy`
is what turns "I started a deploy" into "the deploy succeeded", or into an accurate failure.