# mcp-ui-conference-monday-liad-yosef-2025-10-18

## Veille

Detailed MCP-UI conference talk, islands architecture, remote DOM, theming, distributed state, authentication, native clients - Monday.com

## Titre Article

MCP-UI: The Future of Agentic Interfaces (Conference Talk)

## Date

2025-10-18

## URL

https://www.youtube.com/watch?v=SIXTArBVL5w

## Keywords

MCP-UI, islands architecture, remote DOM, theming, sandboxed iframes, state management, authentication, native clients, post messages, web fragmentation, composable UI, intent-based communication, Shopify, Hugging Face, Postman, Monday.com

## Authors

Liad Yosef (AI & MCP Lead - Monday.com, co-modérateur UI work group)

## Ton

**Profile:** Professional-Technical | First-person demonstrative | Educational-Promotional | Intermediate-Expert

Yosef adopts a tech conference talk style combining architectural rigor and pragmatic demo. A clear problem→solution→architecture→demo→future structure reveals a seasoned presenter. Assumed technical language (sandboxed iframes, post messages, remote DOM, islands architecture) targets an audience of developers and architects. Memorable quotes frame the stakes ("providers lose identity", "wall of text for users"). The concrete Monday sprint management demo illustrates abstract concepts. The final transformative vision ("fragmented web → composable atoms") inspires without overselling. Typical of tech conference talks by senior engineers communicating architectural innovations with pedagogical clarity and tempered enthusiasm.

## Pense-betes

- **Dual problem**: loss of provider identity (Shopify/Airbnb/Amazon) AND degraded user experience
- **MCP-UI = open protocol** for sending UI via MCP + standardizing host/UI communication
- **Community SDKs**: Ruby, Python, TypeScript, Go in progress
- **Major adopters**: Shopify (full), Postman, Goose, Hugging Face (all spaces), 11 Labs
- **Islands architecture**: different UI islands composed within a single context
- **Communication spectrum**: notify → tool call → prompt → intent (increasing levels of responsibility)
- **Security**: sandboxed iframes, no access to host origin, communication via post messages only
- **4-level state**: agent context, internal app state, backend, cookies/localStorage
- **Multi-layer theming**: custom CSS, CSS variables, theme tokens, remote DOM
- **Remote DOM**: separation of structure/rendering, same server → visually different clients
- **Sprint management demo**: interactive Monday widget, automatic Gmail integration, reassign Jordan
- **Future**: auth/SSO, native clients (non web-views), capabilities negotiation
- **Vision**: fragmented web → apps deconstructed into composable atoms by personal assistant
- **mcpui.dev**: guides, walkthroughs, examples

## RésuméDe400mots

**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.

## GrapheDeConnaissance

- Liad Yosef —dirige→ UI work group MCP (ORGANISATION, 0.97)
- Liad Yosef —travaille_chez→ Monday.com (ORGANISATION, 0.98)
- MCP-UI —résout→ perte d'identité visuelle des fournisseurs (CONCEPT, 0.95)
- MCP-UI —utilise→ sandboxed iframes (TECHNOLOGIE, 0.97)
- MCP-UI —utilise→ islands architecture (METHODOLOGIE, 0.95)
- MCP-UI —utilise→ remote DOM (TECHNOLOGIE, 0.93)
- spectrum de communication —fait_partie_de→ MCP-UI (TECHNOLOGIE, 0.92)
- Shopify —utilise→ MCP-UI (TECHNOLOGIE, 0.97)
- Hugging Face —utilise→ MCP-UI (TECHNOLOGIE, 0.95)
- remote DOM —permet→ séparation structure UI et rendering (CONCEPT, 0.9)
- MCP-UI —permet→ recomposition du web fragmenté en atomes d'UI (CONCEPT, 0.88)
- capabilities negotiation —permet→ clients natifs non-webview (TECHNOLOGIE, 0.85)
- Monday.com —publie→ mcpui.dev (TECHNOLOGIE, 0.8)

---
Canonical: https://www.thekb.eu/en/fiches/mcp-ui-conference-monday-liad-yosef-2025-10-18/