Introducing WebMCP: Agents in the Browser — RL Nabors

And even though I know some people are still coming in, I've also been informed to start directly on time. So, much apologies to anyone who was hustling up here from one of the talks downstairs. You should have known this was the best track and hung out here from hour 0, but I'll by all means come in, have fun.

Hi there. I am Rachel Lee, Rachel Lee Neighbors, Neighbors like nearest neighbors, but not spelled that way. I have worked on the standards that powers today's web, with Mozilla on Firefox, DevTools, W3C on web standards, like the Web Animations API.

I've even been a PM on Microsoft's Edge browser. And you may know me from my pandemic babies on the React team, react.dev and react-native.dev. Allright. So I've spent the last 3 years consulting with AI startups and LLM/big browser companies, some of whose logos you may recognize, most of whom you will not, on all things web, AI, and UI.

Recently, I have just become newly minted Principal Developer Experience Engineer at Arise. Have you ever had your CTO ruin your agentic flow with a slight change of prompt or an LLM migration? Have you ever been that CTO? Anyway, if that is you, you need to check out Arise.

Evals are your friends. Check them out. Now, before my big tech career, I made web comics for teenage girls on a, well, it was a part of the iVillage network website. I don't think anyone remembers iVillage, but it was kind of a big deal back in the day.

I had 400,000 weekly readers. It was powered by ads, and I learned how to build for the web so I could reach those people where they were. It was 2006, and it was a mood, let me tell you.

Everyone online was edgy. We were on MySpace, where we had 14-year-olds talking about music with 42-year-olds. And as you can see, I was really into the goth and emo scene. I was the only goth in my village. When I got into the web, I believed that the browser is not just a document reader, despite what the CSS wonks will try to get you to believe.

It is an infinite canvas that can render anything, not just documents, but video, audio, whatever you need, there's an API for it. And I have been working to that end on the web ever since. I worked on that Web Animation API with the W3C, creating such insane demos as the interactive Alice in Wonderland, and generally made the web do things that it was not supposed to do.

And now I write about how agents and AI are changing how we browse and consume content. On my little newsletter, The Agentic Web. And I do a fair bit of shenanigans with agents myself. This is ASA, it stands for Anti-Social Social Agent.

It's an MCP app that lets you use Twitter and Blue Sky next to each other without actually having to visit the sites or be subjected to other people's algorithms. Anyway, check it out if you like it. I'm here today to show you how, with the power of the browser's primitives that already exist and have already been specked outright now, you can turn your agent into an infinite canvas, or at least get your website into agents, one way or the other.

So I have this habit every year when I'm thinking, what do I want to make talks about? What do I want to do? I look at the one thing on my laundry list that I keep putting off. In this case, my web comic site, the archive site that I put together at like 2010, said, OK, you're good there.

I got to go now. And it was starting to get 404s, starting to get some broken images. Maybe I shut down some clusters here and there, and it's like, oh dear, the CDN has failed. Anyway, it needed some repair.

And I was like, well, don't just repair it. Make it future-proof. If everyone is working in agents these days, let's meet them where they are. I'm always meeting my audience where they are, and I still get fan mail from the women who grew up with my comics.

So maybe I can get them to try out agents, too. Allright. So just as a cringe warning, before you go to RacheltheGreat.com, 2000s were a vibe. Old comics, younger Rachel Lee. It's just a little bit cringe, OK? I want to honor the fans.

And also, I'm working a lot with copyrighted images here, and I don't want to get sued by Marvel. So I'm going to use my own stuff. The nice thing about having a former career as an artist is I can do whatever I want with my art, no questions asked.

Of course, I did have to hose them down with glazing to make sure nobody else would. But that's another story. Check out the repo at the end of this if you want to know more about protecting your content from being used for training purposes.

Now, I wanted to make my comics available and navigable. One server, but three different kinds of clients: humans in browsers, humans in agents, and agents in browsers using the web on behalf of their humans. I know, it's complicated.

They've got like this Polly Kiel thing going on. So what we're going to cover today: MCP tools and transports, how to host them on the web just like you would a website. MCP apps, how do they work? You've already been told a lot about this.

I'm just going to show you a really cool example and point out the foot guns. And WebMCP, coming to a browser near you. Before we go, how many of you currently host an MCP server? Like on the web, not locally.

