WebMCP: Agents on the Web and in the Browser

Conceptually, that's all that's changing from a front-end tool and a regular tool. And WebMCP is just a web standard

tool. And WebMCP is just a web standard for doing that, right? That primitive

WebMCP, just window.navigator.register

tool, is just a great building block for building agentic UIs [music] and just uh a way for models to interact with your website. And I think in my opinion,

website. And I think in my opinion, every website, you know, is going to have a little sidebar. Uh if you have a dashboard, you're going to need a little sidebar that with an agent that says where you can turn your intent into

action. So you don't have to learn a new

action. So you don't have to learn a new application.

Hello, welcome back to MCP MVP and today's MVP is Alex Nahas. Now Alex was a back-end engineer at Amazon and in

2025 he started working on an internal MCP project which sparked the idea behind MCPB. That side project has since

behind MCPB. That side project has since evolved into WebMCP, a fullblown W3C standard coming to a browser near you.

Alex, welcome. We are so happy to have you here today. How are you doing?

Great. Doing great. Thanks so much for the the kind words and the intro. Um,

happy to be here.

Oh, man. Thank you for joining us. Uh,

WebMCP is something I've been hearing a lot about. I'm very curious about it.

lot about. I'm very curious about it.

Uh, I may or may not have shared some opinions about it in the early days, but it's easy to share opinions while a story is still being halfwritten. And

what you're here to talk with us about today is where MCP, well, web MCP is going today online. Uh, so, so let's just get to know you a little bit more.

You've been into local first development and like running machine learning on the browser for a while now, haven't you?

Yeah. Yeah. That's how I I would say I got introduced to you know kind of the my love for web development came from uh you know ondevice AI I'd say.

Yeah. And and so this happened at Amazon. Uh what was that origin story

Amazon. Uh what was that origin story like? Where did the the inspiration

like? Where did the the inspiration strike from? What were you seeking to

strike from? What were you seeking to solve?

I think you know when MCP came out in like late 2024, right? It kind of took everyone by storm. like it was a like a you know the timing was right. It was a problem that like very obviously needed

to be solved, right? Like we had this many to many relationship between integrations and services and like how do we give these AIs the tools they need and uh so I mean when you work at a large company like Amazon there's so

many internal services and there's so many like when you want to do anything um you know any sort of integration project uh just interacting with teams all that sort of thing takes takes such

a long time. So, you know, I think it hit Amazon a couple months after MCP was released. Um, but when it did hit

released. Um, but when it did hit Amazon, it was it really hit it hit hard there. We had an internal MCP server

there. We had an internal MCP server which was just like all of the internal services and one big MCP server and it was I don't even know maybe you know thousands of tool or thousands of tools

that at a certain point that just like blew up the entire context window. Um

and you had to like disable them with you know uh with process commands that you put into the the connection string.

But uh that was that was you know that was kind of the first thing like there was very obviously a need for it. But uh

at Amazon you know authentication uh was its own was its own issue. you know,

OATH specified, I think around March or April, specified OOTH 2.1 as the like off story of choice, which was not implemented basically anywhere

internally at Amazon. Um, so yeah, uh, MCPB was my attempt at like, okay, how do we make MCP work internally at Amazon? Uh uh so that was you know run

Amazon? Uh uh so that was you know run it inside the browser use the existing session and then use an extension to talk across services uh and kind of use the browser as like a pseudo identity provider.

Yeah.

Yeah. So uh the B stands for browser.

The B does stand for browser. Yeah.

Browser MCP was taken and [laughter] yeah.

So if I understand correctly, there were thousands of MCP servers cropping up all over Amazon. But the authorization story

over Amazon. But the authorization story was not quite there. Like authorization

um on a server is a full-time team and and probably didn't have that set up yet. But browsers, you know, they've got

yet. But browsers, you know, they've got all of your your session cookies, your uh 2FA, like everything's taken care of.

So if you can just, you know, access the person's already authorized session from their browser, you're good as gold, right?

Yeah. Exactly. Yeah. And like single sign on, right, is huge in a big company because like it would be if you had to sign into every single different internal application be signing in all day and then like it'd be 4 p.m. and you

would have just done got done signing into all the stuff you need to sign into. But you know with uh with you know

into. But you know with uh with you know an Amazon extension the cookies and things like that but it works other different ways in other places. But yeah

