MCP Fusion 5.0.10: kleinere Beschreibungen, wiederhergestellte geworfene Fehler

Veröffentlicht am 17. September 2026 ist die 5.0.10 ein Wartungs-Release, und sämtliche Codeänderungen liegen innerhalb von @mcpfusion/core; die Release Notes bestätigen, dass die anderen 15 Workspace-Pakete weiter unangetastet sauber bauen (Release Notes · MCP Fusion auf GitHub). Zwei P2-Defekte und ein latenter Absturz machen das Release aus. Alle drei zählen, und alle drei lassen sich nur von dort beobachten, wo das Sprachmodell steht.

Bug 152: die Zusammenfassung, 1 + N Mal gesagt

Unter toolExposition: 'grouped' exponiert ein Tool einen einzelnen Namen mit einem diskriminierenden action-Feld statt N flacher Tools, und seine Beschreibung ist geschichtet. Ebene 1 beginnt mit der Tool-Zusammenfassung, der Modul/Aktions-Liste und der Dispatch-Anweisung; Ebene 2 führt je eine Zeile pro Aktion: der Workflow:-Block im Markdown, die desc:-Spalte in TOON. Hat ein Builder einen .description(), aber seine einzelnen Aktionen keinen, wird die Tool-Zusammenfassung in jede Aktion vererbt (korrekt, die flache Exposition stützt sich auf diesen Fallback), und sie wurde dann pro Aktion in Ebene 2 nachgespiegelt. Das Modell sah die Zusammenfassung 1 + N Mal, ohne nach dem ersten Mal neue Information. Eine redundante Beschreibung bläht nicht nur den Prompt auf; sie verwässert genau das Signal, das das Modell gewichten soll. Die Fix behandelt eine Beschreibung, die der Tool-Zusammenfassung gleich ist, als „nicht aktionsspezifisch“ und lässt sie aus Ebene 2 weg; aktionsspezifische Beschreibungen bleiben unangetastet.

Bug 153: der Hinweis, den der Validator abgelehnt hätte

Der Hinweis „welche Felder muss ich übergeben“, die Requires:-Zeile, wurde nur aus dem Schema pro Aktion berechnet. Er sah nie den Tool-commonSchema an und wandte omitCommonFields nicht an. Die praktische Folge: Ein über .commonSchema() deklariertes Pflicht-workspace_id erschien in inputSchema.required, aber nie im Hinweis. Das Modell lies das Feld weg, die Validierung lehnte den Aufruf ab, der Agent las die Fehlermeldung, rief mit dem fehlenden Feld erneut auf, und es gelang. Ein überflüssiger Selbstheilungs-Pingpong, bei jedem gruppiereten Aufruf mit gemeinsamem Feld gezahlt. Die Fix macht getActionRequiredFields() so, dass es dasselbe verschmolzene Schema widerspiegelt, das buildValidationSchema() durchsetzt, omitCommonFields eingeschlossen, Hinweis und Validator können so nie mehr auseinanderlaufen.

Der neue commonSchema-Parameter bei getActionRequiredFields / generateDescription / generateToonDescription ist optional, was die Änderung Wire-sichtbar, aber nicht brechend hält: Keine API, keine Typen, keine Schema-Form ändern sich; die Ausgabe der flachen Exposition bleibt bytegenau, und gruppierete Beschreibungen schrumpfen nur. Die eine operative Konsequenz: Die integrityDigest von mcpfusion.lock ändert sich für gruppierete Server mit geerbten Beschreibungen; Lockfile neu generieren.

Der Catch, der die Bedeutung verschluckte

Die gelehnte Idiom des Frameworks ist, Fehler zu klassifizieren, nicht nur auszulösen: Handler und Middleware dürfen eine bereits klassifizierte Response throw (throw toolError('NOT_FOUND', {...}), throw error('Unauthorized')) statt sie zurückzugeben. Der Catch-Block in runChain() erkannte eine einfache ToolResponse und nichts anderes; eine geworfene Response kam also ohne Fehlercode, ohne Recover-Guidance und ohne ihre Warnung-gegen-Fehler-Schweregrad an und ging als generisches INTERNAL_ERROR wieder hinaus.

Zwei Formen waren schlimmer als bloß „verloren“. Eine geworfene HandoffResponse trägt die Tool-Response-Marke, hat aber kein content-Array; die alleinige isToolResponse()-Prüfung leitete sie an Code weiter, der in content indexiert, ein Absturz auf dem Föderierten-Handoff-Weg. Ein geworfener ResponseBuilder wurde verworfen statt aufgebaut, wodurch jeder komponierte Content-Block verloren ging. Der Catch spiegelt jetzt die Reihenfolge von postProcessResult() (isHandoffResponse → isResponseBuilder → isToolResponse), und nur der tatsächlich unerwartete Rest wird INTERNAL_ERROR.

Das, was an der Modellgrenze am meisten zählt: Dieser Fallback behauptet nicht mehr, der Fehler sei transitorisch. Ein permanenter Fehler (falsche Id, fehlende Ressource, abgelaufene Auth) hätte den Agenten sonst in eine Retry-Schleife mit identischen Parametern getrieben. Der neue Fehler meldet den Ursprung [tool/action] und sagt dem Modell, die Nachricht zu untersuchen, statt blind zu wiederholen, der Unterschied zwischen einem Agenten, der eskaliert, und einem, der denselben Aufruf bis zum Timeout hämmert.

Fixiert und ausgeliefert

• DescriptionInheritance-bug152-153.test.ts (18 Fälle) und ThrownResponseRecovery.test.ts (12 Fälle) fixieren beide Verhaltensweisen, laut den Release Notes.
• Komplette Core-Suite: 5.243 bestanden, 0 fehlgeschlagen; tsc --noEmit sauber; alle 16 Workspace-Pakete bauen.

Die Installation ist eine Zeile:

npm install @mcpfusion/core@5.0.10

Wenn du gruppierete Exposition betreibst, generiere dein mcpfusion.lock neu, damit die integrityDigest zur (jetzt kleineren) Beschreibung passt, und nichts in deinen Handler-Code ändert sich: Das Idiom, eine klassifizierte Response zu werfen, funktioniert jetzt so, wie es die Doku immer versprochen hat.