973: The Web’s Next Form: MCP UI  ## Document Notes ## Highlights - **MCP Standardizes Context And Tool Calling** - MCP standardizes how agents get contextual data and call external tools so models stop relying on copy-paste context hacks. - This lets many services (Sentry, GitHub, etc.) expose reusable capabilities to any agent that supports MCP. Transcript: Kent C. Dodds Yeah, it's, there was a joke, I think yesterday by Dax, he said that nobody wrote down what MCP stands for. And now nobody can remember. Scott Tolinski Yeah, I saw that. And the moment I read that tweet, I was just thinking, yeah, that's, that's right. I don't remember what it stands for. Kent C. Dodds Yeah. Yeah. It's a model context protocol. And so we talk a lot about context engineering with AI and how important it is to get the right context into the model so that it can actually do the things that you want it to do. The model context protocol is all about that. Without going way too deep into all the history here, most of us remember when AI first started being a part of our workflows. And a lot of that workflow was just copy pasting things into the chat and then copy pasting things back out. MCPUI is about eliminating that or not UI necessarily, but MCP generally is about eliminating the need to get things into the context window and then get things out of the context window Back into the real world. So we've had the ability to call tools from these models for a long time, but the mechanisms for doing that were not standardized. And so what MCP does is just standardize that. And so if you're a service provider, you have some context, like Sentry is actually a great example of this. They have an awesome, you all have an awesome MCP server. And you have a lot of context that developers want in their chats. And so by building an MCP server, you can work with any agent that supports MCP. ([Time 0:03:10](https://share.snipd.com/snip/c11e9e2c-18f1-48a0-abab-44bf7d689eaa)) - **Using MCP To Manage Personal RSS Feeds** - Kent built MediaRSS and hooked it to MCP so ChatGPT can inspect and modify his kids' audiobook feeds for him. - He uses it regularly to ask the agent to add missing books to a child's library. Transcript: Kent C. Dodds Yeah. Another practical example is I just, I've had this app for a long time. I rebuilt it recently. It's called Media RSS. It's open source. You can find it on my GitHub. But basically what it does is I've got a directory of media files, mostly audio books and that sort of thing. And I just point my app to this directory and it turns it into an RSS feed. And I can create lots of different RSS feeds and stuff. And so I've got an RSS feed for each one of my kids. And then I add the books that I think they're okay listening to and whatever. And yeah, so of course I hook up MCP to that. And now I can go to ChatGPT and I say, what books is Rebecca missing that like she should probably have in her library? Yeah, go ahead and add those. And it's actually like a really practical thing that I use regularly now. ([Time 0:05:45](https://share.snipd.com/snip/a4776dab-461c-4265-9166-e9c865311a1e)) - **Context Bloat Requires Dynamic Tool Selection** - Context bloat makes models overweight irrelevant tool descriptions and confuses decisions about which tool to call. - Dynamic selection of relevant MCP tools per user prompt is becoming essential to avoid that overload. Transcript: Scott Tolinski So to give some people, some folks, I mean, we're talking about like context in regards to, you know, giving the AI as much context as it needs to fix any problem. What happens, Kent, when that context becomes bloated? Kent C. Dodds Yeah, I think most people listening who've used AI, like know that things tend to get kind of funny when it gets bloated. And most AI harnesses have mechanisms for like dealing with that, whether that be summarize the conversation to keep it going or whatever. It always seems to get turned sideways in that situation. And honestly, like, it's actually a lot like a human. If you approach a human developer or something, you say, here's like everything that you could possibly know about this code base. Now I want you to go fix this button. They might be a little confused about which button you're talking about. They could get confused about what parts of all the things you just told them were relevant to the task that you're giving them. And so the real challenge for anybody working with AI is to know the right context to include and the right context to exclude and make sure that you're only including the right stuff. So one criticism of MCP is that for the model to know whether to call these tools, it needs to have those tools descriptions and titles and all like inputs, everything. It needs to know all of that up front to know whether those tools are appropriate to call. And that leads to context blow. Like imagine you installed the GitHub MCP server, and you installed the Playwright MCP server, and the Sentry one, and Sentry actually does a pretty good job. I don't want to, this is not a paid thing, but Sentry probably has. Scott Tolinski Keep going, yeah, let's hear about how good the Sentry one is. Sentry probably has one of the best MCP servers available. Kent C. Dodds Yeah, like, you include all these MCP servers. Now, what you have left in your context window is just so small, And then like the model thinks that those things are actually really important. It overweights their importance. And so a lot of optimizations have been made just in the last few months to like dynamically determine which, you know, once I get the user prompt, let's go find the appropriate MCP tools To include, and then we'll send just that subset over to the model. ([Time 0:06:34](https://share.snipd.com/snip/39eacdbe-f9cb-40d1-a421-f0e87d9150f6)) - **Pick MCP For Reuse And Control** - Do choose MCP when you need reusable, controlled, and discoverable tool behavior across multiple agents and hosts. - For one-off or narrow uses, directly calling your API or a simple skill might be simpler and sufficient. Transcript: Kent C. Dodds Yeah there are a couple of reasons for that uh first of all i'll say if you're just doing like a one-off thing you probably can just give it access to your api Like cursor, especially, I Just say curl this URL, here's the stuff and boom, it'll do it. And now I can move on with my life. And so like sometimes just giving it an API is the right answer. Other times making a skill, like if it needs to be a reusable thing, making a skill that has like, here are the specific APIs, like that also can be fine for your specific niche use case. What MCP becomes really valuable is when you have something that you want to have a little bit more control over how this API is called, you want to make it reusable by other people and Other agents outside of just your one specific use case. And also, if you have a really, really huge amount of use cases that you want to support, it's more than just like, hit this one API and now we're done. One problem that early MCP adopters had was they had like their open API spec or their swagger docs or whatever. They just hand this over to some tool that would just do that hot potatoing and it would expose a tool for every API. And models did really poorly with that. And if you think about a model, I want to be clear, models are not human. But if you think about them like they are, some of these things become more clear. If you were to just give Swagger docs for something the size of Jira over to a developer, there's a pretty good chance that they would call the right APIs, but there's a really, really Even better chance that they would call the wrong ones or call them in the wrong order or forget to call one or whatever. And the model is going to do the exact same thing. And so what do we do for humans who are going to be interacting with this? Well, we build them a website and we collect all of those different API calls into different buttons and like navigations between things. And you'd like progressively discover different capabilities as you're navigating around. And so that's sort of what MCP does as well. Right now, Wes, you're totally right. I think we're still working through things. I think dynamic discovery of tools, it's supported in the spec, but not a lot of people are doing that. And not a lot of hosts really support that very well. But this progressive discovery of tools, I think, is something that we're going to see a lot of. And I really equate the API and website to API and MCP server, one serving an agent and one serving a user. Makes sense. Yeah. ([Time 0:09:55](https://share.snipd.com/snip/961fb9e2-fb8a-4968-9b79-550586c3791c)) - **Skills Complement MCP, Not Replace It** - Skills and MCP overlap but serve different scopes: skills are portable task specs while MCP targets broader, multi-host integrations. - MCP can be invoked by skills, so the approaches complement each other. Transcript: Kent C. Dodds Yeah, yeah. So here I, like I said, my opinions are typically well formed and I will tell you when they're not. So I have not actually, I still have not used Cloud Code. But I have used like similar things. And I feel like I have a pretty good understanding of things. Skills are basically like a simple way to have basically a spec of how you accomplish a certain task. Okay, do this, then do that. And then if it's going to be this way, then you need to do it that. And if it's this way, then do it this other way. And what's really cool about those is that you can share those across teams, like you can just, you know, copy paste this markdown file, whatever. And that's really powerful. And some people saw that and they're like, oh, okay, MCP is dead, we can just use this now. And the people who feel that way don't quite capture scope of MCP. I think we need to remember that MCP is much bigger than just like people developing software on a desktop. MCP, like I use MCP on my phone in chat GPT. Like I'm not running a CLI on my phone. MCP enables that. And so like, it's a little bit bigger. The other cool thing about skills is that you can actually use a skill to tell it to call an MCP server. ([Time 0:12:57](https://share.snipd.com/snip/fd249912-c4b0-4744-88de-bad1b46d2b34)) - **MCPUI Brings Interactive Widgets Into Chat** - MCPUI lets servers return HTML/CSS/JS widgets so hosts can render interactive UI inside conversations. - The spec includes host and server SDKs to safely marshal UI between servers and chat hosts. Transcript: Kent C. Dodds This was very early on as I started getting into MCP. I thought, OK, yeah, this is really important. We need to have something like this. And where I got this idea was I talked with Ryan Florence, a buddy of mine, who we talked a lot about the future of user interaction. We'd actually just seen Evan Bacon at React Conf, and he gave this demo of using React server components with React Native. And it was like, of course, yeah, that's mind-blowing. How cool. But the demo itself, the subject matter, was the thing that blew my mind. What it was, was he basically said hey here's what a chat gpt conversation looks like if i ask it about movies and it was just a bunch of text and here's gemini and they had an image in there Wow that's great and then he had his uh which used server components which is what he was demoing but what was cool about it was it was like native elements and you could actually click On different buttons in the conversation and and those would interact with the conversation. And I was like, yeah, we have the technology to do this now. And so as soon as I started getting into MCP, I realized, well, here's a gap. MCP is capable of enabling this behavior. So I opened up an issue or a discussion on the protocol and that evolved into a project by Liat and Ito, who created MCPUI, which basically is a two-part thing. It's a part for the host or an SDK for the host, and then an SDK for the server. So if you're building a host, that would be like a host would be VS Code or Cursor or Claw Desktop or ChatGPT. That's the host or Goose. And then the server is your MCP server. So the host is needed because it needs to take the UI that is returned and then render it properly. And then of course the server SDK just makes it so that you can return the right shape of that JavaScript, HTML and CSS so that the host can render that. ([Time 0:17:10](https://share.snipd.com/snip/05b74e7b-dbe4-4cca-8d98-e429a11a1204)) - **Big Players Back Open MCP Apps Spec** - Major providers (OpenAI, Anthropic, Microsoft) are aligning on MCP apps and contributing to an open spec hosted by the Linux Foundation. - This cross-industry participation makes MCPUI and MCP apps a practical, interoperable standard. Transcript: Kent C. Dodds Yeah, yeah. So dude, I'll never forget when ChatGPT came out with that. It was like such a, so much validation for what's going on because let's keep in mind that at this point, ChatGPT has 900 million users weekly. And that's an old number. Like just an insane number of users. As far as the consumer side, and maybe on all sides, ChatGPT is the biggest dog in this race, if you're talking about users. And so they literally could do anything they want. They could be like, we're going to be like Apple, we're going to have our own marketplace, we're going to have our proprietary operating system, we're like, do our own thing. And you all have to bow to us because this is where all the users are. But instead, they decided, you know what, we're going to just jump on board with the standards thing. Instead of a closed ecosystem, we're going to jump with this open ecosystem. And I just applaud them for that. Because really, all the incentives were pointed in the other direction. So yeah, in like September, October, they released ChatGPT apps, the apps SDK. And yeah, it was a little bit rough, but it was rough in the right ways. Like MCPUI had some security challenges that it needed to address and things. And so ChatGPT was very serious about that. And, you know, security typically makes our jobs harder. And so the APIs were a little bit funny. MCPUI very quickly built an adapter layer. And so you could continue with your MCPUI apps that you'd built up to that point and use those in ChatGPT with just a couple of differences for security reasons. And, yeah, from, like day it was announced, I reached out to a contact that I have at OpenAI and I was like, hey, just want to like check. Did you look at MCPUI? Like where's, what's the feeling there? And they were like, yeah, absolutely. We, we want to collaborate. We want this to be open. We want this to be a part of the spec. All of their APIs were very Open focused. And so that made me a little bit nervous, but they were like, no, no, we did that intentionally so that it was like, this is just our implementation of this. We're going to move away from that for the general thing. And so, yeah, I know. What a relief. Wes Bos Yeah. Kent C. Dodds So in, I, November, a little bit before the most recent MCP spec release, they announced that they're going to be working on an extension to the spec, which there may be future extensions. This will be the first official extension to the spec for what they call MCP apps. And what's really encouraging to me is that, like, all this time you've seen all of the right players participating in MCP. You've got Google, you've got Amazon, you've got Microsoft, and OpenAI and Anthropic, like all of the right people are involved here. And then when they released the MCP apps blog post, all of those companies were associated. Well, not all of them, but yeah, you had OpenAI, Anthropic, Microsoft is involved, and then the two guys, Liat and Ido, who built MCPUI. And so they're all participating in this open spec. And actually around that same time, MCP was donated to the Linux Foundation. And we could probably talk about that at length too, but I'm very encouraged by that as well. So the MCP apps extension is still in development. ([Time 0:20:06](https://share.snipd.com/snip/96532a8f-0b51-4b78-9a60-8e9666d31e74)) - **Improve MCP Dev DX With Inspectors And Evals** - Use tools like MCP Jam or inspector forks to speed up development and test individual MCP tool responses locally. - Also write evals for descriptions and prompts since LLM-facing metadata needs testing even if core code doesn't call an LLM directly. Transcript: Kent C. Dodds Honestly, I really like the analogy to early web days because that's actually what this feels like to me. Or anybody who jumped on the mobile train really early and building mobile apps, that's very familiar to them as well. Where the DX is just like very poor. So, and then like, we all know that when something gets significant adoption, more and more people are interested in it, more and more people are feeling that pain. And so more and more people go in and solve that, those pain points. And so that has happened over the last year. There's a really great tool specifically, Wes chat GPT apps because that process is the worst. It's like, yeah, not fun. But it's called MCP jam. That's what I'm using. Yeah. Yeah, it's fantastic. I don't remember if it's a fork of the inspector or like a brand new project, but it's a pretty heavy fork of thing. Wes Bos Like they worked in like probably six months ago it's an excellent so basically if anyone wants to know what it is is when you fire it up you add your mcp servers and then it it asks for all The tools resources templates prompts all of the things that an mcp server can give you and then you're and then you can it has like a chat you can give it like an API key, but you can also Just like fire off each of the different functions and see what the response is from each. It's, it's really good. Kent C. Dodds Yeah, it's, it's very good, but still I would say that it's nowhere near the hot mantra replacement that we're used to on like front end stuff. And the workflow is a little slower than we'd like. Testing is not really something most people do much of. Testing MCP is actually pretty interesting too because while your code doesn't necessarily involve an LLM, so you don't necessarily need evals, you are writing descriptions and Titles and things that are going to be used by the LLM. And those things probably need evals. And so it's a little bit tricky. And right now, we're pretty early in that workflow, but it is definitely improving. ([Time 0:25:10](https://share.snipd.com/snip/1810984c-074b-4485-8901-532653ca50bb)) - **Return Static Widget HTML With CSP Controls** - Serve MCPUI widgets as static HTML resources with CSP guidance and let tool calls supply dynamic data. - Don't rely on server-generated per-request markup; design widgets as constrained, interactive components. Transcript: Kent C. Dodds Yeah, yeah. So with the MCP app spec right now, and ChatGPT kind of introduced this as part of the security concerns, you do need to have that HTML upfront And you're going to be serving that HTML through A resource. So what happens is you have a tool that has metadata and actually like user-specific data and stuff. So that's going to be like your get request when your app first loads up. It's kind of how you might think about that. But it includes metadata about your app and the initial data. And then you have the resource that's like your static assets. And so this will be the HTML. That HTML can link out to JavaScript files and CSS files. But you're also going to include basically CSP suggestions. So that's your content security policy suggestions. Like what resources or what domains can this HTML reach out to? There's a lot with security on that and we could go deeper on that. But basically, the idea is you have this resource that returns a hunk of HTML that can reference JavaScript bundles and CSS and stuff. Typically, this is going to be like not a routed app. It's not like, let's just take my app and I frame it into the conversation. That's not the user experience we're going for. It's more like a widget. I call it a widget. They're actually bike-shedding what they're going to call it right now. They might end up calling it a component, which I think might be a little confusing. But in any case, it effectively is just a smaller thing that accomplishes the specific task and interacts with that conversation. So for your side of things, yeah, you generate the HTML and that HTML should be static. It cannot be dynamically generated on a per request basis or anything. ([Time 0:29:51](https://share.snipd.com/snip/0dad7b9d-6d52-4d68-9367-97e17d8fc0a3)) - **Widgets And Conversation Can Update Each Other** - MCPUI enables two-way interactions where widgets and the conversation update each other, creating richer agent-driven experiences. - This lets agents orchestrate multiple apps and user contexts instead of siloed single-app assistants. Transcript: Kent C. Dodds Yeah, yeah. Actually, I like to think of Tony Stark and how he interacts with Jarvis. I can't believe that it's been this long into the podcast and I haven't said the name Jarvis yet. Because this is like the thing I've been harping on for the last year. Like why I got into MCP is because we can build Jarvis now. But like Jarvis will create an interface for Tony and then he'll say something to Jarvis and then Jarvis will change that interface. Sometimes completely do away with it and make a new one and sometimes just like add, you know, expand to the thing or whatever. It's a very interactive sort of experience. And so and then like sometimes Tony will press a button and then that changes something in the interface. And then Jarvis says something as a result of that. It's like it goes both directions. And so, yeah, it's very much an interactive experience, not just with the app itself in isolation, but also with that conversation that's going on. That is what gets me really excited about this, is the potential for the way that humans interact with our software. For the last couple of years, everybody's been wanting to try and put a chatbot into their application. Well, now we flipped it on its head and we want to put the application in the chat bot. And that makes it so much more powerful because now my agent who understands not only the stuff that I do in this application for ordering pizza, but they also understand my contacts. And I can say, order pizza for my best friends and send them all a message that this is happening. And the agent can kind of coordinate all of that. Where if I had an agent just for contacts and another agent just for ordering pizza, I'd have to go to each one and fill them up with the context necessary for them to do the task. ([Time 0:32:17](https://share.snipd.com/snip/29c8147b-bfa5-49f3-b787-0b89d854108f)) - **Borrow Host LLM For Server-Generated Markup** - Consider letting the MCP server request the host's LLM for generation when needed, enabling servers to sample and produce HTML or other assets. - Use the server's ability to borrow the LLM to work around static-markup limits safely. Transcript: Kent C. Dodds Yeah, that's a great call out. That was part of my original discussion was like, maybe this is just the MCP server returns a bunch of components and then the agent decides what to do with them. I think that's not a closed door that could still possibly happen. Ruben Casas, who's at Postman, he made a demo where he effectively did that using sampling, which is your MCP server. This is another feature of MCP we didn't talk about, but effectively the MCP server can go back to the client, to the host application, say, hey, can I borrow the LLM for a second? Do this thing for me, like do this completion, give me back the result, and then I'll do something with that. And so he used it to generate HTML and then sent that back. So he kind of worked around the problem. ([Time 0:34:25](https://share.snipd.com/snip/7e56a550-c9b0-4713-aad6-d54920171cd2)) - **Goose: An Early MCP Agent From Block** - Block built Goose, a desktop agent and CLI that adopted MCP and MCPUI early and donated it to the Linux Foundation. - Goose shows how an agent can run powerful local extensions and recipes for developer productivity. Transcript: Kent C. Dodds Yeah, so Goose was built by Block. Most people probably familiar with Square. But yeah, it's a cool company, cool people. And they, like most tech companies are always looking for ways to make their engineers more productive. So they decided to build a desktop application and CLI that is effectively an agent. They were one of the really early ones to do that. And they jumped into MCP like really heavily. They call them extensions. They also actually have a feature called recipes, which is an early take on skills, what everybody's doing with skills now. But yeah, just a cool company, really early on both MCP and MCPUI. And they actually donated, Block donated Goose to the Linux Foundation along with all the MCP stuff too. So it's an open source project. ([Time 0:37:31](https://share.snipd.com/snip/2d49d7ba-2280-4bee-b675-38c820fe4a2b)) - **Agents Augment Websites, Not Fully Replace Them** - Chat-plus-widgets won't fully replace traditional websites; some tasks need richer UI than text alone. - The winning experience will blend agent conversation with embedded UI when appropriate. Transcript: Kent C. Dodds End game? You know, I hear people talk about Facebook apps. You remember that? Yeah. Wes Bos I made some money on Facebook apps back in the day. Kent C. Dodds Yeah. So like we've been here before, like, you know, I think that this is different. Chat is not necessarily always the better experience. Like text is not always the better experience. So like if I say, hey, I'm making chicken, I need a timer, I don't want it to say, okay, I set a timer for 30 minutes, just go ahead and ask me anytime you want to know how much time you got left. That's not a great experience, right? I want to have a UI that shows the countdown and maybe a pause and a start again button and stuff. So we do still need UI. Sometimes we don't. And it's actually really fun to build an app. I've got an app that I built that is only accessible through MCP, and it's a journaling app. And so like I just say, here was my day, add that to my journal, and it was great. It works super, super well. But lots of times you do want to have a UI. So I think having a marriage between these two things is a good thing. Is a chat or an agent-like experience the end app? I mean, who knows what comes after, but is that where we're actually going? I actually think yes, because the experience is so much better. And we've been trying this, like I said, for the last couple of years, everybody's adding chatbots to their apps because it's really nice. I don't know if anybody listening has used Shopify Sidekick, but that thing is sick. Really, really cool. You can control the app just using natural language. People love it. It's awesome. The problem with Sidekick and things like it is that it only has context of the app, but not the other things. So like I've also got Kit where I'm sending email marketing things and I want those two things to integrate. Maybe Shopify and Kit can get together and build an actual integration, or I can just have an agent that does that integration for me automatically. And so like I wanna spend time over there in the agent that understands not just what I'm doing in this app, but also what I'm doing in these others and has memory about my preferences from The past. And then it can manage those integrations. But again, text isn't the end all be all there either. And so bringing in some UI when appropriate to that conversation makes a lot of sense. So I do think that this is where we're going because the UX potential is just so much better. ([Time 0:39:40](https://share.snipd.com/snip/bbb1c701-f6fa-426b-ae38-eee8f27ba013)) - **Building With Agents And Minimal Manual Code** - Kent used agents (Cursor, Cursor bug bot, Code Rabbit) to build features in his MediaRSS app and barely looked at the generated code. - He reviews and iterates the agent-produced work, merging when tools report it's ready. Transcript: Kent C. Dodds Yeah, man, I am very excited about that, especially their emphasis on making it really good with LLMs. I don't think I'm alone in saying that the game actually has changed now with agents being able to write our code. That Media RSS app, I have looked at maybe 2% of that code. I literally, I have the, I kind of was very hands-on with the planning and everything early on. And then once I got it to a good state, then I could just send like a cursor cloud agent to go build a feature. And then I would have cursor bug bot review it and code rabbit as well. And then just like iterate, iterate, okay, now cursor says it's good, let's merge it. So like having a framework that is like really specifically tuned to be really easy to work with agents works really well. And one thing specifically that makes Remix really good with that is that closure that appears in the component right above where your JSX is. So for those who aren't familiar, a remix component is very similar to a React component, except that instead of returning JSX, you return a function that returns JSX. And that function is the thing that is called anytime an update needs to happen. And so the upper closure above that function, you can do whatever you want to in it, like fetch some data or connect to Bluetooth or whatever you need to do. Wes Bos Have variables that don't go away. Yeah. Kent C. Dodds Yeah, yeah, exactly. And that's how state is managed is just you make a variable and then you reassign it and say, go update and boom. It's a really simple model. And I think because of that model, I just have an AgentsMD that has maybe 200 lines of like, here's how Remix is different from React. And like, here's the different ways. This is how context works. This is how you get a reference to the domino, different stuff like that. And yeah, it's just like killed it. It's done so well with Remix. So very thrilled about that. It's funny. For a while, I had the biggest Remix app in the world. That was my website. And then with Remix v1, I think I now, again, have the biggest Remix app in the world because it's not actually released yet. And it's like a 20,000 line of code app. It's not like a small one pager thing. They don't even have a client side router yet. ([Time 0:43:43](https://share.snipd.com/snip/6c6fe962-e1a7-49f1-a24c-8eae4c8d97a6))