OK, well, I love you guys. Everyone else, you're going to learn. And how many of you have made an MCP app? Allright. How many of you want to make one? This is going to be the next web pages.

And lastly, has anyone here played with WebMCP? OK, well, we'll see if we can change that. So you're here. I assume you know what an MCP server is. I'm not going to go into them too much. So we're going to get started with transports.

Now, if you've built for the web, I guess I should ask, how many of you have built websites and hosted them in your lifetimes? Allright. So you're familiar. You're probably familiar with HTTP, but you might not be familiar with the concept of transports.

Turns out there's more than one protocol you can use to communicate from one surface to another. Transports are how MCP servers communicate with agents. And there's an important difference between when you should use either of these. So STDIO stands god, it sounds terrible when you read it out.

Standard Input/Output, you can call it.

Studio.

Studio. Like the Phil Collins song, because we're in England, OK? Studio. We're going to call it that for the rest of this time. Unlike my German proofreader who was like, I didn't think you called it studio. I was like, dude, do you want me to call it anything else?

I think we're going to have problems. Allright. So the server, it runs as a local process. It's spawned by the client. This is why when you're wiring up a studio-based MCP app, it's always like a string of JSON with a bunch of command line inputs that most of your users don't want to use, don't want to configure.

Communication, it happens via, as I just said, standard input and output. And the server stays alive throughout the session. HTTP is a little different because we're running over the web. We are not touching, with a 10-foot pole by the way, any of the security or privacy concerns with either of these layers.

That is beyond the scope of today's conversation. But HTTP, the server runs as a web service. It listens at an HTTP endpoint, which you may be familiar with from API development. And communication happens via our best friend, HTTP POST requests.

And it works well with serverless setups. Vercel and Cloudflare keep trying to sell you those edge functions. Well, they've got something to put in them now. Allright. With Studio, you have to update a config file with a command to spin up a local server.

But with HTTP, your user's experience oh my god. Your user experience is as simple as going over to YAML settings. OK, it is buried a little bit, but trust me, when you get oh my god. Please, if anyone from Anthropic is watching this help.

Give it a name, put in a URL, and it is now come on, hurry. Come on, come on, come on, come on. Past Rachel Lee. But you can see I can actually type the dang thing out. It's very that's not how you spell it.

There you go. It's very there you go. I put it at /mcp. You hit Add. And now, there it is. It's a connector. And I go ahead and go in, and I give it all the permissions to always allow, because I know this one.

But it's not easy if you're using an HTTP server for your MCP tools for the user to get them into their, in this case, Claude. Allright. So these are the tools I wanted to make available. They look a lot like what's available when they visit the website.

They're very similar to that navigation. And they all return structured data in the form of JSON, except for get transcripts here. And we'll talk a little bit more about this guy in a little bit. But point is, list the comics.

List the storylines, because the comics include different story arcs and endings and beginnings. List the characters. Search said comics, which is actually searching the transcripts. That's a different talk. And search by character, because I love the cat. I want to see all the cat.

And the transcript is different. It returns Markdown. Boom. Allright. Let's take a look at these babies in action. These are just the tools. We haven't gotten to the interactive part. Bear with me. I have a narrative arc.

Allright. It is a bit wordy. Everyone who's like, chat's the future, I'm like, it is not the future. This is like, thank you for having a long discussion with me, Claude. Yeah, you did find that I make the comics good, Claude.

Good baby. I would like to make a I would like to make the full transcripts and text available to the context for meta-analysis of themes and character arcs, et cetera, instead of asking Claude to get transcript from 533 different comics.

It is not an efficient use of context to do that. I would really love to use MCP resources, which are the perfect vehicle for this and skills and so many other things. But the spec is loosely defined. It is loosely implemented.

And I cannot find a client where I could actively get to these resources. They're on the server. They just ain't visible in your UI. So please, if anyone here is listening who builds an agent harness, go even bare bones, I'll take it.

Give me something to work with here. Allright. So I would love for one or more clients to implement resources. Agents really don't like using MCP tools to go add Markdown to their context. If you've ever maintained a documentation site and you thought, I will add the MCP tools to the documentation site, that just solved the problems with the coding agent knowing how to no.

No. I'd rather die in a fire than go call your documentation by MCP tools. So that is not how they were intended to be used by God. So resources could also allow harnesses to decide when to pre-prime that context with docs.

