Am 10. November 2026 haben die Maintainer des Model Context Protocol (MCP) den Entwurf einer experimentellen Erweiterung namens io.modelcontextprotocol/files veröffentlicht. Damit kann ein Agent Dateien auf einen MCP-Server hochladen und von dort herunterladen, ohne dass die Bytes durch das Modell laufen. Die Datei geht direkt zum Ziel, das Modell sieht nur das Ergebnis. Die Erweiterung arbeitet mit der Protokollrevision 2026-07-28, ist optional und hat noch keine Referenzimplementierung.

In sintesi

io.modelcontextprotocol/files ist ein experimenteller Entwurf für Dateieingabe und -ausgabe, gebaut für die MCP-Revision 2026-07-28. Das Team will ihn bis Jahresende stabilisieren.
Kleine Dateien gehen inline als Base64, große per Out-of-Band-Upload: Der Server antwortet mit upload_required und einer temporären URL, der Client wiederholt den Aufruf nach dem Upload.
Die Schwachstelle ist das Ziel: Die Nutzerfreigabe kommt, bevor das Ziel bekannt ist, ein bösartiger Server kann also jeden öffentlichen Endpunkt nennen. Der Entwurf schlägt eine Origin-Allowlist vor, noch nicht verpflichtend.
Am 11. November hat MCP einen sechsmonatigen Release-Zyklus festgelegt: Die nächste Spezifikation ist für den 30. März 2027 geplant (2027-03-30).
Aktuell taugt der Entwurf für Prototypen und Feedback: Er warnt selbst vor Breaking Changes.

Welches Problem das löst

Jeder MCP-Server, der Dateien verarbeitet, erfindet heute seine eigene Konvention. Der MCP-Blogpost vom 10. November 2026 von Den Delimarsky (Lead Maintainer) und Wil St. Charles (Google) nennt zwei typische Fälle: eine Datei aus einer Konversation in einem Cloud-Speicher ablegen und ein großes CSV in eine Code-Sandbox laden. Ohne Standard baut jede Entwicklerin und jeder Entwickler eigene Tool-Konventionen und Transfermechanismen.

Das erklärte Ziel: Das Modell muss "nicht jedes Byte lesen oder direkt handhaben". Die Arbeit stammt aus der File Uploads Working Group, die das MCP-Team nach wiederholten Kundenanfragen gebildet hat.

Stand: experimenteller Entwurf, keine Implementierung

Die Erweiterung ist ein Entwurf. Das Repository experimental-ext-file-uploads sagt, dass sie nicht Teil der MCP-Spezifikation ist, noch nicht als SEP vorgeschlagen wurde und man "mit Breaking Changes rechnen" soll, solange die Working Group iteriert. Die Referenzimplementierung soll in diesem Repository liegen, ist aber noch nicht da. Bei meiner Prüfung hatte das Repo 6 Commits.

Laut Blogpost will das Team die Erweiterung vor Jahresende finalisieren und stabilisieren. Der Spezifikationsentwurf baut nach eigener Angabe auf SEP-2356 und SEP-2631 auf.

So läuft der Upload ab

Der Ablauf hat fünf Schritte, und das Modell ist am Transfer nicht beteiligt. Er stützt sich auf den zustandslosen Kern der Spezifikation 2026-07-28: Wie der Post zur Spezifikation erklärt, sind der initialize-Handshake und der Header Mcp-Session-Id entfallen, und jede Anfrage trägt Version, Client-Identität und Capabilities selbst mit.

Der Server kündigt die Erweiterung in der Antwort auf server/discover an: upload, wenn er Out-of-Band-Dateien annimmt, maxInlineBytes, wenn er Inline-Dateien annimmt. Der Client deklariert sie in den Metadaten io.modelcontextprotocol/clientCapabilities jeder Anfrage, die sie brauchen kann, auch bei tools/list.
Der Server markiert das Datei-Argument im Input-Schema mit x-mcp-file, samt accept (erlaubte MIME-Typen) und maxSize. Die Datei ist ein Objekt mit id, name, mimeType, size, optionalem SHA-256-digest und einem Base64-Feld data für Inline.
Der Host holt die Freigabe der Nutzerin oder des Nutzers ein (ohne Nutzer entscheidet die Agent-Policy). Der Client ruft das Tool nur mit den Metadaten der Datei auf. Der Server prüft Rechte und Kontingent sofort, ein Fehler kostet also null hochgeladene Bytes.
Bestehen die Prüfungen, antwortet der Server mit resultType: "upload_required", einer Liste uploads mit fileId, url, headers, credentials und expiresAt sowie einem undurchsichtigen, manipulationsgeschützten requestState.
Der Client sendet die Datei per HTTPS-PUT (oder Multipart-POST, wenn das Ziel es verlangt) und wiederholt bei 2xx denselben tools/call mit denselben Argumenten plus dem unveränderten requestState. Der Server prüft den Zustand, bestätigt den Eingang der Bytes, validiert Größe und Typ und führt das Tool erst dann aus.

