# WebMCP Standardizes Agent Authentication and Browser Automation

**Podcast:** alphalist.CTO Podcast - For CTOs and Technical Leaders
**Published:** 2026-05-21

## Transcript

Hello friends, this is the Alphalist podcast.
I am your host Tobi.
The goal of the Alphalist podcast is to empower CTOs with the info and insight they need to make the best decisions for me.
We do this by hosting top thought leaders and picking their brains for insights into technical leadership and tech trends.
If you believe in the power of accumulated knowledge to accelerate growth, make sure to subscribe to this podcast.
Plus, if you're an experienced CTO, you will love the discussion happening in our Slack space where over 600 CTOs are sharing insights or visit one of our events.
Just go to alphalist.com to apply.
Welcome to the Alphalist podcast.
I'm your host, Tobi.
And with me today is a very young engineer called Alex Nahas.
Alex, how old are you actually?
I'm 28, so I guess not that young.
Well, fairly young for what you just achieved.
I appreciate it.
I don't know if it was like a planted or kind of accidental, but you're the creator or initiator of a standard called WebMCP, right?
Yep, correct.
And you're also working on that as like in founder mode as far as I understood it.
And beforehand you worked as a backend engineer at Amazon and yeah, then started like building agents on top of Antrofix MCP and eventually...
This led to WebMCP or what WebMCP is now or is becoming now.
So before we start, maybe you can tell us a little more about yourself, like how you actually got where you are, how you discovered your love for computers.
If you're loving them, I'm not sure.
So what is your nerd path?
For sure.
Yeah, for sure.
No, so I actually did my undergrad, which is like...
Yeah, I guess for the Europeans out there, it's just like, you know, college.
But I did it in physics, right?
So I was really interested in that.
And like, I really enjoyed the computer classes I took, even though they were like MATLAB.
And like, we even did like low-level computing stuff, like in assembly and 86-bit.
you know, little machines that we were running.
I thought that was really fun, right?
But I was, you know, I had plans to go to college or to get my PhD and do all these things.
And then, but it kind of burned out by the end of college.
And a friend of mine was doing like React consulting, right?
React just came out around the time and it was picking up and I started helping him out, kind of doing some web dev.
And yeah, it just kind of got me in there.
And then, yeah, I mean, that was pretty much what got me in.
I got kind of hooked, just building on web stuff.
I ended up getting picked up by a consultancy at Cincinnati where I was living at the time.
And it was a Rails and Elixir shop doing that.
Ah, cool.
Cool.
And yeah.
So I really...
You're a Rails too, as well, in a way.
Yeah.
So yeah, I was, you know, really got like...
A lot of these guys have been developing since like the early 2000s, you know, late 90s.
And so it was great.
Also like you said, you're a bit young for Rails, actually.
Exactly, yeah.
But no, it was good.
It was, I think it gave me a love of, you know, standards and like...
When you're hanging around older engineers, you know, you get to see like all the mistakes that have been made throughout the years and all the things that have been hyped up and then died.
And then, you know, the things that have stayed.
So it was good, you know, not just a React path entirely.
So, yeah.
And from there, I had gotten kind of into competitive programming.
So I, you know, that kind of leads naturally to big tech and ended up doing an interview there and, you know, got hired to work at Amazon.
And it was a great time.
I enjoyed it.
Yeah, that's, you know, WebMCP was meant to solve a problem internally.
And then it kind of spiraled from there, I guess you could say, in a good way.
And was it inspired by MCP initially?
Or did you have like that, I don't know, inflection moment where you thought like, okay, this is how MCP works.
So let's translate it to web.
And then that like kind of led to what it is now or?
Yeah, I mean, basically that.
I think, you know, I think web is a surprising thing that's not.
Like people don't really think about web as much as they should, in my opinion, in places like the West Coast right now.
Like a lot of it's very backend agent heavy.
Like people believe that agents need to run in these cloud containers, you know, things like this.
But like the web has been, you know, and the browser itself is like the perfect sandbox we've been iterating on for so long now.
And in Amazon in particular, like there's so much infrastructure built around the...
the browser.
Every internal app is secured, you know, every is like secured via like the specialized browser extensions that we use to inject authentication via like SSO and things like this.
And yeah, so a lot of the MCP stuff, people were like, oh, you need to like figure out how to talk, make machines talk to each other and authenticate users on our agents on behalf of users somehow.
And like, are we going to do this and all this with MCP?
And I was like, what if we just run an MCP server inside of client side JS?
And then you know, that document, that runtime that it lives in already is authenticated and then just make those calls from there.
So then there's all these benefits that come along with like, you could use it for browser automation and it's, you know, way more token efficient, things like this.
And so basically the user that is already authenticated against, let's say, Amazon would then be able to act as an agent at that moment, right?
Yeah.
So, yeah, I mean, When agents take action, right?
So if we want to take a step back and like, you know, kind of define what MCP is.
So agents are like essentially, you know, they're just chatbots that can like call tools in a loop, right?
So a tool is just a function with some like semantic meaning behind it.
So the model knows when it, you know, has, when it generates a little JSON blob, the runtime it lives in will parse that blob and call a function with it.
And that's a tool.
That's all it is.
Like, it doesn't matter where that tool lives.
Doesn't matter what that tool does.
That's all a tool is.
And MCP is just saying like, okay, I have tools that live in area A and I have my user or agent or whatever lives in area B.
There's your different processes.
How do we get these things to talk to each other?
And that's just what MCP is.
It's an RBC framework.
So like just calling a function on a different area, getting the response in a structured way.
That's the protocol.
It's, you know, there's all this like crazy stuff around MCP that makes it sound super complicated, but it's really just the JSON-RBC protocol.
It's not.
It's super simple.
It'd be just a wrapper around API documentation, right?
100%.
Yeah.
It's literally, yeah, it's 100%.
So it's super, and it's gotten way more complicated since.
But that's the initial inception of MCP was like, yeah, let's just need a few things.
So yeah, I mean, that's...
And that's what WebMCP, the difference between MCP and WebMCP is WebMCP, when I wrote it, was an MCP server, meaning just like a little process that living inside of a web page.
And then the client was an extension, which is like this extension that's also living, you know, it was like an internal agent extension in a browser extension.
So that's where the agent was living.
And the agent wants to call a tool on a page, it can just RPC that call over MCP in the web page.
So if you want to say add to cart, the extension will say, okay, add to cart, calls the web page and it makes the call from there.
And yeah, that's basically it.
But now WebMCP is a web standard.
It's got its own crazy stuff going on and we're working on it as time goes on.
And it doesn't look like WebMCP anymore.
But yeah, the concept is the same.
And what was the problem you wanted to solve if you were able to talk about it?
Yeah, absolutely.
So MCP, like we've just, you know, described it as an RPC.
function calling protocol.
But it very quickly became like the OAuth guys got in there and they were like, well, this doesn't have auth, right?
So we need to figure out, okay, they can make calls, but how do we know?
If they're allowed to make calls, how do we make sure that, you know, we attach the proper headers to their, you know, requests when they make calls, things like this.
And then so they got in there and they said OAuth.
OAuth is the future of authentication for agents.
Right.
And then, you know, every, you know, anyone who doesn't support OAuth be damned, basically.
And Amazon doesn't support OAuth for internal services, right?
We have, you know, like most companies on SAML.
you know, OAuth is great, like, don't get me wrong, but like it's, you know, like most of legacy infrastructure does not run on OAuth, right?
And most enterprises don't.
So yeah, that was basically it.
So the problem to solve was, okay, if we're going to do backend, backend MCP calls, we need to use OAuth.
But if we're going to just use existing infrastructure, use things that already work, just instead of, you know, calling the tool from the backend, let the model call the tool from the front end, and then it can use the, the existing author, assigned in authorization context.
Okay.
And then you just implemented that, implemented a Chrome extension, if I understood it correctly, at the same time to wrap it.
Yep.
And this basically was now migrated into Chrome, as I understood it correctly, right?
Yeah.
So that's basically the way that the Chrome preview extension works.
They have their model context tool inspector.
It's basically exactly the same thing as the original one I wrote, the MCBB extension I wrote.
I open sourced it last year.
But now it's built into the browser.
So by a web standard, like instead of having to use this post message, which is like these browser events as the transport to let the extension of the webpage talk to each other, now it's just built into the browser.
So the extension can just call list tools, call tool from the extension context, and it will list all the tools in the webpage that are registered with window.navigator.registertool, and then it can call the same tools.
So you don't have to...
provide these like third-party script shims to get it to work.
It's just built in.
And then same goes for browser agents, for agents that are calling over a Chrome DevTools protocol and driving the browser remotely, things like this.
They're all going to be able to just list tools and call tools that are declared in the JavaScript on the page or the HTML as well.
Okay.
And I mean, what happened in between the moment you had that initial idea and basically drafted it and the fact that it's now like...
becoming at least like a semi-official or almost official standard.
Where did you publish what you just did?
I mean, you said you started off your own business with MCPB and basically open source.
Did someone from Google reach out at a certain point or what, like, how was that?
Yeah, that's a great question.
So I originally like wanted to, you know, basically use it to like...
solve a problem internally.
So I wrote this thing and like I try to share it with people internally like look like this will solve all of our issues because everyone's so many teams in Amazon were trying to solve this issue.
And but it's like a lot of back end engineers and when they when especially with things with agents like things are like very over abstracted for you know and makes it hard to reason about why solutions work and why certain things don't and like what complexity is actually needed and what's not.
So people were not interested internally, at least.
Like, people didn't really get why this was solving anything.
So I was like, okay, fine.
I'll open source it, put it on Hacker News, and I did that.
And then it blew up.
Like, it got, like, 400 upvotes, and, like, that was what, you know.
And then from there, like, people were really excited about the idea.
You know, I wrote some stuff about, like, how this could improve browser automation, because browser automation, you know, right now is screenshot-based and things like this.
Or DOM parsing based.
And then, yeah, some guys from, I think it was, yeah, Edge at the time reached out and they were working on agent context, which was a similar sort of thing, but more geared towards, you know, how do we let the built-in browser agent interact with pages better?
And then Google guys were working on script tools and they were already kind of talking, trying to come together with like an idea for, you know, what.
a combination of all these ideas would look like.
And then a couple of those guys read the Hacker News post I put out and they invited me to come talk and yeah, kind of became WebMCP.
So the web standard as we know today.
And how unreal did that feel to you at first?
I mean, the initial success of Hacker News obviously is one thing, but then all of that happened?
How did that feel to you?
Yeah, it was crazy, man.
It's funny that Hacker News The Hacker News post, like I've been working on this post for like a month and I was, you know, trying to refine it and make sure it was perfect, all these things.
But I had nasal surgery the day I posted it and they put me under all these things.
And so like, I actually don't remember posting it on Hacker News.
Like my first memory coming back was like me arguing with people about on Hacker News who were like, you know, didn't understand the things like this.
And then from, yeah, but yeah, it's cool.
I mean, like.
You know, it's been kind of surreal since.
So it's, you know, I've always been a huge fan of WebStandard.
So it's been kind of like a dream come true to be part of that process.
And you're now still involved.
Yeah, yeah, yeah.
I meet with the guys, the community group every week or every two weeks.
And we were changing the APIs constantly.
I maintain the polyfills for WebMCP.
So I have a lot of users that I get feedback for and try to give that feedback back to the community group so people can iterate on it.
Cool.
Cool.
And that's not like a typical startup story of someone selling his or her company at a certain point, becoming rich quickly.
And you're also consulting on the side, basically around the whole thing, I guess, which is what you now do for a living, right?
Yeah, exactly.
So I didn't really have a plan.
I just knew I wanted to work on it.
I was super excited.
All these things were coming up.
And when it was announced as a web standard, I was like, okay, this feels like the future.
I was basically doing unrelated things at my job at Amazon.
I enjoyed my job, but I was working on a...
a Clojure code base, which like legacy Clojure code base at Amazon, which was fun.
But it was very different from the, you know, cutting edge stuff that we were doing, you know, with WebMCP.
So yeah, I left and, you know, kind of see what I could do and didn't really have much of a plan.
But after I presented the MCPD extension at TPAC, I had a couple of companies reach out to me and ask me to like basically consult for them, like how to implement WebMCP, how it could be useful for their business.
And I kind of spun that off.
And that's what I've been doing since.
It's been really fun.
And yeah.
I'm curious, how do you think a potential future of agent web communication could look like?
Do you think we're there with what you invented?
Or is there something that is still missing, which basically adds an additional level of indication and ID to whatever is agentic?
How would that look like?
Is that still a requirement?
I think it's a great question.
And I think a lot of people are struggling with this very thing.
There's many startups in SF that are trying to solve agent IDs or identification for agents.
I'm a firm believer that, at least in the current state of agents, they're always acting on behalf of a user, right?
So people were like, OpenClaw, let's give it its own ID, its own credentials, its own bank account, right?
And so it can go off in the world and do things.
But OpenClaw doesn't have...
like its own volition, right?
It doesn't have its own opinions.
It doesn't, like, if you didn't ask it to like go do something, it wouldn't do anything on its own.
Even if you ran a cron, that cron is the thing that's telling it to do things.
So, I don't think we need new stuff personally.
I think like we can just use existing authorization semantics.
We can use existing infrastructure.
I think it's what WebMCP is all about, right?
We don't need to, like, when we try to solve new, like, you know, require everyone.
adopt a new pattern or a new infrastructure or like a new protocol like that's totally unrelated to what we currently have there's like it widens the gap between these companies that are still on SAML right and are not using OAuth or you know they're still on you know running like old you know monoliths on Rails or instead of using like they don't have a JSON API right so I mean like it's to me this agents don't need their identity, they can have an identity that's like a subset of the user who spun them off, which is like on behalf of an OAuth or like things like that.
Or potentially also not an identity.
I mean, there's a big part of the web which lives from the fact that it's like anonymous or is semi-anonymous at least.
And there are markets around like web scraping, et cetera.
And I'm also curious, I mean, I'm partially shareholder in a scraping company called Scraper API.
I'm curious what your view is on that.
Like, how will that evolve from your perspective?
I mean, maybe not in a big explosion, but more like in small baby steps as most things.
But how does like the ultimate goal look like from your perspective around this?
I think scraping is an interesting thing because you don't need an identity to read a blog post or read documentation, right?
But once you've purchased something, right, then There's a bank account there that has this money and this bank account is associated with someone, unless you're doing crypto and it's like a wallet or whatever, right?
But when you're taking action that is destructive or changes things or has outcomes that...
somebody is a benefactor of or is like requiring that outcome or requesting that outcome happen, that's when you need some sort of identity, right?
Maybe, and I don't know if you saw like Moldbook, right?
But Moldbook was like this open claw, a bunch of people with open claws got in there and they just like posted a bunch of, you know, each open claw got its own post.
The Asians did that.
Yeah, right.
But then people realize that like, oh, like the top five posts are just people hitting the API because they just don't actually have an identity, right?
So they're just API calls with like a string associated to it.
There's no database and there's no, because there's no logins, there's no like, you know, source of truth.
There's no email address, right?
Whatever.
So it was super easy to game.
But I think it's a great question.
Do you find yourself running into things where you need identity just for scraping?
I mean, no.
I mean, scraping is exactly that cat and mouse game that you try to avoid being identified, right?
And I think this is also a big part of the web where people try to avoid or processes try to avoid being identified and being seen as the real them, right?
And I think this is also kind of an important part of the web.
And it's not...
And I think this will kind of also be needed in the world of agents, but most likely, yeah, you just have a proxy in between, right?
Yeah, for sure.
And hide yourself if you need to, as long as the opposite party allows that.
I mean, it's like the web, right?
It's not different.
But then it's more the question also for the people that are in a way then...
attacked through their web MCP, right?
Which could happen, right?
Like which actions do you actually allow to whom, right?
Like who is allowed to execute which action on your website?
Who's allowed to put something into the cart?
Who's allowed to, in a structured way, read out information that you don't want to be read, right?
Yeah, absolutely.
That's really, in a way, the elephant in the room, isn't it?
Yeah, and I think the nice thing about web MCP is it doesn't try to solve that.
It says that, your existing JS, you probably have some existing, like maybe you only show add to cart for login users, right?
When you log in, you have to log into Amazon to see add to cart, even if all the JS is there populated in the browser for like your SPA.
And WebMCP only registers when that JavaScript runs.
So, but yeah, I think that's a great point.
Like I don't, I don't necessarily know what the right answer is to identity.
Like if I think WebMCP bot traffic is supposed to outpace human traffic in like the next few years, right?
And at what point, like, is it more detrimental to have no identity in full autonomy on the web, anonymity on the web versus having like people have their own identification so they can separate themselves from bots, which don't, right?
I don't know.
What are your thoughts on that?
Yeah.
I mean, it's really hard to predict from my perspective, but I think we're also like way before that inflection point.
We're just getting started and so many crazy things in the security world will happen until we see that this is really becoming a problem.
I'm curious to see it, but I don't have a clue.
Yeah, it's something we've talked about a lot in the community group.
So a lot of these companies, think of LinkedIn and Amazon or two, especially any company that...
at least part of the revenue comes from advertisements or, you know, sponsored results and search queries, things like this.
Like some part of the revenue comes from the fact that like their customers are expecting human eyeballs to see the screen and see the results so they can have a higher conversion rate, right?
Like Amazon sponsored results, LinkedIn premium ads, whatever, or LinkedIn ads, whatever, right?
But if an agent's, you know, just you have a shopping agent.
It's in chat GPT or whatever.
And it's finding all the best, I don't know, dog food brands for you.
It's going through, scraping the websites, finding the best ones, comparing reviews, all these things.
And it gives you just a list in chat GPT at the end.
All of those people that are paying Amazon to say, okay, yeah, I'm paying you this X amount of money because I'm expecting people to see these sponsored results.
They're losing out now.
Their advertisement dollars are going nowhere.
Well, potentially they will advertise to agents in a way, right?
I mean, there will also be potentially a whole ecosystem around that that you, I don't know, cloak, send some content specialized for some agents, have targeting for certain agents that are basically identified by their users and then like...
Amazon knows what the user really wants and the agent is just a proxy in between, right?
Yeah, yeah.
Isn't that case?
Would this be the case potentially?
And then, yeah, I mean, ultimately, it will be about potentially tricking the agent so that the user ultimately buys something that he or she would never have bought, right?
Yeah.
So I did a consulting job for a guy.
That was doing exactly this.
It was real-time betting for agents.
So the user says, I want to go to San Francisco airport, find me a ride.
And then it will, before the agent responds, a real-time betting thing will take place in the background and it will pull in all providers.
They'll bet on this user's intent and then results will get injected into the, like bids will get injected into the context of the model and the response.
And the model will use that to put it out there.
So yeah, it's totally getting weird in that regard.
Yeah, yeah.
And this is like, I mean, just reminds me of the Super Bowl ads of Antropic, right?
This can really change advertising as we know it right now, right?
And really become a sneaky thing.
And the Wild West again, right?
And like in almost every phase of the web and almost with like almost all inventions.
There was this moment when you could really run arbitrage businesses on certain niches and there were things that were often pushed very early to then later on really kind of wall garden them again.
I mean, this is what happened to advertising and the real-time advertising world already and chances that this will repeat, right?
Yeah, yeah, absolutely.
From your perspective, is there a lot, being done around security right now on this invention?
Or what do you think are the immediate next steps after making it part of a standard, after releasing it to the public?
What do you think will need to happen for this to really mature?
Yeah, it's a good question.
And this is what I've been, I would like to productize this once the standard matures a bit.
But right now, so two parts, yeah, like security aspect, this is, in my opinion, one of the most, especially for businesses that are running SAML, that don't have all the bells and whistles that are needed to run MCPs or things like this in production.
WebMCP is a huge benefit for them.
A lot of these companies have internal extensions.
Or they have lots of internal web apps that they want to automate across service boundaries.
WebMCP, you know, for this, this is what I've been doing, like consulting with companies doing this sort of thing.
It's great.
The issue is that the standard is very early and the API is changing a lot.
And it's, you know, because it's changing a lot and best practices aren't established.
I basically have to go in there and write these things by hand for people.
So the big thing will be, in my opinion, like solving the chicken and the egg problem.
The chicken being, you know, like an agent that can call MCP tools, WebMCP tools, and the egg being the WebMCP tools that live on the page.
Website owners won't want to add support for WebMCP if no clients support it.
And clients like agents won't want to support it or browsers won't want to support it unless people actually adopt the standard, right?
The good news is that there's been a lot of interest on both sides.
So now it's just a matter of, you know.
getting a few clients supported once the standard gets officially in there.
And Chrome was the first start of that, which has been awesome.
Which is already like kind of a good, a good win for profit, right?
Yeah, exactly.
Exactly.
So, but then, so I've been focusing a lot more on the supply side of web MCP sites, like providing lots of skills, MCP servers, documentation, and agents to automate the creation of these web MCP tools.
A lot of the times, MCP is in an interesting spot where it's not something that you just want to have a script add markdown tags to.
If you have 1,000 list items, you don't want to give each of them an MCP tool to delete that item, right?
It'll flood the context of the model, be 1,000 JSON schemas in the model, it'll be like 10,000 tokens worth of JSON schemas.
So there's too many risks just to blanket statement, write automation scripts to add tags to make your markdown support MCP.
But it's also not its own thing, right?
WebMCP wraps existing functionality on the page.
You don't want to give the model more access than the human does.
And a lot of the functionality is already the proper level of abstraction to be wrapped in a WebMCP tool and just exposed.
So it's automatable by agents and also dog foodable by agents.
So we have a fork of the Chrome DevTools MCP that can call WebMCP tools.
So the agent writes a tool in the client JavaScript, the page reloads, it calls that tool in a live browser, gets the feedback, does it work?
And then it can keep going from there in that cyclical loop until your entire website is supported by WebMCP.
So it's been a really fun thing to see happen.
So the MCP that builds itself in a way.
Yeah, exactly.
Yeah.
And adoption-wise?
I guess it pretty much follows also MCP, right?
Which right now gains a lot of traction.
On the other hand, there are many people calling it dead already again because of like high token usage, et cetera, and various other reasons.
And because it's also just not a magic thing, right?
It's basically a wrapper sitting in between the API and the agent.
But I assume this really helps also WebMCP taking off quicker.
than MCP initially.
I mean, MCP was around like, I don't know, nine months or something, nine to 12 months.
Yeah.
Or even a little bit over a year.
Yeah.
It was November of 2024.
Yeah.
So, yeah.
And I just see it taking off now while MCP potentially takes off at the same time because it just is the same on the demand side, right?
While supply is different.
Yeah, exactly.
Yeah, and there's so many, you know, this is my first time being on Twitter, but I feel like MCP is dead, CLIs are a thing, but now people are saying, but also MCP is at all-time high adoption.
The issues people had with MCP was always the fact that it was very token and efficient, but that's not the fault of MCP.
It's just a protocol, right?
It's very much the fault of clients just dumping all of these JSON schemas, which is like these, you know, schema representations of these functions.
into the context of the model directly as a flat list rather than like letting the model discover them gradually like progressive disclosure.
So things like this or, you know, Cloudflare has code mode now, which is just convert these JSON schemas into TypeScript, which is more token efficient and let the models call function like JavaScript to call these functions.
So, yeah, there's a lot going on.
Like one of the engineers I know has been developing since like the 80s.
He works from Pulumi and he was saying that this to him reminds him of like the, like the Donna programming, right.
Where everyone was just kind of like doing things and nobody really knew what they were doing, but people were just trying to figure things out.
Right.
And like all the practices that were, you know, most of the practices that were like being established briefly, like kind of fell out of practice as people realized there was like better ways to do things and things like that.
So I think.
especially with MCP and CLIs and all this stuff.
I don't know if any of this stuff will be here to last, at least in the way we're calling them.
But the infrastructure level and the plumbing and standards and things like this, they're luckily solid enough on the ground floor that you can at least be sure that they'll be there to stay and you can build off of those.
Yeah, I'd also say I feel safer with using semi-standard such as MCP instead of...
like going wild on skills, teaching skills, how to use an API without any intermediate, right?
Or CLI, even though it's magic, right?
Like, I mean, I have a nano banana CLI tool I coded myself.
Nice.
And yeah, I mean, the time Claude calls it with minus age and then like just finds out how to use it and then prompts it without like really having a real...
clue of how to use it and then it's it's magically working that's like really really crazy but yeah i think like having some like a bit more standardized intermediate kind of makes sense right yeah for sure yeah it's it's like at least there's something standard we can build on and like there was a lot of things that were mcp adjacent at the time mcp came out but they had a big enough backing of a big company and people were like yes we need a solid foundation to build on so we can at least agree and like reuse each other's code, right?
And I think, yeah, totally agree.
It's just more things like that are needed.
And I think skills might be the next, you know, I think skills CLI and MCP are actually, they're more conducive to being used in the same stack than you might think, right?
Like as soon as the next round of models are trained to call skills, then they become like part of the, the agent stack, right?
Like that was similar to tool calling, like early models had no idea what a JSON schema, like calling tools via JSON schema was, right?
This is something that had to be like post-trained into these models because like there wasn't any like in the training data, these things like weren't used, right?
So I think we're going to see that same thing with skills and then it'll be, they'll get significantly better, things like that.
What do you think, like from your personal perspective also as being an engineer and engineering basically called dad?
every once in a while.
But how do you think, like, where will we be in two years from now?
Like, how do you imagine a future two years from now also with, like, WebMCP being around, stabilized at that time?
Yeah, I think that people will be using their personal agents and the browser will be a lot more headless than it was before, right?
Like, I think WebMCP is going to let models work.
on browsers in a really token-efficient way.
But the interface will change more towards intent.
So, like, you know, if you, instead of, like, the user wanting to go to, like, google.com and then find the place, you know, or, you know, like, let's say you're researching for a cabin weekend and you want to, like, plan a trip, right?
Right now you have to go to Google, be, like, nice cabins in, you know, Washington, whatever, right?
Then you have to, like...
go there and type in your search query, read different blog posts, maybe look on Airbnb, whatever.
Then you have to go to Google Maps and plan that all out.
I think it's going to look much more like you use an agent, whatever that agent is, and that agent will, you'll be like, okay, I want to plan this out.
That agent will go through, research all those things, call on MCP tools to navigate the different applications.
WebMCP tools to navigate different web apps, things like that, show visual information to the user in like less of a dashboard-y way and more of like, here's just the UI you need for the feedback I need from you or to surface the information that the human needs to see.
And then they'll click OK or they'll do whatever and then the model will continue to work.
So it'll be kind of like more like plan mode and like almost where the model goes off and gathers information.
It only asks you when it needs feedback rather than the very manual process that things are right now.
Looking forward to that.
Going back to today, before we go to the past, what is a good starting point for people to get their hands dirty?
Is there to basically start playing with WebMCP, implementing that for your own web services?
What is a good ground to start with?
I think probably the easiest, there's probably two paths.
Like one, you can download Chrome 146 and turn on the flag in Chrome.
You can put in the show notes, but, and then install their extension or you can use the MTB extension.
And then, you know, call, just add some tools, window.navigator.register tool in your client JavaScript.
It takes a name, description, a JSON schema.
You probably, if you've done anything with agents at this point, you've probably seen a tool, but it's just a tool.
And then you can ask the extension, say, hey, call this tool.
the tool that you just registered in your page and it will call it.
I also have a number of libraries.
I have an iframe you can drop into your website and then a local MCP server that will call.
These two things allow you to call WebMCP tools on a webpage from your local MCP client.
That's nice if you want to use it to automate things in your website, things like that.
Or I can use it today because it's happening via the polyfill.
And then the MCP-B polyfills, and you can find them on my documentation website, and I maintain that.
But honestly, I have a number of clients running WebMCP in production right now, and the spec is moving quickly, and it's a lot for me to maintain personally.
So I would recommend, you know, like, hold off probably on putting things in production for now.
I mean, you can use the polyfills, and I'll deprecate things gracefully.
But, like, give us a couple months to, like...
let the specs settle a little bit.
Don't adopt too early is your recommendation, basically.
Yeah, well, yeah, just like any early adopter, right?
There's upsides, you can get it early, but be ready for breaking changes.
Yeah, I mean, just playing with it and just getting a feeling for it is often helpful.
Yeah, exactly.
Because it will most likely be around for a while.
Yeah, for sure.
Yeah, super, super cool.
Super cool what you did there.
And really looking forward to see it and see it evolving.
And you eventually becoming like a gigantic rich through it somehow.
Yeah, we'll see.
Yeah, I'm currently, you know, like in the process of, you know, getting funding right now for an idea I can't talk about yet.
But so there's excitement there now that ever since WebMTP has blown up.
So we'll see, you know, maybe we'll talk again in the future and I'll either be a success story or a disaster, you know, whoever, but hopefully success story.
Let's do that.
My closing question is always like a little surprise for the folks I'm interviewing.
And I don't know if you knew, but LinkedIn actually has WebMCP implemented and with a certain staging environment with real user data.
So, and let's imagine now we visit your LinkedIn profile.
right now.
And I tell my Claude to use the hidden time machine feature in the LinkedIn API and the LinkedIn MCP.
And we are now able to travel back in time to your LinkedIn profile or your personal life in the year of 2019, basically a year before COVID hit.
And you were working as an application engineer back in the days.
I think already at Amazon, right?
No, not at Amazon.
For a small gluing company, this is a job I had.
This was when I was doing the React contracting on the side.
Ah, okay.
So your first job, basically.
So you see yourself in the first job learning Rails, potentially.
And you have the chance now to whisper something into young Alex ears.
What would you whisper yourself?
Like, go invent MCP?
Oh, man, I'd probably say, that's a great question.
I would say learn machine learning, like right away.
You know what I mean?
Just because it's, no, but I think, yeah, I guess, what did Chachapakee go on?
It came out in 2023, right?
Or like 2022, like December 2022.
I don't know.
Yeah, I guess, I mean, invest in Bitcoin, like whatever, right?
Sure.
No, yeah, I don't know.
I think, you know, I've been pretty happy with my career so far.
I would have taken the leap to go into web development full-time earlier had I known, you know, not wait for it to be late.
Believe in yourself.
Yeah, exactly.
Yeah, it's every time I've doubled down, I don't know about you, but right, I mean, you're a business owner.
It's a gamble, right?
You're like leaving Amazon was like, you know, the most I've ever been paid by a significant amount.
But I, you know, threw it all away to do it.
And then your parents always in the background like, hey, don't do that.
What are you doing there?
Can you explain to us what you're doing at all?
Exactly.
Yeah.
They don't try to explain to them what a...
WebMCP is, has been basically impossible.
Yeah, can't imagine.
For sure.
Thanks a lot, Alex.
Yeah, I really appreciate it.
Really cool stuff that you're doing there.
Let's stay in touch.
If I ever come to the States, I'll visit you there.
Yeah, absolutely.
I'll take on a hike.
I just took one of the guys from the TAG on a hike.
He's a German guy as well.
German guys, I feel like, love to hike.
So maybe that's a generalization.
I like hiking as well.
Thanks a lot.
Have a good day.
Bye.
See ya.
Thank you for listening to the Alphalist podcast.
If you liked this episode, share it with friends.
I'm sure they love it too.
Make sure to subscribe so you can hear deep insights into technical leadership and technology trends as they become available.
Also, please tell us if there is a topic you would like to hear more about or a technical leader whose brain you would like us to pick.
Alphalist is all about helping CTOs getting access to the insights they need to make the best decisions for their company.
Please send us suggestions to cto at alphalist.com.
Send me a message on LinkedIn or Twitter.
After all, the more knowledge we bring to CTOs, the more growth we see in tech.
Or as we say on Alphalist, Accumulated Knowledge to Accelerate Growth.
See you in the next episode.