GitHub Repo
Difyコミュニティ、MCPのリソースリンクが破棄されると報告 ツールが正常に応答しても結果が空になる可能性
DifyのMCP連携でresource_linkが処理されず、リソースリンクのみを返すツールでは空の観察結果が生じる可能性が報告された。リンクとメタデータを保持する修正案がコミュニティから提出されたが、まだマージされておらず、正式版への影響範囲は未確認だ。

Difyコミュニティは10月3日、MCP互換性に関する問題を報告した。ツールがプロトコルに準拠したリソースリンクを返しても、エージェントが読めるツールの観察結果に渡る前に内容が破棄される可能性があるという。報告はmainブランチのあるソースコードスナップショットを対象に、模擬したリモート応答を使って再現されたものだ。これをもって、すべての正式版やクラウド環境が影響を受けるとは判断できない。問題報告
発生条件は限定的だ。ツールに出力スキーマがなく、structuredContentも提供されず、contentにresource_linkだけが含まれる場合に起きる。報告者によると、プロトコルモデルはResourceLinkを認識できる一方、MCPTool._invokeのコンテンツ振り分け処理には対応する処理がなく、サポート対象外のコンテンツとして記録されてスキップされる。リンクだけの場合はメッセージが生成されず、テキストとリンクが混在する場合はテキストが残り、リンクが消える。再現の詳細
MCPのツール仕様では、サーバーはリソースURIを返し、クライアントが後からその内容を取得または購読できる。URIには名前、説明、MIMEタイプを付けられる。こうしたリンクがresources/listに含まれるとも限らない。レポート生成やファイル検索などのワークフローで、ツールがリンクだけを渡す場合、そのリンクが失われると後続のデータ取得経路が途切れる可能性がある。これはプロトコルと報告内容から導かれるエンジニアリング上の影響であり、公表済みの本番障害ではない。MCPツール仕様
同日に提出された修正PRは、既存のJSONメッセージ経路を使い、URI、名前、説明、MIMEタイプ、annotations、_metaを保持する。リソースを自動取得することも、新たな依存パッケージを追加することもない。作者によると、リンクのみの場合とテキスト・リンク混在の場合を対象にした回帰テストは、元のベースラインでは失敗し、修正適用後は通過した。関連する単体テストは計14件通過したという。ただし、これらは提出者による検証結果だ。確認時点で、PRはまだレビューとマージを待っている。修正提案
Difyを使ってMCPを連携しているエンジニアリングチームは、リンクのみの応答と、テキストにリンクを添えた応答の両方をテストし、URIがエージェントの観察結果に完全な形で入るか確認できる。今後は上流でのレビュー、リリースバージョン、実際のリモートサーバーでのテストを追跡するとよい。リンクの保持はデータ受け渡しの一段階にすぎず、内容を読み取るかどうかはアプリケーションのフローで決まる。