The Web’s Next Form: MCP UI (with Kent C. Dodds)

Welcome to Syntax.

We got him on. Kent c Dodds, number one fan of the show. We've been trying to get him on forever, and he's he's a busy guy and hasn't wanted to come on, but we finally nabbed him. And he's here today to talk to us about, MCP and MCP UI. The UI stuff is is really interesting. It's kinda being worked on right now. It's it's kinda cutting edge and really exciting in my opinion.

I'm pretty excited about it. So welcome, Kent. Thanks for coming on. Yeah, man. I'm I'm thrilled to be on. Yeah. Definitely number one fan. I'm I, I have listened to every Syntax episode since day one. Oh my gosh. So I'm an OG,

fan. That's that's insane. Well, we appreciate it. That's great. Yeah. You guys you you make a good show, so keep it up. Well, thanks, Ken. So for those who don't know you, give us a quick rundown of of who you are and what you do.

Yeah. Well, I am, Century's favorite Onewheel owner. You probably can't see it in the video here, but I got a a Onewheel on my wall, that has I'm pissed I didn't get one of those. Century branding on it. It's so sick.

I would kill myself on one of those. I absolutely would. I I can hardly walk back and forth to my office without tripping behind. So

Oh, well no. So I I I enjoy that. But, I'm a full time educator.

I worked in industry for a while and then went full time educator in 2019, took a break to, build up Remix, and we sold it to Shopify.

And then I jumped back into full time educating at that point. So, yeah, Epic or my first big thing that most people probably know me from, Egghead, front end masters, then testing JavaScript, epicreact.dev, epicweb.dev, and now I'm doing epic a I dot pro because the dot dev was taken.

So so Dot pro JS kinda good, though. I I didn't know about dot pro. Yeah. I I I actually have been thinking

that, AI is like it's applicable to way more than just developers, of course. But, like, there are so many people in the world who could benefit so greatly from AI, and they just have no idea.

And so maybe pivoting Epic AI a little bit to be bigger than just development and, like, start getting into I'm gonna turn you into an Epic AI professional. Like Yeah. You're gonna AIFI your business.

So, anyway, just that might work out.

For anyone listening, you might be wanting to turn it off because you might be thinking if you don't know who Kent is, you might be being, like, some AI hookster they're having on. Ken is Ken is legit.

He knows what he's talking about. He he knows how to Node, and and he's incredibly reasonable, I would say.

Oh, so cubes. Certainly stick around. There's a lot of good stuff coming.

I do have opinions, but I I like to think that they're well founded. And if if they're not, then I'll I'll call it out.

Alright. Let's get into real quick, we're gonna explain what MCP JS. And then I think a majority of the show, we're gonna dive into to MCP UI as well as, like like, both how to build for it. You know? Like, people who build websites are probably going to be building MCP servers and MCP UI widgets, I I believe they're called. So you're probably gonna wanna scale up on this. So give us a quick rundown of, like, what is MCP.

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. 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. Yeah. Yeah. It's a model context protocol. And so we talk a lot about context engineering with AI and 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. MCP UI is about eliminating that, or not UI necessarily, but MCP, generally, is about eliminating the Node to get things into the 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 is just standardize that. And so, if you're a service provider, you have some context. Like, Sanity is actually a great example of this. They have a awesome you all have an awesome, MCP server, and 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. And so that's it's like the jQuery of context management, if you wanna say, like, it just normalizes all the differences, across the different agents.

Yeah. Like, if you if you're running, like, a chat or you have your own API calls or whatever, you can sort of, like, load it up with several MCP servers, which once those are loaded, it will it will load all the the tools available for it. So one silly, simple example I I've built is a a currency conversion MCP. Because if you're using, like, chat GPT, it, like of course, it knows, like, currency conversions and whatever because it has its own own tools baked in. Right? But if you're using, like, a straight up API, you're just, like, pinging the OpenAI API or or cloud or whatever, it doesn't necessarily have access to the Internet or things like that. So if you wanna give it specific tools, like, for example, converting currency or another one I've used is is doing math, you can build out these different servers where you can give it access to do things like pull in the latest rates or get your latest bugs from Sentry, etcetera etcetera, and they can sort of do things on your behalf.

