A talk by Marlene Mhangami and Liam Hampton (GitHub) on building interactive UIs inside VS Code using MCP Apps. The session demos a Go app running bubble sort and Fibonacci whose results render as an interactive, sandboxed flame graph directly in the VS Code chat window. The underlying mechanism: an MCP tool returns data plus a resource reference to bundled HTML, which VS Code renders in a sandboxed iframe; the UI calls back to the server for fresh data and updates live. Noted examples of this pattern include Shopify checkout flows and Excalidraw-style draggable architecture diagrams. The speakers walk through building one from scratch using a skill from the MCP repository. # Channel Presentation Observations ## Explicit Self-Description - **Speakers identify as developer advocates**: Marlene Mhangami states, *"My name is Madelaine and I'm a senior developer advocate at Microsoft and GitHub."* Liam Hampton adds: *"I'm Liam Hampton and I also am working at Microsoft and GitHub on the developer tools advocacy team for Visual Studio Code and GitHub Copilot."* - The title itself frames the channel/session identity: **"Building Interactive UIs in VS Code with MCP Apps — Marlene Mhangami & Liam Hampton, GitHub"**, indicating a GitHub/Microsoft-affiliated presentation. ## Claimed Scope - The session covers: **what MCP is, why MCP apps are needed, what they are**, and **live demos of building and using MCP apps in VS Code** — stated explicitly in the agenda portion of the talk. - The speakers describe building demo MCP apps across multiple frameworks: *"You've got React, you've got vanilla JS, you've got Vue, Svelte, etc."* ## Intended Audience (Observable Evidence) - **Developers familiar with AI tooling**: Marlene polls the live room: *"how many of us know what MCP is. Okay, that's a good that's a good amount of the room."* Liam later asks *"Who's using MCP apps already?"* — indicating a conference audience of practitioners. - **Working developers/engineers**: Liam notes *"I'm a Go engineer. I write a lot of Go code"* and demonstrates profiling with Go pprof, targeting hands-on developers. - **VS Code / GitHub Copilot users**: presenters *"usually encourage people to use the client GitHub Copilot"* and demo inside VS Code specifically. ## Demonstrated Presentation Patterns - **Educational, conference-session format**: audience polling, an explicit agenda, slide references, and time-boxing (*"I believe that is actually at time now"*). - **Live coding demos**: Liam shows a working MCP server (*"I have it installed here, and there is one tool for it... There we go. It's rendered out a UI in an iframe"*) rather than only slides. - **Security-conscious guidance**: recommending the curated VS Code server list over random internet servers *"because sometimes you can have some security issues... it can have malicious stuff in it."* - **Promotional closing**: an invitation to *"our booth at GitHub"* and **Microsoft Build** (*"third to the sixth, I think, of June"*), consistent with corporate advocacy representation. ## Claims vs. Demonstration Distinction - **Creator claims about scope**: the stated agenda and speaker roles — both directly quoted above. - **Demonstrated capability**: actual on-screen demo of an MCP app (a flame graph profiler) rendering inside VS Code chat, with step-by-step architecture explanation (host fetches HTML, renders in *"a sandboxed iframe"*). # Delivery Observations — Marlene Mhangami & Liam Hampton, "Building Interactive UIs in VS Code with MCP Apps" ## 1. Two-Presenter Format with Clear Role Division - The session splits into a **conceptual overview** (Marlene) and a **live demo** (Liam), with an explicit handoff: "I think that's all I'm going to cover and now Liam is going to go ahead and do our live demo." - Liam opens his segment by acknowledging the handoff: "Yeah, nice one. Thank you." ## 2. Audience Interaction as a Structural Device Both presenters poll the room with show-of-hands questions — a repeated pattern across speakers: - Marlene: "maybe I can ask uh the question of how many of us know what MCP is. Okay, that's a good that's a good amount of the room." - Liam mirrors this moments later: "Who's using MCP apps already? Okay, there's like all right, perfect." - Later: "who who who here has used flame graphs or touched them or kind of know?" ## 3. Marlene's Delivery Features ### Conversational connective phrasing - Frequent use of **"So,"** to launch explanation steps: "So, MCP apps let server tools return rich interactive components…", "So, when MCP was first released…" - **Self-questioning as transitions**: "A good question to ask is how can we create rich UI experiences in chat?" and "Who is currently building MCP apps? I think this is a good question to ask." ### Concrete, relatable examples - Explains limitations with everyday specifics: "you can go to a GitHub repository and most of the readmes have ASCII art or they have a lot of emojis. I feel like we were overcompensating with emojis." - Uses hypothetical user speech: "maybe they'll say, 'Show me analytics.'" and "you can ask your client, can I buy something online?" ### Practical, safety-oriented asides - Volunteers security guidance mid-explanation: "sometimes you can have some security issues if you just go on the internet and pick a random server, it can have malicious stuff in it." ### Self-correction on stage - "Spotify is not Spotify, Shopify." — caught and corrected in real time. ## 4. Liam's Delivery Features ### Humorous analogies - Signature moment: "The reason we're doing this in an iframe or the why the iframe is the same reason that you put a hamster in a cage, right? If you don't let it loose in a room, it's just going to chew things up." ### Personal authority framing - Anchors the demo in his own practice: "I'm a Go engineer. I write a lot of Go code, but all I really care about in here is a bubble sort algorithm." - References borrowed/reused material transparently: "I actually borrowed borrowed a skill which is on the Model Context Protocol repository online." ### Narrating the live demo in real time - Repeated time-marking fillers during the demo: "I'll just give this just a moment to run. There we go." and "Give it just 1 second to load. There we go." - Casual assessment of output: "it's a very nasty bit of data you get out at the end, and it's all jumbled up." ### Colloquial register - "massaged as you want to make it fit your chat window" - "it's going to spit out some data" / "spit out a number of different MCP apps" ## 5. Shared Patterns Across Both Speakers - **Verbal fillers**: frequent "uh" and "um" from both, e.g., Marlene's "Uh it's an open protocol so hope thankfully the community can use it." - **List-based teaching structure**: both enumerate ("So, just to get a bit of an overview…", "you can see that there is three main parts to an MCP app"). - **Repetition for emphasis**: Liam's "You're actually getting rid of it. You just have it all available to you in here."; Marlene's "it is open. Uh it's an open protocol." ## 6. Uncertainty Notes - No curated metadata was supplied, so tone observations rest solely on transcript text — **pauses, pace, and vocal tone cannot be verified**. - Some apparent repetitions (e.g., Marlene vs. Liam both polling the audience) are based on only **two instances each**, so these are noted as observed moments rather than confirmed habits. - Presenter name spellings vary in the transcript ("Madelaine", "Marlene", "Marlon"); exact pronunciation/naming cannot be confirmed from the text alone. # Observation Record: Building Interactive UIs in VS Code with MCP Apps **Speakers:** Marlene Mhangami (introduced as "Madelaine"/"Marlene"/"Marlon" in transcript) and Liam Hampton, both developer advocates at Microsoft/GitHub. > Note: The transcript renders Marlene's name inconsistently ("Madelaine," "Marlene," "Marlon"); identification is based on video metadata and self-introduction. --- ## 1. What MCP Is — Marlene Mhangami - **MCP** is an **open protocol** that standardizes how applications provide context to LLMs; it was **created by Anthropic**. - It allows LLMs to access context such as **tools, prompts, and resources**. ### MCP Architecture Components - **Hosts**: programs like VS Code that want to access data from MCP servers. - **Clients**: maintain a **one-to-one connection with servers**; sometimes the same as the host, but not always. In VS Code, Marlene says they "usually encourage people to use the client GitHub Copilot." - **Servers**: lightweight programs exposing specific capabilities through MCP; can be self-built or selected from existing ones. ### Security Qualification (Marlene) - She recommends using the server list in VS Code rather than picking random servers from the internet, because random servers "can have malicious stuff in it." --- ## 2. Motivation for MCP Apps — Marlene Mhangami - **Stated limitation of early MCP**: it mostly returned **text only**. - She claims GitHub repos' reliance on ASCII art and emojis in READMEs was "overcompensating" because rich diagrams couldn't be generated with available tools. - **MCP apps** let server tools return **rich interactive components rendered directly in chat**. - Example: the **Excalidraw MCP server** returned a diagram of MCP that the user can **move around and edit** as a live element in chat. ### How MCP Apps Work (Marlene's stated flow) 1. User sends a prompt (e.g., "Show me analytics"). 2. The agent/LLM decides which MCP tool to call. 3. Server returns tool results with a **UI resource reference** pointing to server-generated HTML. 4. The **host** (VS Code, not the client/Copilot) fetches the HTML. 5. Host renders the app in a **sandboxed iframe**; the app can call back to the server for fresh data. ### Use Cases (Marlene) - **Data exploration**: clicking buttons in a UI instead of repeatedly typing chat queries about datasets. - **E-commerce**: full checkout inside chat UIs (she notes "maybe not as much in VS Code, but in other chat UIs like OpenAI"), keeping users in chat instead of following links out to a browser. ### Builders Mentioned (Marlene) - **Shopify**: focused on preserving brand feel in chat-rendered elements; she cites a talk she listened to (not shown) on this. - **Excalidraw**: generating architecture/interactive diagrams, e.g., in "Cloud Code" (likely Claude Code per context; stated as "Cloud Code"). - **Figma**: generating components on the fly; Marlene qualifies she "couldn't find a picture of a nice Figma MCP app rendered." --- ## 3. Live Demo — Liam Hampton - Built MCP apps by **borrowing a skill from the Model Context Protocol repository online (from Anthropic)**, editing it, and running it through **GitHub Copilot CLI** to generate multiple apps (flame graph, markdown viewer, flight status, color picker, etc.). ### Three Main Parts of an MCP App (Liam) - **Tool**: the LLM plus the host (VS Code). - **Resource**: bundled HTML UI — "could be in React, that could be in Vue, whatever." - **Link**: the host/server recognizing the link between the data response and a renderable UI. - The **skill** defines handler code examples and **tool visibility**: whether only the model invokes the tool, the model plus the app, or only the app. ### Demo Details - Go example with a **bubble sort** and **Fibonacci sequence**; MCP server profiles the code over **5 seconds** using **Go pprof**. - Server runs on localhost; TypeScript server code bundles the Go program, runs it, profiles it, returns data; React flame-graph app with hooks renders results. - Copilot recognized the installed "profile the app" tool and rendered the UI in an iframe within chat, showing top functions and a summary. - **Claimed benefit**: eliminates the "back and forth" of asking the model "is this good? Is this bad?" — data is directly visible in the UI. ### Iframe Security Rationale (Liam) > "The reason we're doing this in an iframe... is the same reason that you put a hamster in a cage... You don't want this application to interact with your VS Code settings, any APIs, anything external." --- ## 4. Closing — Both - GitHub/Microsoft booth available at the venue. - **Microsoft Build** will focus on code with workshops, "third to the sixth, I think, of June" (Marlene expressed mild uncertainty on the dates: "I think"). # Speaker Attribution & Provenance Record **Video ID:** `01a15ca9-10de-7fdf-99b8-9e102267cf5a` **Title:** Building Interactive UIs in VS Code with MCP Apps — Marlene Mhangami & Liam Hampton, GitHub ## Speakers & Roles - **Marlene Mhangami** (transcribed variously as "Madelaine" / "Marlon") — **Co-presenter / creator-adjacent speaker**. Self-identified: *Senior Developer Advocate at Microsoft and GitHub*. Delivered the conceptual/overview portion (what MCP is, MCP apps, use cases). - **Liam Hampton** — **Co-presenter / demo presenter**. Self-identified: works at Microsoft and GitHub on the **developer tools advocacy team for VS Code and GitHub Copilot**; identifies as a **Go engineer**. Delivered live demos. - **Audience** — Present (hands raised in response to poll questions); no speaking lines. - No separate narrator; no other identified speakers. ## Referenced Sources & Third-Party Claims - **MCP (Model Context Protocol)** — described as an **open protocol created by Anthropic** standardizing how applications provide context to LLMs. - **Skill from the Model Context Protocol repository online** — Liam states he **borrowed a skill from Anthropic's repository, edited it, and ran it through GitHub Copilot CLI** to generate MCP apps. - **Third-party companies cited as building MCP apps:** - **Shopify** — checkout experiences in chat; claim sourced by Marlene to *"a really good talk"* she attended (unspecified talk/speaker). - **Excalidraw** — diagram generation; also referenced via "Cloud Code" (likely transcription of Claude Code). - **Figma** — component generation via MCP apps; Marlene notes she *couldn't find a picture of a Figma MCP app rendered*. - **Technologies referenced:** VS Code, GitHub Copilot, Copilot CLI, Go pprof, React, Vue, Svelte, TypeScript, OpenAI (mentioned as an example chat UI). ## Promotional Segments — FLAGGED - **Closing segment:** Invitation to visit the **GitHub/Microsoft booth** ("fourth floor... third floor" — speaker appears uncertain of location) and to attend **Microsoft Build** (stated as "third to the sixth, I think, of June"), described as focusing on code with workshops. ## Provenance / Availability Limits - No curated metadata was supplied beyond the title; speaker name spellings are uncertain due to transcript variations ("Madelaine"/"Marlon" vs. title's "Marlene Mhangami"). - No timestamps available in the transcript. - **Comment availability:** not indicated in the supplied material. - Speaker uncertainty flagged inline: booth floor ("fourth floor on the third floor"), Build dates ("I think"). Hi everyone. Uh we'll introduce ourselves. My name is Madelaine and I'm a senior developer advocate at Microsoft and GitHub. \>\> And likewise, I'm Liam Hampton and I also am working at Microsoft and GitHub on the developer tools advocacy team for Visual Studio Code and GitHub Copilot. \>\> Yes. I do similar things but probably Liam is more in the VS Code side as well. Um so just to get started, a bit of an agenda of what we're going to cover today in this session. We're going to talk about what MCP is and then we're going to talk about why we need MCP apps and what they are. And then Liam is going to do some live demos of how to use MCP apps, how to build them and use them in VS Code. So just to get started, maybe I can ask uh the question of how many of us know what MCP is. Okay, that's a good that's a good amount of the room. Okay, good. That means that we are up to date. I will do a quick then summary uh to talk about what it is but MCP, of course, is an open protocol that standardizes how applications provide context to LLMs. So it was created by Anthropic. Uh it is open. Uh it's an open protocol so hope thankfully the community can use it and it allows us to access context or LLMs to access context like tools or prompts or resources um in different ways. So just to get uh a bit of an overview of which parts of MCP we will be looking at with MCP tools. The first thing is that we have MCP hosts. And hosts are prob are programs like VS Code that want to access data from your MCP servers. So, you can have different types of hosts, um and they will come with different clients as well. So, the second thing is that we have clients and these are sometimes going to be the same as the host, but not all of the time. And these will maintain the one-to-one connection with the servers. So, in our case in VS Code, we usually encourage people to use the client GitHub Copilot. And that's what we'll be looking at today. And then the final thing would be the servers. And with servers, these are going to actually lightweight programs that expose specific capabilities through MCP to provide that context. And you can build your own servers or you can use any of the many servers that are available out there. So, in VS Code, if you actually go to the extensions tab and you type in at MCP, you'll get of different servers that are available. We definitely encourage you to use the server list that is in VS Code just because sometimes you can have some security issues if you just go on the internet and pick a random server, it can have malicious stuff in it. So, we recommend using um what's there in in VS Code or or GitHub. So, when MCP was first released, one of the downsides was that you would pretty much only have it return text. So, if someone was going to ask a question like in this case, I would ask a question asking it to draw an image, a diagram explaining what MCP is. And so, a lot of the times in the early days of MCP or in general of LLMs, you can go to a GitHub repository and most of the readmes have ASCII art or they have a lot of emojis. I feel like we were overcompensating with emojis because we actually couldn't generate diagrams or interesting rich text with MCPs or the tools that we had available to us. So, a good question to ask is how can we create rich UI experiences in chat? So, this is exactly where MCP apps comes into play. So, MCP apps let server tools return rich interactive components that render directly in the chat. So, you're able to have the server actually return these nice UI elements so that you can be able to interact with them directly in the chat and also just improves the general visual element of things as well. So, I showed earlier that ASCII art example where it was text returned. I asked the same question using the Excalidraw MCP server, which now uses an MCP app to generate a diagram that explains MCP. And you can see that it generates This is a just a screenshot of of what it looks like. But there, another really cool thing is that you can actually interact with that diagram. You can go ahead and move it around um even update the text and so on because this is a live element that's actually available in the chat. So, how do How do you MCP apps actually work? A good example is that maybe we have a user. We start by the user asking a question. So, they'll send a prompt. Maybe they'll say, "Show me analytics." And the agent with the LLM is going to decide which tools to call using the MCP server. It'll connect and then decide on a tool. And then the server is going to return the tool results with a UI a resource reference. So, MCP has MCP resources, and this reference will point to an HTML element that is stored that the server has generated. Then the host, so not the client, it wouldn't be GitHub Copilot, but the host, which is VS Code, is going to fetch the HTML from that UI reference that was referenced from the server, and then the host is going to render the app inside a sandboxed iframe. So, the user at that point is able to interact with the iframe in the host, and there's really a nice separation there between the two. And then the app can call back to the server back and forth so that you have this live interaction experience. And then the use the server can return fresh data, and the app will update as well. Some different use cases for MCP apps. One, for example, is data exploration. You can think of if you are Imagine if we were just typing into a chat all the time, and we wanted to understand more about a data set. It'd be difficult to interact with the database. It'd be difficult to always type in and ask new questions. Oh, you know, maybe you found out information about a trend in with the bar chart, and then you wanted to find more information about um maybe some specific numbers in another chart, and actually typing in that information is going to be tiring for the user when they can just click different buttons in the UI in that way. Another thing is e-commerce. I think this is a really great example where a user maybe in one case would want to be able to actually buy something in the chat UI. So, maybe not as much in VS Code, but in other chat UIs like in OpenAI or something like that, the user should be able to in the chat actually go ahead and buy and go through the entire checkout experiences in the chat instead of just typing out in the past what would happen is maybe you type you can ask your client, can I buy something online? And then it would just return links to you and then you'd have to navigate over to the browser. What we want is to keep the user inside the chat and then have them interact and have that experience there. Who is currently building MCP apps? I think this is a good question to ask. Spotify is not Spotify, Shopify. Shopify is an example of a company that's currently building with MCP apps. And I listened to a really good talk about how they're also focusing on keeping the brand experience of a company the same as if you were on the company's website. If the user is in the chat, the elements that are rendered should be the same and it should give the same brand feel. So, they're really working on the UI elements that are returned so that the user can literally go through the full checkout experience like I was mentioning to be able to actually buy in the chat. Another group that are using MCP apps like I mentioned before is Excalidraw. That is really popular right now for maybe generating architecture diagrams or having interactive diagrams. If you go go to Cloud Code for example, they have really nice MCP apps that use Excalidraw to just generate an image visualizing things. Figma is another company that's using MCP apps. I couldn't find a picture of a nice Figma MCP app rendered, but generally speaking they have components that you can generate on the fly with MCP apps. So, I think that's all I'm going to cover and now Liam is going to go ahead and do our live demo. \>\> Yeah, nice one. Thank you. So, everybody put their hand up when Marlon asked who's using MCP or who knows what MCP is. Who's using MCP apps already? Okay, there's like all right, perfect. Uh shout at the back if you can't see this. Um but essentially an MCP app is going to allow us to really interact or stay within one context such as VS Code. So, the way that I do this is I actually borrowed borrowed a skill which is on the Model Context Protocol repository online. So, it's from Anthropic. I edited it a little bit and I ran it through GitHub Copilot CLI. That allows me to spit out a number of different MCP apps. So, in this repository here I've got a flame graph one. That's the one we're going to be showing today. Uh but I've got a markdown viewer, flight status, um color picker, etc. Just the gen generic ones that you just go through when you're starting to build these projects. So, starting with this uh readme, you can see that there is three main parts to an MCP app. You've got the tool which is the LLM itself and the host, i.e. at the moment VS Code. You've got the resource which is then the bundled HTML HTML UI which you're going to be putting together. That could be in React, that could be in Vue, whatever, however you want to render your UI. Uh and then you've got the link between the two. So, the host and the MCP itself or the server are going to recognize the link between having the actual data response and a UI being available to render. So, there's good ways you can do this. Like I said, you've got React, you've got vanilla JS, you've got Vue, Svelte, etc. So, you can just go through this whole skill. This is going to basically tell Copilot CLI or Claude or whatever AI tooling that you're using how to run this or what to do when it comes to running this skill. Uh it's going to set it up in a certain way uh and it's going to tell you exactly how to run it as well and how it should be run with code examples such as handlers, tool visibility, um so whether it's just the model that can call the application, whether it's the model and the app, or whether it's just the app. So, that's who invokes the tool at any given point. So, for this example I'm going to be using a Go file. I'm a Go engineer. I write a lot of Go code, but all I really care about in here is a bubble sort algorithm. So, just comparing an array values together, pretty standard in any coding interview. Uh and then we've got the Fibonacci sequence as well. So, n + 1. This is like big O. So, essentially just adding to the next one before it. What I'm doing there is I'm going to use an MCP server to profile the application code over 5 seconds to see where is the time being spent most in this application. As any profiling would do, this is using Go pprof, so the underlying profile that you get in Go. But, essentially the MCP server is running localhost. This is the entry point in here. It's just a server that I'm running locally. That then calls out to the server TypeScript. This is all written in TypeScript as per the skill that was enabled. Of this entire file, this is the one that really matters the most, where the MCP is going to bundle up my Go program, run it, profile it, and spit out some data. And it's at that point that the UI is then linked to the MCP server itself to render the front end. I Over here, we have the React app flame app, which is using hooks in React. And in here, we can see that we're going to look at the receiving the tool input. We got the results. We got the um uh where it's spending basically most of its time and the flame graph itself. So, who who who here has used flame graphs or touched them or kind of know? Basically, it's a very nasty bit of data you get out at the end, and it's all jumbled up. Um this is a really nice way to profile and see how it's working. So, I'm going to open up GitHub Copilot and my make sure my MCP server is running. I have it installed here, and there is one tool for it. So, profile the app. Hopefully, if I go and ask GitHub Copilot, it should still be working. It should recognize that it needs to call the tool itself. So, I'll just give this just a moment to run. There we go. It's noticed I've got the flame uh flame graph profiler installed. Should be using this, loading the MSP app. Give it just 1 second to load. There we go. We can close this. Here, this is what an MSP app is really looking like inside the chat window. So, it's rendered out a UI in an iframe. We can look at the top functions and the summary of how this is running. This can be edited and then run down and sort of massaged as you want to make it fit your chat window. Mine is pretty big. Uh but this gives a general overview of exactly what they're looking like and how you can match them. Typically, what I would be doing with this data is asking my AI models is this good? Is this bad? Where am I spending my time? There's a lot of back and forth. With a UI app that we have inside an iframe, you are just eliminating that. You're actually getting rid of it. You just have it all available to you in here. So, you can see where it's spending most of its time in the functions, etc., etc. So, that's a really good way to use it. Now, I wrote a very rudimentary drawing, which was a little bit better um on Marlene's slide here. But essentially, what I've done is I said profile my application. That has been sent to the LLM model, which has then said I need to call this tool. The MSP server's run, gives me back some JSON data, passed it to the host. The host has recognized that there's a resource to link and therefore it has been rendered in an iframe in the chat window. The reason we're doing this in an iframe or the why the iframe is the same reason that you put a hamster in a cage, right? If you don't let it loose in a room, it's just going to chew things up. You don't want this application to interact with your VS Code settings, any APIs, anything external, all of that kind of stuff. So, you want to keep it all contained inside the chat window. That's the reason why it's in an iframe. And I believe that is actually at time now. So, I guess Marlene, anything else? \>\> Uh nope. Uh we are Microsoft is here. GitHub has a booth on the fourth floor on the third floor. So, oh. Uh How do I get back? Need to be in the camera. But, GitHub has a booth available. We also have Microsoft Build this year that's really going to be focusing on code and we'll have a bunch of workshops. It's going to be on the third to the sixth, I think, of June. So, we'd invite you to come by either our booth at GitHub or to check out Microsoft Build as well online. But, yeah, thanks for joining us. \>\> So, that's it. Thank you.