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

How can a chat response become an interface you can actually use? Marlene Mhangami and Liam Hampton approach that question through MCP Apps, moving from the protocol’s basic roles to a working profiler inside VS Code. Mhangami introduces herself as a senior developer advocate at Microsoft and GitHub; Hampton works on developer tools advocacy for VS Code and GitHub Copilot.

Model Context Protocol (MCP) is an open protocol, created by Anthropic, that standardizes how applications provide context to language models. Its capabilities include tools, prompts, and resources. The architecture separates the application the user works in from the connections and programs that supply those capabilities.

You can build a server yourself or use an existing one. In VS Code’s Extensions view, searching for @mcp brings up available servers. Mhangami recommends starting with the VS Code or GitHub listings because an arbitrary server downloaded from the internet can contain malicious code. A server is executable software, so choosing one is also a trust decision.

Consider a request to draw a diagram explaining MCP. In the early experiences Mhangami describes, the response was often text: ASCII art, diagram source, or a README decorated with emojis. The limitation here is the interaction experience, not a historical rule that MCP could carry only text: the 2024-11-05 tools specification already supported images and embedded resources. A textual representation still leaves the user without a directly manipulable diagram.

MCP Apps let server tools provide rich interactive components that render directly in chat. Mhangami repeats the diagram request using the Excalidraw MCP App server. Instead of just reading the response, the user can work with the diagram. Her slide is a screenshot, but she describes the live app’s ability to move diagram elements and edit their text without leaving the conversation.

Mhangami traces the interaction with a simple analytics request:

1. The user asks, “Show me analytics.”
2. The agent chooses an appropriate tool exposed by an MCP server.
3. The server supplies results associated with a UI resource reference pointing to HTML.
4. The host—VS Code in this example—fetches the HTML and renders it inside a sandboxed iframe.
5. The user interacts with the app, which can request more server data and update its display.

The host renders the interface; the model selects the tool. That distinction explains why the HTML is fetched by VS Code rather than by the Copilot client in her account.

The presentation describes the UI reference as arriving with the result. In the current MCP Apps architecture, the tool definition declares _meta.ui.resourceUri, so the host can discover—and potentially preload—the UI before the tool finishes. Subsequent app-to-tool communication also passes through the host. The essential separation remains: the tool produces data, a resource supplies the interface, and the host connects them.

For data exploration, an initial question might reveal a trend in a bar chart. The next action is often narrower: inspect particular values or switch to another chart. Repeatedly describing those actions in text makes the user translate a visual intention back into language. Buttons and other controls let the user take the next step directly.

Commerce offers a related example, aimed more at general chat products than at VS Code. A shopping assistant can return a link and send the buyer to a browser, but Mhangami’s proposed experience keeps product selection and checkout inside chat. The UI carries the transaction forward instead of making the conversation merely a directory of destinations.

The examples span several kinds of interface:

• Shopify: Mhangami describes preserving a merchant’s website branding in the rendered components, with a full checkout experience inside chat. This is the experience she highlights, rather than a walkthrough of a particular checkout API.
• Excalidraw: Architecture diagrams become interactive visualizations. She also mentions an example she calls Quip Code.
• Figma: She describes generating components on the fly, although she does not show a rendered Figma app example.

The common design goal is to keep the task’s useful interaction surface alongside the conversation.

Hampton starts his implementation with a skill from the Model Context Protocol MCP Apps repository. He modifies it and runs it through GitHub Copilot CLI to generate several apps. His demo repository includes the FlameGraph example he will demonstrate, alongside a Markdown viewer, flight-status app, and color picker. The purpose is to keep the interaction within one working context: VS Code.

The implementation has three essential pieces:

A tool is distinct from the LLM that chooses it. Likewise, the resource is distinct from the tool’s data response: the host needs the association between them to know which interface should display that data. The frontend can be built with React, Vue, vanilla JavaScript, or Svelte.

The skill provides setup and run instructions, code examples, handlers, and tool-visibility guidance for the coding assistant. Visibility determines who can invoke a tool:

• Model only: The model can select it during the conversation.
• Model and app: Both the model and the embedded interface can invoke it.
• App only: The interface can invoke it without exposing it as a model-selectable operation.

That choice belongs in the app’s design because an interactive control and an agent need not have the same set of operations.

The Flamegraph Profiler app profiles a Go program containing bubble sort and a Fibonacci workload. These give the profiler recognizable functions whose execution costs can be inspected. A compact version of those two workload functions looks like this:

package workload

func BubbleSort(values []int) {
	for end := len(values) - 1; end > 0; end-- {
		for i := 0; i < end; i++ {
			if values[i] > values[i+1] {
				values[i], values[i+1] = values[i+1], values[i]
			}
		}
	}
}

func Fibonacci(n uint) uint64 {
	if n < 2 {
		return uint64(n)
	}
	return Fibonacci(n-1) + Fibonacci(n-2)
}

Bubble sort repeatedly compares neighboring values and swaps them when necessary. The recursive Fibonacci function repeatedly evaluates smaller Fibonacci inputs. Together they illustrate the kinds of application work the demo is set up to inspect.

Hampton configures a five-second profiling window using Go’s pprof. The MCP server runs on localhost, with a local entry point invoking the TypeScript server implementation. The important server operation prepares the Go program, runs it, profiles it, and returns the resulting data. Five seconds is the collection window, not a reported speedup.

The linked frontend is a React app Hampton calls Flame App. It uses hooks to receive tool input and results, then presents the profile as a flame graph and information about where the program spends its time. This is the practical value of the tool/resource split: profiling remains server work, while the frontend makes the resulting data easier to inspect.

With the MCP server installed and running, Hampton opens GitHub Copilot. The server exposes one tool, which he describes as “Profile the App.” He asks Copilot to profile the application; Copilot recognizes the installed Flame Graph Profiler, selects the tool, and begins loading the MCP App. The resulting interface appears inside an iframe in the chat window.

The interface exposes top functions and a profiling summary. Its size and presentation can be adjusted to fit the chat window; the onstage version is fairly large. Instead of repeatedly asking the model whether the profile is good or bad, or where time is being spent, the user can inspect the function information directly. Hampton’s claim is about reducing that conversational back-and-forth: the relevant data is already visible in the app.

The completed demo follows the same path as the earlier analytics example. A request to profile the application reaches the model, the model selects the tool, and the MCP server returns JSON data. The host recognizes the associated UI resource and renders the interface in chat. The model does not have to turn every part of the profile into prose before the user can explore it.

Hampton explains the iframe with a hamster analogy: leave a hamster loose in a room and it may chew things up; give it an enclosure and its activity stays contained. The corresponding goal is to keep an embedded app from having unrestricted access to VS Code settings or external systems. An iframe is part of that boundary, not a blanket ban on all external access: host permissions and content security policy govern permitted resources, and tool calls are mediated by the host. The interface can remain interactive without receiving the editor’s full authority.

The session closes with invitations to meet the GitHub team at its booth and continue learning through Microsoft Build’s code-focused sessions and workshops. The technical demonstration ends at the local server and embedded profiling UI: a useful application can live inside the conversation while the host retains responsibility for rendering and containment.