Mhmm. Yeah. Another practical example, is, I just I 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 a directory of, media files, mostly audiobooks and that sort of thing. And I just point my app to this directory, and it turns it into an RSS feed. And 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 they're okay listening to and whatever. That's great. And, yeah. So, of course, I hook up MCP to that. And now I can go to chat GPT, 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. It's pretty cool. Yeah. That's great. So 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?

Yeah. I think most people listening who've used AI, like, know that things tend to get kinda funny when it gets bloated. And and most, AI harnesses have mechanisms for, like, dealing with that Wes 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 Bos. Now I want you to go fix this button. The they might be a little confused about which button you're talking about. They could get confused about what it like, 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 TypeScript and, titles and all, like, inputs, everything. It needs to know all of that upfront to know whether those tools are appropriate to call.

And, that leads to context flow. Like, imagine you installed, the GitHub MCP server and you install the Playwright MCP server and the Sanity one, and Sentry actually does a pretty good job. I I don't wanna this is not a paid thing, but Sentry probably has Keep keep going. Yeah. Let's hear about how to put the Sentry one in. Yeah. Sentry probably has one of those steps to keep it simple for you guys. Yeah. Available. Yeah. Like, you include all these MCP servers. Now what you have left in your context window is just so small, and, 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, Wes once I get the user prompt, let's go find the appropriate, MCP tools to include, and then we'll send all just that subset over to the model.

And there are a whole bunch of others. Like, you probably heard of code mode and and, code execution and all of that stuff. We're at the phase with MCP Node where, we've made it work. Now Wes, are trying to make it right and also make it fast and, like, we're optimizing.

And so there are gonna be a lot of things that are tried. Some things aren't going to work very well. But, like, MCP Node today is a lot more useful and, and valuable than it was a a year ago, and it's, like, barely a year old. So Yeah. Right. Wow. Yeah. Feels like a lifetime. I I think there's still quite a bit that's still being figured out. But everybody's happy that

it's at least a standard, you know, that that can work across tools, whether using in a coding, whether using it in some sort of chat, whether you're making API calls.

It's ideally all a standard. But, one question a lot of people have is, like like, what is the difference? If you're building out an MCP server, sometimes it feels like you're just hot potatoing the Wes from the MCP onto an API. Like, what why don't you just give the AI access to your API directly?

Yeah. Yeah. There are a couple of reasons for that. 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.

Yeah. 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 a API spec or their Swagger docs or whatever. They just hand this over to some, tool that would just do that hot potato ing, and it would expose a tool for every API.

And models did really poorly with that. And and if you think about a model I wanna 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 JS gonna do the exact same thing. And so what do we do for 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, I Wes, you're totally right. I I think we're still working through things. I think dynamic discovery of tools, it's 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 gonna see a lot of. And I I really equate the, like, API and website to,

API and MCP Vercel, one serving an agent and one serving a user. Makes sense. Yeah. Makes a lot of sense to me. Yeah. You you see Node, Anthropic came out with skills for Claude, and you're hearing the word skills pop up a lot more. I think that can get a little bit confused in terms of, like, what how is MCP, differentiated

from the idea of skills or or some of even things have been slash slash names. Agents, prompts. Yeah. They've, like like, it's probably six or seven things in, in Cloud Code. I am curious about that as well. Yeah. Yeah. So, to here 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. Okay. Yeah. But I I have used, like, similar, similar things, and I I feel like I have a pretty good understanding of things. Skills are are basically, like, a simple way to, to have basically a spec of how you accomplish a certain task. Okay. Do this, then do that. And then if it's gonna 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 or 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. Mhmm. And the people who feel that way don't quite capture the the 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. And so MCP being, like, really, portable and adaptable, again, if it's a really simple thing, then, you say, yeah. Just call this API, you know, curl it and and bingo bango, and you move on with it. But for things that are highly reusable, having the protocol there is really helpful. There are a bunch of other things. I think, like, you got your cursor rules and everything else that we've we've talked about. There's a lot of overlap on what these different features are capable of doing, and that's mostly because we don't know what we're doing. We're all just kinda figuring out the best way to do this. For a while, we had, like, 300 different files, and now it's agents empty. But there are problems with that too. So, like, we're all just trying to figure out the best way to do this. But, none of these things, eliminate, the really the reason I'm excited about MCP, and most of them just complement MCP anyway.

