# Operate

> 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.

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

---

## 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.

## 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.