Time for a 2025 throwback because we

need to talk about MCP. It's a standard

that was really popular at the time. It

felt like everybody was trying to

integrate it in their stuff, but it

wasn't something I was particularly fond

of. In fact, I was notoriously against

MCP. I felt like it was massively

overrated and really bloated spec that

caused as many problems as it solved.

And I just didn't find myself using it a

whole lot in my day-to-day workflows. In

fact, I've actually found it more

annoying recently because tools like

Codeex use it properly. And by using it

properly, they end up wasting a bunch of

resources because every single MCP

server needs to be a dedicated server

with a dedicated connection to the

client while it's existing. Even if the

client never ends up calling it, it has

to be bound to a real connection on a

real server. It got so bad that a lot of

the MCP stuff that we use was just

hosted locally because the amount of

infrastructure it would take to host it

in the cloud just wasn't worth it when

it wasn't being used 99% of the time.

But there's a new MCP spec now. They

should call this something else like

MCP2 or just a new name entirely because

the MCP branding's been destroyed. But

this improvement is massive. Simon

Wilson just posted an article saying

that stateless MCP has recaptured his

interest. This is kind of the spoiler.

By the way, MCP can now be stateless.

This is a very, very exciting change

that makes MCP go from a worse version

of a CLI to a potentially actually

useful integration to have in our tools.

I'm really excited about what this

means, but there's also some concerns

that I have with the change. And I

cannot wait to talk about all of that

right after a quick break for today's

sponsor. Agents have gotten way, way

better at writing code, but they've also

gotten better at using computers, too. I

am blown away when I watch models like

56 navigate the web. But there's a

problem. They need a browser.

Thankfully, somebody made the best

possible browser for your agents, and

it's today's sponsor, Browserbase. These

guys understand browsers and agents

incredibly well. Just as a quick demo, I

set up Cloud Code with the Browserbase

MCP, and it's so so cool. I put together

a lake bed to-do list so you can see the

live updates as they happen because the

platform is fully live syncing. I didn't

define an API for my agents to use to

modify things on this page. All there is

is a website, which turns out 85% of the

web doesn't have APIs. It's only web

sites, which means agents need a web

browser in order to access it. Oh, look

at that. A live to-do just appeared on

the fly from Claude, doing it through

the browser. Of course, it's making fun

of me for still demoing to-do apps.

What's even cooler is if we go to the

dashboard, we can live monitor how the

agent is using the browser. This is the

actual instance it's using. I could even

hop in here and control it myself if I

want to, clicking on things and saying,

"Hey, sup." Because remember, this is a

real browser. They are hosting in the

cloud. If you don't have use cases for a

tool like this, you're not thinking

creatively enough. If you are, check

them out now at sidyv.link/browserbase.

Good to have you back. It's time to talk

about the new MCP standard. I wish they

gave it a good name, but instead it's

MCP 2026728.

Didn't we learn this lesson with model

names when Anthropic had all the

different versions of Sonnet 3.5 that

were just different dates? Like, they

know better than to do this. Yet, here

we are doing this. I have other

complaints about this coming up, don't

worry. The fifth spec release of the

model context protocol MCP 202060728 is

live today. The latest spec moves MCP to

a stateless core while hardening

authorization and graduating official

extensions. Support is being rolled out

across clawed products. This is the big

part here that MCP has moved to a

stateless core. Very very very exciting.

What do we mean by this stateless core?

Well, according to Enthropic, MCP has

moved from a birectional stateful

protocol to a request response model.

Huh, almost like the exact thing I've

been saying it should do for a long time

now. Servers can now deploy on

serverless and edge infrastructure. This

simplifies the experience of building

MCP servers for Claude and scaling their

usage as they grow in adoption. Yep,

this is the key piece. In as I mentioned

before, in order to set up MCP, you had

to have a dedicated connection between

the thing running your agent and the

server providing the service. So if you

were building an MCP for, I don't know,

let's say that you had a database

platform and you wanted an MCP that

allowed for your customers agents to

look data up or find things in the DB or

audit, make changes, stuff like that. In

an era where we didn't have a good way

to share all of that context, MCP was