I'm I'm pretty sure it was I think it was Node. I was reading their docs where they only load the description of the skill up top. And then once it's actually needed, then they'll load the entire thing so they're not muddying the,

the entire context window. But I think, like, that's something similar we're gonna get. Yeah. Yeah. Optimizations like that are exactly what we need. Last year, when people started talking well, actually, when I first got into MCP, I I saw this as a problem right from the start, and I was like, how would you solve this problem? Is this an unsolvable problem? Because I made a really big bet, like, going into, you know, as much into MCP as I did. And so I was really careful thinking about it. You don't wanna jump into something that has unsolvable problems. And it was really obvious to me, like, as let let's assume again that the agent is a human. If I had a human assistant and I asked them to do something they've never done before, they're gonna go over to Google and figure out how to do it. Like, they'll just do it. How do I send money to this person to pay them for pizza or whatever? And Google will give them some results and and they'll say, hey. They'll come back to me and say, I've got PayPal and I've got Cash App and I've got, like, these others. Which one do you wanna use? I I'd like to use PayPal for this, please. Okay. Great. And then the next time, they'll remember. Oh, yeah. You used PayPal last time. I'm gonna just assume that you're good with that this time. And I I don't see any reason why the agent couldn't do something similar, though. Have some sort of search mechanism, find the thing you like, and then save that in your memory, and and now it's really your assistant. Yeah.

Alright. So that's MCP. There's a couple other pieces of MCP, but probably tool calling is is the biggest one. But, like, one thing that is is currently being worked on is this idea of MCP UI because MCP will simply just return data.

Right? And then you just you give that data to the AI, and then it can it can parse through that and then figure out how to how to respond back generally in in text. Right? Mhmm.

But if text is not the the be all, end all of everything, sometimes you wanna return buttons or UI or a carousel or images or or literally anything else. So, there's this idea of instead of the MCP server returning just data, it returns HTML, CSS, JavaScript. Right? So give us an explainer of that.

Yeah. This Wes, very early on, as I started getting into MCP, I I thought, okay. Yeah. This is really important. We need to have something like this. And 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 ReactConf, and he gave this demo of using React Vercel Components with React Native. And, it was like, of course, yeah, that's mind blowing. How cool. But the demo itself, the subject matter Wes the thing that blew my mind. What 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, which use 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 and I was like, yeah. We have the technology to do this now. Mhmm. And so as soon as I started getting into MCP, I realized, well, here's a gap. Like, we MCP is capable of of enabling this behavior. So I opened up an issue on, the or a discussion on the protocol, and that evolved ESLint, a project by Liat and Ito who created MCP UI, which basically is two part thing. It's a a part for the host or Wes SDK for the host and then an SDK for the server. So if you're building a Scott, that would be like, a host would be Versus Node or cursor or, cloud desktop or chat GPT. That's 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 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 of that JavaScript, HTML, and CSS so that the host can render that. And so, that worked super Wes. Lots of adoption. And, I I could. There's probably a Scott more to say about that, but I'll just pause right there. That's that's where we were back in, like, June.

Okay. Because the last time I've dipped into it was probably, like, November.

And at that time, there was kinda like like the the state of returning UI from, MCP was, like, kind of in two spots. Right? The MCP UI was trying to figure out what their spec was and then possibly move into the the actual MCP spec. You can tell me that. And then there was also this other thing, which is OpenAI came out with their apps SDK, which was a source, ex like, very, very crappy implementation of MCP UI, being able to return HTML CSS and and render it inside of the ChatGPT, thing. So, like, where are we at right now with all of this stuff?

Yeah. Yeah. So, dude, I'll never forget when ChatGPT came out with that. It Wes, like, such a so much validation for what's going on. Because let's keep in mind that at this point, ChatGPT has 900,000,000 users weekly. That and and that's an old number.

Like, just an insane number of of users.

JS 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 gonna be like Apple. We're gonna have our own marketplace. We're gonna 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 gonna just jump on board with the standards thing. Instead of a closed ecosystem, we're gonna jump with this open ecosystem.

And I just applaud them for that, because, really, there were all the incentives were pointed in the other direction. Mhmm. And 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, MCP UI had some security, challenges that it needed to, 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, and use those in chat GPT, with, just a couple differences, for security reasons.

