MCP: due release l’anno e i file arrivano agli agenti
Il Model Context Protocol, lo standard aperto con cui gli agenti AI si collegano a strumenti e dati aziendali, ha dato due notizie in due giorni. La prima riguarda il calendario, perché da ora le nuove versioni escono a date fisse. La seconda tocca un limite che chi integra agenti conosce bene, cioè passare un file a uno strumento senza soluzioni artigianali.
Cosa hanno annunciato
L’11 novembre i maintainer di MCP hanno comunicato che le specifiche usciranno ogni sei mesi, di norma l’ultimo martedì di marzo e di settembre. La regola è scritta nella SEP-3398 (le SEP sono le proposte formali di modifica del protocollo), accettata il 14 ottobre. La prossima versione è attesa per il 30 marzo 2027 e si chiamerà 2027-03-30. Il rilascio che era previsto per dicembre 2026 slitta quindi a fine marzo.
Il ciclo ha tappe precise. Il congelamento “morbido” arriva due mesi e mezzo prima dell’uscita e da lì entrano solo proposte già approvate e unite alla specifica. Le versioni beta degli SDK principali arrivano un mese e mezzo prima. L’ultimo mese è riservato alle correzioni critiche. Una proposta non pronta passa al ciclo successivo, senza spostare la data. I maintainer precisano che per client e server esistenti non c’è nulla da modificare.
Il 10 novembre, sempre sul blog ufficiale, è stata presentata la bozza di un’estensione per caricare e scaricare file. Si chiama io.modelcontextprotocol/files e funziona con la revisione del protocollo 2026-07-28 e successive. Lo strumento dichiara quale argomento è un file. Il client invia prima solo i metadati (nome, tipo, dimensione), così il server può verificare permessi e spazio disponibile. Se tutto è in ordine, il server restituisce un indirizzo di caricamento e il file viaggia direttamente verso lo storage, fuori dalla conversazione. Il modello non vede né i byte né l’URL. I file piccoli possono ancora viaggiare dentro la chiamata, codificati in base64, entro un limite dichiarato dal server. Il download segue lo stesso schema al contrario, con il controllo della dimensione e, se presente, dell’impronta SHA-256.
Prima dell’invio serve l’approvazione dell’utente oppure, se l’agente lavora da solo, una policy che la autorizzi. Il team è trasparente sullo stato dei lavori. L’estensione è sperimentale, non esiste ancora un’implementazione di riferimento e l’obiettivo è renderla stabile entro fine anno.
Cosa significa in pratica
Pensiamo a un’azienda di logistica che vuole un agente per gestire i documenti di trasporto. Ogni giorno arrivano decine di DDT in PDF da archiviare nel gestionale documentale, e ogni sera serve un export CSV delle spedizioni per l’analisi. Oggi ogni fornitore di server MCP risolve il problema a modo suo. C’è chi chiede un link a un file già caricato e chi accetta il file in base64 dentro la chiamata, con il rischio di gonfiare il contesto del modello e quindi i costi. Con l’estensione, un PDF da 40 MB va dritto allo storage, il server controlla prima che la cartella sia scrivibile e l’agente riceve solo l’esito dell’operazione.
Il calendario fisso pesa invece sulla pianificazione. Se sto progettando un’integrazione per il 2027, so che le novità del protocollo arriveranno a fine marzo e che le beta degli SDK saranno disponibili circa sei settimane prima. Posso prevedere un periodo di test sui miei server senza inseguire annunci sparsi tra GitHub e Discord.
Il mio punto di vista
Il calendario è la notizia meno appariscente, ma per me è la più utile. Chi porta MCP in produzione ha bisogno di prevedibilità più che di funzioni nuove ogni mese, e una data che non si sposta per aspettare una proposta in ritardo è una scelta da progetto maturo. Il rovescio della medaglia è lo slittamento da dicembre a marzo, che allunga i tempi per chi aspettava funzioni già in discussione.
Sull’estensione dei file sono più cauto. Il disegno è sensato, soprattutto la separazione tra file e contesto del modello e la verifica preventiva dei permessi. Però resta una bozza, e gli stessi autori lasciano aperte questioni di sicurezza. Un server malevolo potrebbe indirizzare un caricamento verso un endpoint che controlla, e per ora la bozza raccomanda (senza imporla) una lista di destinazioni consentite. Ne avevo già parlato nell’articolo sui server MCP e le falle chiuse con la v2.1.0, perché ogni capacità in più è anche una superficie di attacco in più. Aggiungo che un’impronta corretta conferma l’integrità del file, non che il file sia innocuo.
Il mio consiglio
Se oggi i tuoi agenti si scambiano file con soluzioni improvvisate, non riscrivere tutto adesso. Fai l’inventario dei punti in cui un documento passa da un sistema all’altro, concentra quella logica in un unico componente e segna in agenda la metà di febbraio 2027, quando le beta degli SDK permetteranno i primi test seri. Nel frattempo, per ogni server di terze parti che usi, chiediti dove finiscono davvero i file che carichi.
Se in azienda DDT, ordini ed export passano ancora a mano tra gestionale, email e cartelle condivise, partiamo da lì. Scrivimi e analizziamo insieme il processo dall’ordine alla consegna per capire quali passaggi affidare a un agente e con quali controlli.