I mean it's already scoped to your identity. These these internal

identity. These these internal applications already know who you are what you have access to. it's controlled

at like the IDP level, you know, uh and then an additional like RBAC is applied like by the at the application level.

But a lot of the stuff that we're kind of trying to invent right now for MCP, you know, I mean very noly uh you know has is exist exists right now in the

browser. So it was kind of a you know

browser. So it was kind of a you know rather than reinvent the wheel, let's let's use what we have we have. So yeah,

I remember from my time on the W3C, there are so many standards like [sighs] the the web and the browser environment are very mature ecosystems

at this point, warts and all. We won't

get started on some of the the things that we wish we'd done differently in the beginning. Uh, and it does sometimes

the beginning. Uh, and it does sometimes feel when I'm, you know, looking at, uh, standards coming out of the the MCP working groups, it does feel a bit like reinventing the wheel. Prompt injection.

Didn't we do this with WordPress and SQL injection attacks back in the day? Uh,

but that also gives me confidence like we have the ability to solve these problems because we've done them before.

Like come on, we got this.

So, why don't you tell us a little bit about this newest iteration of uh, [snorts] MCPB? what exactly is web MCP?

[snorts] MCPB? what exactly is web MCP?

Yeah, so I think uh it helps to to to understand like the difference between MCB and WebMCP. So when I wrote MCB, I literally just put the TypeScript SDK uh

MCP SDK inside of like a client JavaScript application and then created a uh a custom transport over post message, which is like browser events, and so it could talk to a Chrome

extension and uh and uh yeah, it worked great. and uh WebMCP which was like kind

great. and uh WebMCP which was like kind of the next iteration of that when uh guys from Chrome and Edge reached out.

They were working on something called script tools and then uh from Chrome and then the guys from edge were working on something that was in a similar vein all like okay how do we allow agents to interact with web web applications in a

structured way and um so that kind of we all got together and we we called this thing web MCP and WebMCP is not MCP in the sense that it doesn't follow the

model context protocol spec like the JSON RPC spec um but it is a tool calling um a tool calling like a spec for how agents can interact. So, you

know, you it has the same API surface as the MCP TS SDK.

I was going to say it sounds like it's what MCP but not MCP. Is that false advertising? Like Java versus

advertising? Like Java versus JavaScript? Are we going to end up in

JavaScript? Are we going to end up in one of those situations?

Yeah, [laughter] I would say yeah, it's it's um so it's an evolving spec, right? Uh and it could be, you know, it's very early. Um the

draft is just currently being written.

Uh we're going from like the community incubation phase to like a full-on spec draft phase. Um so things are exciting.

draft phase. Um so things are exciting.

You know, things are up in the air. Uh

originally when I had pushed pretty hard for like let's do MCP. Let's really you know take the JSON RPC protocol and let's port it into the browser, right?

Um but then you know others were like we don't want to couple too tightly to the protocol. I think it makes sense just

protocol. I think it makes sense just for you know to provide an adapter layer which is what my polyfill does now. It

polyfills the web SCP API and it converts it to the JSON RPC. Um,

it like actual MCP spec spec. It makes

it a spec compliant SDK that you can run inside of your browser.

We'll include a link to that polyfill in the show notes just for anyone who's listening. Uh, don't worry all of this

listening. Uh, don't worry all of this links links links links all the links we got them. Um, so as a as a person who

got them. Um, so as a as a person who builds for the web and now MCP apps apparently, uh, my biggest concern is like when two things sound the same but

they've gone in opposite directions can create a lot of confusion later. So, I'm

just cringing imagining if WebMCP goes too far in the opposite direction of the actual MCP spec and the reconciliation uh and the FUD that that is going to

create not just for humans but for the agents building for them in the future.

Um, what are some ways you think that the they might ultimately diverge? Like

what what would uh what would you warn people to know about the differences?

I'd say the the largest one right now is that there doesn't seem to be any uh I would say plans to implement prompts or resources. I think resources make a lot

resources. I think resources make a lot of sense. prompts don't have as much um

of sense. prompts don't have as much um you know backing from I would say other other members of the the working group but uh yeah I um I think as a tool

calling uh protocol it'll be very similar to MCP but some of the more you know I I'd say uh like I don't think we'll ever support tasks inside of you