And, yeah. From, like, the day it was announced, I reached out to a contact that I have at OpenAI, and I was like, hey. Just wanna, like, check. Did you look at MCP UI? Like, where 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 OpenAI 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 gonna move away from that for the the general thing. And so Okay. Good.

Yeah. I know. What a relief.

Okay. Good.

Yeah. So in, I think, November, a little bit before the most recent MCP spec release, they, announced that they are going to be working on an extension to the pnpm, 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, OpenAI and Anthropic.

Like, all of the right people are involved here. And then when they released the MCP apps, blog post, it all of those companies Vercel, associated. Well, not all of them, but, yeah, you had OpenAI, Anthropic, Microsoft is involved, and then the the two guys, ESLint and Ito, who built MCP UI. And so they're all participating in this open spec. And it and, actually, around that same time, MCP was donated to the Linux Foundation.

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

It resembles it it really does look like a marriage between MCP UI and, chat GPT apps, which I think is really encouraging. It's a really good thing. And, Goose already supports MCP apps. Postman supports MCP apps. Versus Node has I think it's in a branch right now, like, experimental release or something, but they have MCP app support. I'm not sure what the the process on a ChatGPT and Cloud Desktop are, but, yeah, they can't be too far behind.

Yeah. Okay. Yeah. So when you're working on this stuff as a developer, I often found I I built an MCP server for a video we did to, deliver me pizza to my house.

And I I I can only imagine this this problem, I'm gonna say, is gonna be, exaggerated when you get into UI stuff. But I found me personally being ignorant to writing MCP servers.

The debugging and writing process for an MCP server felt really difficult in terms of, like, I just have to try this thing. It felt like going back to the old days of opening up the website and, like, just trying it. The feedback loop of The okay. It's so slow. Like, you had to go back into settings and, like, refresh the connector, and it would go download all the templates. And then Even writing my own MCP server, the feedback loop was slow because I would get to, like, the fifth or sixth step in ordering a pizza, and then something would go wrong, and then I'd have to start over. And I was just like, what's the typical dev flow for building MCP servers that actually

pnpm? Maybe I'll we'll let Ken tell us what the Yeah.

This is this is a super, good question. Honestly, I really like the, analogy to early web days, because that that's actually what this feels like to me or anybody who jumped on the mobile train really early in building mobile apps, that's very familiar to them as Wes, where the 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 and solve that those pain points. And so that has happened over the last year. There's a really great tool, specifically, Wes, for, 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've been using. Yeah. Yeah. It's 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 of something. Like, they they forked it, like, probably six months ago. It's an excellent so, basically, if if anyone wants to know what it is JS when you fire it up, you add your MCP servers, and then it 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 and see what the response is from each. It's it's really good. Yeah. It's it's very good. But still, I would say that it's nowhere near the hot module 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 and, like, things that are going to be used by the LLM, and those things probably need evals. And so it it's a little bit tricky. And and, right now, we're pretty early in that workflow, but it is definitely improving.

Let's talk about the actual flow for building out a MCP UI. Because, like like, with MCP, what you do is you you register tools.

You have, like, a schema of what what arguments it can take in, and then you give it a schema of what type of data it it can return back.

But then, like, once you're past data, what does it look like for actually registering like, do you register components? How does that work?

Yeah. Good question. So, if we're just talking straight up MCP, which applies very much to MCP UI as well, there are a couple of ways that you can distribute your MCP server. How you distribute it depends on the clients or the the host applications that you want to be able to connect.

So if you're building something for developers running in an editor, then you can actually use either one of these approaches. One is it runs as a local process on their machine, and the host application just communicates over standard IO. So it spins it up as a subprocess and then talks to it over standard IO.

And so distribution on that is just, like, publish it as an Npm package and then npm x Yarn yada, and then, like, Bob's your uncle. And it's that's pretty straightforward.

And Wes SDK has it, like, pretty easy to to start that server with the standard IO protocol and all that.

If you want it to be usable by, like a website or even, lots of desktop applications, as well, or chatgpt.com or cloud.ai, And then you're going to want to host this remotely on your own server because chatgpt.com is not going to be running subprocesses for you.

And so so you do need to run this as a remote thing. In the early days of the spec, there there have been a couple of bouncing around of how this is done, but now we're pretty much, settled. We're we're still actually evolving to to make this more of a stateless protocol as Wes, but it's pretty much just an HTTP, with streaming interface.

