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?