Safe DML

DML では通常のクエリ実行よりも厳格な手順を使います。人が承認した変更内容と、コミット直前に実行される内容が同一であることを保証するためです。

UPDATE と DELETE

1. データ変更をコンパイル

   承認を求める前に、要求された SQL を解析、検証、認可し、実行可能な形へコンパイルします。

2. 対象行を事前確認

   事前確認用のトランザクションを開き、変更を実行せず、現在条件に一致する行を読み取ります。

3. 1 回限りの承認情報を作成

   承認チャレンジに、検証済み実行計画、ポリシーのバージョン、対象行数、行集合のフィンガープリントを結び付けます。

4. MCP Elicitation で人に承認を求める

   elicitation/create を送信し、MCP クライアントからフォームによる明示的な承認を要求します。

5. 承認済みチャレンジを使い切る

   承認後に 1 回限りのチャレンジを検証して消費し、汎用的な権限トークンとして再利用できないようにします。

6. コミット用トランザクションで再取得

   対象行をもう一度読み取り、現在のフィンガープリントと行数を、承認時の事前確認結果と比較します。

7. すべて一致した場合だけコミット

   実行計画、ポリシー、チャレンジ、行数、対象行集合が変わっていない場合にだけ、承認済みのデータ変更を実行します。

INSERT VALUES

INSERT ... VALUES には、変更前から存在する「条件に一致した行集合」がありません。そのため承認時には、行集合の事前確認ではなく、変更不能な挿入データと、検証済みの実行計画を結び付けます。

Elicitation は必須です

execute_dml_sql と公開済みの DML Custom Tools を使うには、MCP クライアントが form Elicitation に対応している必要があります。承認操作を実行できないクライアントからは、これらのデータ変更経路を利用できません。

これは単なる UI の確認ダイアログとは異なります。承認チャレンジはサーバー側のデータ更新プロトコルの一部として扱われ、実行直前にも再検証されます。

関連ドキュメント