You make a get Wes. You leave that open so that you can stream events back, and then you make post Wes to make tool calls and stuff. As far as your server, though, it actually resembles the standard IO server code, like, really closely. It's just that little bit of integration

of how you're connecting to, clients. Let let's say I wanna return some HTML. Right? Like, instead of returning data, you simply just return HTML, and it will render it on out. But, like, do I need to have all of that HTML rendered ahead of time? And, like and, also, if it's, like, a React component, I gotta, like, bundle it and then put it in? Like, what does that workflow look like? Yeah. Yeah. So

with the MCP app spec right now and and ChatGPT, kind of introduced this as part of the security concerns.

You do need to have that HTML up front, and it's you're going to be serving that HTML through a resource.

So what happens is you have a a tool that has metadata, and actually, like, user specific data and stuff. So that that's gonna be like your get request when your app first loads up. It's kinda how you might think about that. But it it includes metadata about your app and 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 you're also going to include, basically, CSP suggestions. So that's your content security policy suggestions. Like, what resources or what domains can you, can this HTML reach out to? There's a a lot with security on that, and that Wes 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 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 iframe it into the the conversation. That's that's not the user experience we're going for. It's more like a widget.

I call it a widget. They're actually, bikeshedding what they're gonna call it right now.

They they might end up calling it a component, which I think might be a little confusing. But pnpm any case, it it effectively is just a 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.

The dynamic stuff comes from, the tool side of things.

And and that HTML and JavaScript that is is returned, it can then, like, make more calls on your behalf. Right? Like like, you might want to return their example is like a pizza place. Right? You might want to click a button that says order pizza, or, you might wanna configure a pizza and then and then click submit, and then then that will send it back to the chat. Right? So, like, these these Yarn this is not just, like, display the weather widget, and it looks nice, you know, or display a chart. But it their actual you can interact with them. Right?

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. Yeah. Sometimes completely do away with it and make a new Node, and sometimes just, like, add you know, expand to the thing or whatever. And 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, so then Jarvis says something as a result of that. It's, like, it goes both directions.

And so, yeah, it's it's very much a, 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 JS the the potential for the way that humans interact with our software. We for the last couple Yarn, everybody's been wanting to try and put a chatbot into their application.

Well, now we flipped it on its head, and we wanna put the application in the chatbot.

And that makes it so much more powerful because Node my agent who understands not only the stuff that I do in this application for, you know, 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, like, this is happening. And and the agent can kind of coordinate all of that. Where if if I had a agent just for contacts and another agent just for ordering pizza, I'd have to go to each one and and fill them up with the context necessary for them to do the task.

Is it not like a like a missed opportunity that the fact that you can't programmatically generate markup? AI is very good at generating markup. Like, you give it couple shad c n components and say, I wanna display a UI for doing x, y, and z with this data.

You return the markup. And, like, right now, you can't do that.

Is that missed, or is that a security thing?

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 the agent decides what to do with them. I think that's 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 can go back to the client to the host application and say, hey. Can I borrow the LLM for a second? Do this thing for me that 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.

But, yeah, I don't know if I'm ready to call it a missed opportunity. I think that's still a possibility, something we could do, but it's not part of the spec yet. And and what about, like,

calling the LLM from your UI as well? You Node? Like, it it you click a button, and it it just pings the LLM's API and is able to, like, run a query for you. Is that possible?

Yes. Actually, it is possible.

You can, send a message and, like, have that continue the conversation. I have a fun example where, I have ChatGPT pull up a calculator, and it's all Tron themed because I made this example when the Neutron movie was coming out. And Yeah. If you, made a calculation that resulted in 1982 Wes the original Tron movie was released, then it would send a prompt back to chat g b t to tell it to act as if it was the master control program from the original Tron and, like Mhmm. Try to, you know, talk to you like you're a programmer or, like, see if you're a user or whatever. It's just fun fun little thing. But yeah. So that that conversation can,

work back and forth. But, like, can you can you get the data from that? I I like, I I've known that you can send a prompt back to the chat, and then it will run it, which in in turn may render a new embedded widget. But I'm always I'm always curious about, like like, what if I wanna stay on that widget? Yeah.