Ein verkürztes Schema-Beispiel, angepasst aus dem offiziellen Post (150 MiB sind 157.286.400 Byte):

"file": {
  "type": "object",
  "x-mcp-file": { "accept": ["application/pdf"], "maxSize": 157286400 },
  "required": ["id", "mimeType", "size"]
}

Die Wiederholung mit demselben requestState folgt dem Muster Multi Round-Trip Requests (MRTR), das 2026-07-28 eingeführt hat und das laut Spezifikations-Post serverseitig gestartete Anfragen wie elicitation/create und sampling/createMessage ersetzt. Bei Tools, die nicht zweimal laufen dürfen, etwa beim Anlegen einer doppelten Datei, markiert der Server den requestState vor der Ausführung als verbraucht, in einem Speicher, den alle Instanzen teilen.

Downloads und Credentials

Downloads laufen über das Feld _meta des Ergebnisses, ohne Wiederholung. Das Feld content sagt dem Modell, was entstanden ist (zum Beispiel "Exported q3-orders.csv."), das Ziel bleibt außerhalb des Modellkontexts. Der Client lädt per HTTPS-GET, vergleicht die Bytezahl mit size und prüft bei vorhandenem digest den Hash: Bei Abweichung wird die Datei verworfen. Ob Downloads in _meta gehören, ist für die Autoren eine offene Frage.

Jedes Ziel hat ein Feld credentials, damit der Client keine MCP-Zugangsdaten an beliebige URLs schickt:

Wert	Was der Client sendet	Wann es passt
`omit`	Kein MCP-Token, keine Cookies, keine Umgebungs-Credentials	Externer Speicher mit vorab signierter URL
`include`	Das MCP-Credential, nur an einen `path` unter der MCP-Adresse oder eine URL derselben Origin wie der Server	Gateways und Sandbox-Clients, die nur das Gateway erreichen

Clients müssen Redirects ablehnen und Ziele zurückweisen, die einen Authorization-Header mitliefern.

Sicherheitsrisiken, die du kennen solltest

Der Sicherheitsabschnitt des Entwurfs ist der nützlichste Teil. Die wichtigsten Punkte, alle aus dem Spezifikationsentwurf:

Die Host-Freigabe kommt, bevor das Ziel bekannt ist. Ein bösartiger Server kann jede öffentliche URL als omit-Ziel nennen und die Datei empfangen. Die Freigabe begrenzt, welche Dateien rausgehen, nicht wohin. Als Gegenmaßnahme ist eine Origin-Allowlist vorgesehen.
Bei form-Zielen kontrolliert der Server den Großteil des Request-Bodys, den der Client aus seinem eigenen Netzwerk sendet.
Auf einer Origin, die sich mehrere Anwendungen teilen, kann die Origin-Prüfung bei include sie nicht unterscheiden. Der Entwurf rät davon ab, MCP-Server auf geteilten Origins zu betreiben.
Wer ein beschreibbares Ziel hält, kann die Datei durch gleich große Bytes ersetzen, und vorab signierte URLs lassen sich oft nicht widerrufen. Gegenmaßnahmen: kurze Laufzeiten, Ziele mit Einmalschreibzugriff, verpflichtender digest.
Downloads brauchen keine Nutzerfreigabe, und eine heruntergeladene Datei kann Anweisungen an das Modell enthalten. Ein passender digest zeigt nur, dass die Bytes zum Hash passen, nicht dass sie sicher sind. Clients müssen Dateien als nicht vertrauenswürdig behandeln.
Ziele, Header, form-Felder, requestState und Inline-Daten müssen aus Logs, Traces und Fehlerberichten entfernt werden.

Für akzeptierte Formate verweist der Entwurf auf OWASP ASVS 5.0 V5.

Offene Fragen