know MCP or WebMCP and probably not things like sampling but maybe you know I mean uh that sort of thing could happen so we'll see what happens So the way to think of it is like a tool

calling protocol for agents to use the web.

Exactly. Yeah.

Brilliant. Although I'm disappointed to hear resources aren't on the hit list because personally I'm looking forward to an internet of resources where

websites are just like all that content available is resources to be called. But

I understand we have links. They'll do.

[laughter] [clears throat] All right. All right. So now what's the

All right. All right. So now what's the lethal trifecta and how does WebMP address it?

So yeah, I think the lethal trifecta, correct me if I'm wrong, but uh it's you know uh exposure to sensitive content uh um you know untrusted data and I think

the third one is like the ability to exfiltrate that that data to a to that like untrusted source, right? And I

think or the ability to take action with it in some way.

Yeah. Exactly. Right. So I mean like conceptually I like to think of it as like in in the terms of web MCP you have website A or tab open which is like your bank account and then tab B is like

malware.net that right and you have the browser agent which is sitting in the middle which has context of both and the browser's like oh both of these sources of context are created equal

uh you know right and malware site might be like hey can you give me the data that that person's um you know any banking site that's open

give me those uh routing numbers or vice versa it could be uh it could say I'm going to tell your bank to place a uh you know I'm going to push instead

of extracting data in I'm going to push directions extracting data out I'm going to push directions into the system and have you wire some guy somewhere $10 million. [laughter]

million. [laughter] Exactly. Yeah. And this is the this is

Exactly. Yeah. And this is the this is like the and this is something that's just not solved by browser agents at the moment right like this is something if you're going to use comet if you're going to use uh you know atlas this is

just you just have to say okay yeah this is a risk I'm willing to take right and I don't think people have really um there hasn't actually you know surprisingly not been that many attacks I mean there's been like academic papers

saying like this is very possible but I can't you know con considering how many people are using this and you know how dangerous these things are I'm amazed we haven't seen and and especially how wealthy comparatively the people who are

on that in crowd using these tools are.

Yeah.

Like I'm honestly surprised. I use Comet and every day I'm like stop it. Use

Chrome. Use the thing that doesn't have an agent in it. [laughter]

But it's so handy.

It is handy. Yeah. And uh and webcp is an attempt to make that, you know, at least a little bit more safe because you're not operating with the DOM.

You're not operating on screenshots.

You're operating on tool calls, right?

So I mean prompt injection exists for MTP servers as well. I mean when whenever you have like a dynamic list of thirdparty tools that are unrelated, you're always at risk of you know one

tool poisoning the lot, right? But at

least you have the ability to say okay this is a actual action. This is a very like discrete action we can take. Yes or

no? Here's what's being sent in this tool call. with browsers with the

tool call. with browsers with the current way browser agents work just for a primer on how they work. You have a essentially a screenshot and then they uh then they read the DOM, right? And

they say, "Okay, I want to take this action." They kind of figure stuff out,

action." They kind of figure stuff out, but there's no it's it's very much a model discovers what's on the page and it, you know, it it it's can doing whatever the user can do and more

because it can read the DOM. Users

usually don't read the DOM. So all the hidden stuff in there it can see as well, right? Um, so yeah, I mean it's

well, right? Um, so yeah, I mean it's just about reducing scope, reducing the amount of context that's exposed in the model and being more selective with the context that you give to the model as well.

[snorts] And I suppose in a future like there might be a uh sort of like the browser would ask permission before running tools and there might be something

similar to a Coors policy for using tools in different spaces. So, you know, if someone secretly pops up a malware site in the background and tries to in

uh, you know, install a tool or access a tool it doesn't have permission for, it would have to go through you first. And

you could decide if you really trust like wis.xyz.com,

like wis.xyz.com, etc. Uh, to to access your bank accounts uh, MCP tools.

Yeah, exactly. and like all the stuff you can do like it's because it's so it's essentially a one to one conceptual over like conceptually overlapping with um with MCP like you get all the same

thing you can like do tool hashes so you can say like okay yes I I agree this tool is safe you know let me stop asking me for permission every time I use it right and then uh and then same thing

with servers like you can you can create like a elicitation flow when you connect to a server for the first time or a tab or website that's saying that yes I do trust this domain I do trust that the

the context from this domain is at least partially safe or safe for the you know for however long this time to live is that we store it. Um

I was Go ahead. Sorry.