Yeah. So two two answers to the question. So first, you can call tools, from your UI. So, like, click a button, call tool, get the results. So that's exactly what you're asking. But you can also there are a couple of ways that the UI can be visualized. So you can have it be just like a little widget, as part of the conversation flow. Not all of the hosts really support this just yet, but, there's experiments with, having a sidecar. So it's, like, right next to the conversation.

And that on its yeah. I'm I'm with you, Wes. Like, that is the thing that gets me really interested and excited.

Another one that, Chat GPT demoed was, the Zillow app. It went full screen, and then you just got this little chat, like, an input at the bottom. And then you just say, now filter it this way. Now, like, you know, find me houses in this area and, like, only those within walking distance to a school or whatever. And and it just updates that full screen data. Okay. Yeah. That's sweet.

Yeah. You had mentioned Goose a couple of times. Can you talk about what Goose is and how you use it?

Yeah. So Goose was built by Block. Most people are 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 to do that, and, they jumped into MCP, like, really heavily. They call them extensions.

They also actually have a a feature called recipes, which is, an early take on skills, what everybody's doing with skills now. Mhmm. But, yeah, just a cool company, really early on both MCP and MCP UI. And they actually donated that block donated Goose to the Linux Foundation along with all the MCP stuff too. So it's, an open source project.

Yeah. Definitely one to look at if you're looking for an agent. And you like, if you give it all the permissions, then it can do all kinds of crazy things on your computer. Yeah. I'm kinda doing that with ClaudeBot right now. Yeah.

And Wes we just recorded an episode about personal software. And, yeah, it is, it's crazy. That's for sure. Oh my Node. Yeah.

I don't know what to say about it other than that. Okay. So the chat UI

for this, is it everybody's saying, like, the web the browser is Deno. Websites are over. The entire existence of interacting with anything in the world is going to be via a chat app.

And and we've seen some people like Airbnb say, like, that's not a good experience. That sucks. I'd rather people go to our own website, and we have full control over it. And then other people are saying, yeah. Absolutely. It's it's gonna be it. We've seen it happen in in China. Lots of the like, there's there's on WhatsApp and all these, what's what's the Chinese one that's everybody uses? Not WhatsApp. It's WeChat. WeChat has this this whole idea of of, like, apps in WeChat.

They've had it for for many, many years. So it's it certainly is something that is happening. But, like, do you really think that this chat UI with embedded little widgets is is this is the endgame?

You Node, I hear people talk about Facebook apps. You remember

that? Yeah. Yeah. I made some money on Facebook apps back in the day. Yeah.

So, like, we we've been here before. Like, you Node, I 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 I'm making chicken. I need a timer. I don't want it to say, okay. I set a timer for thirty minutes.

Just go ahead and ask me anytime you wanna know how much time you got left. You know? Like Yeah. That's not a great experience. Right? I wanna have, like, a a UI that shows the countdown and and maybe a pause and a Scott again button and stuff. So, like, we do still need UI.

Sometimes Wes don't, and it's actually really fun to build an app. I 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 Wes my day, add that to my journal, and and it was great. It 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 like, an agent like experience the end app? I mean, who knows what comes after, but, like, is that where we're actually going? I actually think Wes, because the experience is so much better.

And we've we've been trying this, like I said, for the last couple Yarn. 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, like, not the other thing. 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 and has memory about the my preferences from the past, and then it can manage those integrations.

But, again, text isn't the the end all be all there either. And so bringing in some UI Wes 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.

Yeah. Yeah. We were just talking about this with Node assistant. Like, I had a natural language to modify my home assistant. And before, I was editing YAML files on my phone from my phone's keyboard. It's like, oh, this is so much better. So, yeah, I feel that. Yeah. It's Totally.

Home assistant has an incredibly powerful UI where you can do literally anything, and everybody hates it because it's it's hard. It's hard to use, and that's not a that's not a knock against, like, the UI developers. It's just a very complex piece of software, and and clicking buttons is maybe not the best way to interface with it. You Node? It's a powerful piece of software, and maybe the better way to interface with it is via

via text, right, via natural language. Yeah. Yeah. Absolutely. And I actually since you brought up Node assistant, I have to say, thank you for singing the praises of Cloudflare Tunnels, recently because, I, with that MediaRSS RSS app is running on my NAS. I've got a Synology, and that's where all my audiobooks and stuff are. And, Node exposing ports is great. So Oh, yeah. Yeah.

