Dual Problem and Solution
Liad Yosef (AI & MCP Lead at Monday.com, co-moderator of the UI work group) presents MCP-UI as a solution to a dual problem. First, text-based interfaces create walls of text for users. Second, and more critical, providers (Shopify, Airbnb, Amazon) lose their identity when they send only text - the chat decides how to display it, depriving them of their place in the value chain. MCP-UI allows each application to send "UI chunks" - pieces of their identity - preserving visual recognition and user experience perfected over years.
Technical Architecture and Security
MCP-UI is an open protocol + SDK for sending UI via MCP and standardizing host/UI communication. The architecture relies on sandboxed iframes guaranteeing security: the UI code does not access the host's origin, cannot steal cookies/memory, and communicates only via post messages. Three content types are supported: external URLs, raw HTML, remote DOM (a powerful concept separating structure definition from rendering - the same MCP server can send an identical response to different clients that will render it with their own components).
Communication Spectrum and State
MCP-UI defines a communication spectrum representing levels of UI responsibility over user actions: (1) Notify - UI executes a backend action and notifies the chat; (2) Tool call - UI requests triggering a specific tool; (3) Prompt - UI requests execution of a prompt; (4) Intent - UI sends the user's intent, the host decides what to do. This islands architecture (different UI islands composed within a single context) requires sophisticated state management across 4 levels: agent context (for the agentic flow), internal app state (preferences, steppers via cookies/localStorage), backend (data not relevant to the agentic flow but needed for synchronization), and state shared between components.
Concrete Demonstration: Sprint Management
The demo shows an engineering manager asking "sprint status". Instead of useless text, MCP-UI returns an interactive Monday widget with a visual breakdown. Clicking "stuck tasks" → displays the task "implementing authentication" assigned to Sarah. Clicking "analyze" → the communication mechanism sends a prompt to the agent which, connected to Gmail via another MCP server, fetches emails automatically discovering Sarah is sick, Jordan knows the code. The widget injects a colorized analysis suggesting reassignment to Jordan. Clicking "reassign" → an intent message triggers an MCP tool call completing the flow. Crucially: the provider did not build the Gmail integration - the agent made the connection using existing context.
Multi-Layer Theming
To avoid a "compilation of third-party UIs" experience, MCP-UI supports sophisticated theming: custom CSS (Shopify already implements it), CSS variables, theme tokens, and remote DOM (the most powerful - remote UI rendered with host components, guaranteeing visual consistency while preserving the provider's structure/interactions).
Adopters and Ecosystem
Massive adoption already underway: Shopify full deployment, Postman, Goose, Libra chat (hosts); Hugging Face (all spaces expose MCP-UI), 11 Labs, MCP storefront (providers). Community SDKs in Ruby, Python, TypeScript, Go. Community project at mcpui.dev with complete guides.
Future Vision: Recomposed Fragmented Web
Transformative vision: today one opens 10 different tabs (Amazon, Calendar, Booking) for a single task (planning a birthday), each with a complex UI 90% of which is irrelevant. Future: a personal assistant composes UI atoms from providers - Google Calendar sends an event chunk, Amazon a product list chunk, Booking a listings+map chunk. No provider-to-provider integration is needed - the assistant has full context. Result: deconstructible apps into reusable components, Jarvis made accessible because integration overhead disappears.
Roadmap Challenges
Three major challenges: (1) Auth/SSO - currently state is baked into context/UI or in-UI auth, need for seamless SSO; (2) Native clients - ChatGPT/Claude going native, many do not support iframes/webviews, exploring an abstract payload convertible to HTML or native with capabilities negotiation; (3) Standardization adoption - technology ready, needs community momentum.