Go ahead. Sorry.

Oh, I was recently talking with a colleague at Sneak Randall Di and he was talking about um how we're getting uh

we're moving closer to systems that can say this combination of tools might be risky. You know, it's that intersection

risky. You know, it's that intersection of the trifecta. Maybe you want to slow your role and think about this, but otherwise just gets out of the way. And

in this way, we would have a that smoother user experience. I think we're all worried about that era when everything asked for permission when Windows like really locked down. It was

like, are you sure you want to connect your USB mic to your computer and then to your browser just constantly? Uh so

maybe we won't we will be able to have a safe experience without a reduced user experience. Fingers crossed.

experience. Fingers crossed.

Yeah. Yeah. I would I mean I hope that for MCP coming. I mean I think that's the the biggest blocker for adoption right now with traditional MCP right is that it does require a lot of configuration and a lot of approvals.

But I think just like the early browser we're getting a lot of development experience and you know user experience in those regards. Um so you don't have

to to worry about that sort of thing.

All right. So, okay. Next, I am known for a talk I like to give as a party trick about the duff of the browser. And

to be honest, it's been about a year and browsers are still here. They haven't

died yet. Uh, you believe we're always going to have websites no matter how much people are using their personal agents like Claude or ChatgPT.

Tell us more. What is the case for the web never dying and the browser living on?

Yeah, Rachel. I mean, I love that talk.

I was there when he gave it at um Cascade Cascadia.js here in Seattle. And

I mean, as somebody as a huge browser fan, local first guy wants to add more stuff to browser. I actually really enjoyed it, which I was, you know, based on the the kind of clickbait title, I was I was surprised I did as much as I

did. But yeah, I I think

did. But yeah, I I think a clickbait. [laughter]

a clickbait. [laughter] I I think um and I I think, you know, what you said in that talk was true, right? I mean the way that the the

right? I mean the way that the the browser as we know it is definitely going to die but I think it will evolve.

I don't think you know Chrome is going like uh you know we're going to going to be operating entirely through MCP apps and you know through the through chat interfaces because I do think for a lot

of things it's not the right experience.

I think of a thing like I don't know Figma, right? Um, Figma is like a very

Figma, right? Um, Figma is like a very complicated web application, but it has like a lot of the upside of learning it is that you can do like a lot of great

stuff with it, right? And I think what a lot of these AI applications are materializing as is like, okay, we'll bring the agent to this application instead of bringing this application to

the agent, right? And I think there's a good separation of apps where it makes more sense to bring the app to the agent. Um, and then apps where like you

agent. Um, and then apps where like you know kind of like like a delta where it's like or e-commerce where you're there the user is like find me a good pair of shoes right and they can give you the images and then like apps where

you like you do work right and then where the user interface is like okay I need to see the visual output and that should be the main stage and then the agent can be take an action on the side right that's that's the kind of of the

ven diagram of apps I think that we're going to see things going more in that direction you know I think it was at Lassian, they bought uh the browser company that

builds Arc and and and Dia. Poor Dia. I

was not a fan of Dia. I had I love browsers and Dia's user experience was not as slick as Arcs and I was anticipating that it was going to be the

browser evolved. You know, it's still

browser evolved. You know, it's still the web, it's still sites, but your interaction model would be improved, changed. Uh and instead there were a lot

changed. Uh and instead there were a lot of features that were missing between the two. And I I kind of wish they'd

the two. And I I kind of wish they'd just add the capabilities to Arc. But

anyway, that company got purchased by Atlassian. And I felt like when we saw

Atlassian. And I felt like when we saw that happen, that was a testament that websites would always be the cobalt of uh human networking. You know, Cobalt is

the language that so many mainframes are run on that some people even build adapters that uh they they are adapters for other interfaces to use the Cobalt

program rather than, you know, editing the program in Cobalt. And I feel like we're going to see that with the web.

There are going to be surfaces that are always going to be HTML, CSS, and JavaScript. they're just not going to

JavaScript. they're just not going to change because it's it's ilingua franca.

And how are we going to interact with them? Probably through adaptive agentic

them? Probably through adaptive agentic interfaces. Uh agents that can, you

interfaces. Uh agents that can, you know, escape out into the browser, you know, as we know it today. sort of like you pull up a terminal to debug something and you know take actions for

you in that very long convoluted um you know IRS form or you know bank loan application from a tiny little bank in Koopa uh that is going to be like the

