Ship
What are the Ship tools for?
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.
Tools
| Tool | Access | Purpose |
|---|---|---|
connect_github | read | Start connecting a GitHub account so ZopDay can deploy from its repositories |
get_project_stats | read | Get rollup counts (services, environments, health) for one or more projects in a single call |
get_service_config | read | Get the runtime configuration of a service: port, replicas, liveness probe path, rootPath, exposed hosts, CPU/memory resources, and the NAMES of its environment variables |
get_service_overview | read | Get everything about one service in a single call: its status and statusBucket, the current revision (number, stage, image, commit, who deployed it), recent deploys, the last deploy events, and its public URL if it has one |
get_service_url | read | Get the public URL a service is reachable at |
list_branches | read | List the branches of one git repository reachable through a connected git integration |
list_deploys | read | List a service's deploy history, newest first |
list_environments | read | List the environments in a project, each resolved to WHERE it actually runs |
list_integrations | read | List the org's connected integrations (git, ITSM) |
list_projects | read | List the ZopDay projects in this organisation |
list_repositories | read | List the git repositories ZopDay can deploy from, through a connected git integration |
list_services | read | List the services deployed in one environment |
wait_for_deploy | read | Wait for a service's in-flight deploy to finish, then report the outcome |
create_environment | write | Create an environment inside a project |
create_project | write | Create a project |
deploy_service | write | Create a new service in an environment and ship its first deploy |
redeploy_service | write | Ship an existing service again as a new deploy |
rollback_service | write | Roll a service back to an earlier deploy |
set_auto_deploy | write | Turn auto-deploy on or off for a service |
set_service_env_vars | write | Set or remove a service's environment variables AND roll them out |
update_service_config | write | Change a service's runtime settings: port, replicas, liveness probe path, root path |
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.
Ship tools: 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.