Un agente che «ricorda» il tuo progetto tra una sessione e l'altra non sta ricordando nulla. Qualcosa gli ha passato un file, e lui ha letto il file. La domanda interessante non è come il modello immagazzini la conoscenza, ma chi decide cosa viene consegnato, e il Model Context Protocol risponde a questa domanda in una frase che quasi tutti saltano.
La frase che risolve la questione
La specifica MCP descrive le risorse, il meccanismo con cui un server espone dati a un modello, e ne dichiara apertamente l'intento di progettazione:
Le risorse in MCP sono progettate per essere guidate dall'applicazione, con le applicazioni host che determinano come incorporare il contesto in base alle proprie esigenze.
Guarda cosa viene assegnato, e a chi. Il server offre. L'applicazione host decide. Il modello riceve ciò che è sopravvissuto a quella decisione.
La specifica poi rinuncia a standardizzare la decisione stessa: le implementazioni sono libere di esporre le risorse attraverso qualsiasi schema di interfaccia ritengano adatto, e il protocollo stesso non impone alcun modello specifico di interazione con l'utente. Suggerisce possibilità, un selettore in vista ad albero o a elenco, un campo di ricerca, oppure l'inclusione automatica basata su euristiche o sulla selezione del modello stesso, senza richiederne nessuna.
Così due agenti che parlano lo stesso protocollo, collegati allo stesso server, possono ritrovarsi con contesti completamente diversi. Non è un difetto. È il protocollo che si rifiuta di prendere una decisione di prodotto al posto tuo.
Cos'è una risorsa, concretamente
Una risorsa è un dato identificato da un URI: un file, uno schema di database, informazioni specifiche dell'applicazione. I server che le supportano devono dichiarare una capability resources, e possono annunciare due funzionalità opzionali:
listChanged, se il server emette una notifica quando cambia l'elenco delle risorse disponibili.subscribe, se supporta le notifiche di aggiornamento per risorse specifiche che un client ha chiesto di monitorare.
Un server può annunciarne una, entrambe o nessuna. I client scoprono cosa esiste con resources/list e leggono i contenuti con resources/read.
Su un vincolo della specifica vale la pena soffermarsi, perché esclude un'intera categoria di soluzioni ingegnose. L'insieme di risorse che un server restituisce non deve variare per connessione né come effetto collaterale di altre richieste sulla connessione. Può cambiare nel tempo, e può variare in base all'autorizzazione presentata nella richiesta, poiché le credenziali sono un input per richiesta e non uno stato di connessione.
In altre parole: un server non può mostrarti in sordina un catalogo diverso a causa di ciò che hai chiesto prima nella sessione. Ciò che varia è quello che le tue credenziali consentono, non quello che la tua cronologia lascia intendere.
Le annotazioni sono la vera politica di memoria
Se c'è un luogo in cui la «memoria» viene decisa, è questo. Le risorse portano annotazioni opzionali che suggeriscono ai client come usarle:
audience: a chi è destinato il contenuto,"user","assistant", o entrambi.priority: un numero da 0.0 a 1.0. La specifica è insolitamente diretta sugli estremi di quella scala: 1 significa il più importante, di fatto obbligatorio, mentre 0 significa il meno importante, del tutto facoltativo.lastModified: un timestamp ISO 8601.
I client le usano per filtrare per destinatario, per dare priorità a quali risorse includere nel contesto e per ordinare in base alla recenza.
Questo è tutto il meccanismo. Ciò che un agente «ricorda» è ciò che ha ottenuto un punteggio abbastanza alto nel campo di priorità di qualcun altro da sopravvivere al budget di contesto. Non c'è rievocazione, non c'è oblio, non c'è consolidamento. C'è un elenco ordinato e un limite.
Due regole sugli errori che rivelano la filosofia di progettazione
La gestione degli errori della specifica dice qualcosa su quanto seriamente essa prenda l'ambiguità.
Una risorsa mancante deve restituire un errore JSON-RPC, codice -32602. E poi questo: i server non devono restituire un array contents vuoto per una risorsa inesistente, perché un array vuoto è ambiguo, potrebbe significare che la risorsa esiste ma non ha contenuto, oppure che non esiste affatto.
Un protocollo che si prende la briga di spiegare perché un array vuoto è inaccettabile è un protocollo progettato da persone che hanno fatto debug di agenti. Il vuoto silenzioso è il modo in cui un agente finisce per ragionare con sicurezza su un file che non ha mai letto.
Le regole di sicurezza che erediti usandolo
Poiché le risorse sono indirizzate tramite URI e spesso corrispondono a file, la specifica porta con sé obblighi espliciti. I server devono validare tutti gli URI delle risorse. Devono sanificare i percorsi dei file per prevenire attacchi di directory traversal quando servono risorse file://. I controlli di accesso dovrebbero essere implementati per le risorse sensibili, e i permessi dovrebbero essere verificati prima delle operazioni.
Non sono requisiti esotici, ed è proprio questo il punto. Esporre il tuo filesystem a un modello attraverso un protocollo non cambia cosa sia un path traversal. Aumenta soltanto il numero di mani che tengono la corda.
Cosa cambia nel modo di pensare agli agenti
Smetti di chiederti cosa ricorda il modello. Chiediti quali risorse l'applicazione host ha deciso di includere, con quale priorità e con quali credenziali. È tutta lì la risposta, e vive nell'applicazione, non nel modello.
La persistenza è un file, non una facoltà. Un agente che ricorda le tue convenzioni tra le sessioni sta leggendo un documento che qualcosa ha scelto di esporre di nuovo. Cambia l'esposizione e la memoria cambia, istantaneamente e completamente.
È nella priorità che avviene la vera progettazione. Un campo da 0.0 a 1.0 decide cosa sopravvive a un contesto limitato. Quel numero, impostato da chi ha scritto il server, plasma il comportamento dell'agente più di gran parte del prompt engineering.
La parola «memoria» importa aspettative dalla cognizione umana che il meccanismo non sostiene. Ciò che MCP specifica in realtà è un catalogo, una politica di accesso e una classifica. Saperlo è la differenza tra progettare deliberatamente il contesto di un agente ed esserne sorpresi.
La descrizione delle risorse MCP qui riportata, compresi l'intento di progettazione guidato dall'applicazione, l'affermazione che il protocollo non impone un modello di interazione con l'utente, la capability resources con listChanged e subscribe, il vincolo secondo cui l'insieme delle risorse non deve variare per connessione mentre può variare in base all'autorizzazione, le annotazioni audience, priority e lastModified, il codice di errore -32602, il divieto di restituire un array contents vuoto, e i requisiti di validazione degli URI e di sanificazione dei percorsi, è tratta dalla specifica del Model Context Protocol, verificata al momento della stesura. La specifica evolve; verifica rispetto alla revisione corrente prima di fare affidamento su un dettaglio specifico.
