MCP Apps per le aziende: servizi dentro Claude e ChatGPT

Ristoranti, e-commerce, hotel, configuratori, dashboard e processi interni: come trasformare un server MCP in un’applicazione interattiva e perché costruirla con Velthub.

2026-08-06

Il prossimo cliente potrebbe non arrivare dalla homepage del sito, ma da una conversazione. Immagina una persona che scrive a Claude o ChatGPT: “Trova un ristorante con opzioni senza glutine per domani sera, mostrami i piatti e prenota per quattro”. Invece di ricevere un elenco di link, vede direttamente nella chat menu, allergeni, orari disponibili, selettore del tavolo e riepilogo della prenotazione.

Questa non è più soltanto un’idea. MCP Apps è l’estensione ufficiale del Model Context Protocol che consente a un server aziendale di restituire interfacce HTML interattive: form, dashboard, mappe, cataloghi, configuratori e flussi di approvazione renderizzati dentro una conversazione. ChatGPT implementa lo standard aperto MCP Apps per le UI restituite dai server MCP; Claude web e Claude Desktop figurano fra gli host compatibili. Le estensioni sono però opt-in, richiedono negoziazione delle capability e il supporto può dipendere da client, versione, piano e rollout.

Per un’azienda significa aprire un nuovo canale digitale: non un altro chatbot che risponde soltanto con testo, ma un’applicazione collegata a disponibilità, CRM, e-commerce, ERP o sistemi di prenotazione. Il sito e l’app tradizionale restano importanti; MCP Apps aggiunge un punto di accesso nel luogo in cui l’utente sta già formulando il bisogno.

Da chatbot a interfaccia operativa

Un normale assistente conversazionale spiega. Una MCP App può anche far scegliere, confrontare, configurare e confermare. Il modello interpreta l’intenzione dell’utente, chiama gli strumenti esposti dal server MCP e decide quando presentare una UI. L’interfaccia vive accanto alla conversazione, conserva il contesto e può richiamare nuovi tool quando l’utente interagisce.

Lo standard usa due primitive MCP: un tool dichiara una risorsa UI tramite _meta.ui.resourceUri; la risorsa ui:// fornisce HTML, CSS e JavaScript. L’host la renderizza normalmente in un iframe sandboxed e dialoga con essa tramite JSON-RPC su postMessage. L’app può ricevere risultati, chiedere nuove chiamate agli strumenti e aggiornare il contesto visibile al modello.

Non ogni tool deve avere una schermata. Le documentazioni MCP e OpenAI suggeriscono di aggiungere UI quando la persona deve ispezionare, confrontare, modificare, confermare o navigare informazioni strutturate. Per un dato semplice può bastare il testo; per un calendario, un catalogo o una pratica da approvare, l’interfaccia riduce attrito ed errori.

Come funziona una MCP App aziendale

Dietro una UI apparentemente semplice c’è una separazione importante fra conversazione, presentazione e sistemi aziendali.

1. L’utente esprime un obiettivo, per esempio prenotare un tavolo o confrontare tre prodotti.
2. Il modello sceglie il tool MCP in base a nome, descrizione e schema dell’operazione.
3. Il server interroga i sistemi reali: gestionale, catalogo, CRM, calendario, ERP o API proprietarie.
4. Il risultato strutturato alimenta la UI, renderizzata in modo isolato dentro l’host.
5. L’utente interagisce con filtri, pulsanti, mappe o form; la UI può chiedere altre chiamate al server.
6. Le azioni sensibili richiedono conferma e autorizzazione prima di modificare dati, prenotare o acquistare.

Un pattern raccomandato, soprattutto nei flussi di ricerca, raffinamento e rendering finale, separa i tool dati dai tool di presentazione. Prima si cercano e filtrano le informazioni; soltanto quando il risultato è pronto si monta il widget. In questo modo l’app evita continui refresh dell’iframe e la logica di business rimane sul server, non dispersa nell’interfaccia. Non è però un requisito universale di MCP Apps.

Una sola applicazione, più superfici AI

