MCP Fusion 5.0.10: 記述のスリム化、throw されたエラーの復元

2026年9月17日リリースの 5.0.10 はメンテナンスリリースで、コード変更はすべて @mcpfusion/core 内部にある。リリースノートでは、残り15のワークスペースパッケージが何も触れられずにクリーンにビルドするのを確認できる(リリースノート · GitHub の MCP Fusion)。リリースの中身は P2 欠陥2件と潜在的なクラッシュ1件。3つとも重要、そして3つとも、言語モデルが立っている場所からしか見えない。

Bug 152:サマリーが 1 + N 回言われた件

toolExposition: 'grouped' では、ツールは N 個のフラットツールではなく、識別 action フィールドを持つ1つの名前を露出し、その記述は階層化される。レイヤー1はツールサマリー、モジュール/アクション一覧、ディスパッチ指示で始まり、レイヤー2はアクションごとに1行(markdown では Workflow: ブロック、TOON では desc: 列)。builder が .description() を持ちアクション個別にない場合、ツールサマリーは各アクションへ継承される(これは正しい。フラット露出はこのフォールバックに依存しているからだ)、そして5.0.9ではレイヤー2でアクションごとに1回ずつ繰り返されていた。モデルはサマリーを最初の1回以降、一切新情報なしに 1 + N 回見ることになる。冗長な記述はプロンプトを肥大させるだけではない、モデルが本来重み付けるべきシグナルを薄める。修正は、ツールサマリーと等しい記述を「アクション固有ではない」と扱いレイヤー2から省略する。アクション固有の記述はそのまま通す。

Bug 153:バリデータが拒否するはずだったヒント

「どのフィールドを渡すべきか」のヒント(Requires: 行)はアクション単位のスキーマのみから計算されていた。ツールレベルの commonSchema を絶対に見ず、omitCommonFields も適用していなかった。実務での結果はこうだった:.commonSchema() で宣言された必須の workspace_id は inputSchema.required には出るが、ヒントには出なかった。モデルはフィールドを省略し、検証が呼び出しを拒否し、エージェントがエラーを読み、欠落フィールドを付けて再呼び出し、成功。不要なセルフヒーリング往復が1回、共通フィールドを共有するすべてのグループ化呼び出しで発生した。修正で、getActionRequiredFields() は buildValidationSchema() が強制する同じマージ済みスキーマ(omitCommonFields 込み)を反映する、ヒントとバリデータが食い違う構造的根絶だ。

getActionRequiredFields / generateDescription / generateToonDescription に加わった commonSchema パラメータは任意なので、変更はワイヤー上に見えるが壊さない:API・型・スキーマ形状の不変、フラット露出の出力はバイト単位で不変、グループ化記述は縮むだけ。運用上の唯一の影響:継承記述を持っていたグループ化サーバーの mcpfusion.lock の integrityDigest が変わる、lockfile を再生成すること。

意味を飲み込んでいた catch

フレームワークが教えるイディオムは、失敗を単に throw するのではなく分類すること:ハンドラーとミドルウェアは、分類済みレスポンスを throw できる(throw toolError('NOT_FOUND', {...})、throw error('Unauthorized'))、返す代わりにだ。runChain() の catch ブロックは生の ToolResponse しか認識しなかったため、throw されたレスポンスはエラーコードもリカバリーガイドも警告/エラーの深刻さも失い、汎用 INTERNAL_ERROR として再ラップされて出ていた。

「失われた」以上の深刻さを帯びていたのが2つ。throw された HandoffResponse はツールレスポンスのブランドを持つが content 配列を持たず、isToolResponse() のみによるチェックは content をインデックスするコードへフォワード、フェデレート・ハンドオフ経路でのクラッシュ。throw された ResponseBuilder は構築される代わりに破棄され、組み合わされた全コンテンツブロックを失う。catch は今や postProcessResult() の順序をミラーし(isHandoffResponse → isResponseBuilder → isToolResponse)、本当に予期せぬ残り物だけが INTERNAL_ERROR になる。

モデル境界で最も効いてくる点は、このフォールバックが失敗が一時的だと主張しなくなったこと。恒久的な失敗(不正な id、資源の不在、認証の有効期限切れ)は、さもなければ同一パラメータのリトライループへエージェントを送り込んでいたはずだ。新しいエラーは [tool/action] の由来を報告し、盲目的なリトライではなくメッセージの検査を促す、エスカレートするエージェントと、タイムアウトまで同じ呼び出しを叩き続けるエージェントの差だ。

固定され、出荷されたもの

• DescriptionInheritance-bug152-153.test.ts(18ケース)と ThrownResponseRecovery.test.ts(12ケース)が、リリースノートに基づき両方の動作を固定。
• core スイート全体:5,243 合格 / 0 失敗;tsc --noEmit クリーン;全16のワークスペースパッケージがビルド。

インストールは1行:

npm install @mcpfusion/core@5.0.10

グループ化露出を運用しているなら、mcpfusion.lock を再生成して integrityDigest を(小さくなった)記述に合わせること以外、ハンドラーコードで変わるものはない、分類済みレスポンスを throw するイディオムが、ドキュメントがずっと約束してきた通りになる。