Duplice problema e soluzione
Liad Yosef (AI & MCP Lead presso Monday.com, co-moderatore del gruppo di lavoro UI) presenta MCP-UI come soluzione a un duplice problema. Primo, le interfacce testuali creano muri di testo per gli utenti. Secondo, e più critico, i provider (Shopify, Airbnb, Amazon) perdono la propria identità quando inviano solo testo - è la chat a decidere come visualizzarlo, privandoli del loro posto nella catena del valore. MCP-UI consente a ciascuna applicazione di inviare "UI chunks" - frammenti della propria identità - preservando il riconoscimento visivo e l'esperienza utente perfezionata negli anni.
Architettura tecnica e sicurezza
MCP-UI è un protocollo aperto + SDK per inviare UI tramite MCP e standardizzare la comunicazione host/UI. L'architettura si basa su sandboxed iframes che garantiscono la sicurezza: il codice UI non accede all'origin dell'host, non può sottrarre cookie/memoria, e comunica solo tramite post messages. Sono supportati tre tipi di contenuto: URL esterni, HTML grezzo, remote DOM (un concetto potente che separa la definizione della struttura dal rendering - lo stesso server MCP può inviare una risposta identica a client diversi che la renderizzeranno con i propri componenti).
Spettro di comunicazione e stato
MCP-UI definisce uno spettro di comunicazione che rappresenta i livelli di responsabilità della UI sulle azioni dell'utente: (1) Notify - la UI esegue un'azione backend e notifica la chat; (2) Tool call - la UI richiede l'attivazione di un tool specifico; (3) Prompt - la UI richiede l'esecuzione di un prompt; (4) Intent - la UI invia l'intento dell'utente, è l'host a decidere cosa fare. Questa architettura islands (diverse isole UI composte all'interno di un unico contesto) richiede una gestione dello stato sofisticata su 4 livelli: contesto dell'agente (per il flusso agentico), stato interno dell'app (preferenze, stepper via cookie/localStorage), backend (dati non rilevanti per il flusso agentico ma necessari per la sincronizzazione), e stato condiviso tra i componenti.
Dimostrazione concreta: gestione dello sprint
La demo mostra un engineering manager che chiede "stato dello sprint". Invece di testo inutile, MCP-UI restituisce un widget interattivo Monday con una ripartizione visiva. Cliccando su "stuck tasks" → viene visualizzato il task "implementazione dell'autenticazione" assegnato a Sarah. Cliccando su "analizza" → il meccanismo di comunicazione invia un prompt all'agente che, connesso a Gmail tramite un altro server MCP, recupera automaticamente le email scoprendo che Sarah è malata e che Jordan conosce il codice. Il widget inserisce un'analisi colorata che suggerisce la riassegnazione a Jordan. Cliccando su "riassegna" → un messaggio di intent attiva una chiamata a un tool MCP che completa il flusso. Punto cruciale: il provider non ha costruito l'integrazione con Gmail - è l'agente ad aver stabilito la connessione utilizzando il contesto esistente.
Theming multilivello
Per evitare un'esperienza da "compilation di UI di terze parti", MCP-UI supporta un theming sofisticato: CSS personalizzato (Shopify lo implementa già), variabili CSS, theme token, e remote DOM (il più potente - la UI remota viene renderizzata con i componenti dell'host, garantendo coerenza visiva pur preservando la struttura/interazioni del provider).
Adottanti ed ecosistema
Adozione massiccia già in corso: deployment completo di Shopify, Postman, Goose, Libra chat (host); Hugging Face (tutti gli space espongono MCP-UI), 11 Labs, MCP storefront (provider). SDK della community in Ruby, Python, TypeScript, Go. Progetto della community su mcpui.dev con guide complete.
Visione futura: il web frammentato ricomposto
Visione trasformativa: oggi si aprono 10 schede diverse (Amazon, Calendar, Booking) per un singolo compito (organizzare un compleanno), ciascuna con una UI complessa il cui 90% è irrilevante. Futuro: un assistente personale compone atomi di UI provenienti dai provider - Google Calendar invia un chunk relativo all'evento, Amazon un chunk con una lista di prodotti, Booking un chunk con annunci+mappa. Non è necessaria alcuna integrazione da provider a provider - l'assistente ha il contesto completo. Risultato: app decostruibili in componenti riutilizzabili, un Jarvis reso accessibile perché l'overhead di integrazione scompare.
Sfide della roadmap
Tre sfide principali: (1) Auth/SSO - attualmente lo stato è integrato nel contesto/UI o nell'autenticazione in-UI, serve un SSO fluido; (2) Client nativi - ChatGPT/Claude che diventano nativi, molti non supportano iframe/webview, si esplora un payload astratto convertibile in HTML o nativo con negoziazione delle capabilities; (3) Adozione dello standard - la tecnologia è pronta, serve slancio da parte della community.