Il vantaggio strategico è la portabilità. Se server e UI seguono MCP Apps, la stessa base può funzionare in più host compatibili. La matrice pubblicata sul sito MCP elenca oggi, fra gli altri, ChatGPT, Claude web, Claude Desktop, VS Code GitHub Copilot, Microsoft 365 Copilot, Cursor, Postman e Goose. La matrice è mantenuta dalla comunità e non costituisce una garanzia commerciale: prima del rollout va verificato il client, la versione e il piano target.

Nel caso di Claude, la guida indica i custom connector per server personalizzati sui piani a pagamento Pro, Max o Team, mentre Anthropic descrive un rollout progressivo fra i propri prodotti. Anche quando client e server dichiarano MCP Apps, l’estensione viene usata soltanto dopo la negoziazione delle capability.

Portabile non significa identico. Ogni host può offrire presentazioni e capacità aggiuntive. ChatGPT, per esempio, documenta estensioni proprie per checkout, file, modali e stato del widget tramite window.openai. Una soluzione ben progettata usa prima lo standard condiviso, rileva le capacità disponibili e prevede un fallback quando una funzione è specifica del client.

Anche autenticazione, distribuzione e revisione cambiano fra piattaforme. Per questo non basta trasformare una pagina web in un iframe: serve un prodotto progettato per essere guidato dal modello, sicuro nelle azioni e utile anche quando una UI non viene renderizzata.

OpenAI pubblica inoltre specifiche di conversione per Restaurant Reservation, Product Checkout e Local Services Get Quote. Al momento questi flussi pubblici sono in beta e testati con partner approvati: costruire il server e la UI non garantisce automaticamente il pulsante Reserve, il checkout inline o la comparsa nei risultati di ChatGPT. Per quelle superfici servono il contratto previsto, un feed idoneo e l’accesso approvato.

Nota sulle immagini: la cover e le visualizzazioni dei casi d’uso sono mockup concettuali realizzati da Velthub con GPT Image 2. Illustrano possibili interfacce MCP Apps e non sono screenshot di prodotti già in produzione.

Scenario 1: il ristorante diventa prenotabile nella conversazione

Un ristorante può esporre tool come search_availability, list_menu, check_allergens, create_reservation e cancel_reservation. La conversazione raccoglie il bisogno; la UI mostra ciò che il testo gestisce male: fotografie dei piatti, filtri alimentari, calendario, orari e tavoli disponibili.

Il flusso potrebbe partire da “Vorrei una cena romantica vegetariana venerdì”. L’AI filtra il menu, propone due fasce orarie e apre una scheda interattiva. L’utente sceglie, inserisce il numero di persone e conferma. Il server scrive nel gestionale soltanto dopo un consenso esplicito e restituisce il codice reale della prenotazione.

Per il ristoratore non è necessario sostituire il booking engine esistente: il server MCP può diventare uno strato controllato sopra API e database già presenti. Il valore sta nel rendere l’inventario prenotabile in un nuovo contesto, mantenendo regole su coperti, turni, allergeni e cancellazioni.

Scenario 2: e-commerce, confronto e configurazione senza cambiare scheda

In un e-commerce, la conversazione è efficace per esprimere vincoli: “Cerco una poltrona blu, larga meno di 80 centimetri, disponibile entro due settimane”. La UI è migliore per confrontare immagini, misure, varianti, prezzi, disponibilità e consegna.

Una MCP App può combinare search_products, get_product, check_inventory, configure_variant, add_to_cart e create_checkout. Il modello restringe il catalogo; un carousel presenta i candidati; una tabella mette in evidenza differenze e compatibilità. L’utente modifica colore o quantità e vede il riepilogo prima di procedere.

ChatGPT documenta window.openai.requestCheckout come estensione propria per l’Instant Checkout; disponibilità, idoneità del merchant e policy restano specifiche di ChatGPT. Sugli altri host serve un fallback, per esempio l’apertura del checkout sicuro dell’azienda. È importante non promettere un pagamento universale “dentro qualsiasi chat”: MCP rende portabili tool e UI, ma il completamento commerciale dipende dalle capacità del client, dalle policy e dall’infrastruttura del merchant.

Scenario 3: hotel, strutture ricettive e turismo

Per un hotel, “camera matrimoniale con spa e parcheggio dal 12 al 14 settembre” è un input naturale. L’app può visualizzare camere disponibili, fotografie, servizi, policy, supplementi e mappa. Tool distinti gestiscono ricerca, preventivo, disponibilità e conferma.

