Did Anthropic finally fix MCP? Transcript, AI Summary & Key Points

00:00 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.

00:18 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.

00:35 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.

00:53 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.

01:26 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.

01:40 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.

02:02 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.

02:24 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.

02:43 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.

03:02 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.

03:27 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.

03:50 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.

04:14 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.

04:42 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.

05:05 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.

05:25 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

05:55 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

06:24 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

06:56 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.

07:18 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.

07:39 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.

07:55 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.

08:15 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.

08:38 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.

09:01 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.

09:18 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.

09:42 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.

10:00 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.

10:15 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.

10:35 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.

10:59 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.

11:21 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.

11:43 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.

12:07 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.

12:30 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."

12:52 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.

13:24 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.

13:54 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.

14:15 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.

14:44 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.

15:09 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.

15:40 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.

16:02 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.

16:28 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.

16:52 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.

17:09 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.

17:28 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.

17:52 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?