Operate
What are the Operate tools for?
The `operate` MCP tools act on infrastructure: schedules, overrides, resource groups, provisioning jobs, Kubernetes workloads and bulk start and stop. Reads need no write tier. Group and policy edits sit at tier 2, while `start_resource`, `bulk_start_resources` and `bulk_stop_resources` sit at tier 3, which an org admin must enable explicitly.
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
Twenty-four of these tools only read, among them list_schedules, get_schedule,
list_overrides, get_resource_group, list_provisioning_jobs, get_state_history,
list_events and get_infrastructure. They work at the default read-only setting.
The other thirty-one change something, and they sit at two write tiers. Fourteen are
tier 2, reversible: they edit groupings and policies, for example create_resource_group,
update_resource_group, add_resource_to_group, attach_group_to_schedule,
set_group_start_stop_order and most autoscaler policy edits. Seventeen are tier 3,
irreversible and act on infrastructure directly, including start_resource, stop_resource,
bulk_start_resources, bulk_stop_resources, 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.
Write access is opt-in per organisation. The org’s tier starts at none, an org admin picks the highest tier assistants may use, and a global switch, off by default, keeps every write inert until it is turned on. Enabling tier 3 is a deliberate 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
Most mutating tools here have a read counterpart, and the ordering matters.
get_autoscaler_policy before update_autoscaler_policy, get_resource_group before attaching
it to a schedule, 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?
Seventeen that act on infrastructure directly, among them start_resource, stop_resource, bulk_start_resources, bulk_stop_resources, delete_k8s_resource, restart_k8s_workload, update_k8s_manifest, delete_service, delete_project and the provisioning-job writes. Fourteen group and policy edits need tier 2, and the 24 read tools 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.