AIAI EngineerJun 3, 2025· 19:54

Letting AI Interface with your App with MCP — Kent C Dodds

Kent C Dodds explains how Model Context Protocol (MCP) enables AI assistants like Claude Desktop to interface with any app or service, moving beyond limited built-in integrations. He traces the evolution from early LLM chat (phase one) through host applications with custom integrations (phase two) to MCP's open standard (phase three), arguing that MCP lets developers build once for any assistant. In his live demo, he runs a Locationator server to derive his location, a GetWeather server for weather, and an Epic Me server with OAuth authentication to create a journal entry. MCP servers handle tools, resources, and prompts; the client standardizes communication while the server controls unique logic. Kent contends this protocol is how we give AI "hands" to perform real tasks, leading toward a universal Jarvis-like assistant that can dynamically connect to any service without manual integration per platform.

Transcript

Intro0:00

Kent C Dodds0:01

Hello, my name is Kent C Dodds, and I teach people how to build excellent user experiences wherever they are. I've taught people how to build excellent user experiences on the web, and now, guess what, we're all moving over to AI because that's where our users are going.

And so now I teach people how to build excellent user experiences with Epic AI.Pro as my course platform. Go take a look at it. Today I want to talk with you about how user interaction is changing, how Model Context Protocol and things like it are helping make that change possible, and what your role in this is as a product developer or as somebody who's trying to reach users where they want to be.

And where they want to be is inside of AI assistants. So let's talk about that. My talk is "Letting AI Interface with Your App with MCPs" or Model Context Protocol services. And normally when I start my talk, I actually invite people to stand up because—or at least get their body moving because our bodies need blood to flow for our brain to operate properly.

This is kind of an awkward thing to do in a remote setting, so we're not going to do that. But if you've been just sitting around for a while, I invite you to move your body, stand up if you can, and get blood flow because your brain does need that.

So make sure you're taking care of your body. Allright, so let's just getright into it. I'm going to show you a video of Tony Stark interacting with his AI assistant, Jarvis. So if you're not familiar with Tony Stark, he's Iron Man, and this is from one of the Iron Man movies.

Jarvis Clip1:20

Kent C Dodds1:36

So as we're watching this, I want you to consider what are the things that Tony is having his AI assistant, Jarvis, do that we are not able to do with the technology that we haveright now. And then we'll talk about it once the video is done.

Here we go.

Speaker 21:53

I've compiled a Mandarin database for you, sir, drawn from shield, FBI, and CIA intercepts. Initiating virtual crime scene reconstruction.

Speaker 32:05

Okay. What do we got here? Close.

Speaker 22:09

The heat from the blast was in excess of 3,000 degrees Celsius. Any subjects within 12.5 yards were vaporized instantly.

Speaker 32:16

No bomb parts found in a three-mile radius of the Chinese theater.

Speaker 22:20

No, sir.

Speaker 32:22

Any military victims?

Speaker 22:23

Not according to public records, sir.

Speaker 32:26

Bring up the thermogenic signatures again. Factor in 3,000 degrees.

Speaker 22:30

The Oracle Cloud has completed analysis, accessing satellites and plotting the last 12 months of thermogenic occurrences now.

Speaker 32:38

Take away everywhere that there's been a Mandarin attack.

That's two military guys.

Integration Woes2:50

Kent C Dodds2:50

Ever been to Tennessee, Jarvis?

Speaker 22:52

Creating a flight plan for Tennessee.

Kent C Dodds2:59

Allright, well, that's pretty cool. I would like to have a Jarvis like that that can help me. Can you imagine Tony doing all of that research and everything without an AI assistant? It would take longer. Let's just put it that way.

So what did Jarvis do? Compiled database, generated UI on demand, accessed public records, brought up thermogenic signatures. I think I know what that is. And Tony said, "Take away everywhere there's been a Mandarin attack," so joins across different datasets, showed related news articles, created a flight plan for Tennessee, and answered the doorbell.

