Worker management tooling gaps: no workers_delete despite can_delete:true, no pause/disable, workers_versions empty after edits, workers_write_file silently drops omitted files

[federicodeponte]

Summary

Four related gaps/bugs in worker management via MCP:

1. No workers_delete tool — the worker data model reports can_delete: true, but no MCP tool exists to actually delete a worker.
2. No pause/disable — workers_update rejects both enabled and trigger_type: disabled as a way to pause a worker without deleting it.
3. workers_versions returns empty after edits — after editing a worker (e.g. via workers_write_file), workers_versions shows no version history, so there's no rollback/diff path.
4. workers_write_file silently full-replaces the file set — calling it with a partial file list drops files that were not included in the call, rather than merging/patching. Verified: a worker that needed requirements.txt lost that file after a partial edit that didn't re-include it.

Repro

1. workers_get on any worker → model includes can_delete: true; search tool catalog for a delete tool → none exists.
2. workers_update with enabled: false or trigger_type: "disabled" → rejected.
3. Edit a worker via workers_write_file, then call workers_versions → empty.
4. workers_write_file with only some files (omitting requirements.txt) on a worker that had requirements.txt → after the call, requirements.txt is gone from the worker.

Expected

• A workers_delete tool matching the can_delete field.
• A way to pause/disable a worker without deleting it.
• workers_versions reflects real edit history.
• workers_write_file merges/patches by default (or has an explicit replace: true vs. patch-by-default flag), never silently dropping files not mentioned in the call.

Actual

All four gaps present; #4 is the most dangerous — it's silent data loss (a working worker can be broken by an edit that never touched the missing file).

Severity

P1 (bumping #4 close to P0-adjacent in impact) — silent, unprompted data loss on a common edit workflow (workers_write_file partial update) is a correctness/trust issue, even though it's not a crash.

Filed from 2026-07-17 WorkerOS launch-readiness audit.