La UI riduce il rischio di perdere dettagli fra molti messaggi: numero degli ospiti, bambini, trattamento, accessibilità e cancellazione restano visibili nello stesso riepilogo. Prima della prenotazione, il server può verificare nuovamente disponibilità e prezzo nel PMS, evitando di presentare come confermato un dato obsoleto.

Scenario 4: preventivi per servizi e appuntamenti

Software house, installatori, consulenti, officine, centri estetici e studi professionali possono trasformare un questionario rigido in un configuratore guidato. Il modello chiarisce il bisogno; la UI raccoglie opzioni, allegati, disponibilità e dati necessari senza costringere l’utente a conoscere il linguaggio tecnico.

Un installatore fotovoltaico potrebbe mostrare tipo di immobile, consumi, superficie e fascia di investimento; un’officina potrebbe identificare il veicolo, proporre gli slot e preparare la richiesta; una società di consulenza potrebbe comporre un brief e fissare una call. Il preventivo definitivo deve provenire dalle regole aziendali, non essere inventato dal modello.

Scenario 5: immobiliare con mappa, filtri e visite

Le ricerche immobiliari sono iterative: zona, budget, metratura, distanza dai servizi, classe energetica. L’AI può interpretare preferenze espresse in linguaggio naturale; la MCP App presenta schede e mappa, permette di salvare candidati e prenotare una visita.

La documentazione OpenAI usa proprio il caso degli annunci immobiliari per spiegare il pattern disaccoppiato: il tool dati recupera candidati e metadati, il modello li raffina rispetto alla domanda successiva e un tool dedicato renderizza soltanto gli ID finali. È un buon esempio di collaborazione fra ragionamento e interfaccia, senza trasferire la logica di selezione nel widget.

Scenario 6: configuratori B2B e ricambi industriali

Nei prodotti industriali il cliente spesso deve combinare modello, potenza, misure, accessori, certificazioni e tempi di consegna. Un catalogo tradizionale può diventare dispersivo; una risposta testuale può nascondere incompatibilità. Una MCP App può guidare la configurazione, evidenziare vincoli e generare una distinta preliminare collegata a listini e disponibilità reali.

Lo stesso approccio vale per i ricambi: l’utente descrive il macchinario e il problema, il server identifica le parti compatibili, la UI confronta codici e immagini, poi apre una richiesta di offerta o un ordine. Le regole critiche — compatibilità, sconti, approvazioni — devono restare nel backend aziendale.

Scenario 7: dashboard e approvazioni interne

MCP Apps non è soltanto un canale verso il cliente. Un’impresa può portare in Claude, ChatGPT o un altro host compatibile una dashboard collegata a ERP, CRM, ticketing e data warehouse. Il manager chiede “Mostrami le commesse in ritardo e spiegami le cause”; il modello prepara il perimetro, la UI mostra KPI e drill-down.

Per note spese, ordini, ferie o richieste di acquisto, l’interfaccia può presentare documenti, importi, policy e pulsanti di approvazione. È essenziale separare lettura e scrittura, applicare permessi per ruolo e richiedere conferma sulle azioni irreversibili. L’AI non deve aggirare il processo: deve renderlo più comprensibile e rapido.

Scenario 8: assistenza clienti e interventi sul campo

Un tecnico può descrivere il guasto, caricare una fotografia, consultare manuali e vedere una procedura visuale. Se serve un intervento, l’app mostra disponibilità, ricambi e stato del ticket. Per il cliente, la stessa infrastruttura può offrire tracking, appuntamento e cronologia senza aprire portali diversi.

Una UI persistente è utile quando il lavoro dura nel tempo: passaggi completati, log, allegati e stato devono rimanere visibili. Per operazioni lunghe si può combinare MCP Apps con l’estensione Tasks, se supportata dal client e dal server, senza presentarla come capacità universale.

Scenario 9: HR, onboarding e servizi ai dipendenti

Un dipendente potrebbe chiedere “Quanti giorni di ferie ho e quali date non si sovrappongono al mio team?”. Il server consulta il sistema HR, il modello interpreta la domanda e la UI presenta calendario, saldo e policy. La richiesta parte solo dopo conferma e autorizzazione.

