Il 10 novembre 2026 i maintainer del Model Context Protocol (MCP) hanno presentato la bozza di un'estensione sperimentale, io.modelcontextprotocol/files, che permette a un agente di caricare e scaricare file da un server MCP senza far passare i byte dal modello. Il file va direttamente a destinazione, il modello vede solo il risultato. L'estensione funziona con la revisione 2026-07-28 del protocollo, è opzionale e non ha ancora un'implementazione di riferimento.

In sintesi

L'estensione io.modelcontextprotocol/files è una bozza sperimentale per file in ingresso e in uscita, pensata per la revisione 2026-07-28 di MCP. Il team punta a stabilizzarla entro fine anno.
I file piccoli viaggiano inline in base64, quelli grandi con un upload fuori banda: il server risponde upload_required con un URL temporaneo e il client ripete la chiamata dopo il caricamento.
Il punto debole è la destinazione: l'approvazione dell'utente arriva prima che il bersaglio sia noto, quindi un server malevolo può indicare un endpoint pubblico a sua scelta. La bozza propone una allowlist di origini, ancora non obbligatoria.
L'11 novembre MCP ha fissato un ciclo di rilascio semestrale: la prossima specifica è prevista per il 30 marzo 2027 (2027-03-30).
Per ora è adatta a prototipi e feedback: la bozza avverte di aspettarsi breaking change.

Che problema risolve

Oggi ogni server MCP che maneggia file reinventa la propria convenzione. Il post del blog MCP del 10 novembre 2026, firmato da Den Delimarsky (lead maintainer) e Wil St. Charles (Google), cita due casi tipici: salvare in uno storage cloud un file nato in una conversazione e portare un CSV grande dentro una sandbox di codice. Senza uno standard, ogni sviluppatore costruisce convenzioni e meccanismi di trasferimento propri.

L'obiettivo dichiarato è che il modello "non debba leggere ogni byte né gestirlo direttamente". Il lavoro nasce dal File Uploads Working Group, formato dal team MCP dopo richieste ripetute dei clienti.

Stato: bozza sperimentale, senza implementazione

L'estensione è una bozza. Il repository experimental-ext-file-uploads dice che non fa parte della specifica MCP, non è stata proposta come SEP e che bisogna "aspettarsi breaking change mentre il working group itera". L'implementazione di riferimento arriverà nello stesso repository, ma al momento non c'è. Al controllo di oggi il repo aveva 6 commit.

Il post del blog indica che il team conta di finalizzarla e stabilizzarla entro la fine dell'anno. La bozza della specifica dice di costruire su SEP-2356 e SEP-2631.

Come funziona il flusso di upload

Il flusso ha cinque passi e il modello non partecipa al trasferimento. Si appoggia al core senza stato della specifica 2026-07-28, dove, come spiega il post sulla specifica, l'handshake initialize e l'header Mcp-Session-Id sono stati eliminati e ogni richiesta porta con sé versione, identità del client e capability.

Il server dichiara l'estensione nella risposta a server/discover: upload se accetta file fuori banda, maxInlineBytes se accetta file inline. Il client la dichiara nei metadati io.modelcontextprotocol/clientCapabilities di ogni richiesta che può servirne, tools/list compresa.
Il server marca l'argomento file nello schema di input con x-mcp-file, con accept (tipi MIME ammessi) e maxSize. Il file è un oggetto con id, name, mimeType, size, un digest SHA-256 opzionale e un campo data in base64 per l'inline.
L'host chiede l'approvazione all'utente (se non c'è un utente decide la policy dell'agente). Il client chiama il tool con i soli metadati del file. Il server controlla permessi e quota subito, e un errore costa zero byte caricati.
Se i controlli passano, il server risponde con resultType: "upload_required", una lista uploads con fileId, url, headers, credentials e expiresAt, e un requestState opaco e protetto da manomissioni.
Il client invia il file con PUT HTTPS (o POST multipart se il bersaglio lo chiede) e, a risposta 2xx, ripete la stessa tools/call con gli stessi argomenti più il requestState invariato. Il server verifica lo stato, controlla che i byte siano arrivati, valida dimensione e tipo, e solo allora esegue il tool.

Un esempio abbreviato dello schema, adattato dal post ufficiale (150 MiB sono 157286400 byte):

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

Il ritorno al server con lo stesso requestState segue il pattern Multi Round-Trip Requests (MRTR) introdotto dalla 2026-07-28, che ha sostituito le richieste iniziate dal server come elicitation/create e sampling/createMessage, secondo il post sulla specifica. Per i tool che non devono girare due volte, come la creazione di un file duplicato, il server segna il requestState come usato prima di eseguire, in uno storage condiviso fra tutte le istanze.

Download e credenziali

I download usano il campo _meta del risultato, senza ripetizione della chiamata. Il content dice al modello cosa è stato prodotto (per esempio "Exported q3-orders.csv."), mentre il bersaglio resta fuori dal contesto del modello. Il client scarica con GET HTTPS, confronta i byte con size e, se c'è il digest, verifica l'hash: se non coincide scarta il file. Che i download stiano in _meta è una domanda aperta per gli autori.

Ogni bersaglio porta un campo credentials che evita di mandare credenziali MCP a URL arbitrari:

