MCP サーバーでローカルファイル由来の取り込み機能を設計するとき、AI クライアント自身がそのファイルを読めるなら、サーバー側にローカルファイル読み取り tool を持たせず、skill や手順書でクライアントに読ませる選択肢を優先する。

判断基準

• サーバーの責務は、処理済み状態の取得、候補や成果物の登録、ポリシー更新など、API-backed な状態管理に寄せる。
• ローカルファイルの探索、必要部分の抜粋、ユーザー確認は、ローカルファイルアクセス権を持つ AI クライアント側の手順にする。
• Remote と local の両方の接続形態を提供する場合、接続形態ごとにツールセットや保存場所を分けず、永続状態は共通 API に集約する。
• 読み取り対象が端末上のログや transcript なら、MCP サーバーが読む tool を残すより、クライアントの明示的なファイルアクセスとユーザーへの報告に寄せた方が権限境界が明確になる。

避けるべき設計

• local CLI mode にだけファイル読み取り tool を残し、remote mode と説明・挙動が分岐する設計。
• local cache と remote API storage を同期する設計。状態分岐や競合を増やし、ユーザーに cache の存在を意識させやすい。
• 互換性のために古い cache/status tool を残す設計。運用の正本が曖昧になる。

検証観点

実装後は tools/list、skill、rules、docs を横断検索し、サーバーがローカルファイルを読む前提の文言や tool が残っていないことを確認する。あわせて、未処理判定と処理済み登録が API-backed な tool で完結することをテストする。