Or at least showed Tony who was at the door with all their, you know, don't go to Tony's house if you want your privacy. But yeah, so this is really exciting stuff to think that we could maybe have some of this.

And so the question is, can we? What did Jarvis do that we can't do? Okay, so there were actually a couple of things. It's not just nothing. We probably couldn't create a database based off of FBI and CIA and shield database stuff, but not for technical reasons.

And the holographic stuff, I think we're still working out. But generating UI, we absolutely can do that, and people do that all the time. So we have the technology to do this stuff. So my question is, why don't we each have our own Jarvis already?

What's stopping us? And the interesting thing is that we've actually tried this. We've been trying this forever, and it's just not quite there. And so why is it not quite there? What's holding us back from being able to have Jarvis?

Isn't that just the most amazing experience? And Jarvis isn't just like something that you talk with. If you're in the office with a bunch of other people, you probably don't want to have a talking interface. It's also like he uses typing, and he also uses gestures and everything too.

And he generates dynamic UIs, and then he can interact with those as well. So it's a really, really awesome user experience. So why don't we have a Jarvis, even though we've been working on it? What is holding these different assistants back?

And the answer is integrations. It's just really, really hard to build all the integrations for all the possible things. Here are a bunch of logos for things that you might recognize, some things that you don't. Some are technical, some are like normal people things.

And I want to have a robot that can interface with all of them. And here's the real kicker. I want to have a robot that interfaces with everything. And the challenge of building an integration for every one of those things just means that Google is not going to build an integration for your local city's government website for reserving pavilions at the park.

And I want that. I want my robot to be able to do all of those things. And if it can't do everything, then why spend the time wiring everything up together so that it can do some things? And there are some activities that we take, or some activities that we do, some things that we do that don't really

make it worth it to spend all the time wiring things up. We just don't do it enough. But it would be really cool if there was some standard mechanism for my AI assistant to interface with something that I've never used before and I won't ever use again.

But I don't want to have to click around the website and figure it out. I want my LLM to figure that out. And that is what Model Context Protocol enables for us, is a standard mechanism whereby our AI assistants can communicate with these various tools and services.

MCP Unveiled6:29

Kent C Dodds6:47

So let's talk a little bit about the history and architecture of MCP, Model Context Protocol, and just like tool calling and that sort of thing in general. So phase one, about three years ago, ChatGPT comes out. And this is a really, really exciting time because it answers our questions.

Three Phases7:08

Kent C Dodds7:08

We can tell it something and ask it something, and it can answer the questions. And maybe the answer isn't alwaysright because it's not intelligent, it's just generating tokens. But lots of the times it is, and it's gotten way better.

And so this is really exciting. And what made it so pivotal is the fact, not the fact that we had an LLM. We've had LLMs for a long time. What made ChatGPT so awesome is the host application layer around the LLM, ChatGPT itself, not the LLM, but the application around it that brought a good user experience to interfacing with an LLM.

And then once that happened, a lot of investment went into LLMs, and they got better, better, and better, and better much faster because we started to see a lot of value. The problem was that you would have to provide the context yourself.

You'd copy-paste your code and say, "Hey, what's wrong with this? Please refactor it," whatever. And then you'd have to copy and paste its result back into your codebase, and then you'd find out it wasn't working for some other reason.

But there was a lot of context, like manual context, bring it in in the form of text, and then we added images. But having to manually bring in that stuff and then manually take it out, and then, of course, you've got your context window and all that stuff.

So it couldn't do anything. It could answer questions, but it couldn't do anything, and managing context ourselves was kind of a pain. So then we get into phase two, where the host application is like, "Hey, I'm like regular code.

I interface with this LLM. I could tell the LLM, 'Hey, I need you to let me know if you need more context, and I can go get it for you.'" So now we have search engines. And hey, if they want to schedule a time to meet with somebody, I have a calendar integration.