Nell’onboarding, una MCP App può mostrare checklist, documenti mancanti, account da attivare e formazione. L’accesso deve seguire identità e ruoli aziendali; dati personali e documenti non vanno esposti al modello o al widget oltre quanto necessario.

Scenario 10: CRM e commerciale aumentato

Un commerciale può chiedere “Preparami le opportunità da seguire oggi”. La UI mostra pipeline, valore, ultimo contatto e prossima azione; il modello sintetizza il contesto. Da lì si può aprire una scheda, pianificare un’attività o preparare una bozza di email, lasciando all’utente la decisione finale.

Per la direzione, la stessa app può aggregare andamento per area, motivi di perdita e forecast. Il vantaggio non è solo vedere un grafico nella chat: è poter interrogare il dato, cambiare perimetro e avviare l’azione successiva nello stesso flusso.

Da quale caso d’uso conviene partire?

La prima MCP App non dovrebbe essere il processo più grande dell’azienda. Conviene scegliere un flusso frequente, con dati disponibili, confini chiari e un risultato misurabile.

Le metriche dipendono dal caso: completamento del flusso, tempo medio, errori, richieste gestite senza passaggio manuale, qualità dei lead o adozione interna. Non esiste un incremento di conversione garantito: il vantaggio va dimostrato con un pilot e confrontato con il percorso esistente.

Sicurezza: l’interfaccia è sandboxed, il business no

L’iframe sandboxed impedisce alla UI di leggere il DOM, i cookie e il local storage della pagina host. La UI può mantenere il proprio stato e richiedere capacità aggiuntive, ma è l’host a controllare permessi e canale di comunicazione. È una buona base, non una protezione completa dell’intero sistema. Il server MCP resta responsabile di autorizzazione, validazione degli input, rate limiting, audit e segregazione dei dati.

Per dati specifici del cliente o azioni di scrittura, OpenAI richiede un flusso OAuth 2.1 conforme alla specifica MCP; nell’implementazione ChatGPT viene usato authorization code con PKCE e il server deve verificare issuer, audience, scadenza e scope di ogni token. Per Claude e gli altri host occorre verificare separatamente il contratto di autorizzazione supportato dal client, dal piano e dall’ambiente di distribuzione. In azienda possono entrare in gioco Entra, Okta o altri identity provider, oltre a gruppi, ruoli e policy.

Ogni operazione dovrebbe avere il minimo privilegio. Cercare prodotti non richiede gli stessi scope di creare un ordine; leggere una pratica non equivale ad approvarla. Tool e annotazioni di sicurezza sono parte dell’esperienza, perché aiutano l’host a decidere quando chiamare un’azione e quando chiedere conferma.

Perché affidare una MCP App a Velthub

Costruire il widget è soltanto una parte. Il vero progetto comprende processo, integrazioni, sicurezza, esperienza conversazionale e distribuzione. Velthub propone un servizio dall’idea al pilot operativo, con l’obiettivo di evitare che MCP diventi una demo scollegata dai sistemi reali.

• Analisi del processo: proposta di identificazione del flusso dove conversazione e UI possono produrre un vantaggio concreto.
• Progettazione di tool e interfacce: definizione di letture, rendering, azioni, schemi, fallback e conferme.
• Integrazione: piano di collegamento con CRM, ERP, e-commerce, calendari, database e API esistenti.
• Autenticazione e governance: progettazione di OAuth 2.1, scope, ruoli, audit, segreti e protezione delle azioni sensibili.
• Portabilità: approccio standards-first con isolamento delle estensioni specifiche dei singoli host.
• Deployment e osservabilità: definizione di endpoint HTTPS, monitoraggio, errori, latenza, versionamento e ambienti di test.
• Validazione: piano di test e misurazione prima dell’estensione del perimetro.

Il nostro obiettivo non è vendere “un connettore” generico. È trasformare un servizio aziendale in un’esperienza che l’AI possa capire, presentare e azionare con confini chiari. Quando serve, la stessa infrastruttura può alimentare più host; quando una funzione non è portabile, viene progettato un fallback esplicito.

Il percorso Velthub: dal processo al prodotto

