MCP per i chatbot del sito web: integrare strumenti con OAuth e autorizzazioni

MCP rende i chatbot per siti web più operativi, ma solo con limiti chiari

MCP per i chatbot AI non è un connettore magico che affida improvvisamente qualsiasi sistema a un chatbot per siti web. Il Model Context Protocol descrive piuttosto un'interfaccia comune attraverso la quale un modello può scoprire e richiamare strumenti: ad esempio una ricerca in una knowledge base, una richiesta di ticket, una logica di prenotazione o una verifica interna sui dati di prodotto. Questo è particolarmente interessante per i chatbot dei siti web, poiché molte conversazioni non si concludono con una semplice risposta. I visitatori chiedono informazioni sullo stato della spedizione, sui prezzi, sui canali di contatto, sui moduli, sulla disponibilità o sui passaggi successivi. Senza strumenti, il bot deve limitarsi a spiegare. Con gli strumenti, può recuperare dati rilevanti o avviare azioni preimpostate in modo controllato e tracciabile.

La domanda cruciale, quindi, non è: un chatbot può usare gli strumenti? La vera domanda è: quali strumenti può vedere in un determinato contesto, con quale token può richiamarli, con quale autorizzazione umana può eseguirli e con quale tracciamento potrà spiegarli in seguito? La specifica finale di MCP del 28 luglio 2026 rafforza proprio questi aspetti operativi. Rende il core stateless, richiede metadati rilevanti per singola richiesta e precisa come si collegano l'autorizzazione HTTP remota, OAuth, gli scope e il binding dell'audience dei token.

Cosa cambia per i team web con la specifica 2026-07-28

Il cambiamento architetturale più importante è il core stateless. Un server MCP non deve presumere che le richieste precedenti sulla stessa connessione abbiano già stabilito un contesto, le capability del client o una sessione. Tutto ciò che è necessario per l'elaborazione deve essere presente nella richiesta corrente. Per le infrastrutture web distribuite questo è molto pratico: le richieste possono essere smistate su diverse istanze dietro load balancer, edge gateway o piattaforme di worker. Per chi implementa, tuttavia, significa anche: nessuna assunzione nascosta sulle sessioni di trasporto, nessun diritto implicito derivante da una connessione precedente e nessuna conversazione di chat utilizzata come perimetro di sicurezza.

Ogni richiesta richiede i metadati _meta necessari. Tra questi rientrano in particolare la versione del protocollo e le client capability; le informazioni sul client sono utili per l'interfaccia, i log e il debugging, ma non sono valide come prova di sicurezza. Se un sito web serve più istanze del bot, lingue o aree clienti, questo strato di metadati deve essere volutamente convalidato e registrato nei log. Non sostituisce l'autorizzazione di business, ma garantisce che il server possa classificare correttamente le richieste.

Gli elenchi di strumenti sono dinamici, ma non arbitrari

tools/list nella specifica attuale è impaginato e cachabile. Le risposte possono contenere indicazioni sulla cache come ttlMs e cacheScope. Allo stesso tempo, l'ordine deve rimanere deterministico, a patto che l'insieme di strumenti sottostante non cambi. Non si tratta solo di ottimizzazione delle prestazioni: se i cataloghi di strumenti sono ordinati in modo stabile, i client possono salvarli in cache in modo più affidabile e i contesti del modello rimangono più stabili.

È importante notare la sfumatura nell'autorizzazione. L'insieme degli strumenti può variare da una richiesta all'altra in base all'autorizzazione presentata, ad esempio perché un token concede solo diritti di lettura sui dati di supporto ma non di scrittura su un CRM. Tuttavia, non deve fluttuare in modo casuale come effetto collaterale di richieste precedenti sulla stessa connessione. Per i chatbot dei siti web ne deriva un modello chiaro: il catalogo di strumenti visibile si compone in base a ruolo, scope, tenant, lingua, contesto e livello di rischio della richiesta corrente.

Le descrizioni degli strumenti non sono una base di fiducia

Gli strumenti MCP descrivono il loro nome, i loro input, facoltativamente gli output e le annotazioni. Questi metadati aiutano il modello e l'interfaccia utente a comprendere la funzione, ma non rappresentano un'ancora di sicurezza. La specifica afferma chiaramente che i client devono trattare le annotazioni degli strumenti come non attendibili, a meno che non provengano da server fidati. Uno strumento che si descrive come in sola lettura deve essere comunque costruito lato server in modo da non eseguire effetti collaterali di scrittura.

Questo vale anche per i risultati strutturati. Un outputSchema aiuta a convalidare le risposte invece di restituire semplice testo libero al modello. Ciononostante, i server devono verificare gli input, controllare gli accessi, impostare rate limit e sanificare gli output. Un chatbot per siti web non dovrebbe inserire i risultati degli strumenti nelle risposte visibili senza prima filtrarli, specialmente se sono coinvolte API esterne, dati dei clienti o contenuti simili all'HTML.

OAuth: Il server MCP è una risorsa protetta