Yeah. Yeah. I I've got a an MCP server running in my closet connected to chat GPT through Cloud Flare tunnel. It's awesome. It's amazing. I love it. Cloud Flare tunnels are awesome. Yeah. One other thing unrelated to MCP I wanted to ask about is is Remix three. Right? Like, I was at the announcement, and I know you obviously used to work on Remix, and it's pretty exciting, space. What are your thoughts on Remix three, which they've done away with React and and built this entirely new thing?

Yeah, man. I am very excited about that, especially their emphasis on making it really good with LLMs.

It like, 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 the I 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 it would have Cursor BugBot review it and and CodeRabbit as Wes. And 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 one thing specifically that makes Remix really good with that is, that closure, you know, that appears in the component right above where your, JSX is. So for those who aren't familiar, Remix component is very similar to 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. Mhmm. And so the the upper closure above that function, you can do whatever you want to in it, like fetch some data or, you know, connect to Bluetooth or whatever you need to do.

And variables that don't go away. Yeah. Yeah. Yeah. Exactly. And that's that's how state is managed. It's just you make a variable and then you reassign it and Yeah. Say go update and boom. It's it's a really simple Node. And I think because of that model, I I just have an agents empty that has maybe 200 lines of, like, here's how Remix is different from React and, like, here are the different ways. This is how context works. This is how you you get a reference to the domino, different stuff like that. And, and, yeah, it's it's just, like, killed it. It's done so well with Remix. So Wow. Very thrilled about, about that. I I it's funny. I, for a while, I had the biggest Remix app in the world. That was my website.

And then, with Remix v one, I think I Node, again, have the biggest Remix app in the world because it's not actually released yet.

And, with it's it's like a 20,000 line of code app. It's not like a a small one pager thing. No. They don't even have a client side router yet. So so, like Yeah. We're we're pretty early, but it's it's been awesome.

That's great. I'm I'm pretty excited about that. And Wes we were trying to predict what it was in the, like, year leading up to the announcement, that, some of our predictions were way off, which it Wes, like one of them Wes, like, it's gonna be a Shopify theming system. Yeah. Yeah. You know? Yeah. But one of them was that there it's going to be a clear, concise, explicit API that leans on web standards that AI will be very good at writing. And I'm I'm glad to hear that that's that's actually the case.

Yeah. You know, they they have a much bigger ambition as well.

I was talking on x with Michael about this, and, like, they're gonna build an ORM. Like, they're they're going, like, full everything.

They're building a component library, which would be super nice. So, like, a a a shad c n that's built by the framework authors. Like I that's that's what they should all do. Right? Yeah. Yeah. I agree. So I'm very excited about the, like, the scope of what they've taken on, and they've just proven over the last decade that they can deliver. So, I'm just looking forward to I think they said March Wes their plan for I and I don't think that's secret. I hope it's not secret. But but yeah. Yeah. I think they were planning on releasing something in March. Sick. Wicked.

Wes, let's get into sick picks and shameless plugs.

Finally, I guess Wes don't have to explain what a sick pick is. Did you come prepared with one? I know we caught you a little, last minute here.

Yeah. Sure. You know, like, I for the last several years, I always thought, what would I what would I pick as my sick pick? And now, like, I I I actually didn't think about it. So, I'm gonna I'm gonna go ahead and pick a Onewheel. If if y'all haven't tried a Onewheel before, yeah, like, they're dangerous, all of that. You know, living life, you you gotta live. Yeah. And so hop on a Onewheel sometime.

Those things are a blast. My shameless plug is gonna be, epicweb.dev and epicreact.dev and epicai.pro.

I am actively developing stuff on those, platforms, and it is, really the best way to learn, React and full stack web development and AI with MCP specifically, that I am aware of. So, go take take a look at those. It's a pretty unique take at

retention focused learning. So that's Node a shameless plug. Yeah. You've been doing it for a long time, Kent. So, you got the, the skills right there. So Thank you. Every yeah. A lot of positive reviews on all fronts. So thanks so much. It was really great, to connect with you in, Seattle this year and talk about MCP. So I'm glad we got to make this happen. Alright. Well, thank you so much, and we'll catch you later.

Thank you all. Bye. Peace. Peace.