Building Interactive UIs in VS Code with MCP Apps — Marlene Mhangami & Liam Hampton, GitHub

1 MCP Fundamentals

▶ 0:14

Marlene opens with a quick refresher on the Model Context Protocol (MCP) — an open protocol created by Anthropic that standardizes how applications provide context to LLMs. The key word is open: the community can build on it freely, and it allows LLMs to access three types of context:

• Tools — executable functions the LLM can call
• Prompts — reusable prompt templates
• Resources — data sources the LLM can read from

The session focuses specifically on MCP tools and how a new primitive — the MCP App — extends what tools can return beyond plain text.

2 Hosts, Clients & Servers

▶ 1:51

Marlene breaks down the three-part MCP architecture that matters for understanding MCP Apps:

• Hosts — programs like VS Code that want to access data from MCP servers. The host is responsible for rendering UI (this becomes critical for MCP Apps).
• Clients — maintain the one-to-one connection with servers. Sometimes the same as the host, but not always. In VS Code, the recommended client is GitHub Copilot.
• Servers — lightweight programs that expose specific capabilities through MCP. You can build your own or use existing ones. In VS Code, typing @mcp in the extensions tab shows available servers.

3 The Text-Only Limitation

▶ 3:19

When MCP was first released, tools could only return text. Marlene illustrates this with a concrete example: asking the LLM to "draw a diagram explaining what MCP is." The result? ASCII art. She points out a pattern in the community — GitHub repository READMEs became filled with ASCII art and emoji-heavy text because there was no way to generate actual diagrams or rich visual content through MCP tools.

This leads to the core question that motivated MCP Apps:

4 Enter MCP Apps

▶ 4:12

MCP Apps let server tools return rich, interactive components that render directly in the chat window. Instead of getting a text description, the user sees an actual UI element they can click, drag, scroll, and interact with — all without leaving the conversation.

Marlene demonstrates this with the Excalidraw MCP server: the same "draw a diagram of MCP" prompt now produces an actual interactive diagram that the user can:

• Move elements around
• Edit text directly
• Resize and rearrange components

The diagram is a live element in the chat — not a screenshot, not a link to an external tool, but a fully interactive canvas.

5 How MCP Apps Work — The Architecture

▶ 5:15

Marlene walks through the full data flow of an MCP App interaction, step by step:

1. User sends a prompt — e.g., "Show me analytics"
2. Agent + LLM decides which tool to call — connects to the appropriate MCP server
3. Server returns tool results with a UI resource reference — this is the key innovation. The response includes not just data but a reference pointing to an HTML element the server has generated
4. The host (VS Code) fetches the HTML — note: the host, not the client (GitHub Copilot), fetches the UI
5. Host renders the app in a sandboxed iframe — the user sees and interacts with the UI directly in chat
6. App calls back to the server — enabling live, bi-directional interaction
7. Server returns fresh data — the UI updates dynamically

6 Use Cases

▶ 6:33

Marlene outlines two primary use cases that demonstrate the value of MCP Apps:

Data Exploration

Imagine exploring a dataset entirely through text chat — you'd have to type out every follow-up query, every "now show me the bar chart for X," every "zoom into that trend." With MCP Apps, the data visualization renders as an interactive UI: you can click on chart elements, filter data, and drill down visually rather than typing each request. This drastically reduces the friction of iterative data analysis.

E-Commerce