really powerful because it allowed you

to expose an endpoint on your service,

not just enabling it to access that

data, but also giving it effectively

instructions on how it can use those

endpoints and what it can do with them,

providing examples and whatnot, too. The

problem with MCP is that that

relationship between the client and the

server required them to be connected

throughout the entire process, even if

you weren't using it. So if you set up

five MCPS in your cloud code and then

went and did a task that used zero of

them, that cloud code run still has five

dedicated stateful connections bound

between it and external services. I'm

going to show you one of the silliest

examples of how this affects you in

day-to-day. I'm going to spin up codeex.

It's trying to failing to initialize the

Xcode build MCP. So I got an error

there. But watch what happens when I say

sup. I'm hitting enter now.

Oh, did they suppress it finally? They

suppressed it finally. Cool. I gave them

a shitload of feedback about this. There

was a problem where every time you spun

up a thread in codeex, it would block

your first message until it finished

initializing the MCP servers for

computer use and whatnot. They recently

changed it so that those wouldn't happen

until after you send, which helped a

bit, but they have changed it even

further where you don't see it as much

now, which is good. But previously it

was obnoxious because every thread and

more importantly every sub aent would

have to spin up five or more stateful

MCP connections which means that on your

computer if you have one agent run

you're doing in codecs and it spins up

five sub aents that is now 30 stateful

connections that are bound on your

machine for one prompt and that is for

the server and the client because it has

to spin up the server side for that

locally for all the computer use servers

in case any one of those sub aents wants

to do computer use and now you have 30

stateful processes on the server side in

codecs and then they're bound 30 times

on the client. It is so much overhead

and if you have seen CIS policyd

eviscerating your CPU this is why for us

Mac users because sis policyd is how Mac

OS monitors processes to make sure

they're not doing anything sketchy and

spinning up 30 servers on your machine

looks a little sketchy but now that it's

stateless none of that matters. Each

agent can just hit a random endpoint and

get back some JSON and then decide when

it wants to do things from there instead

of it being a bound connection. It is

just an endpoint that is hit which is to

be frank the way it always should have

worked because all MCP should be doing

is informing the agent of what its

capabilities are and then giving the

agent everything it needs in order to

call and do things. This also means the

infrastructure you host it on and the

ways you provide it on your computer can

be entirely different too. You can have

a simple local HTTP API or one in the

cloud that fetches data and has like one

little key in it to distinguish between

things instead of keeping a bound

connection the whole time. There are

other things they added here like they

standardize extensions through apps and

tasks. They hardened off which is cool

as well. And a bunch of companies said

awesome things about it. Oh, cool. The

official MCP site has a nice visualizer

for this. Like setting up your MCP

before required a intelligent load

balancer to make sure the client

connected to the same place always and

that things went back to that one and if

somebody else came in, they got routed

to the correct instance as well. In a

world where things are stateless,

everything is significantly simpler. So

you don't have to maintain the

connection through the load balancer the

whole time. It was one of the most

highly requested features from

developers who were eager to get better

reliability and scalability for their

MCP servers. [ __ ] yes. Yeah, it was the

lazier on demand stuff. If there is

something for that, they finally killed

the handshake [ __ ] from that awful

old web spec that they shouldn't have

implemented. That's a nice change. I

want to share what Simon Willis had to

say about this and then I'm going to

share my personal concerns about this

change. As I mentioned at the start,

Simon refers to this as stateless MCP,

which I think is a really good way to

clarify what this release is. Tuesday

was stateless MCP day, the roll out of

MCP 2.0, or the 2026 0728 model context

protocol specification to use the more

formal but less memorable name. This is

the most significant change to the MCP

spec since it first launched, and it's

also served to reignite Simon's personal

interest in the protocol. For

background, MCP is the model context

protocol, which describes a standard way

to expose new tools to LM powered agent

frameworks. It was introduced by

Anthropic in November of 2024 and it had

a huge spike of interest throughout much

of 2025 and it became eclipsed by skills

which was another thing anthropic

invented. Kind of crazy that this super

fancy spec and protocol got replaced by

a markdown file as many things do

nowadays and the skills took over when

