Model Context Protocol
Ruoli, primitive e confini del protocollo che collega applicazioni AI a strumenti, risorse e prompt dichiarati.
In breve
Sezione intitolata “In breve”Il Model Context Protocol, MCP, standardizza il collegamento tra un’applicazione AI e capacità esterne. Un server dichiara ciò che offre; un client mantiene il collegamento; l’host decide come quelle capacità entrano nell’esperienza dell’utente. MCP rende l’interfaccia leggibile da software differenti, ma non rende affidabile per definizione ciò che sta dietro l’interfaccia. Autorizzazione, consenso, validazione e trattamento degli effetti collaterali restano responsabilità dell’implementazione (Architecture, specifica 2026-07-28).
Questa voce è versionata sulla revisione ufficiale 2026-07-28. Esempi e guide riferiti a revisioni precedenti possono descrivere handshake, sessioni o capacità ormai cambiate; la data della specifica fa parte del contratto, non è una nota bibliografica.
Tre ruoli, responsabilità diverse
Sezione intitolata “Tre ruoli, responsabilità diverse”| Ruolo | Possiede | Non dovrebbe delegare al protocollo |
|---|---|---|
| Host | Esperienza utente, policy, consenso e composizione del contesto | La decisione finale su quali capacità rendere disponibili |
| Client | Collegamento con un server e scambio dei messaggi MCP | Il significato applicativo delle operazioni del server |
| Server | Descrizione ed esecuzione delle proprie capacità | La fiducia automatica dell’host o l’autorizzazione dell’utente |
Un host può contenere più client, ciascuno collegato a un server. I messaggi usano JSON-RPC; nomi, schemi e risultati rendono le capacità validabili.
Le primitive non sono intercambiabili
Sezione intitolata “Le primitive non sono intercambiabili”| Primitiva | Domanda a cui risponde | Esempio di uso |
|---|---|---|
| Tool | “Quale operazione può essere invocata?” | Cercare un ordine o aggiornare un ticket |
| Resource | “Quale contenuto può essere letto?” | Consultare un documento o una configurazione |
| Prompt | “Quale struttura di interazione è riutilizzabile?” | Preparare una revisione guidata con argomenti dichiarati |
Chiamare tutto “tool” perde informazione. Una risorsa è leggibile senza fingere che ogni lettura sia un comando; un prompt espone una struttura riutilizzabile senza trasformarla in funzione di dominio. Le primitive server-side e i relativi percorsi di scoperta sono distinti nell’indice normativo della revisione 2026-07-28 (Server primitives).
Un contratto concreto prima del wire
Sezione intitolata “Un contratto concreto prima del wire”Prima di implementare un tool, conviene poter compilare una scheda come questa:
| Campo progettuale | Valore di esempio |
|---|---|
| Nome | lookup_order |
| Scopo | Leggere lo stato di un ordine |
| Input | Oggetto con order_id stringa non vuota |
| Output | Stato strutturato oppure errore di dominio |
| Effetti collaterali | Nessuno: sola lettura |
| Autorizzazione | Verificata dal servizio prima della lettura |
Non è un messaggio MCP normativo, ma un test di progettazione: uno schema formalmente valido non rende sicura un’operazione i cui effetti o policy restano impliciti.
Sequenza di una chiamata ben delimitata
Sezione intitolata “Sequenza di una chiamata ben delimitata”- L’host rende disponibile una capacità secondo la propria policy.
- Il client ottiene descrizione e schema; il modello propone input strutturato.
- Host e server applicano i rispettivi controlli di consenso e autorizzazione.
- Il risultato torna all’host, che decide come usarlo nel contesto.
Il server non deve assumere che una richiesta sia autorizzata soltanto perché è arrivata tramite MCP.
La discontinuità della revisione 2026-07-28
Sezione intitolata “La discontinuità della revisione 2026-07-28”La revisione 2026-07-28 rende il core stateless, introduce Multi Round-Trip Requests per gli scambi multipli e depreca Roots, Sampling e Logging. Le attività di lunga durata passano da estensioni, non dal core. Prima di riusare un esempio occorre quindi chiedere dove viva lo stato, se impieghi funzioni deprecate e quale estensione negozi (Key Changes, Deprecated Features).
Cosa MCP non risolve
Sezione intitolata “Cosa MCP non risolve”MCP non è un sistema universale di autorizzazione, un catalogo di modelli né un protocollo di collaborazione tra agenti. Non stabilisce che un tool sia idempotente, che una risorsa sia vera o che un prompt sia innocuo. Per la collaborazione tra partecipanti autonomi, con task e conversazioni, il dominio appropriato è discusso in MCP e A2A.
La tesi pratica è semplice: MCP standardizza l’esposizione di una capacità, non il suo governo. Più l’interfaccia diventa facile da scoprire e invocare, più effetti, policy e provenienza devono essere espliciti.
La revisione 2026-07-28 potrà essere superata. Le bozze, i SEP e le estensioni indicano direzioni possibili ma non vanno presentati come core vigente. Prima di implementare, confrontare la pagina normativa versionata, lo schema della stessa revisione e il supporto effettivo dell’SDK scelto. Le policy di sicurezza dipendono inoltre dal trasporto, dall’ambiente e dal servizio esposto.