By The original Model Context Protocol specification locked every MCP client to a single server session. That one design decision made it impossible to put an MCP server behind a standard load balancer, blocked round-robin routing, and forced teams to manage session state on their own infrastructure. For any organization trying to run MCP at production scale, that was a hard ceiling.
In this interview on TFiR, Du’An Lightfoot, Senior Developer Advocate for AI Engineering at Akamai, breaks down the latest MCP specification changes, why the old session model failed at scale, and what the stateless architecture in the new spec unlocks for enterprise AI engineering teams.
Guest: Du’An Lightfoot, Senior Developer Advocate for AI Engineering at Akamai
Show: TFiR
Here is what every AI engineering team and platform engineer needs to know.
Technical Deep Dive
Q: Why can’t you scale MCP servers behind a load balancer with the original spec?
Du’An Lightfoot, Senior Developer Advocate for AI Engineering at Akamai, explains that the original MCP specification established a strict client-server session: one client bound to one server for the duration of a session. That binding made round-robin load balancing impossible because any server other than the one that opened the session could not answer a request. Organizations trying to scale MCP across multiple servers or multiple users hit this ceiling immediately.
“If you wanted to scale as a business to have an MCP server and scale it across multiple servers and multiple users, you would struggle with that because you couldn’t put it behind a load balancer and do something like round robin.”
Du’An Lightfoot, Sr. Developer Advocate – AI Engineering, Akamai
Q: How does the new MCP spec fix the load balancing problem?
The new specification removes the session handshake from the server side, making every request independent. Because no server holds session state, any server in the pool can answer any request. Standard round-robin load balancing now works as expected, and teams can distribute MCP traffic across as many nodes as needed without custom routing logic.
“Every request kind of stands alone, and any server can answer any request. So now you can actually do that round robin when it comes to MCP behind a normal load balancer.”
Du’An Lightfoot, Sr. Developer Advocate – AI Engineering, Akamai
Q: What reliability improvements come with stateless MCP servers?
Removing server-side session state eliminates a class of reliability failures: if a server goes down, no session is lost because there was no session to lose. The client manages its own state, and any available server can resume handling requests. This architectural shift aligns MCP more closely with how teams already operate stateless REST APIs at scale.
“It also increases reliability because now you’re not also maintaining that session state on your end.”
Du’An Lightfoot, Sr. Developer Advocate – AI Engineering, Akamai
Q: What security and safety controls did the new MCP spec add?
The updated specification includes tighter security controls alongside interactive confirmation flows. An MCP server can now send a form or prompt asking whether the user actually intended to make a change before executing it, which reduces the risk of unintended actions triggered by an agent. Lightfoot describes this as a meaningful guardrail for agentic workflows where consequences of a wrong action can be significant.
“Now you can send forms or send additional information or request, did you really want to make this change through the MCP server?”
Du’An Lightfoot, Sr. Developer Advocate – AI Engineering, Akamai
Q: How does the new spec handle long-running MCP tasks?
For tasks that take extended time to complete, the new spec introduces a ticketing mechanism. When a long-running task is submitted, the MCP server issues a ticket and returns it to the agent. The agent can then poll the server at intervals to check progress rather than holding an open connection, making async workflows practical without custom plumbing.
“If you have long running tasks, you can create some type of ticketing to say this task is going to take maybe an hour, send it back to the agent. The agent now can check back to see how long it’s going to take.”
Du’An Lightfoot, Sr. Developer Advocate – AI Engineering, Akamai
Q: How does MCP handle deprecations, and is it stable enough for enterprise adoption?
The new specification introduces a formal one-year deprecation notice before any feature is removed. For enterprise teams evaluating MCP for production use, this commitment addresses one of the core adoption risks: a spec change breaking a deployed application without warning. Lightfoot frames this as the MCP maintainers treating the protocol as a stable community standard rather than a moving target.
“They kind of standardized to say, hey, we’re delivering MCP to the community since it’s open source and we’re going to make sure that it’s stable and available for businesses to be able to use it within their enterprise applications.”
Du’An Lightfoot, Sr. Developer Advocate – AI Engineering, Akamai
Q: Is MCP fragmentation a real problem, and does the new spec solve it?
Lightfoot acknowledges that fragmentation exists in implementations built on the older spec, where vendor-specific behaviors diverged from the standard. The new spec addresses this by aligning MCP’s transport model with conventional HTTP APIs, making it behave like infrastructure teams already know how to operate. Security implementation differences may persist, but the deployment and consumption model is now far more consistent.
“The changes that they have made it more in line with how you would scale an API within your organization.”
Du’An Lightfoot, Sr. Developer Advocate – AI Engineering, Akamai
Q: What is the role of MCP in giving AI agents access to tools and data?
MCP standardizes the way tools are built and exposed to AI applications. Before MCP, developers had to write custom Python functions for each agent and repeat that work across every agent in their system. MCP replaces that fragmented approach with a single protocol: build a tool once as an MCP server and any compliant agent can consume it, whether the tool talks to a Git backend, a database, or an external API.
“What MCP did was it said, let’s standardize a way to build tools and provide them to AI applications in this standardized way.”
Du’An Lightfoot, Sr. Developer Advocate – AI Engineering, Akamai
Resources & Documentation
- Akamai, cloud and edge platform offering compute, security, and delivery infrastructure for enterprise AI applications
- Model Context Protocol (MCP), open standard for connecting AI agents to tools and data sources, maintained as an open-source project
***
👇 Click to Read Full Raw Transcript
Swapnil Bhartiya: It’s not even a question that who doesn’t know about mcp? But let’s just quickly talk about the role mcp. Since Anthropic announced it, then it was open source, but now it is playing, it is plugging into the. It has kind of, you know, become a backbone. So talk about the role of mcps before we talk about specification and what has changed.
Du’An Lightfoot: Yeah, so when you think about AI applications, whether it’s a coding agent or you have some other agent that are performing tasks, what helps an agent be successful and actually play the role of an agent is the tools it has access. And so those tools can come in the form of git with connecting the traditional back end APIs to, let’s say get the weather, get some information from a database, or they can just come from looking up information on some other back end storage where you have some data. Right. Well, in order to connect the tools, traditionally what you would have to do as a developer was you would have to write, let’s say Python functions and you would have to write them connected to your agent and then scale that to every agent that you have. So there was a lot of manual work in order to give capabilities to agents and AI applications. What MCP did was it said, okay, let’s standardize a way to build tools and provide them to AI applications in this standardized way. Now when it was first released, it was through standard in, standard out. So everybody was building MCP servers and running them on their laptop or desktop. Well, in enterprise, since it’s standardized, it also needs to be centralized. So we needed HTTP, streamable HTTP. So now we could host this on a virtual machine or a Docker container and then other developers can connect to this MCP server, get the tools and capabilities. And it’s constantly been progressing to where we are today.
Swapnil Bhartiya: Now let’s talk about this latest specifications, what has changed and what kind of impact it will have on developers and the way they plug things to AI and LLMs.
Du’An Lightfoot: Yeah. So when you think when we were talking about the initial version of mcp, it had this client server relationship, one client connect to a single MCP server. Right. So if you wanted to scale as a business to have an MCP server and scale it across multiple servers and multiple users, you would struggle with that because you couldn’t put it behind a load balancer and do something like round robin. What this new version allows you to do is remove the session in the handshake. That would happen with mcp. Right. So now every request kind of stands alone, right? And any server you know can answer any request. So now you can actually do that round robin. When it comes to MCP behind a normal load balancer. This helps scale for an organization, you know, and it also increases reliability because now you’re not also maintaining that session state on your end. This is more on the client side when it comes to managing mcp. There’s also some tightening around securities improvements. There’s introductions around interactive apps, right? So now you can send forms or send additional information or request, did you really want to make this change through the MCP server? Right. And then if you have long running tasks, you can create some type of ticketing to say, okay, this task is going to take maybe an hour, send it back to the agent. The agent now can check back to see how long it’s going to take. One last thing which is also important when it comes to MCP is that before when changes happen, there was no real way to mitigate when these changes happen within your application. Now you get a one year notice before anything is removed, right? So they kind of standardized to say, hey, we’re delivering MCP to the community since it’s open source and we’re going to make sure that it’s stable and available for businesses to be able to use it within their enterprise applications.
Swapnil Bhartiya: Interesting thing with standards is that there was a joke also. We love standards so much that we have made so many of those and that becomes a problem. While on paper MCP does look like standards, but when it comes to day to day also depends on the provider you’re using, the kind of tool you’re using. Everybody is doing their own things. There is a kind of fragmentation. Also how you talk to tools, they are, everybody is doing their own implementation. How much fragmentation problem is there and will this, because it is solving a lot of major problems that we face day to day, will it push organizations towards more standardized standard or will that fragmentation remain?
Du’An Lightfoot: There will be fragmentation in the older version. The newer version was designed to operate more like traditional APIs through HTTP. So rather than you having that client server relationship, you kind of just build your MCP server and then you connect to it like a traditional API. So I believe that there will may be some challenges around the security and the risk around mcp. But when it comes to being able to roll it out and use it and consume it, I believe the changes that they have made it more in line with how you would scale a API within your organization.