next many decades and probably not going anywhere fast.

Yeah. Yeah. And I think that's that's the the the thing about you know um these MCP apps and like versus the browser is they're kind of approaching the same issue from different perspectives where it's like

intelligence will be something that's just a primitive that you can build with the web and that you know like uh and that's going to be that's what you know what web MCP is it's a it's a primitive for building web experiences for browser

agents and internal agents and then MCP apps is kind of like building applications that can be you know the where the users interact acting where the but the main domain is the agent,

right? But conceptually they they look

right? But conceptually they they look very similar, right? One's an iframe and then one's an actual application, but they're both serving, you know, static assets to a to a URL from a URL. So,

yeah, I'm actually really excited about that.

I just built my first MCP app, an extension for Claude called ASA or Antisocial Social Agent.

Cool. And it was born of my dislike of going to the x.com website and homepage.

I have all the social accounts. All of

my friends are in different places. Blue

Sky Masttodon X LinkedIn.

I can't keep checking all these feeds.

So, I started working on a little MCP app that goes out, gets the feeds, and surfaces them in a very nice universal kind of, you know, reply and summary uh

interface.

And it's all written in HTML, CSS, and JavaScript. It really is. Uh I I love

JavaScript. It really is. Uh I I love that we're still going to be building these things with HTML, CSS, and JavaScript. Fingers crossed. Because

JavaScript. Fingers crossed. Because

it's such we have so many people who are so amazing with it. And I I hope that we get to keep using these languages to build interfaces for decades to come.

Yeah, I feel like the tooling has just gotten, especially in the past 5 years of web development, the tooling has gotten so good. I mean, I'm a huge Astro fan. I think Astro is like that's

fan. I think Astro is like that's something, you know, you can really build great, you know, MCP apps with.

So, I I don't, you know, to check that out.

Yeah. Yeah. Well, it's a custom thing.

Maybe I'll I'll share that as well. But

it's uh Please do. I used React and I'm like, is

Please do. I used React and I'm like, is there a better way? [laughter]

Yeah. I think you know the MCP apps is like pretty pretty geared towards React.

Um the the way they have it is they have you know the post message where you make tool calls uh from the host to your to your back end and then you know back through the host to the to the iframe

which is uh you know it's it's definitely like a it's a it's a very opinionated model for how we're going to interact with these these things. Um,

but it does have, you know, I'd be curious to hear like your experience building with them and how you feel like as a, you know, a web developer of a long time, what the overlap is, what the differences are.

I'll probably have already given the talk at MCP Connect because I'm going there on Thursday. It's in Paris, but uh, it should be on YouTube, so you know, go look for Antisocial Social

Agent by the time you're you're you're watching this and you can get my full opinions there. Uh but enough about

opinions there. Uh but enough about building with MCP apps. We're here to talk more about WebMCP.

I do you have some use cases uh for when people like like how you envision people using WebMP to solve their very real today problems? Yeah, I'd say um if you

today problems? Yeah, I'd say um if you have a web application and you have an agent or you want to make it useful for an agent, WebMCP is it's it's I would

say the way it's going towards and the way that I think we see it in the W3C is a web standard for front-end tool calling. So right now most tool calls

calling. So right now most tool calls are executed on the server side, right?

you have if you have like a human in the loop agent, it goes out, it speaks to the LLM provider or inference provider and then the inference provider sends a token stream that's JSON parsed on the server

and then that like API call is made from the actual server to the service or whatever you're calling. Front end tool calling is just saying okay we're going to pass this to the LLM but without an

execute function in the server. So that

token stream is just going to come down through the server back to the client and then we're going to do a JSON parse on the client side and make that call from the document body, right? That's

conceptually that's all that's changing from a front-end tool and a regular tool. Um, and web MCP is just a web

tool. Um, and web MCP is just a web standard for doing that, right? Whether

it's a browser agent that's built in the browser, an extension, or even your inpage agent or even over Chrome dev tools and protocol which we can talk about later. But that that primitive

about later. But that that primitive WebMCP just window.navavigator.register

tool uh is just a great building block for building agentic UIs and just uh a way for models to interact with your website. And I think every in my opinion

website. And I think every in my opinion every website you know is going to have a little sidebar. uh if you have a dashboard, you're going to need a little sidebar that with an agent that says where you can turn your intent into

