For MCP-server limitation closure where upstream API has no in-place u…
Decision
For MCP-server limitation closure where upstream API has no in-place update endpoint, implement the operation as DELETE-old + CREATE-new with these mandatory safety properties: (1) build/validate the replacement object BEFORE the destructive call, (2) surface old_id + new_id in the return payload because IDs change, (3) provide recovery_hint + captured_state on transport-level partial failure. Drop any parameter the underlying SDK silently ignores (don’t accept it on the MCP surface).
Rationale
Codex hard-gate found a validate-after-delete ordering bug pre-deploy (would have caused destructive data loss on invalid Weekly-without-week_days input), and a silent priority-drop bug (TSC create_extract_req XML builder doesn’t emit priority). Both root-causable to the same anti-pattern: assuming SDK does what its public surface suggests. The fix establishes a pattern for the next limitation closure: verify SDK XML/payload output, not just method signatures.
Alternatives Rejected
Outcome
Pending