Like you're switching over into React mode. Good. Go get all the React resources from React's MCP server. Thank you. Goodbye. Allright. Little tirade over. That was your public service announcement. Tools, they can return plain data, JSON, text, Markdown.

But they can also return an interactive app, app, app, app, app. So I wanted to put a comic reader in your agent. So while you're reading, you can read some things with some pictures instead of a long wall of text.

It's like, Claude, you are not my best friend in crisis. Why are you wall of texting meright now? It's been said that chat is the lowest common denominator of the user experience. That it is to the future of agentic experiences, what the CLI was to software.

My mother programmed in COBOL. And when at school, they were making us click, double-click on icons to access video games. She was like, we do not do that in this household. We open DOS, and we do CD, blah, blah, blah, .exe.

That is how programmers do things. But we all know that you don't do that on an iPhone. You tap and you point and grunt,right? So this is probably a phase for us developers. There's a current, what I call the chat box landing page or starfish design, because it sits there, and it lets the user do all of the work.

And you have to have a lot of context in your head when you land. You have to kind of know what this thing can do. Like if you're on Linear, you're like, I know this is a ticketing system.

I'm pretty sure I want to see X, Y, or Z. It's great if you're already familiar with the system. But otherwise, it can be a bit challenging not to have any visual cues or guidance. It's sort of like these text games were really popular back in the day.

But I wouldn't want to have to do my taxes by being like, check mailbox. Is there mail? Whose house is this? That's not great. It's asking your poor customer to do a little bit too much discovery. So fortunately, we have MCP apps in line, in agent, rich media experiences created by bundling of HTML, CSS, and JavaScript into a single file.

That sounds so familiar. I'm having flashbacks to like DHTML. So this is Git Page. Git Page is my MCP tool baby. And I love it very much. This is it in action. It returns an MCP app. I say, yo, I want to read Crow Princess the comic to the starfish chat box of everything.

And of course, Claude's getting chatty. And it's like, I'll help you read. Let me just check all of my MCP things. Wow, I found it in the other comics collection. Let me go Git Page that. Here we go.

OK, thank you. And check it out. I can show the commentary. I can show the comments. That's pretty cool. Those are available on the website. It's everything the website can do. It looks just as good as the website.

You can navigate forward and backward. But the fun part is, you go up here. You can click on Text Mode. And boom, it shows you the transcript. So you could just read it if you wanted to. That'll come back later.

So yeah, it's like a little mini website. Comic reader, but it's using all the resources from the website. OK. Now,

how do you do that? Well, I define the tool as Git Page. Give it the description. There's an input schema. Of course, I'm going to have to take the comics ID, the storyline ID, the page number, so it can really hone in on where to get this.

To be honest, it just needs the storyline ID and the page number. I'm going to refactor that. And of course, all of this stuff is required. But most importantly, down here where the magic happens is you pass this little meta attribute, give it UI, and you point it at a universal resource locator.

Boom,right there. Love it. OK. Important thing to keep in mind is that MCP apps are a little special. They're not like websites. They're an island. They're a single HTML file. So everything that you need there has to be embedded, base64.

If you're going to link to something external, like a cached CDN font file or something, you've got to add that to essentially a CORS policy. So this means you're not going to be dynamically pulling in stuff from other people's servers unless you really are certain about that and enabling it in your app.

It's sandboxed in an iframe. You don't get local storage with this. So you're not going to be tracking state across iframes. You're stuck with it. Async tool calling. OK. And no network access. You have to ask the server to do things for you with the call server tool.

This gets into a real mother-of-mei situation, which I'll cover in the gotchas. So what does this mean? It means that it becomes super useful to build your MCP app with your design system. In this case, I'm sharing fonts, CSS, and everything from the same server.

Got the CORS policy set up and everything. And the HTML and JavaScript components can be bundled. I'm using Vite single file for this. So if you already have a design system, put your pot up. If you do. OK, good.

All the rest of you, oh god. I'm sorry for you. But a design system is a thing of beauty. Allright. Bonus round. Links require host permission. Remember I said, mother mei, you can't just window open or href. No, no.

No, no. You've got to be like, app ref, current open link, pretty, pretty, please. OK. Remember I said external resources needed CORS? Well, you've got this thing called the CSP or Content Security Policy. Fonts, images, other external resources, they're blocked by default.