And oh, if you want to summarize your Slack messages or your notifications or something, I have a Slack integration, whatever. So the host application is now enabling it to do stuff. I can tell it, "Hey, do this thing," and now it will do that thing.

And the problem here is that you're kind of limited with the things that it can do and also the sources where it can get its context. You're limited by the developer's time at OpenAI or Anthropic. How much time do they have to dedicate to building out these integrations?

And this is really the same problem that we have with our existing assistants and the existing efforts that we've put into building integrations with all these different services. You're not going to convince OpenAI or Anthropic developers to build an integration for your city government website or anything like that.

That's just not going to work. And granted, OpenAI has their own GPT plugin system, but it's proprietary, and so it's difficult. Even though ChatGPT has a lot of buy-in from the users that you have, it's difficult to justify building something special for ChatGPT and then something special for Anthropic and then something special for Google and whatever.

It'd be much better if we had some standard mechanism. So yes, it can do stuff. And for a lot of people who couldn't get buy-in from the company to build a built-in integration, they would just build a wrapper, their own host application with their own tools.

And the thing is, users don't want to do that. Users want one Jarvis, just one, just one Jarvis that is able to augment itself with any capability in the world, any possible capability. They don't want to have to load up your LLM wrapper with the context necessary and then grab that context and put it into the next tool and whatever.

They want one thing that can interface with all of them. And so yeah, it can do stuff, but it can't do enough. And that is a big pain. And that's what pushes us into phase three, MCP. Now, with MCP, it can do anything because MCP is a standard protocol that all of the different assistants support or will very soon support.

And now you can build to the MCP spec, and you're usable by any of these AI assistants because it's a standard. So we can do anything. The clients aren't quite ready at the time of this recording just yet, but soon they will be, and it's going to be phenomenal.

We are just one really good user experience application away from Jarvis for everybody, and that's very exciting. So to expand out on this a little bit as far as the architecture is concerned, the host application is communicating with the LLM, and the host application tells the LLM what services are available to it.

Architecture11:30

Kent C Dodds11:51

And those services can be dynamically added. They can be added and removed. So this context can be managed by the host application, and the LLM just knows what's available now and the user's query, and then it can select the most appropriate tool.

The host application creates a client for every service that it wants to interface with, and this client is a standard client, so it doesn't need to have any special integration with anything. There's a standard interface for this. And then the service provider creates the MCP servers, and those servers interface with tools, resources, prompts, sampling, lots of really cool features on that end of the spectrum.

And this is what makes it so great, is that the service provider is in control of this stuff. This is the stuff that's going to be unique to every service. Everything else, like the server and the client, that interface, that communication is standard.

And that's why this works. That's why it's so cool. The way I say it is, this is how we give Jarvis hands to be able to actually do stuff. It's very exciting. So I want to show you a little demo of a couple of MCP servers that I put together to kind of explore what's possible here.

Like I said, the clients aren't quite ready, so the experience is not what the Jarvis experience was, but I don't see any reason why we can't get there. So let's get into that. So first, I made this in London, so it's going to find out my current location here in a second.

Live Demo13:10

Kent C Dodds13:28

But here's the prompt. This is in Claude Desktop, which has been configured with my MCP servers, three of them. Please write a journal entry for me. So one of the MCP servers is a journaling server. Here's my email address.

About my trip with my daughter, I would like you to derive my location and weather conditions from my device location and make up a creative story with relevant text. Thanks. So we execute this. And as part of the context, it has an MCP server called Locationator, which will determine the current location.

And so with this, I'm going to allow it for this chat. Now, you notice Tony didn't have to approve different tool calls and stuff for Jarvis because Tony has a lot of trust built up with Jarvis. We don't quite have that trust built up yet or that capability.

And so that's why we're not quite there yet, and we have to approve every tool call and stuff. But we'll get there eventually once things get more reliable. So here it gets my current location. That was my location at the London hotel, so don't worry.

