Il Model Context Protocol, o MCP, fornisce un linguaggio comune per collegare un'applicazione basata su un modello a strumenti e fonti di contesto. Un client può scoprire capacità, chiamare uno strumento o integrare un'interfaccia senza sviluppare un connettore specifico per ogni coppia di applicazioni.
Questa standardizzazione accelera l’integrazione. Non trasforma un server in un componente degno di fiducia. L’azienda deve sempre decidere chi può utilizzarlo, quali dati vede, quali azioni compie e come viene monitorato.
La specifica ufficiale
2026-07-28ha introdotto un cuore senza stato e diverse evoluzioni importanti; gli SDK e le deprecazioni devono essere verificati prima dell'implementazione.
Ciò che MCP standardizza
MCP descrive gli scambi tra un'applicazione client e un server che espone delle capacità. A seconda della versione e delle estensioni, queste possono includere strumenti, risorse, interfacce o compiti lunghi.
Il protocollo apporta:
- scoperta strutturata;
- schemi di ingresso e uscita;
- trasporto ;
- ciclo di richiesta ;
- meccanismi di autorizzazione;
- convenzioni di compatibilità;
- SDK in diversi linguaggi.
Non definisce le regole aziendali, il livello di fiducia, la classificazione dei dati o il diritto reale dell’utente nel sistema di destinazione.
Cosa cambia la revisione 2026-07-28
La specifica pubblicata il 28 luglio 2026 adotta un cuore del protocollo stateless. Il handshake e la sessione gestiti a livello di protocollo sono rimossi, al fine di facilitare il routing, la scalabilità e l'infrastruttura HTTP classica. L'applicazione può conservare uno stato, ma non deve più dipendere da una sessione MCP implicita.
La revisione rafforza anche l'autorizzazione, formalizza il quadro delle estensioni, introduce o stabilizza meccanismi come le richieste multi-fase, le app MCP e l'estensione Tasks per i lavori lunghi. Alcune capacità storiche sono deprecate. Il team deve leggere il changelog e testare i suoi client e server con gli SDK appropriati.
Distinguere protocollo e architettura d'impresa
Un'architettura aziendale aggiunge generalmente:
- registro dei server approvati;
- passerelle o proxy ;
- identità e delega;
- politica degli strumenti ;
- filtraggio di rete;
- segreti ;
- osservabilità ;
- cassetta di sabbia ;
- approvazioni ;
- processo di versione e ritiro.
Il cliente non dovrebbe poter connettersi liberamente a qualsiasi server scoperto su Internet da un ambiente sensibile.
Progettare l'identità e l'autorizzazione
L'accesso deve riflettere l'utente e il contesto. Un server non deve ricevere un token generale che dia più diritti della persona. Gli ambiti sono limitati alle capacità e risorse necessarie.
I principi includono:
- consenso esplicito;
- pubblico del gettone;
- durata breve;
- separazione client/server;
- rotazione ;
- protezione contro reindirizzamenti abusivi;
- revoca;
- registro delle autorizzazioni.
I diritti professionali vengono sempre ricontrollati dal servizio destinatario. Uno strumento MCP non è una scorciatoia per le API abituali.
Esporre strumenti sicuri
Gli strumenti sono piccoli, chiamati secondo il mestiere e convalidati da uno schema rigoroso. Non danno accesso a una shell o a una richiesta arbitraria. Restituiscono risultati strutturati e limitano i dati.
Per un'azione :
- identità ;
- portata ;
- validazione ;
- idempotenza ;
- anteprima;
- approvazione ;
- verifica;
- audit ;
- compensazione.
La descrizione dello strumento aiuta il modello, ma la politica indipendente determina se può essere chiamato.
Trattare risorse e interfacce come dati non affidabili
Un server può esporre un contenuto contenente istruzioni dannose. Il client deve separare dati e istruzioni e applicare le stesse protezioni utilizzate per il web o l’email.
Le applicazioni MCP o le interfacce rese dal server sono isolate, soggette a una politica di contenuto e private dell'accesso implicito ai segreti. La loro origine e le loro capacità devono essere visibili all'utente.
Gestire i compiti lunghi
Le attività agentiche possono durare oltre una richiesta. L'estensione delle attività fornisce un modello, ma l'applicazione deve ancora gestire:
- identità e autorizzazione durante la durata;
- stato ;
- cancellazione;
- ripresa ;
- scadenza;
- bilancio ;
- notifica ;
- risultato;
- idempotenza.
Un compito non deve conservare un potere indefinito. Le autorizzazioni possono scadere o richiedere una nuova approvazione prima di una fase sensibile.
Stateless non significa senza stato
Il cuore stateless semplifica l’infrastruttura, ma le applicazioni mantengono conversazioni, compiti, approvazioni e risultati. Questo stato deve essere esplicito, memorizzato in un sistema governato e associato a un’identità.
Il routing basato sugli header e le liste memorizzate nella cache richiedono una politica di privacy e di invalidamento. I metadati non devono rivelare capacità vietate.
Governare un catalogo di server
Ogni server è un fornitore di software, dati e azioni. Il registro deve includere:
- proprietario;
- provenienza ;
- versione ;
- capacità ;
- dati ;
- diritti ;
- ambienti ;
- dipendenze;
- supporto ;
- rischi;
- stato di approvazione;
- data di revisione.
Architettura MCP 2026-07-28 con cuore stateless, autorizzazione, strumenti, App ed estensione Tasks.
Qualificare un server di terze parti
Il team esamina il codice o la provenienza, la politica di aggiornamento, le vulnerabilità, la raccolta dei dati e le destinazioni. Un server può cambiare i suoi strumenti; il client deve rilevare la differenza e richiedere una nuova approvazione quando il rischio evolve.
Il pilota viene eseguito in un ambiente isolato, con dati sintetici e gettoni limitati. Vengono testati i comportamenti in caso di errore e di ritiro.
Passerelle e proxy
Un gateway aziendale può centralizzare autenticazione, lista autorizzata, limiti, registri e instradamento. Riduce la dispersione, ma diventa un componente critico. Deve preservare l'identità dell'utente ed evitare di diventare un super-account.
Può bloccare alcuni strumenti, trasformare gli scope, applicare una politica di destinazioni e fornire metriche. I log minimizzano i parametri sensibili.
Osservabilità
Ogni chiamata è correlata all’applicazione, all’utente, al server, allo strumento, alla versione e al risultato. Le metriche seguono latenza, errori, volume, costi, rifiuti, approvazioni e destinazioni.
Un aumento di chiamate, un nuovo strumento o una destinazione insolita provoca un allarme. La capacità di interruzione permette di sospendere un server senza distribuire tutti i clienti.
Migrazione verso 2026-07-28
La migrazione deve iniziare con un inventario dei clienti, server, SDK e funzionalità utilizzate. Il changelog identifica gli elementi deprecati e le modifiche del trasporto o dell’autorizzazione.
La procedura comprende:
- test di compatibilità in un ambiente separato ;
- aggiornamento degli SDK;
- eliminazione delle dipendenze dalla sessione protocollare;
- adattamento dell'autorizzazione;
- validazione degli schemi;
- test delle estensioni ;
- dispiegamento progressivo;
- osservazione ;
- ritiro del vecchio sentiero.
I client e i server potrebbero richiedere un periodo di coesistenza con versioni diverse.
Test di sicurezza
Tester :
- server non approvato;
- cambio di utensile;
- campo d'applicazione troppo ampio;
- gettone destinato a un altro server;
- contenuto iniettato;
- strumento generico;
- risposta malformata ;
- compito senza fine;
- cancellazione;
- destinazione esterna ;
- perdita di connessione;
- revoca.
Gli scenari diventano una serie di regressioni.
MCP come contratto di integrazione
MCP riduce il costo dei connettori e favorisce un ecosistema aperto. La sua adozione in azienda richiede la stessa disciplina delle API: catalogo, versione, sicurezza, osservabilità e responsabilità.
Partitech può sviluppare server e client MCP, progettare il gateway, qualificare gli strumenti e accompagnare la migrazione alla specifica 2026-07-28. Il protocollo diventa così un elemento controllato della piattaforma agentica, non una porta aperta verso tutti gli strumenti.
Parliamo del tuo progetto
Progettare un catalogo MCP sicuro e governato con Partitech. Contatta Partitech.