1. Discovery: processo, utenti, dati, rischi e metriche.
2. Blueprint: tool MCP, risorse UI, autorizzazioni e architettura.
3. Prototype: interfaccia concettuale collegata a dati controllati.
4. Pilot: integrazione reale su un perimetro limitato.
5. Hardening: sicurezza, test, logging, fallback e prestazioni.
6. Distribuzione: connessione privata, pubblicazione o rollout interno secondo il caso.

Questo percorso riduce due rischi opposti: costruire troppo prima di sapere se gli utenti lo vogliono, oppure lanciare una demo fragile su dati e azioni reali. Il primo risultato utile può essere circoscritto, ma deve avere già fondamenta da prodotto.

La valutazione di Velthub

Il punteggio usa cinque criteri ponderati: impatto strategico 25% (9,5), qualità dell’esperienza 20% (9,3), portabilità 20% (8,7), maturità produttiva 20% (8,3) e accessibilità all’integrazione 15% (9,7). La media ponderata è 9,09, arrotondata a 9,1.

9,1/10. MCP Apps è una delle opportunità più concrete per trasformare gli assistenti AI da interfacce testuali a canali operativi. Il valore cresce quando l’azienda ha dati aggiornati, API accessibili e un processo in cui visualizzazione e conversazione si completano.

Il voto non è 10 perché l’ecosistema è ancora in evoluzione: il supporto varia, le estensioni specifiche possono ridurre la portabilità e la distribuzione pubblica dipende dalle policy dei singoli host. Inoltre un’applicazione senza autorizzazioni, fallback e osservabilità può creare più rischio che vantaggio.

Il momento giusto per iniziare non è quando tutto sarà standardizzato. È quando esiste un caso d’uso delimitato su cui costruire un pilot misurabile. Un ristorante può partire dalle disponibilità; un e-commerce dal confronto; un’azienda dalla dashboard in sola lettura. Da lì si aggiungono azioni e superfici soltanto dopo aver verificato utilità e sicurezza.

Vuoi capire quale MCP App costruire?

Velthub può analizzare il processo, progettare la UI, sviluppare il server MCP e collegarlo ai sistemi aziendali. Il primo passo è identificare una domanda semplice: quale operazione vorresti permettere a un cliente o a un dipendente di completare direttamente dentro la conversazione?

Da quella risposta si può costruire un blueprint concreto: utenti, strumenti, interfaccia, dati, autorizzazioni, host compatibili e metriche del pilot. Non una presentazione astratta sull’AI, ma un percorso tecnico e operativo verso un’applicazione utilizzabile.

Domande frequenti

Una MCP App sostituisce il sito o l’app mobile?

No. Aggiunge un canale conversazionale e operativo. Sito e app restano utili per navigazione completa, SEO, contenuti e percorsi che non beneficiano del contesto AI.

La stessa MCP App funziona su Claude e ChatGPT?

Lo standard MCP Apps è pensato per la portabilità e la matrice pubblicata sul sito MCP elenca entrambi, ma è community-maintained e non garantisce disponibilità uniforme. L’estensione è opt-in; per Claude i custom connector indicati dalla guida richiedono un piano a pagamento compatibile e il rollout può variare. Prima del progetto vanno verificati client, versione, piano e capability, oltre ai fallback per funzioni host-specific come alcune API window.openai.

Serve rifare il gestionale?

Non necessariamente. Il server MCP può esporre in modo controllato API e operazioni dei sistemi esistenti. La qualità dell’integrazione dipende però da dati, permessi e affidabilità delle fonti.

È sicuro mostrare dati aziendali nella chat?

Può esserlo se l’architettura applica autenticazione, scope, ruoli, audit e minimizzazione dei dati. L’iframe protegge l’host dalla UI, ma non sostituisce la sicurezza del server e dei backend.

Quanto tempo serve per un progetto?

Dipende da integrazioni, identità e profondità del flusso. Velthub propone di partire da un pilot delimitato; una stima attendibile nasce dopo discovery tecnica e accesso alle API, non da una promessa standard.

Qual è il miglior primo caso d’uso?

Un processo frequente, con dati disponibili, confini chiari e risultato misurabile. Prenotazioni, cataloghi comparabili e dashboard in sola lettura sono spesso candidati migliori di un workflow aziendale totale.

https://velthub.ai/blog/mcp-apps-aziende-interfacce-chatgpt-claude-velthub-v2