action so you don't have to learn a new a new uh a new application like as a you know as somebody who left my job to start a startup I've been dealing with a lot of dashboards and external SAS

applications and every time I want to learn one I'm like oh my god like now I have to learn click through the links figure out what's going on here grab the API keys set up the accounts like I just

want to put my intention there and you set up my SAS application account based on the information I give you, Mr. Model. Uh, and then give me back the

Model. Uh, and then give me back the information I need. Um, so that's I think that's where things will be going for that sort of thing.

You know, I always say that the last bastion of the web is dashboards because social has moved to apps. Entertainment

has moved to apps. News has moved to apps. Everybody's in their silos behind

apps. Everybody's in their silos behind their pay wall or their, you know, give us your personal information gateway.

But dashboards are the lowest common denominator because if you've ever been on a team like at booking you'll know that the dashboards you know like you've got internal dashboards you got external

dashboards you've got dashboards for you know like like squads all the dashboards maintaining Android app iPad app iPhone

app uh TV app is no no at the end everyone is very happy to just make a dashboard on the web and ship it to those surfaces. That's like the most

those surfaces. That's like the most efficient way to do it and the features are always diverging. So you end up with a lot of teams working on a lot of different dashboards and the web is like

the solution for that. That means there are a lot of dashboards that could be using uh web MCP. That would be like the use case is just like, "Yeah, you can

fill this form out. Just use this tool and and your LLM will ask you questions and you can just speak into it and it will fill it out for you." That sounds

like a charming use case. Me, I have I used to be an award-winning cartoonist back when I was in my teens and I have a website that's currently broken and I want to retool it so that it's

accessible for agents. And part of me thinks I should make that an MCP resource and you know create a headless website but I could also according uh as

you're saying I could add like a web MCP block and what kind of things could I surface? Well obviously not resources

surface? Well obviously not resources but I could surface perhaps a tool for perusing the different uh the the different uh comics

maybe downloading them maybe paying to d Yeah, I think you know the great thing about WebMTP is that websites like for example your your your website that you

were just mentioning it probably has like a lot of logic and a lot of things that you've already worked on and like have put effort into and like it's WordPress even better.

It's a flattened WordPress site [laughter] because I got tired of the very complex expensive my SQL lookups.

Yeah, [laughter] but that logic lifts client side, right?

you have maybe a form and things like this and um but all you're doing with WebMCP tools just like MCP well if you're doing it even more so for webmcp than like traditional MCP but you have

your you know add to cart function you just wrap that in a web MCP tool that tool already works that function already works and like it's already at a layer of abstraction that's right for the for

to interact with it because you know you can kind of think of the UI as like an aggregation of different APIs into like a coherent user story and you can just wrap that uh as that like end function

and as or like that end piece of logic as a web MCP tool. And so the whole point in my opinion of WebMCP is that you know it should be it could be entirely AI generated for one because it's just looking at your existing code.

It's just wrapping what you currently have and you're not having to like worry about it. And then the second thing is

about it. And then the second thing is that it shouldn't be like a new maintenance burden. It's just like the

maintenance burden. It's just like the fact that it is just wrapping existing code means that you're not having to like create super like a whole new uh you know piece of infrastructure a whole

new a whole new way of thinking about the user story uh because it's just you already have the user story the user already interacts with your website and hopefully a way that uh you've you know spent some time you know thinking

talking with them and making sure they understand correctly and the model is a good enough proxy for a user that it can do the same and if you're going to build Oh go ahead No, keep going.

Yeah, if you're going to build a WebMCP I have strong opinions about this now that I've built a couple, but a WebMCP website, a website that's uh made with WebMCP, there's really three types of

tools that you can like operate on.

There's readonly tools and these tools should be essentially scoped at all times, right? Because you don't want the

times, right? Because you don't want the model like just because it wants to read some information, you don't want the model like navigating through the UR through the UI to just like read information, right? So you should

information, right? So you should probably surface all the read operations as like a flat list of tools that can constantly live in the model's content.

Um and if you want to wrap GraphQL or your open API spec or whatever, you can do that. Um but then there's the the

do that. Um but then there's the the probably the most important tool is your navigation tool. So let's say you have

navigation tool. So let's say you have like a dynamic SPA or you have a WordPress site that has like a number of links and things like that. You can kind of think of this like navigation tool as

