DML 採用比一般查詢更嚴格的執行流程，因為系統必須確保最後認可的修改與使用者實際核准的內容完全一致。
01 編譯
02 預覽
03 核准
04 重新驗證
05 認可
UPDATE 與 DELETE
- 編譯資料修改
在要求使用者核准前，先解析、驗證並授權這段 SQL，再把它編譯成可執行計畫。
- 預覽目標資料列
開啟預覽交易，在不執行修改的情況下讀取目前符合條件的目標資料列。
- 建立一次性核准資訊
把核准挑戰值綁定到已驗證的執行計畫、政策版本、目標資料列數與資料列集合指紋。
- 透過 MCP Elicitation 要求使用者核准
傳送
elicitation/create，要求 MCP 用戶端透過表單明確取得使用者核准。 - 用完已核准的挑戰值
使用者接受後驗證並消耗這次性挑戰值，避免它被重複利用成通用權限憑證。
- 在認可交易中重新查詢
再次讀取目標資料列，並把目前的集合指紋與資料列數和核准時的預覽結果比較。
- 只有全部一致才認可
只有執行計畫、政策、核准挑戰值、資料列數與目標資料列集合都沒有變化時，才執行使用者核准的那項資料修改。
INSERT VALUES
INSERT ... VALUES 在修改前不存在一組「已經符合條件的目標資料列」。因此核准協定不會綁定資料列集合預覽，而是綁定不可變的插入資料與已驗證的執行計畫。
Elicitation 是必要條件
execute_dml_sql 與已發布的 DML Custom Tools 要求 MCP 用戶端支援 form Elicitation。無法完成核准互動的用戶端不能使用這些資料修改流程。
這與一般 UI 確認視窗不同。核准挑戰值是伺服器端資料修改協定的一部分，而且會在真正執行前再次驗證。