it became apparent that agent harnesses

with access to terminals in curl could

do most of what MCP did in a more

flexible way. Time is coming back around

to MCP now. Giving an agent a shell

environment with the ability to access

the internet is fraught with risk and it

requires a strong model that is capable

of effectively driving such an

environment. MCB tools in comparison are

much easier to audit and control and

they're simple enough that smaller

models that run on a laptop can still

drive them reasonably well. The new

stateless MCP spec greatly decreases the

complexity of implementing both the

client and the server for the protocol.

He built three of them just this week.

He linked this blog post that shows the

before and after where before you had to

have a sticky route to one server and

share sessions and data and manage all

of this to make sure that when a request

came in it always stuck with the one

server that was hit before. Now it

doesn't matter. The older stateful MCP

which he refers to as legacy MCP

required two HTTP requests. One to

initialize the session and obtain an ID

and the second to actually start calling

tools. But when the tool calls come in,

it has to match this session ID and get

routed to the right place, which means

it has to be maintaining the connection.

Obnoxious. And the new stateless version

uses a single HTTP request, which is

what it always should have been. It's so

much cleaner for both client and

serverside implementations. It's also a

better fit for building scalable web

apps since now you don't need to

maintain serverside state to keep track

of those session IDs or worry about

routing the same session to the same

backend machine. MCP Explorer is a cool

tool he built with Codeex in order to

explore MCPs to see how they're behaving

with these new changes. the stateless

Python CLI. You don't even need to

install it to try it out. You can just

call it with uvx. It queries the agentic

mermaid.dev demo mcp. The above command

returns the following list of tools. I

can even run this in my terminal. Let's

try it. That's super cool. This simple

command can be pointed at an MCP server

and then describe all the things that

are available on it. This one has an

execute one for executing mermaid SDK

code. Describe SDK, render SVG, render

as render PNG. all these commands that

could be useful if you want to use the

agentic mermaid site to generate images

and verify like mermaid diagram code.

Kind of cool that his demo here isn't

even using agents. He's just calling it

by hand to show how the protocol works

because now it's simple enough to just

fire off a command and get a result.

Yeah, that's great. That's awesome. He

also made one for data set which allows

MCP endpoints to be added to any data

set instance. He's tried building this

four times, but thanks to the new

stateless MCP specification, he finally

has a version that feels good to

release. Huge. Then

you end up with a bloated spec that

requires you to have an expensive

infrastructure to put it out, the

likelihood you bother putting the thing

out goes down massively. But now that

these are stateless, it's way easier to

get it working, to get it shipped, to

get it integrated, and to scale it if it

does end up being used heavily, and to

spend $0 if it's not used at all. You

can throw this on any Lambda or

Cloudflare worker or anything now

trivially and it's so much better. And

in a world where agents are doing more

and more unsafe things, MCP as a way to

be really strict about what agents can

do is sensical because again, if you

give it a CLI, the agent can do pretty

much anything. But if you give it a spec

out set of endpoints effectively that

are self-describing in a way the agent

can use, then it can only do the things

that those endpoints provide. Simon's

conclusion is that he plans to lean into

MCP much more now when he builds

sensitive applications on top of LLMs.

And I agree. It's crazy that I actually

think the spec is interested, good, and

usable now. But there is a catch. As

long as you're on the right version.

This is the problem that always happens

when specs change, when capabilities

change, when things change. Imagine

you're looking at a product and they

gladly exclaim, "We support agents." and

you're like, "Oh, cool. I would love to

use this with cloud code." So, you go to

set it up and the instructions are all

specific for using it in cursor, but all

of the screenshots are the version of

cursor from like 3 years ago. You're

like, "Wait, I thought you support

agents." Well, yeah, they technically do

in the same way that a phone cable might

support USBC. I have like eight

different tiers of USBC cable in this

apartment alone. And the problem is that

all of them are USBC. So if I ask for

USBC cable, I don't know if the thing I

get is actually going to be what I want.

And now that there is so much absolute

slop MCP servers that were built in an

era where MCP was just a way for a

company to justify their AI budgets,

those are all MCP servers. So if I

decide I want to try out MCP and I go to