This is where MCP Apps get particularly compelling beyond VS Code. In a chat UI (whether VS Code, OpenAI's interface, or any other host), a user could go through an entire checkout experience — browsing products, selecting options, and completing payment — without ever leaving the chat window. Previously, asking a chat client to help you buy something would result in a list of links, forcing you to navigate to a browser.

7 Who's Building MCP Apps

▶ 8:06

Three notable companies are already building production MCP Apps:

• Shopify — building full checkout flows inside chat. Marlene highlights their focus on brand consistency: the in-chat UI elements should match the company's website design so the user experience feels seamless. Users can literally go through the entire purchase process — browsing, selecting, paying — all within the chat window.
• Excalidraw — interactive diagrams rendered in chat. Popular for architecture diagrams that users can drag, edit, and rearrange. Used by tools like Claude Code to visualize system designs.
• Figma — generating design components on the fly with MCP Apps. While Marlene notes she couldn't find a good screenshot, Figma's integration lets users create and manipulate design components directly in the chat interface.

8 Anatomy of an MCP App

▶ 9:35

Liam takes over and dives into the code structure. He references a skill from the Model Context Protocol repository (Anthropic's official repo) that he adapted for his demos. An MCP App has three main parts:

1. The Tool — the LLM-facing interface plus the host (VS Code). This is where the MCP server registers its capabilities.
2. The Resource — the bundled HTML UI. This can be built with any framework: React, Vue, Svelte, vanilla JS — whatever the developer prefers for rendering the frontend.
3. The Link — the connection between the tool's data response and the UI resource. The host and MCP server recognize this link to know when and how to render the frontend.

Tool Visibility Modes

Liam explains that MCP Apps support different visibility configurations for who can invoke the tool:

• Model only — only the LLM can call the tool
• Model + App — both the LLM and the rendered app can call the tool
• App only — only the rendered UI can invoke the tool (useful for user-driven interactions)

Skill-Driven Development

The skill file Liam references tells Copilot CLI (or Claude or other AI tools) exactly how to set up, run, and build MCP Apps — including code examples for handlers and visibility configurations. This is a skill-driven workflow: the AI tool reads the skill and generates the correct boilerplate.

9 Live Demo — Flame Graph Profiler

▶ 11:31

Liam demonstrates the full MCP App workflow with a flame graph profiler. The setup:

The Go Application

A simple Go file with two functions: a bubble sort (comparing array values — "standard coding interview stuff") and a Fibonacci sequence (n+1, big O complexity). This provides measurably different performance characteristics for the profiler to capture.

The MCP Server

Written in TypeScript, running on localhost. The server:

• Bundles up the Go program
• Runs it with Go's built-in pprof profiler for 5 seconds
• Captures the profiling data
• Links the data to a React-based flame graph UI

The React App

A React application (flame-app) using hooks that:

• Receives tool input from the MCP server
• Processes the profiling results
• Renders an interactive flame graph showing where time is spent across functions

The Demo in Action

Liam opens GitHub Copilot in VS Code, verifies the MCP server is running (one tool: "profile the app"), and asks Copilot to profile the application. Copilot:

1. Recognizes the flame graph profiler tool is available
2. Calls the tool
3. The MCP App loads inside the chat window
4. An interactive flame graph renders, showing top functions and performance summaries

The rendered UI is fully interactive — users can scroll, resize, and explore the flame graph. Liam notes that traditionally, developers would have to copy profiling data, paste it into the chat, and ask "Is this good? Is this bad? Where am I spending my time?" — a tedious back-and-forth. The MCP App eliminates this by making the data visually explorable inline.

10 The Sandbox Model — Why Iframes

▶ 14:47

Liam explains why MCP Apps render inside sandboxed iframes with one of the talk's most memorable analogies:

The sandboxed iframe ensures the MCP App cannot:

• Interact with VS Code settings
• Access external APIs
• Read or modify the user's workspace
• Interact with other extensions or the editor itself

This is a critical security boundary. The app is fully contained within the chat window — it can only communicate back to its own MCP server through the established channel. This sandboxing is what makes it safe to render arbitrary HTML from third-party MCP servers.

Liam summarizes the complete flow: prompt → LLM → tool call → MCP server runs → JSON data → host recognizes resource link → iframe renders → user interacts inside chat.

🎯 Key Takeaways

🔗 Resources & Links

• Model Context Protocol — Official MCP specification and documentation
• MCP GitHub Organization — Official repositories including the skills referenced in the demo
• Marlene Mhangami (GitHub) — Speaker's GitHub profile
• Liam Hampton (GitHub) — Speaker's GitHub profile

⏱ Timestamp Index