This isn't my home. And then I check the weather. This is from another tool, another server, Get Weather, for getting the current weather at given coordinates. And now it's going to run another tool from Epic Me. This is the Authenticate tool because I haven't logged in yet.

And so I'm going to provide my email address to the Epic Me server. And at the time of this demo, I didn't want to actually open up my email as part of this recording. And so I was just running it locally, and I logged it to the console.

So let me just grab that token, and I provide that auth token. And so now my MCP client has been or it's going to be authenticated with this validation token. So the MCP server has authentication built in. It's based on OAuth 2.1, and so it's as secure as anything else that you're using OAuth with.

And my Jarvis client or Claude Desktop has been authenticated so I can perform authenticated tasks, one of which is to create a journal entry. Now, of course, the LLM is going to write the journal entry for me. I don't want to take the time to do that, but you could write your own journal entry, of course, and have it just insert that yourself.

And with theright kind of interface, you could speak your journal entry, and it could format it nicely for you and everything. That's what makes these LLMs so cool, and especially when we're talking about multimodal stuff. So we're going to create a journal entry with that information.

My MCP server configured the inputs and things. And now it's going to check, "Okay, what tags do you have available?" Okay, great. So you've got a travel tag. Or let's create a travel tag because you don't have one for that, and that makes sense for this journal entry.

We'll add that tag to the entry. And then it continues in this manner. And here's another really cool and interesting thing about MCP and the fact that we're working with an LLM is I can actually ask it, "Hey, could you show me that journal entry?"

And remember, that journal entry, it had a title, and it had contents. But here, it's going to retrieve that journal entry, and then it decides based off of what it retrieves that there's a good way to format that that's better than just the JSON format that is provided.

So the server can communicate in a way that makes a lot of sense for the server, and then the client can take that as context to display whatever it wants to the user. Right now, we don't have very many clients that support any mechanism for displaying a dynamic UI or a card or something like that, but you can imagine that we could totally do that.

There's nothing stopping us from doing that. And I think it's actually also interesting that it rendered this as kind of markdown with title and everything too, which I think is pretty cool. And additionally, I could actually ask it to translate this into any language, and it would do a pretty good job of that too.

So maybe the MCP server is sending responses in English, but you're talking to your LLM in Japanese, and the LLM can convert that English response into Japanese, which I just think is very, very cool and interesting. So here now I'm telling it to delete the post and log me out because it's fake.

And again, all of the authentication stuff that you would expect all works here. The Epic Me MCP server is completely only accessible via MCP and clients like this. You can't actually access it as a web application. And I think that is the transition that we're going to be experiencing very soon.

Users don't want to use a browser. They don't want to Google and have to figure out theright way to phrase their question. When I was teaching my parents how to Google, they just typed out a full-on question, and their results were not very good.

The Future18:19

Kent C Dodds18:32

So we had to train them. No, no, no. You have to write it in this special format, and then you'll find with these keywords and stuff, and then you'll find what you're looking for. Well, now we're going back to what's more natural.

Just speak your question, and the AI will be able to figure out what you're trying to accomplish, and not just what you're trying to search for, but what you're actually trying to do, and it'll actually be able to do that thing for you.

That is what MCP enables, and that's why I'm so excited about it. So just to wrap us up, I've got a bunch of resources for you. There's the specification for model context protocol. It's very good. You should definitely take a look at that.

Wrap-up18:56

Kent C Dodds19:09

I am very active on Epic AI, and so you can go check out epicai.pro and learn all about not just MCP, but AI in general. I've got a whole bunch of posts that you can take a look at all about

the future of user interaction and how AI is changing the game for us. It's very exciting, and I hope that you join me there. I also have workshops and cohorts and things that you can go through and join me on.

And at whatever time you're watching this, there will be something to go and learn there. So go check out epicai.pro. With that, I just want to say, you're great. Thank you so much for watching my talk.