Safe DML

DML 采用比普通查询更严格的执行流程，因为系统必须确保最终提交的修改与用户实际批准的内容完全一致。

UPDATE 与 DELETE

1. 编译数据修改

   在请求用户批准之前，先解析、验证并授权这条 SQL，再把它编译为可执行计划。

2. 预览目标行

   打开预览事务，在不执行修改的情况下读取当前满足条件的目标行。

3. 创建一次性批准信息

   把批准挑战绑定到已验证的执行计划、策略版本、目标行数和目标行集指纹。

4. 通过 MCP Elicitation 请求用户批准

   发送 elicitation/create，要求 MCP 客户端通过表单明确取得用户批准。

5. 消费已批准的挑战

   用户接受后验证并消费这次性挑战，避免它被重复使用为通用权限凭证。

6. 在提交事务中重新查询

   再次读取目标行，并将当前行集指纹和行数与批准时的预览结果进行比较。

7. 只有全部一致才提交

   只有执行计划、策略、批准挑战、行数和目标行集都没有变化时，才执行用户批准的那项数据修改。

INSERT VALUES

INSERT ... VALUES 在修改前不存在一组“已经匹配的目标行”。因此审批协议不会绑定行集预览，而是绑定不可变的插入数据和已经验证的执行计划。

Elicitation 是必需条件

execute_dml_sql 和已发布的 DML Custom Tools 要求 MCP 客户端支持 form Elicitation。无法完成审批交互的客户端不能使用这些数据修改路径。

这与普通 UI 确认弹窗不同。批准挑战是服务器端数据修改协议的一部分，并且会在真正执行前再次验证。

相关文档