Un’applicazione di IA deve leggere un catalogo, consultare un CRM o aprire un ticket. MCP può rendere queste capacità scopribili e utilizzabili attraverso un contratto comune. Ma una connessione riuscita dimostra soltanto che i messaggi attraversano il confine: non dimostra che il server sia affidabile, che il modello abbia scelto lo strumento giusto o che l’azione sia autorizzata.
Il punto di partenza: MCP è un contratto di connessione
Il Model Context Protocol (MCP) è un protocollo aperto che standardizza il modo in cui un’applicazione basata su modelli linguistici comunica con servizi che espongono risorse, prompt o strumenti.
Può essere utile quando più applicazioni di IA devono scoprire e riutilizzare le stesse capacità, oppure quando l’azienda vuole separare l’integrazione dai singoli modelli e client. Se, invece, esistono una sola applicazione utilizzatrice e un flusso stabile, una chiamata API diretta o un’integrazione fissa può essere più semplice.
Il confine decisivo è questo: MCP standardizza connettività, scoperta e invocazione. Non definisce l’autorità aziendale. Identità, permessi, approvazioni, gestione delle credenziali, log e revoca restano responsabilità del sistema che implementa e gestisce la connessione.
Che cos’è MCP nella specifica attuale
Questa guida usa come riferimento la specifica MCP 2026-07-28, verificata il 24 ottobre 2026. La data conta: molte spiegazioni online descrivono ancora handshake, sessioni e trasporti delle versioni precedenti.
Nella specifica corrente, le richieste sono autonome e includono le informazioni necessarie sul protocollo, sul client e sulle capacità. La release di luglio 2026 ha rimosso l’handshake e l’identificatore di sessione dal core, introdotto server/discover, rivisto i flussi che richiedono più passaggi e rafforzato l’architettura di autorizzazione. Alcuni elementi precedenti, tra cui il trasporto HTTP+SSE legacy, sono deprecati per le nuove implementazioni.
Questi sono requisiti e decisioni della specifica. Non provano che ogni host, SDK o server disponibile oggi implementi già la stessa versione. Il supporto di un prodotto va verificato separatamente.
I ruoli principali possono essere tradotti in tre domande aziendali:
- Host: quale applicazione conduce l’esperienza, presenta le scelte e applica le proprie regole?
- Client: quale connessione MCP interna all’host parla con quello specifico server, con quale versione e identità?
- Server: chi espone le capacità e quali sistemi, dati o credenziali usa a monte?
Il server può esporre:
- risorse, cioè dati o contesto che l’applicazione può caricare;
- prompt, cioè modelli o workflow riutilizzabili che una persona può selezionare;
- strumenti, cioè funzioni invocabili che possono leggere informazioni o produrre effetti.
I nomi sembrano tecnici, ma la distinzione è operativa. Leggere una risorsa, scegliere un prompt e invocare uno strumento non hanno la stessa conseguenza né richiedono lo stesso controllo.
Il valore compare quando esiste qualcosa da riutilizzare
Immagina due applicazioni di IA approvate che devono entrambe consultare lo stesso catalogo e aprire ticket di assistenza. Un server MCP mantenuto dall’azienda può esporre il catalogo come risorsa in sola lettura e la creazione del ticket come strumento circoscritto. Il valore non sta nel chiamare “MCP” l’integrazione: sta nel riutilizzare una capacità coerente attraverso applicazioni compatibili.
Quel valore diminuisce se le applicazioni utilizzatrici interpretano gli strumenti in modo diverso, se le descrizioni cambiano senza revisione, se il server non è mantenuto oppure se esiste un solo utilizzo prevedibile. MCP non elimina il lavoro di integrazione. Sposta una parte del lavoro dentro un confine comune che deve comunque essere progettato, versionato e gestito.
Prima di adottarlo, nomina il riuso concreto:
- quali host o team useranno la capacità;
- quali risorse o azioni devono restare coerenti tra loro;
- chi manterrà server, descrizioni e compatibilità;
- quale duplicazione reale viene evitata.
Se non riesci a rispondere, probabilmente stai scegliendo un protocollo prima di avere un problema di interoperabilità.
MCP non sostituisce un’API
MCP e API operano spesso su livelli diversi. Un server MCP può chiamare un’API, interrogare un database o avviare una funzione locale dietro il protocollo. L’API resta il contratto con il sistema aziendale; MCP offre all’applicazione di IA un modo comune per scoprire e invocare la capacità esposta.
Per questo “MCP oppure API?” è spesso la domanda sbagliata. La scelta reale è tra:
- una connessione MCP riutilizzabile sopra i sistemi esistenti;
- una chiamata API diretta controllata dall’applicazione;
- un workflow fisso in cui sequenza e regole non sono scelte dinamicamente;
- nessuna connessione finché perimetro e responsabilità non sono definiti.
Un workflow interno che ogni mattina legge un endpoint di stato e produce sempre lo stesso rapporto non ha bisogno di scoprire strumenti. Un’integrazione API pianificata è più facile da delimitare, osservare e testare. MCP guadagna spazio quando la scoperta e il riuso tra applicazioni compatibili sono requisiti reali, non quando aggiungono soltanto un livello.
MCP non rende autonomo un agente
Esporre uno strumento non attribuisce al modello il diritto aziendale di usarlo. La specifica può descrivere come una capacità viene scoperta e invocata; il prodotto e l’organizzazione devono ancora decidere chi può attivarla, quali argomenti sono ammessi, quando serve una conferma e quali effetti sono vietati.
Allo stesso modo, adottare MCP non trasforma automaticamente un chatbot o un workflow in un agente. La scelta di usare un agente dipende dal percorso decisionale, dalla variabilità del compito e dalla necessità di selezionare strumenti entro limiti chiari. Agenti AI: cosa sono e quando usarli in azienda tratta quella decisione separatamente.
Qui la domanda è più stretta: se un sistema può scoprire una funzione chiamata crea_ticket, quale autorità effettiva riceve? Può scegliere il cliente, allegare documenti, impostare la priorità o inviare il ticket senza conferma? Il nome dello strumento non risponde a queste domande.
La mappa M4TIC del valore e dell’autorità MCP
Questa mappa è una sintesi editoriale M4TIC, non una funzione del protocollo. Serve a verificare il valore della connessione e, separatamente, l’autorità che attraversa il confine.
1. Valore della connessione
Domanda: quale problema ripetuto di integrazione elimina MCP?
Prova minima: host, strumenti e casi di riuso nominati; confronto esplicito con API diretta e workflow fisso.
2. Superficie di scoperta
Domanda: quali risorse, prompt e strumenti può scoprire il client, e chi può modificarne descrizioni o comportamento?
Prova minima: catalogo consentito, provenienza verificata, versioni o modifiche sottoposte a revisione, capacità non necessarie rimosse.
3. Identità e credenziali
Domanda: quale identità raggiunge il server MCP e il servizio a monte?
Prova minima: identità di utente, workload e server distinte; destinatario del token verificato; credenziali conservate e separate correttamente; nessun inoltro di token vietato.
4. Autorità effettiva
Domanda: che cosa può leggere, cambiare, inviare, eliminare o attivare la capacità?
Prova minima: privilegi minimi, regole applicative, utenze di prova e domini di dati o azione circoscritti.
5. Approvazione ed esecuzione
Domanda: dove può essere negata, confermata o portata in escalation un’azione materiale?
Prova minima: interfaccia comprensibile, consenso legato al server e all’azione, approvazione deterministica prima degli effetti rilevanti.
6. Evidenza e uscita
Domanda: che cosa viene registrato e come si disattiva davvero la connessione?
Prova minima: log di attore, server, strumento, argomenti, risultato ed esito; proprietario operativo; percorso di incidente; procedura provata di revoca, disabilitazione e rimozione.
Un’autorizzazione tecnica non esaurisce nessuno di questi livelli. Anche un flusso OAuth corretto non stabilisce da solo se un’azione è appropriata per quel ruolo, quel cliente o quel momento.
Dove entra il rischio
MCP non è una garanzia di sicurezza e non è, da solo, la causa di ogni rischio. Aggiunge però un confine in cui descrizioni, dati, strumenti e credenziali possono influenzarsi.
Quattro controlli meritano attenzione:
- Provenienza del server: chi pubblica e aggiorna il server? Come viene verificato prima dell’uso?
- Contenuto non attendibile: risorse e descrizioni degli strumenti possono contenere istruzioni o formulazioni capaci di influenzare il comportamento del modello.
- Credenziali e permessi: uno strumento dall’aspetto innocuo può ereditare accessi molto più ampi del suo nome.
- Audit incompleto: registrare soltanto che “lo strumento è stato chiamato” non basta se mancano identità, argomenti, risultato, effetto e approvazione.
Le linee guida MCP richiedono particolare attenzione al destinatario dei token, alla separazione delle credenziali, ai privilegi minimi e al divieto di inoltrare token in flussi non consentiti. Sono controlli necessari nei casi pertinenti, non una prova automatica che l’intero sistema sia governato.
Se dati riservati attraversano la connessione, il luogo di esecuzione è solo una parte del problema. L’IA privata per le aziende approfondisce esposizione e confini dei dati; la distribuzione privata non sostituisce autorizzazioni e audit.
Un server locale e uno remoto creano confini diversi
Un server locale avviato tramite stdio è un normale processo sul dispositivo. Il protocollo non lo trasforma in una sandbox. Può ereditare i privilegi dell’utenza, vedere file o variabili disponibili al processo e introdurre un rischio di provenienza o della catena di fornitura. “Locale” non significa automaticamente “limitato”.
Un server remoto aggiunge identità di rete, autorizzazione, gestione dei token, disponibilità del servizio e fiducia nell’operatore. Può essere più semplice da amministrare centralmente, ma non è automaticamente più sicuro.
La domanda utile non è quale categoria vinca in astratto. È: quale processo o servizio esegue il codice, con quali credenziali, sopra quali dati, sotto quale controllo e con quale via di revoca?
Quattro decisioni, non una corsa all’adozione
Scegli MCP ora
Quando più host, team o applicazioni compatibili devono riutilizzare capacità ben delimitate; proprietario, provenienza, identità, approvazioni, log e revoca sono già definiti.
Avvia un pilota circoscritto
Quando il riuso è plausibile ma supporto dei client, semantica degli strumenti o responsabilità operative devono ancora essere provati. Parti con lettura o azioni a bassa autorità, dati limitati e una via di uscita reale.
Usa un’API diretta o un workflow fisso
Quando esistono una sola applicazione utilizzatrice, una sequenza prevedibile e un contratto stabile. La minore flessibilità può offrire un perimetro più chiaro e un audit più semplice.
Non collegare ancora
Quando non sono definiti bisogno, provenienza, dati, permessi, approvazione o responsabile. Un server locale di terze parti non verificato che richiede accesso ampio al sistema di file e alle variabili d’ambiente non è un esperimento innocuo: è una connessione senza un modello di controllo.
Il primo passo deve essere piccolo e revocabile
Un buon primo esperimento non misura quante funzioni riesce a esporre. Verifica se una capacità circoscritta conserva significato, limiti ed evidenza attraverso l’intero percorso.
Definisci un solo caso d’uso, un proprietario e un risultato osservabile. Concedi il privilegio minimo. Separa le identità. Richiedi una conferma visibile prima di un effetto materiale. Registra richiesta, strumento, argomenti, approvazione, risultato ed esito. Infine, prova a disattivare server e credenziali: una revoca mai testata è soltanto un’intenzione.
Quando il pilota passa dalla connessione al comportamento di un sistema operativo, servono casi di prova, limiti, escalation e recupero. Come testare un agente AI prima del lancio copre quel passaggio senza confonderlo con la scelta del protocollo.
MCP merita un posto quando l’interoperabilità è reale e l’autorità resta esplicita. Se il valore dipende soltanto dalla novità del protocollo, oppure se nessuno sa dire che cosa la connessione può fare davvero, la scelta migliore è semplificare o fermarsi.
Fonti e approfondimenti
Indicazioni primarie dietro questo articolo.
- Model Context Protocol Specification — 2026-07-28Model Context Protocol
Definizione corrente verificata di ruoli, capacità, richieste e principi di sicurezza del protocollo.
- The 2026-07-28 SpecificationModel Context Protocol Blog
Note ufficiali su core stateless, autorizzazione, estensioni e deprecazioni.
- Authorization — 2026-07-28Model Context Protocol
Specifiche di autorizzazione HTTP, ruoli, individuazione e privilegi minimi.
- Authorization security considerationsModel Context Protocol
Indicazioni normative su destinatario dei token, conservazione, validazione, reindirizzamenti e inoltro dei token.
- Security best practicesModel Context Protocol
Guida ufficiale su consenso, ambiti, proxy, SSRF e compromissione locale.
- Local server securityModel Context Protocol
Guida su fiducia nei processi locali, catena di fornitura, catalogo degli strumenti e contenimento.
- Model Context Protocol: Security Design Considerations for AI-Driven AutomationNSA Artificial Intelligence Security Center
Guida pubblica del 20 maggio 2026 sui confini di fiducia e sull’invocazione dinamica degli strumenti.