Difyコミュニティ、ネストされたスキーマで配列が文字列化される問題に対するMCP型修正を提案

Difyコミュニティは10月19日、MCPツールの引数型判定にネスト構造の処理上の抜けがあると報告した。文字列または配列を許可するanyOfが、さらにallOfで包まれている場合、正当な配列が呼び出し前に文字列へ変換される可能性がある。報告はセルフホスト環境のソースコード版を対象とし、メインブランチのコミット96202aaを明記して、スキーマと入力値を提示している。これだけでは、すべての正式リリースが影響を受けるとは判断できない。問題報告

再現例では、domainフィールドは単一の文字列または文字列の配列を許可している。入力["light", "cover"]に対し、変換器は引数をstringと判定し、input_schemaも保持しなかった。その結果、後続の呼び出し処理はJSON配列ではなく、Pythonリストの文字列表現を送信した。つまり、上流で元のスキーマに適合する引数が生成されても、中間変換によってツールが実際に受け取るデータ型が変わる可能性がある。再現の詳細

このケースは、条件を組み合わせる意味に関わる。JSON Schemaの公式ドキュメントによると、anyOfは少なくとも1つのサブスキーマに適合することを意味し、allOfはすべてに適合することを求める。そのため、修正では深い階層に複数の型があるかどうかを探すだけでは不十分で、条件の共通部分も扱う必要がある。そうしなければ、複数の型を受け入れるスキーマが別の条件でさらに制限されているケースでも、誤判定が起こりうる。JSON Schemaの組み合わせルール

同日提出された修正PR #44322は、ネストされた組み合わせ構造を走査し、allOf制約の共通部分を計算する方式に変更している。構造上、複数のJSON型が許される場合には、元の値を保持する。提案者によると、回帰テストでは2種類の分岐順序、スカラー値と配列、共通部分によって単一型に限定されるケースを対象とし、関連する単体テスト72件が成功した。これらは提案者が示した検証結果であり、正式リリースの保証ではない。修正提案

MCPツールを統合するエンジニアにとって、この事例はリモート側が実際に受け取る引数まで検証する必要性を示している。利用するツールのスキーマに応じて、ネストされた組み合わせや配列入力を確認し、送信前後でJSONの型を比較するとよい。確認時点で、この提案はコードオーナーのレビュー待ちだった。今後はマージ状況、リリース版、より多くのスキーマ構成に対するテストを追跡する必要があり、現行の修正をすべてのJSON Schemaケースに対応するものと見なすことはできない。