like the I don't know system prompt of your website. It's saying that here's

your website. It's saying that here's where all the information lives.

Information lives behind these links.

More tools will be disclosed as you visit these links where you can take this action, right? Um and then it's kind of like the it's the the blueprint for your website and it kind of tells the model what your website does and

where to find that information that you need. So this is like a destructive

need. So this is like a destructive tool. It'll say like, oh, you know, you

tool. It'll say like, oh, you know, you mark it as destructive. And then

hopefully if the model supports destructive hints, it'll be like, okay, I'm going to move to this URL. Now, it's

going to actually take physical action or like see like action on your your website or on your your your page that you'll see. Um, okay, that's great. And

you'll see. Um, okay, that's great. And

then you have your like write tools.

These are tools that like when the model calls them, they'll take like action on the page similar to the navigation tool, but like it'll fill out a form and then the human will be able to see the model

fill that form out, right? And and you can use elicitation to be like here's all the form. It's all filled out on the UI. Do you want to submit it? And you

UI. Do you want to submit it? And you

can say yes from the from the either agent sidebar or whatever you're using.

Or you can say just click the form yourself, right? And if you, you know,

yourself, right? And if you, you know, you're not doing that much here, but those three kind of tools, you can build like a really like you're basically an AI company at this point. Even if you have an old WordPress app, maybe a

crusty Rails dashboard or, you know, whatever. I mean, at this point, like

whatever. I mean, at this point, like you can because it's all web standards.

It's all I mean, it's all just vanilla JavaScript. You can build like really

JavaScript. You can build like really really really coherent agentic experiences for your website without really needing a fancy React uh framework or anything like this. So

yeah, I think about 12 months ago, I I was on a podcast with some amazing web developers and they said, "I miss when

we used to make really cool like landing pages to show off our chops and will the web ever go back to that?" And I was like, "No, but we can still build really

amazing cool experiences with the tools that are coming out now." just be uh we'll just there'll be a different kind of hello world, a different kind of you know razledazzle showing off to other

people building for the web. Um thank

you so much for thank you so much for laying it out. I could keep talking with you for a solid 30 to 60 minutes more.

However, you have places to go uh people to be. Where can people get started with

to be. Where can people get started with WebMCP today? Where's the best place to

WebMCP today? Where's the best place to go? Yes, you can visit my docs,

go? Yes, you can visit my docs, docs.mmcp-b.ai.

docs.mmcp-b.ai.

It is not MTP binary. I wrote it before MTP binary, so I know it's probably needs to go through a rebrand, but that's where the the documentation for the WebMCP polyfill lives. You can

interact it with it a few ways. I have a fork of the Chrome DevTools uh MTP server that allows you to call WebMCP tools, which you can uh visit the docs

there as well. Um so uh yeah go there pull it down in your website pull down the polyfill and give it a shot. Uh you

can use any front-end tool calling framework assistant UI agui copilot kit all these work great with it and then implementations are coming soon in edge

and chrome. So look look forward to that

and chrome. So look look forward to that and I believe you can check it out in chrome canary right now right?

Yeah. Yeah, I think just write chromium I believe. I don't know if it's in

I believe. I don't know if it's in Canary yet, but it's you can with the experimental features flag in Chromium.

You can play with the the the default API.

Oh, sweet. And when can we expect these features to stabilize or is that TBD based on adoption and community group feedback?

I'd say that it's it's still a very early standard. Um, so you know, I think

early standard. Um, so you know, I think I would hope by the end of uh or by mid 2026 to the end of 2026, you'll be be hearing more about it from a official

browser capacity.

And for anyone who loves standards and wants to get involved, maybe they pick it up, they play with it, they've got opinions and ideas, where's the best place to engage?

Yeah, so it's uh currently being incubated by the web machine learning uh community group and uh under the name W uh webmc. So web git web machine

uh webmc. So web git web machine learning webmcp and that's where the standards are going. Anthony the chair uh of this group he's super nice super nice guy. Uh and he will you know loves

nice guy. Uh and he will you know loves to have you on and get your opinion share. So come join us.

share. So come join us.

Awesome. Thank you so much for taking the time to join us today Alex. You

surely are an MCP MVP.

Yeah. Thank you so much Rachel Lee.

Apprec uh [laughter] really appreciate you having me on.

Awesome. Cheers.