MCP tool の readOnlyHint、destructiveHint、openWorldHint をツール名の動詞だけで推定すると、命名規則外の読み取り処理や、同じ更新系でも公開範囲が異なる処理を誤分類しやすい。安全性 metadata は、descriptor、handler、呼び出し先の API client まで追い、実際に何を読み、作成し、上書きし、削除し、公開するかを一次情報にして決める。

判定の要点

• read-only は結果取得や計算だけで、ログ記録やジョブ開始を含め状態を一切変えない場合に限定する。
• destructive は削除だけでなく、既存値の全置換、取り消し手段のない状態遷移、不可逆な送信も対象にする。
• open-world は別サービスへの送信だけでなく、同一製品内で公開ページや公開コンテンツを作成・更新・非公開化できる場合も対象にする。

命名規則による共通判定は初期値として使えても、最終判定にはしない。たとえば find という動詞のツールが実装上は読み取り専用の検索である一方、内部データ管理に見える作成ツールが公開フラグを持つことがある。名前からの推測だけでは両方を見落とす。

検証手順

公開される登録ツール一覧を基準に全ツールを列挙し、各実装の副作用から期待する3 hintを表にする。サーバーが返す実際の annotation と提出用metadataを機械的に突合し、ツール数、過不足、3 hintの差分がゼロであることを確認する。新規ツール追加時も同じ一覧テストへ必ず含めると、例外判定の追加漏れと提出ファイルの転記ミスを同時に検出できる。

既存コードに一律値や名前ベース判定がある場合は、提出ファイルだけを直さない。サーバーdescriptorを修正し、その登録結果から提出metadataを作ることで、再scanや次回申請でも同じ不一致が再発しないようにする。