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

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.

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.

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