Operate
What are the Operate tools for?
Twenty-six MCP tools for acting on infrastructure: schedules, overrides, resource groups, provisioning jobs and Kubernetes workloads. Fifteen are read-only; the eleven that mutate sit at tier 3, the irreversible tier, which an org admin must explicitly enable before any assistant can call them.
Tools
| Tool | Access | Purpose |
|---|---|---|
get_action | read | Get details of a specific start/stop action execution |
get_infrastructure | read | Get one cluster or VM pool by id, as returned by list_infrastructure |
get_latest_bulk_action | read | Get the most recent bulk start/stop action for a resource group |
get_override | read | Get details of a specific schedule override |
get_provisioning_job_overview | read | Get everything about one provisioning job in a single call: its status, every step with that step's own status and timings, the actionable failure detail when a step failed (errorCategory, errorFixHint, errorRetryable, errorConsoleUrl), and the databases the job created |
get_resource_group | read | Get resource group details including member resources |
get_schedule | read | Get full schedule details including weekly time windows and assigned resource groups |
get_state_history | read | List resource start/stop state transitions |
list_events | read | List scheduler execution events showing what the scheduler did and when |
list_infrastructure | read | List all the infrastructure in this organisation as ONE list — the same board the Infrastructure page shows |
list_overrides | read | List schedule overrides — temporary force-on/off rules that take priority over schedules |
list_provisioning_jobs | read | List provisioning jobs — the record of ZopNight building, changing or tearing down infrastructure |
list_resource_groups | read | List resource groups — logical groupings of resources assigned to schedules |
list_schedules | read | List start/stop schedules that control when resources run |
list_workflows | read | List the remediation workflows that are PARKED WAITING FOR YOU to act |
cancel_workflow | write | Cancel a running remediation workflow |
create_provisioning_job | write | Provision NEW cloud infrastructure — a cluster, a VM pool or a managed database |
delete_k8s_resource | write | Delete a live Kubernetes object |
delete_project | write | Delete a Project |
delete_provisioning_job | write | Tear down provisioned cloud infrastructure — the reversal of create_provisioning_job |
delete_service | write | Delete a Service: uninstall it from the cluster and remove it from ZopDay |
restart_k8s_workload | write | Restart a Kubernetes workload's pods — a rolling restart |
retry_provisioning_job | write | Re-attempt a FAILED provisioning job |
start_resource | write | Start ONE stopped cloud resource right now |
stop_resource | write | Stop ONE cloud resource right now |
update_k8s_manifest | write | Replace a live Kubernetes object's spec |
The split that matters
Fifteen of these tools read: list_schedules, get_schedule, list_overrides,
get_resource_group, list_provisioning_jobs, get_state_history, list_events,
get_infrastructure. They work at the default read-only setting.
The other eleven change your infrastructure: start_resource, stop_resource,
delete_k8s_resource, restart_k8s_workload, update_k8s_manifest, delete_service,
delete_project, create_provisioning_job, delete_provisioning_job, retry_provisioning_job,
cancel_workflow.
Those eleven are tier 3, irreversible. That is the highest write tier, off by default, and enabling it is a deliberate org-admin decision rather than a side effect of turning MCP on.
What “irreversible” means here
Not “dangerous by reputation”. Irreversible in the literal sense that ZopNight cannot undo it for you. Stopping a resource is recoverable by starting it again; deleting a Kubernetes resource or a provisioning job is not. They share a tier because the recovery path is outside the platform, not because they are equally risky.
Guardrails that apply regardless of tier
Every mutating tool call is authorised exactly like the equivalent UI action, so a user’s own RBAC still applies. The write tier is a ceiling, not a bypass. Every call is audit-logged with its source, so MCP activity is distinguishable from UI and API activity after the fact.
Mutating tools accept idempotency keys, which matters more with assistants than with humans: a retried tool call after a timeout will not stop the same instance twice.
Reading before acting
Every mutating tool here has a read counterpart, and the ordering matters. get_schedule
before update_schedule, get_resource_group before attaching to it, get_state_history
before a stop. That way an assistant can state what it is about to change, and what the current
value is, rather than overwriting blind.
Operate tools: common questions
Which operate tools require tier 3?
The eleven that change infrastructure: start_resource, stop_resource, delete_k8s_resource, restart_k8s_workload, update_k8s_manifest, delete_service, delete_project, create_provisioning_job, delete_provisioning_job, retry_provisioning_job and cancel_workflow. The other fifteen read and work at the default setting.
Why is stopping a resource in the same tier as deleting a project?
Not because they carry equal risk. Stopping is recoverable by starting again; deleting a Kubernetes resource or a provisioning job is not recoverable by ZopNight at all. They share a tier because the recovery path sits outside the platform.
Will a retried call stop the same instance twice?
No. Mutating tools accept idempotency keys, which matters more with assistants than with humans, so a retry after a timeout is safe. Every call is also audit-logged with its source.