DifyコミュニティがMCPのユニオン型修正を提案、正当な配列引数が文字列に変換される可能性

Difyコミュニティは10月16日、MCPツールの相互運用性に関する修正を提案した。引数が複数のJSON型を許容するとき、フレームワークがそれを単一の型に簡略化し、実行時に正当な入力を書き換える可能性があるという。報告者はDockerでセルフホストしたDify 1.16.1を使用し、当時のメインブランチでも同じ問題があったと述べている。現時点の根拠は公開された再現手順と修正提案であり、影響範囲はメンテナーによる確認を待っている。issueの記録

再現例では、Home Assistant 2026.9に組み込まれたMCPサービスに接続する。そのGetLiveContextツールでは、domainに文字列または文字列配列を指定できる。しかし、モデルが{"domain":["light"]}を渡すと、Difyが送信する値は文字列"['light']"に変わり、サービスは該当するドメインのエンティティが見つからないと応答する。報告者によると、サービスを直接呼び出せば、文字列でも配列でも成功する。再現手順 Home Assistantの公式ドキュメントでも、このMCP統合によってエージェントが現在の状態を取得し、ツールを呼び出せることが確認されている。そのため、引数の受け渡しに誤りがあると、エージェントが環境情報を取得する能力に影響する。公式ドキュメント

提案の分析によると、問題は2段階にまたがる。スキーマ変換では、ユニオン型の最初の非null分岐だけが選ばれ、モデルに不完全な引数定義が提示される。実行時には選ばれた型に従って値が強制変換され、配列にstr()が適用される。技術的には、モデルが元の定義に適合する引数を生成しても、中間フレームワークがその意味を変えてしまう可能性がある。デバッグでは、ツールに実際に送信された値を照合する必要がある。修正分析

PR #44182は、多型の引数について元のスキーマを保持し、こうしたMCP引数をそのまま渡してサービス側で検証することを提案している。単一型の引数には従来の変換を適用する。作成者は、3種類のユニオン型表現、2通りの分岐順序、文字列と配列の入力を網羅するテストを追加し、関連テスト991件が通過したと報告した。これは提案者による検証結果であり、確認時点でPRはレビュー待ちだった。提案とテスト

エンジニアリングチームは、マージとリリースの状況を注視し、自社の多型引数をテストする必要がある。単一ドメインの検索では、報告内で検証済みの文字列形式を一時的な回避策として使えるが、複数ドメインを配列で呼び出す用途の代わりにはならない。また、ほかの正当な入力の挙動を変えるおそれがあるため、すべての引数を配列型に変更するのも避けるべきだ。制約の説明