Valore	Cosa invia il client	Quando ha senso
`omit`	Nessun token MCP, cookie o credenziale d'ambiente	Storage esterno con URL pre-firmato
`include`	La credenziale MCP, solo verso un `path` sotto l'indirizzo MCP o un URL della stessa origine del server	Gateway e client in sandbox che raggiungono solo il gateway

I client devono rifiutare i redirect e i bersagli che forniscono un header Authorization.

Rischi di sicurezza da conoscere

La sezione sicurezza della bozza è la parte più utile da leggere. Alcuni punti, tutti dalla bozza della specifica:

L'approvazione dell'host precede la conoscenza del bersaglio. Un server malevolo può indicare qualsiasi URL pubblico come bersaglio omit e ricevere il file. L'approvazione limita quali file partono, non dove arrivano. La mitigazione proposta è una allowlist di origini.
Con i bersagli form il server controlla gran parte del corpo della richiesta che il client invia dalla propria rete.
Su un'origine condivisa tra più applicazioni, il controllo di origine su include non distingue le applicazioni: la bozza consiglia di non ospitare server MCP su origini condivise.
Chi possiede un bersaglio scrivibile può sostituire il file con byte della stessa dimensione, e gli URL pre-firmati spesso non si revocano. Mitigazioni: scadenza breve, bersagli a scrittura singola, digest obbligatorio.
I download non richiedono approvazione dell'utente, e un file scaricato può contenere istruzioni rivolte al modello. Il digest prova solo che i byte corrispondono all'hash, non che siano sicuri: i client devono trattare i file come non fidati.
Target, header, campi form, requestState e dati inline vanno rimossi da log, tracce e report di errore.

Per i formati accettati la bozza rimanda a OWASP ASVS 5.0 V5.

Domande ancora aperte

La bozza elenca sette punti irrisolti. I più rilevanti per chi progetta: se la allowlist di origini per omit debba essere obbligatoria (e se ammettere host con wildcard), se digest debba essere richiesto per ogni file, se i download debbano usare resource_link, come gestire file lunghi da generare e come esporre argomenti file da gateway che offrono un solo tool generico. Resta aperto anche se estendere il flusso alle resource.

Il nuovo ciclo di rilascio

Il post dell'11 novembre 2026 di Delimarsky e David Soria Parra fissa rilasci semestrali, di norma l'ultimo martedì di marzo e settembre. La prossima specifica è prevista per il 30 marzo 2027 (2027-03-30). Il soft freeze cade 2,5 mesi prima, gli SDK Tier 1 vanno in beta 1,5 mesi prima e l'hard freeze a un mese. Una proposta non pronta slitta alla release successiva senza ritardare la specifica. Il post precisa che cambia solo la preparazione: messaggi e negoziazione di versione restano uguali, quindi client e server non devono cambiare nulla.

La bozza non dice se files entrerà nel core. Secondo Rayo, finché resta sperimentale conviene trattarla come estensione opzionale e prevedere sempre un'alternativa, come accettare l'URL di un file già caricato.

Cosa fare adesso

Se hai server MCP con tool che prendono o producono file, elenca quali hanno oggi una convenzione ad hoc e quali file superano pochi MB: sono i candidati naturali.
Tieni l'inline in base64 per file piccoli. Il base64 gonfia i dati di circa un terzo (3 byte diventano 4 caratteri), e maxInlineBytes esiste proprio per fissare il tetto.
Se esponi un bersaglio omit, usa URL pre-firmati a scadenza breve, scrittura singola e digest obbligatorio.
Non ospitare server MCP su origini condivise con altre applicazioni.
Fai provare la bozza in un ambiente di test e segnala feedback al working group tramite le issue del repository o il suo Discord. Non agganciare ancora flussi di produzione a un formato che cambierà.
Per i download, tratta ogni file come non fidato: niente esecuzione automatica, niente name usato come percorso, niente sovrascritture senza approvazione.

Fonti

FAQ

Cos'è l'estensione files di MCP?

È una bozza sperimentale, io.modelcontextprotocol/files, che definisce come i client MCP inviano file ai tool e come i tool restituiscono file. I byte vanno direttamente a una destinazione di storage o al server, senza passare dal contesto del modello. Funziona con la revisione 2026-07-28 ed è opzionale.

Posso usarla in produzione adesso?

Meglio di no. Il repository avverte di aspettarsi breaking change e non c'è ancora un'implementazione di riferimento. Il team punta a stabilizzarla entro fine anno. Va bene per prototipi e feedback, non per flussi che non puoi riscrivere.

Come funziona l'upload di file grandi?

Il client chiama il tool con i soli metadati. Se permessi e quota sono a posto, il server risponde upload_required con URL temporanei e uno requestState. Il client carica il file con PUT e ripete la stessa chiamata con lo stato invariato: il server verifica l'arrivo dei byte ed esegue il tool.

Qual è il rischio di sicurezza principale?

L'esfiltrazione. L'utente approva l'invio prima di conoscere la destinazione, quindi un server malevolo può indicare un URL pubblico come bersaglio e ricevere il file. La bozza propone una allowlist di origini per i bersagli senza credenziali, ma non è ancora obbligatoria.

Quando esce la prossima versione di MCP?

Il team MCP ha annunciato l'11 novembre 2026 un ciclo semestrale. La prossima specifica è prevista per il 30 marzo 2027, con la stringa di versione 2027-03-30. Le proposte non pronte passano alla release successiva.