Safety tiers

ray-mcp gates its tools into three permission tiers. The server is read-only by default; the write and destructive tiers are opt-in flags. A tool is only advertised when its tier is enabled — a disabled tool doesn't appear in tools/list at all.

Tier	Flag required	Tools
Read	(always on)	read tools — capabilities, list/get/events, the RayJob wedge
Write	--allow-mutations	write tools — create / update / scale / submit / deploy
Destructive	--allow-mutations and --allow-destructive	destructive tools — delete cluster / service

--allow-destructive on its own does nothing — the write tier must be enabled too. ray_capabilities reports the enabled tiers at runtime (enabledTiers).

Guardrails on writes

Beyond the tier gates, the write path carries several safety mechanisms (see design spec §8 Safety Model):

• Server-Side Apply with dry-run. Every write can be previewed with dryRun: true, and returns a field-level before/after diff so server defaults surface.
• Two-step confirm-fingerprint on destructive ops. Delete tools require a first call without confirm (which previews and returns a fingerprint), then a second call echoing that fingerprint. The fingerprint is derived from the target's identity, so it can't be replayed against a different or recreated object.
• The ray-mcp/protected annotation. A resource carrying this annotation is refused by the delete tools regardless of tier.
• force guard on serving RayServices. ray_service_delete refuses a service that appears to be serving traffic unless force: true is passed (stacked on top of the confirm-fingerprint, not instead of it).
• Writes never go through the Ray dashboard. All mutations flow through the guarded Kubernetes CRD path; the unauthenticated dashboard is never a write vector.

Transport is independent of tiers

The permission tiers are the same whether the server runs over stdio or HTTP. HTTP auth (see HTTP transport & auth) gates who can reach the listener; the tiers gate what any connected caller can do.