Speaker unverified: belief

Transcript context

…Awesome. Okay, cool. I think so, you know, we are sorry. Thanks for indulging on like some of the servers. We just wanted to double click on these. I think we have time for just like future roadmap things. People were most excited about this recent update. Moving from state to state. Stateful to stateless servers. You guys picked SSE as your sort of launch protocol and transport. And obviously transport is pluggable. The behind the scenes of that, like was it Jared Palmer's tweet that caused it or were you already working on it? No, we have GitHub discussions going back, like, you know, in public going back months, really talking about this, this dilemma and the trade-offs involved. You know, we do believe that like. The future of AI applications and ecosystem and agents, all of these things I think will be stateful or will be more in the direction of statefulness. So we had a lot of. I think honestly, this is one of the most contentious topics we've discussed as like the core MCP team and like gone through multiple iterations on and back and forth. But ultimately just came back to this conclusion that like if the future looks more stateful, we don't want to move away from that paradigm. Completely. Now we have to balance that against it's it's been operationally complex or like it's hard to deploy an MCP server if it requires this like long lived persistent connection. This this is the original like SSE transport design is basically you deploy an MCP server and then a client can come in and connect. And then basically you should remain connected indefinitely, which is that's like a tall order for anyone operating at scale. It's just like not a deployment or operational model. You really want to support it. So we were trying to think, like, how can we balance the belief that statefulness is important with sort of simpler operation and maintenance and stuff like that? And the news sort of we're calling it the streamable HTTP transport that we came up with still has SSE in there. But it has a more like a gradual approach where like a server could be just plain HTTP, like, you know, have one endpoint that you send HTTP posts to and then, you know, get a result back. But do you think that's it? Yeah. And then you can like gradually enhance it with like, OK, now I want the results to be streaming or like now I want the server to be able to issue its own requests. And as long as the server and client both support the ability to like resume sessions, like, you know, to disconnect and come back later and pick up where you left off, then you get kind of the best of both worlds where it could still be this stateful interaction and stateful server, but allows you to like horizontally scale more easily or like deal with spotty network connections or whatever the case may be. Yeah. Yeah. And you had, as you mentioned, session ID. How do you think about auth going forward? For some MCPs, I just need to like paste my API key in the command. Is there kind of like a, yeah, what do you see as the future of that? Is there going to be like the dot M equivalent of like for MCPs or? Yeah.…

Stored transcript either side of the excerpt. The highlighted words are the published quote; the surrounding text is unedited source, never generated.