What an Anthropic Engineer Thinks About MCP

Yeah.

Like the, the original version of the protocol, right, it was like all standard IO.

It was like, it was a very natural thing that you have this notion of, you know, a program that you can always interact with, um, that's this MCP server.

And then as we went over trying to do this over HTTP, we tried to retain this because we fundamentally believed that agents are somewhat stateful.

Mm-hmm.

But it turned out operationally over the year we learned that there are other methods how you can still get that without having to rely on a stateful protocol or a stateful transport.

And the, the cracks kind of showed particularly when we saw, again, the really big hyperscaler try to do this with like... at like massive scale, like thousands of tens of thousands of servers serving like millions of requests.

And then you're like, you're getting into really hard difficulty problems of like how do you scale this? How do you, you know, move the state around? Um, there's a particular problem where, you know, you hit one server and you kind of wanna have a load balancer hit the next server, but if you have some form of state in this one server, you kind of need to communicate it to the other server.

Oh, man.

And that's hard to do, and you can do it, uh, but it's painful, it's... um, it causes, uh, latencies and it causes CPU usage, and it's just like very unpleasant to serve.

Um, and so a lot of the hyperscalers really want stateless workloads so that they can go to one server, um, make a request, take the request, go to the next server, um, do, you know, something else, and everything, you know, can go through a load balancer, everything can... you know, some of the things can be cached.

Just the standard things we kind of know how to do.

Um, we kind of went there and we, again, over time figured out what are the pieces of MCP that need to be stateful? What are the pieces that don't need to be stateful?

Mm.

And we decided the transport part doesn't need to be.

And so it's...

I think it's a very natural, um, you know, progression and evolution of the protocol.

Um, maybe we could have seen some of it a bit earlier, but I think now I think it's a great time and we have worked really hard with, again, some of the, the industry giants, honestly, to like make this work for them and also make it work for us.

It does feel like a maturing, and this is something-

It, uh, it certainly is maturing, yeah.

[laughs]

Yeah.

It's, it's something that you're like, oh, very clear value prop there.

Are there any trade-offs that you had to grapple with when you were deciding this?

Yeah, some of the hardest part is that some things inside the protocol are somewhat inherently stateful.

Yeah.

Like the, the original version of the protocol, right, it was like all standard IO.

It was like, it was a very natural thing that you have this notion of, you know, a program that you can always interact with, um, that's this MCP server.

And then as we went over trying to do this over HTTP, we tried to retain this because we fundamentally believed that agents are somewhat stateful.

Mm-hmm.

But it turned out operationally over the year we learned that there are other methods how you can still get that without having to rely on a stateful protocol or a stateful transport.

And the, the cracks kind of showed particularly when we saw, again, the really big hyperscaler try to do this with like... at like massive scale, like thousands of tens of thousands of servers serving like millions of requests.

And then you're like, you're getting into really hard difficulty problems of like how do you scale this? How do you, you know, move the state around? Um, there's a particular problem where, you know, you hit one server and you kind of wanna have a load balancer hit the next server, but if you have some form of state in this one server, you kind of need to communicate it to the other server.

Oh, man.

And that's hard to do, and you can do it, uh, but it's painful, it's... um, it causes, uh, latencies and it causes CPU usage, and it's just like very unpleasant to serve.

Um, and so a lot of the hyperscalers really want stateless workloads so that they can go to one server, um, make a request, take the request, go to the next server, um, do, you know, something else, and everything, you know, can go through a load balancer, everything can... you know, some of the things can be cached.

Just the standard things we kind of know how to do.

Um, we kind of went there and we, again, over time figured out what are the pieces of MCP that need to be stateful? What are the pieces that don't need to be stateful?

Mm.

And we decided the transport part doesn't need to be.

And so it's...

I think it's a very natural, um, you know, progression and evolution of the protocol.

Um, maybe we could have seen some of it a bit earlier, but I think now I think it's a great time and we have worked really hard with, again, some of the, the industry giants, honestly, to like make this work for them and also make it work for us.

It does feel like a maturing, and this is something-

It, uh, it certainly is maturing, yeah.

[laughs]

Yeah.

It's, it's something that you're like, oh, very clear value prop there.

Are there any trade-offs that you had to grapple with when you were deciding this?

Yeah, some of the hardest part is that some things inside the protocol are somewhat inherently stateful.