a website and they say they support MCP,

I'm like, "Okay, cool. I'm going to go

connect that." and then it uses the old

standard. That sucks. Or what I'm more

concerned about is the client side where

there's a lot of different agentic

clients, harnesses, etc. Things like

cloud code and codeex as well as all of

the others like open code, pi, cursor,

of course, anti-gravity.

There's too many. And a lot of those

support MCP, but do they support the new

MCP? Do they support MCP 2026728?

because that is very different. And if I

build an MCP server that is on the new

standard, the new spec, and somebody

goes to install it in an older version

of Cloud Code or in some other tool that

just hasn't updated their MCP bindings

yet, that sucks. And this is going to be

a real problem for adoption because the

previous standard was so heavy, weird,

and annoying, and it still got

implemented everywhere. This new, much

more elegant, reliable standard won't be

implemented everywhere. and two things

that both support MCP might be entirely

different and entirely incompatible. And

that's a real concern I have because

that's the point of MCP is that it's a

simple standard that everything supports

on both server and client. Now it isn't.

By fixing the standard, they ruined the

nature of the standard. It is a way way

better solution. But this new solution

is not backwards compatible because the

previous implementations on the client

side expect a stateful connection to be

bound. And this is the opposite of that.

You can't just take something that

expects a dedicated connection and sever

it and expect it to work. There is a

catch though. One of the things that

makes this less likely to matter.

There's this cool thing you guys might

have heard of recently. I don't know. I

I know they're still niche, but but hear

me out. There's this thing called LMS,

and it turns out LM are good at code.

What this means, hypothetically,

is any tool that you're using that is

only supporting the old MCP standard on

the client side really doesn't have much

of an excuse to not implement the new

standard. Because if you're a company

building a harness or an agentic tool or

something like that, it's your

responsibility to keep up to date.

Because if you built a coding tool that

you think is the bees knees, you think

it's super cool, and I go and try your

super cool AI code tool and then it

doesn't work with my MCP services,

you're on an old version, and I say,

"Hey, you your harness doesn't work with

the new MCP. You say you support MCP,

but it's the old version. Can you update

it?" You only really have two answers

you can give. They are yes, absolutely,

I'll get an agent on it now or eh, I

don't really care or I'm too busy or

something along those lines. And if

their agentic coding tools are so

powerful that they can convince you to

try their thing, but they're not

powerful enough to update the standard

relatively quickly, you should ignore

that person in their tools. So hopefully

the way this works out, fingers crossed,

is that it becomes a bit of a self-own

where the companies building tools that

only support the old version of MCP get

called out for what they are, which is

not understanding of how powerful these

things are and how quickly they can

iterate and fix stuff or they do and it

can be a good filter for which companies

and products do and don't get it and do

and don't improve over time. I'm at the

point where if a company is building an

AI tool and they're not giving

meaningful updates every week that I

just assume they've deprecated and

stopped working on it internally because

there is no excuse to not be shipping

updates regularly at this point in time.

It's too easy to ship code that is too

good. There's no excuse for not

upgrading. So that's the only reason

this is acceptable. In a previous era

where you had to manually update

everything by hand and rebuild this

whole standard into your stuff, this

would be hell. But in a world where you

can point an LM at the new spec and say,

"Hey, make sure this works. here's three

test MCPS and it tests it and it does

awesome to take like an hour with Opus

or Fable. Not a big deal. So, those are

my thoughts. That's my one big concern

is a big change like this that is

inherently not backwards compatible is

going to cause some churn. But in a

world where an LLM can go and update

your tools for you, it's not a big deal.

What is a big deal is how much more

powerful this standard is now that it is

stateless and can be properly

implemented across scalable solutions

without having to spend a shitload of

time and money and complexity to get

there. It's a nice change. It feels like

it actually understands developers and

what their needs are instead of just

trying to be this god spec with every

possible thing included in it. And I'm

excited to play with it now. I can't

believe I'm excited to go try out MCP

again, but I really am. And I can't wait

to see what I'm able to do with it. Let

me know what you guys think. Are you

going to stick with your CLIs or do you

see real potential with MCP now that we

have these changes?