MCP schlägt Standard für den Dateiaustausch zwischen Modellen und Tools vor

10. November 2026, 10:00Von der KI Nachrichten RedaktionQuelle: Model Context Protocol Blog

Die Community des Model Context Protocol hat einen Entwurf für Datei-Uploads und -Downloads veröffentlicht. Ziel ist ein gemeinsamer Weg für MCP-Server und -Clients, große Dateien auszutauschen, ohne deren Inhalte durch ein Modell zu leiten. Der experimentelle Vorschlag ist unter anderem für das Speichern von Gesprächsdateien in der Cloud und den Import von CSV-Daten in Code-Sandboxes gedacht.

Das Wichtigste in Kürze

MCP hat einen experimentellen Entwurf für eine Erweiterung für Datei-Uploads und -Downloads veröffentlicht.
Der Vorschlag unterstützt Inline-Dateien sowie direkte Out-of-Band-Uploads.
Clients übermitteln zunächst Dateimetadaten, damit Server Berechtigungen und verfügbaren Speicherplatz prüfen können.
Das Modell muss weder die Datei-Bytes noch die Upload-URL erhalten.
Die Gruppe erwartet, dass die Erweiterung vor Ende des Jahres stabil wird.

Ein Entwurf als Antwort auf die wachsende Dateinutzung

MCP wurde ursprünglich entwickelt, um Modelle mit Tools zu verbinden. In den vergangenen zwei Jahren sind die mit dem Protokoll entwickelten Projekte jedoch anspruchsvoller geworden. Laut dem Model Context Protocol Blog müssen viele MCP-Server inzwischen mit Dateien als Teil der Fähigkeiten und der zunehmenden Autonomie von Agenten arbeiten.

Das Speichern einer PDF-Datei aus einem Gespräch im Cloud-Speicher und das Einlesen einer CSV-Datei in eine Sandbox beschreibt der Blog als häufige Wünsche von Entwicklern, die MCP einsetzen. Bislang erforderten solche Abläufe eigene Konventionen für Tools und Übertragungsmechanismen. Die File Uploads Working Group wurde gegründet, nachdem dieses Anliegen wiederholt in Kundengesprächen aufkam, und hat im vergangenen Monat einen vorläufigen Erweiterungsentwurf ausgearbeitet.

Die Gruppe bittet Entwickler, den Entwurf auf dem Weg zur Prototypenphase zu testen. Die Arbeit ist weiterhin experimentell, eine Referenzimplementierung gibt es noch nicht. Laut Blog kann sich das Design nach der Integration mit Dateidiensten von Drittanbietern ändern, darunter Cloud-Speicher sowie Systeme zum Import und Export von Datenbanken.

So soll die Erweiterung mit Dateien umgehen

Die Erweiterung trägt die Kennung io.modelcontextprotocol/files und funktioniert mit der Protokollversion 2026-07-28 und späteren Versionen. Server können Unterstützung für Out-of-Band-Uploads und Inline-Dateien ankündigen, während Clients Unterstützung für Uploads und Download-Ziele angeben können.

Im vorgeschlagenen Ablauf kennzeichnet ein Server ein Tool-Argument mit x-mcp-file als Datei. Kleine Dateien können als Base64-Daten inline übertragen werden, sofern sie die vom Server festgelegte Grenze maxInlineBytes einhalten. Bei größeren Dateien kann ein Client die Daten zunächst weglassen und die Datei separat hochladen, wenn der Server Uploads unterstützt. Das Schema kann außerdem akzeptierte Dateitypen, eine maximale Größe und einen optionalen SHA-256-Hash angeben.

Das Modell muss die Dateiinhalte nicht direkt verarbeiten. Stattdessen übermittelt der Client Metadaten wie die ID, den Namen, den MIME-Typ und die Größe der Datei. Der Server kann diese Informationen nutzen, um Berechtigungen und verfügbaren Speicherplatz zu prüfen, bevor ein Upload beginnt.

Freigabe, direkte Übertragung und ein zustandsloser Wiederholungsversuch

Bevor eine Datei gesendet wird, holt der Host die Zustimmung des Nutzers ein. Ist kein Nutzer anwesend, entscheidet die Richtlinie des Agenten, ob die Übertragung zulässig ist. Nach der Prüfung der Metadaten kann der Server ein Ergebnis mit upload_required zurückgeben, das einen Upload-Speicherort, Anweisungen und einen Wert für requestState enthält.

Der Client überträgt die Datei anschließend direkt per HTTPS-PUT-Anfrage an das Ziel. Laut Blog kann ein Upload-Ziel stattdessen POST mit einem multipart/form-data-Body vorgeben, wenn dies von einem Speicherdienst verlangt wird. Die Dateiinhalte werden außerhalb von JSON-RPC übertragen. Das Modell erhält weder die Bytes noch die Upload-URL in seinem Kontext.

Nach einem erfolgreichen Upload ruft der Client das Tool mit denselben Argumenten und dem Wert für requestState erneut auf. Der Server überprüft den Zustand, bestätigt den Eingang des Uploads und kontrolliert Größe und Typ, bevor er das Tool ausführt. Das requestState-Design ermöglicht es einer anderen Serverinstanz, den Auftrag fortzusetzen, und kann verhindern, dass ein Tool in Situationen zweimal ausgeführt wird, in denen ein doppeltes Ergebnis unerwünscht wäre.

Was der Vorschlag für MCP-Nutzer bedeutet

Die Erweiterung bleibt optional. Clients und Server, die sie nicht unterstützen wollen, müssen keine Änderungen vornehmen. Clients, die x-mcp-file nicht erkennen, können das Argument als gewöhnliches Objekt behandeln. Gibt ein Client in seiner Anfrage tools/list keine Unterstützung an, sollte der Server das Tool weglassen oder eine Alternative anbieten, etwa die Annahme einer URL zu einer bereits hochgeladenen Datei.

Für Entwickler bietet der Vorschlag ein gemeinsames Muster für dateibasierte Abläufe, statt für jedes Tool oder jeden Dienst eine eigene Konvention zu erfordern. Für Nutzer und Agenten könnte dadurch der Bedarf sinken, große Dateien durch ein Modell zu leiten, während Freigaben und serverseitige Prüfungen erhalten bleiben. Laut Blog erwartet die Gruppe, die Erweiterung vor Ende des Jahres abzuschließen und zu stabilisieren. Das aktuelle Design kann sich jedoch weiterhin ändern.