Der Entwurf listet sieben ungeklärte Punkte. Die wichtigsten für Entwickler: ob die Origin-Allowlist für omit verpflichtend sein soll (und ob Wildcard-Hosts erlaubt sind), ob digest für jede Datei Pflicht sein soll, ob Downloads resource_link nutzen sollen, wie lange laufende Dateierzeugung behandelt wird und wie Gateways mit nur einem generischen Tool Datei-Argumente sichtbar machen. Offen ist auch, ob der Ablauf auf Resources ausgeweitet wird.

Der neue Release-Zyklus

Der Post vom 11. November 2026 von Delimarsky und David Soria Parra legt halbjährliche Releases fest, in der Regel am letzten Dienstag im März und im September. Die nächste Spezifikation ist für den 30. März 2027 geplant (2027-03-30). Der Soft Freeze liegt 2,5 Monate davor, die Tier-1-SDK-Betas 1,5 Monate davor, der Hard Freeze einen Monat davor. Ein Vorschlag, der nicht fertig ist, rutscht ins nächste Release, ohne die Spezifikation zu verzögern. Laut Post ändert sich nur die Release-Vorbereitung: Nachrichten und Versionsaushandlung bleiben gleich, Clients und Server müssen nichts anpassen.

Ob files in den Kern wandert, sagt der Entwurf nicht. Rayos Einschätzung: Solange sie experimentell ist, behandle sie als optionale Erweiterung und halte immer einen Fallback bereit, etwa die URL einer bereits hochgeladenen Datei.

Was du jetzt tun kannst

Wenn du MCP-Server betreibst, deren Tools Dateien annehmen oder erzeugen, liste auf, welche heute eine Ad-hoc-Konvention nutzen und welche Dateien über wenigen MB verarbeiten. Das sind die natürlichen Kandidaten.
Behalte Inline-Base64 für kleine Dateien. Base64 bläht Daten um etwa ein Drittel auf (3 Bytes werden zu 4 Zeichen), und maxInlineBytes legt die Obergrenze fest.
Wenn du ein omit-Ziel anbietest, nutze kurzlebige vorab signierte URLs, Einmalschreibzugriff und einen verpflichtenden digest.
Betreibe MCP-Server nicht auf Origins, die du dir mit anderen Anwendungen teilst.
Probiere den Entwurf in einer Testumgebung aus und gib der Working Group Feedback über die Repository-Issues oder ihren Discord. Hänge keine Produktionsabläufe an ein Format, das sich noch ändert.
Behandle jeden Download als nicht vertrauenswürdig: keine automatische Ausführung, kein name als roher Pfad, kein Überschreiben ohne Freigabe.

Quellen

FAQ

Was ist die MCP-Files-Erweiterung?

Ein experimenteller Entwurf, io.modelcontextprotocol/files, der festlegt, wie MCP-Clients Dateien an Tools senden und wie Tools Dateien zurückgeben. Die Bytes gehen direkt an ein Speicherziel oder den Server, ohne durch den Kontext des Modells zu laufen. Sie arbeitet mit Revision 2026-07-28 und ist optional.

Kann ich sie schon produktiv einsetzen?

Besser nicht. Das Repository warnt vor Breaking Changes, und es gibt noch keine Referenzimplementierung. Das Team will sie bis Jahresende stabilisieren. Für Prototypen und Feedback passt sie, für Abläufe, die du nicht umschreiben kannst, nicht.

Wie funktioniert der Upload großer Dateien?

Der Client ruft das Tool nur mit Metadaten auf. Passen Rechte und Kontingent, antwortet der Server mit upload_required, temporären URLs und einem requestState. Der Client lädt die Datei per PUT hoch und wiederholt denselben Aufruf mit unverändertem Zustand. Der Server prüft den Eingang der Bytes und führt dann das Tool aus.

Was ist das größte Sicherheitsrisiko?

Datenabfluss. Die Nutzerin oder der Nutzer gibt den Versand frei, bevor das Ziel bekannt ist, ein bösartiger Server kann also eine öffentliche URL als Ziel nennen und die Datei empfangen. Der Entwurf schlägt für Ziele ohne Credentials eine Origin-Allowlist vor, die noch nicht verpflichtend ist.

Wann erscheint die nächste MCP-Version?

Das MCP-Team hat am 11. November 2026 einen halbjährlichen Zyklus angekündigt. Die nächste Spezifikation ist für den 30. März 2027 geplant, mit der Versionsangabe 2027-03-30. Nicht fertige Vorschläge wandern ins nächste Release.