So without that CSP config, the browser would just not load those things. So if you're getting a blank look and you're wondering what's janked up, check your CSP. And unlike MCP UI, which you may be familiar with, MCP apps can call tools.

So I could do that forward and backward navigation with a tool call. But if you're doing that, remember, some tools were not meant to be viewed as a big fat pile of JSON. You want to set visibility app there just to make sure that the model's not going to try to use that and return text.

It's not going to go, oh, look at this lovely forward and backward. I will use that. No. Soccer arm. Don't do that. Allright. So people are still using browsers,right? There are smarter, more accessible browsers coming out all the time.

Big and small browsers are shipping with agents builtright into them. Sadly, they still struggle with navigating websites because they rely on taking screenshots and guessing how to use the navigation or traversing the DOM, which burns tokens, chewing up XML, which is really not a great use.

Both of these are compute intensive, because you're using visual models, or you're just eating a bunch of HTML to find out where the next URL is. Wouldn't it be great if they just had a way to call the same functions and links you already have in your JavaScript directly from the page that they're visiting?

Well, with WebMCP, they can do just that. It makes every HTML page a mini MCP tools server. However, I just want to point out that WebMCP is to MCP as JavaScript is to Java, inspired by riding the hype wave of.

But if you actually look under the hood, it's taking inspiration. It is not a one-to-one compliance with the MCP spec. It's really just like tools for agents in your browser, yo. Allright. So the specs might diverge. Keep that in mind.

It comes in two flavors. Since my comics are not forms except for search, I used mostly the imperative model. But with declarative, you can just add tool name and tool description attributes to a form. Boom. If you're using JavaScript or functions to process that form, you just basically told you expose that form as a tool to the agent.

Great for sites with lots of forms already, if you're one of those people whose site is a dashboard. Using the imperative model, it passed navigator.modelContext.registerTools with parameters. It's great for API calls, workflows, data transformation. I used a lot of those.

Allright. So now, if it's available, if you find model context in navigator, you can say, I'm going to register a tool. You give it a name. You give it a description. Give it an input schema. My god, it's so similar to MCP.

How amazing. How can this not be the same thing? But you also pass it an execution callback. And in this case, this is a what do we do? Next page. This one basically grabs the link rail next from the page and passes it as the thing that you're supposed to navigate to next.

So you could call this to navigate forward and backward on the page with a browser without having to click around. Whew. This is new. So I can only help you imagine how it works, because the standards bodies are still fighting back and forth on it.

So I'm going to show you how to use it using the MCPB extension. This is kind of like a debugging extension. You can see all of the little tools are exposed over there. I've got a little chat window.

This kind of imitates what people might see in Gemini or some future in-browser agent. In this case, I believe I am saying, read this to me. It returns the transcript. And then I might say, I might type in thank you.

Love that transcript. I might type in, like, go to the next page. Come on. Go to the next page. Oh, I was speaking into the microphone at this point. That's fine. Anyway. And when I hit go, it takes me to the next page.

That's just the model calling that function on its own. Yay. That's the wow. Don't applaud yet. So best place to get started to check this out is actually with this interview I did with the creator of WebMCP. It actually started at Amazon.

This was something he made to get around a bunch of auth issues. And I love that I screen captured it. Window.navigator.registerTool. There's standards community group. All very lovely. It's not fully supported yet, but you find all the resources in the commentary on that article.

So I started my journey with the agentic web with this talk like two years ago, when I was like, the browser is going to die. But what people didn't take away from the clickbait was that the web isn't dead, y'all.

It's just changing. It's evolving. CSS and JavaScript aren't just the language of the web. They're the language of interactive experiences on agents. Allright. Here it is in action. I want to show you that there is a version of this that talks.

Brenda looks skeptical while Rachel continues explaining. Rachel, ha. Gore left out some important tidbits. Rachel, what about how plant life will respond to the extra carbon dioxide? Panel 2 illustration shows tall plants and vegetation growing vigorously.

I could keep going. But that's just the web speech API there. It sounds terrible. I'm sure you can do something great with 11 Labs. It's the browser's built-in text-to-speech capability. Zero dependency solution. No inference required for that. It'sright there, waiting for you to use it.

So are all the other amazing APIs available in the web today. So all these APIs, web speech, animation, audio, canvas, Wasm, CSS, and more, they're already there, waiting for you to make something with them. And I just can't wait to see what you do with this infinite canvas.