Nel caso di MCP HTTP remoto, la divisione dei ruoli è fondamentale. Un server MCP protetto agisce come OAuth Resource Server. Il client MCP opera per conto di un Resource Owner, tipicamente un utente o un'organizzazione. L'Authorization Server interagisce con l'utente, se necessario, ed emette gli Access Token. Il server MCP deve fornire i propri Protected Resource Metadata affinché i client possano individuare l'Authorization Server corretto. L'Authorization Server deve mettere a disposizione almeno uno dei metodi di discovery: OAuth Authorization Server Metadata o OpenID Connect Discovery; il client MCP deve supportarli entrambi.

Per i product team questo significa che il chatbot non dovrebbe gestire direttamente password, API key o token terzi se è previsto un flusso OAuth. Dovrebbe invece guidare l'utente verso un'autorizzazione chiara, utilizzare successivamente un Access Token dedicato e limitare visibilmente gli strumenti consentiti da quel token. Per la registrazione dei client sono preferibili i Client ID Metadata Documents; la Dynamic Client Registration rimane disponibile solo per retrocompatibilità ed è deprecata. Questa separazione è importante soprattutto nelle integrazioni con calendari, CRM, helpdesk, archivi documentali o e-commerce, poiché la stessa conversazione passa spesso da domande pubbliche ad azioni legate all'account.

I token devono essere vincolati alla risorsa di destinazione

L'attuale specifica di autorizzazione richiede i Resource Indicator secondo l'RFC 8707. Il client deve impostare il parametro resource nelle richieste di autorizzazione e di token, indicando la URI canonica del server MCP a cui il token è destinato. Il server MCP deve verificare che l'Access Token sia stato emesso esattamente per la propria risorsa. I token non devono mai essere trasmessi tramite query string, ma vanno inseriti nell'header Authorization.

Questo vincolo di audience impedisce una scorciatoia pericolosa: un token destinato al servizio A non può essere accettato o inoltrato al servizio B. I chatbot per siti web necessitano quindi di un perimetro di token ben definito per ciascun server MCP e per ciascun ambiente. Preview, Staging e Production non dovrebbero condividere la stessa audience se rappresentano risorse distinte. Allo stesso modo, un aggregatore che unifica più server MCP davanti a un modello non deve mescolare i token.

Gli scope sono un contratto di UX e sicurezza

È consigliabile partire con scope ridotti. La specifica suggerisce di utilizzare le indicazioni sugli scope presenti nelle challenge WWW-Authenticate e di consentire un flusso di step-up in caso di permessi mancanti. All'atto pratico: un visitatore può inizialmente operare con strumenti di sola lettura. Solo quando un'azione richiede maggiori privilegi (come creare un ticket, scrivere un file o preparare un ordine), il sistema richiede in modo mirato l'autorizzazione aggiuntiva.

Un buon design del consenso non indica soltanto il nome dell'integrazione, ma anche il suo impatto: quali dati vengono letti? Quale azione viene preparata? Qualcosa viene salvato all'esterno, inviato o modificato in modo permanente? Per le operazioni sensibili, l'utente dovrebbe visualizzare una conferma esplicita con la possibilità di rifiutare. Non si tratta di consulenza legale, ma di una regola di progettazione tecnica: le autorizzazioni devono essere comprensibili per le persone, applicabili dai server e tracciabili per gli audit.

Un'architettura solida per i chatbot web con MCP

Un'architettura robusta separa il modello, la facciata degli strumenti e i sistemi di destinazione. Il chatbot del sito web non comunica direttamente con ogni servizio di terze parti, ma passa attraverso un client o gateway MCP che controlla la versione del protocollo, le capability del client, lo stato di autenticazione, i rate limit e l'osservabilità. Dietro questo strato si trovano i server MCP per le singole integrazioni o aree funzionali. Ogni server dichiara solo gli strumenti consentiti per la richiesta corrente e convalida nuovamente ogni singola chiamata.

La facciata degli strumenti dovrebbe utilizzare nomi stabili, schema di input rigorosi e schema di output chiari. I nomi degli strumenti devono essere sufficientemente univoci, specialmente se più server offrono funzioni simili come search, create o lookup. In caso di aggregazione, un namespace o un prefisso risulta molto utile. I parametri devono essere progettati in modo che il modello non debba inventare dati grezzi e riservati. Se una procedura si sviluppa su più richieste, il server dovrebbe restituire un handle esplicito a breve termine e riautorizzarlo ad ogni chiamata successiva.

Un secondo elemento fondamentale è l'interfaccia utente. I visitatori dovrebbero poter vedere quando viene richiamato uno strumento, quali input vengono inviati e quando è necessaria un'autorizzazione. Per i semplici accessi in lettura è spesso sufficiente uno stato trasparente. Per le azioni di scrittura, a pagamento, esterne o che coinvolgono dati personali, serve invece una conferma più consapevole. La specifica lascia aperti i pattern di interfaccia, ma richiede chiaramente che le applicazioni consentano il controllo umano sulle chiamate agli strumenti.

Checklist di rilascio per MCP nei chatbot AI

