読み取り中心の MCP サーバーにレコード作成を担わせるとき、汎用の create_record を最初に作るのは筋が悪い。難所は MCP プロトコルではなく、動的な項目設定を安全に既存の作成処理へ変換する層にある。

推奨する形

オブジェクト別に3段で切る。

1. describe_<object>_create — 作成可能項目・必須条件・選択肢・書込可否を返す
2. validate_<object>_create — 入力を検証し、登録内容をプレビューする
3. create_<object> — 確定実行

既存のサービス層には必須項目・項目権限・集計・検索索引の更新などの作成ロジックがすでにあるので、MCP 側はそれを呼ぶ薄い変換層にする。

見落としやすい追加課題

• 検索用の設定取得 API はそのまま作成に使えない。検索に必要な情報しか返していなく、必須条件や書込可否を含まない。
• 作成権限の検査がコントローラ層のデコレータなどにある場合、サービスを直接呼ぶ経路では検査が抜ける。補強が必要。
• トランザクション境界と、リトライでの二重作成を防ぐ冪等キーを決める。
• 実行前プレビューと確認を入れる。

進め方

関連先・サブタイプ・公開範囲・外部連携など固有条件の多いオブジェクトは、汎用ツール1本ではなくオブジェクト別ツールの方が安全。主要オブジェクトから段階的に増やす。