MCPのreadOnlyHint: 副作用と情報開示は別に確認
readOnlyHintは環境を変更しないというtool側の宣言です。data開示、外部request、課金、audit記録、別toolとの組合せによる作用を防ぐ強制境界ではありません。
Read in Englishstable MCP schemaのreadOnlyHint: trueは、そのtoolが環境を変更しないという宣言です。同じschemaは、すべてのtool annotationをhintと呼び、信頼できないserverから来た値だけでtool利用を判断しないよう求めています。MCP公式Blogはさらに、annotationはconfirmationやpolicyの材料にはなるものの、enforcement、sandbox、prompt injection耐性を提供しないと説明しています。
したがって「read-only」は「security上の作用がない」より狭い概念です。読取callでも、private recordをmodelへ開示し、queryを外部serviceへ送り、quotaを消費し、provider audit logを増やし、cacheを作り、後続writeへ影響するuntrusted contentを返す可能性があります。これらが仕様どおりの正常動作である場合もあります。問題は、annotationだけから「何も起きない」と判断することです。
一回のlookupで生じる複数の作用
find_customerがreadOnlyHint: trueで、email addressからCRM profileを返すとします。CRM recordを変更しなくても、requestはいくつかの境界を越えます。
| 作用 | read-only宣言と両立するか | 別に必要な制御 |
|---|---|---|
| private customer recordを返す | はい | field単位のaccessとoutput最小化 |
| email addressをremote CRMへ送る | はい | destinationとdata transferのpolicy |
| access logやbilling記録を作る | 多くの場合は両立 | retention、audit、cost確認 |
| local cacheやtelemetryへ書く | 「環境」の定義に依存 | runtime観測とfilesystem制限 |
| 返却文から別のemail toolを呼ぶ | lookup自体はread-onlyの可能性 | cross-tool承認とdata flow制御 |
| CRM recordを削除・更新する | いいえ | server-side認可とruntime試験 |
この表は、annotationが表す変更性と、privacy、外部送信、tool組合せを分離しています。openWorldHintは外部entityとの関係を補足できますが、これもhintです。どちらのfieldも、単独でnetwork accessを許可したり、data transfer承認を省略したりする根拠にはなりません。
信頼できるread pathの確認記録
完全なtool definitionを取得し、server運営者、artifactの配布経路、稼働versionを確認します。readOnlyHint宣言を実装契約とprovider API methodへ照合します。説明文がread-onlyでも、server credentialからupdate/delete scopeを外します。環境が対応する場合は、runtimeのfilesystem writeと外部接続先も制限します。
専用accountとsynthetic recordで一回のcallを実行し、前後のprovider audit log、network destination、local file change、queue activity、課金を観測します。繰返しが安全と確認できる場合だけ同じcallを再実行します。readOnlyHintはidempotenceを意味せず、別のhintが用意されているためです。retryやfallbackが異なる経路を使う可能性に備え、error caseも確認します。これらは推奨する確認操作であり、今回serverに対して実行した試験ではありません。
利用者承認には、record種別、要求field、account、destinationを表示します。「read-only検索」というlabelだけではdata開示の判断が抜けます。返却内容から後続のwrite toolを呼ぶ場合は、lookup時の承認を流用せず、送信時点で新しい確認を置きます。
stable要件、draft提案、限界
2026年9月22日に確認した規範的な根拠は、2026年7月28日版のstable MCP仕様とversioned schemaです。2026年3月の公式Blogには、追加annotationのSEPがDraftまたはProposalとして示されています。将来のclientでtrustやsensitivityを表す助けになる可能性はありますが、stable要件や現在利用できる強制制御として扱っていません。現行のreadOnlyHintは説明metadataです。
今回のreviewで確認したのはannotationの意味と検証方法です。特定serverが誤表示しているという指摘、すべてのreadで表中の作用が起きるという主張、または一度のclean testが将来の全callを保証するという主張ではありません。