1. Creare un inventario degli strumenti: quali sistemi devono essere collegati, quali strumenti sono di sola lettura, quali modificano i dati e quali richiedono la conferma umana?
2. Definire gli scope: suddividere i permessi in base alle azioni e non ai team interni. Uno strumento per la verifica dello stato richiede scope diversi rispetto a uno per creare, modificare o inviare informazioni.
3. Verificare la discovery OAuth: testare per ciascun ambiente i Protected Resource Metadata, gli Authorization Server Metadata, la registrazione dei client e le URI di reindirizzamento.
4. Forzare il vincolo dell'audience: accettare i token solo per la URI canonica del server MCP, non inoltrarli mai a risorse errate e non inserirli mai negli URL.
5. Rendere tools/list deterministico: testare insieme l'ordinamento stabile, la paginazione, i suggerimenti di cache e i filtri di autorizzazione.
6. Mantenere rigorosi gli schema: convalidare gli input, utilizzare output strutturati e disattivare di default il caricamento automatico da rete di riferimenti $ref esterni (consentendolo eventualmente solo tramite allowlist, timeout, limiti di dimensione e tracciamento).
7. Costruire le autorizzazioni nell'UI: rendere visibili il nome dello strumento, lo scopo, gli input, il sistema di destinazione, lo step-up dello scope e l'opzione per rifiutare.
8. Garantire l'osservabilità: registrare nei log ID richiesta, nome dello strumento, scope, decisione, errori, latenza e tipo di risultato, evitando di memorizzare inutilmente contenuti sensibili.
9. Testare la gestione degli errori: trattare risposte 401, 403, token scaduti, scope mancanti, handle sconosciuti, timeout e autorizzazioni rifiutate come normali stati dell'applicazione.
10. Iniziare gradualmente: portare in produzione prima uno o due strumenti di sola lettura a basso rischio, per poi aggiungere progressivamente step-up, azioni di scrittura e ulteriori integrazioni.

Errori tipici nell'implementazione

L'errore più comune è concedere un token iniziale con permessi troppo ampi. Se un chatbot per siti web ottiene subito ampi diritti di scrittura dopo il primo accesso, ogni decisione del modello diventa più rischiosa. È molto meglio iniziare con uno scope minimo e applicare uno step-up mirato. Il secondo errore è creare un catalogo di strumenti basato sui nomi dei sistemi interni anziché sulle intenzioni dell'utente. Un modello lavora in modo più affidabile con azioni chiare e ben descritte piuttosto che con endpoint generici multiuso.

Il terzo errore è la mancanza di separazione tra la fiducia nel modello e la fiducia nel server. Il modello può suggerire un'azione, ma è il server a decidere se gli input sono validi, se il token è corretto e se è presente l'autorizzazione. Il quarto errore è la mancanza di tracciabilità. Se in un secondo momento non è chiaro quale strumento abbia letto o modificato determinati dati con quale scope, diventa impossibile gestire correttamente sia il supporto che la sicurezza.

Approfondimenti

Questo articolo tratta lo strato di integrazione MCP: core stateless, tools/list e OAuth HTTP. I seguenti articoli approfondiscono la sicurezza generale degli strumenti e la loro gestione operativa: Per il modello di autorizzazioni consultare KI-Chatbots: Tools sicher mit Rechten und Bestätigungen nutzen. Per la strutturazione concreta delle chiamate agli strumenti vale la pena leggere KI-Chatbot-Tool-Aufrufe sicher gestalten. Se i risultati degli strumenti devono rimanere elaborabili dalle macchine, si veda Strukturierte KI-Chatbot-Ausgaben validieren. Per il monitoraggio e la risoluzione dei problemi, il proseguimento tecnico ideale è KI-Chatbot-Observability für Traces, Retrieval und Tools.

Fonti ufficiali

La base tecnica è la specifica finale di MCP 2026-07-28: la pagina su MCP Tools, la sezione MCP Authorization, l'articolo ufficiale The 2026-07-28 Specification e la panoramica Base Protocol Overview.

Conclusione

MCP per i chatbot AI diventa davvero prezioso quando i team web non lo considerano una cassetta degli attrezzi aperta, ma uno strato di integrazione controllato. La specifica 2026-07-28 si adatta perfettamente alle moderne infrastrutture web: richieste stateless, elenchi salvabili in cache, header HTTP instradabili e autorizzazione esplicita per risorsa. Allo stesso tempo, rende le responsabilità ancora più chiare. Gli strumenti disponibili devono corrispondere al token corrente, le operazioni sensibili richiedono il controllo umano e ogni chiamata deve essere convalidata lato server.

L'approccio pratico prevede un avvio graduale: uno strumento di sola lettura, uno scope ristretto, un testo di consenso chiaro, una tool discovery deterministica e log dettagliati. Successivamente è possibile collegare altri strumenti senza trasformare il chatbot in una scatola nera. In questo modo, il chatbot del sito web non diventerà un agente incontrollato, ma un assistente trasparente e affidabile, autorizzato a utilizzare solo i sistemi approvati per l'utente e il compito corrente.