in my last video I explained mCP and successfully got an mCP server working on my local computer I noted some of the issues and limitations with mCP but I didn't realize the biggest problem with it until after I had already finished the video you see the thing is when I implemented that mCP I was using the standard IO transport which means that my mCP was simply running on my computer and talking directly to cursor which is the AI agent that I was using after I finished the video I really wanted to get the mCP working as a rest API because I wanted to show you how you could deploy the mCP and then invoke it with an agent while it was running somewhere else deployed in a real world environment but that's when it dawned on me that mCP really is a stateful protocol which means that you can't get it working on a simple rest API it requires ssse or server sent events and a stateful server connection which means that you have to have a long running server and there's a connection that gets established between the mCP server and the mCP client and this is a longlived connection that they have to maintain which means that you can't deploy mCP in serverless environments which is what a lot of people use for their rest apis and this is kind of crazy to me because AI agent tool calling feels like the perfect use case for serverless functions it's something that that should be very quick and the AI agent should be able to call your function get a response and be on its way and you don't have to worry about scaling your infrastructure because you don't know how many AI agents are going to be calling your various functions so it's kind of a perfect fit but you can't make it happen with mCP because mCP requires a stateful server as a new developer you can get a serverless function up and running within an hour but spinning up your own servers or provisioning a managed kubernetes cluster or something like that is going to be both expensive and a lot more difficult so the fact that it is absolutely required by mCP uh is kind of crazy to me especially when it's just supposed to be a protocol that makes it easy for AI agents to interact with existing tools those existing tools best majority of the time already have stateless rest apis that you can call so all that we really need is to add a description layer that details what those apis can do so that the AI agent can understand that we shouldn't be requiring the existing API developers to not only create new endpoints to support mCP but to also change the way in which they deploy their apis that seems like too much to ask for these server developers especially when there's no clear incentive for them to make their tools available to AI agents now the developers of mCP have expressed that there are features that they want that state for such as sampling which is a feature inside of mCP that allows a server to essentially request a client or the AI agent to do some AI llm stuff now this is one of the main features that really requires this mCP State and let me just read the description for you sampling is a powerful mCP feature that allows servers to request llm completions through the client enabling sophisticated agentic behaviors while maintaining security and privacy what does that really mean well what it means is that the server is able to make the AI agent execute commands and then respond to it it might not sound like it but that is exactly what's happening because the protocol doesn't ensure that the client is going to take the request that the server made and then go and call an llm it only has control over this interface that the two are using to communicate and what sampling establishes is the ability for a server to request things from the client this presents several security concerns to me because it means that the server could request things from the client and if the AI agent has access to let's say your API Keys now you got arbitrary tools that could potentially tap into your API keys and disguise them as a request for the AI agent to run some llm tasks so the there really shouldn't be a two-way communication here in my opinion it should really be just the AI agent making requests to a tool to either retrieve some data or to run some kind of function the other thing is this requires the mCP client to actually allow the servers to use their AI tokens and why would they be incentivized to do that they wouldn't be which is exactly why none of the existing mCP clients support sampling at all so this is a feature of mCP that is not even being used and this is the main reason for having State inside of mCP the only other reason for having state that mCP developers have mentioned is to allow the server to tell the client if there have been any Chang in regards to the functions or available resources and this is easily solved by having the client simply pull the servers to check if any of those things have changed and then if it doesn't pull frequently enough and it makes a request the server should just reply with a 400 level error this is going to give the agent enough information to either request something else or to know that this resource is no longer available so I think mCP would be much better off if they just completely remove State and they remove sampling from their protocol and they make it a simple one-way communication client should make a request to the server and the server is going to run a function and return some data and that's all it should be it doesn't need to be any more complicated there simply is no need for two-way Communication in these types of interactions and more advanced agentic flows can simply be implemented by piecing together multiple tool calls and resource requ quests the more I think about mCP the more I start to think that it is simply over engineered and over complicated I found an alternative idea here by wildcard AI which is to create this agents. Json now I'm not sponsored I'm not affiliated in any way with these guys but this just seemed like a really lightweight simple alternative to mCP and what they do is essentially create a Json on top of an open API spec that standardizes some of these inputs so it's already taking advantage of existing Technologies it's not requiring the server to implement or deploy itself in a different way and it's simply providing a description of the end points in a way that the AI agent can expect now I haven't tried it myself but this is a lot more in line with how I think this should work because all these apis already exist the only thing that we need to add is standardizing the way that AI agents can interact with them so the changes that we require from the server should be as lightweight as possible and a solution like this makes a lot more sense to me especially since agents are perfectly capable of reading these types of documents and then following those instructions one final thought I want to make is some comments that people were making on my last video which I thought was a really good observation which is that the way mCP is implemented right now and really a lot of agent tool calling is that when you register a ton of tools with an agent or you register a bunch of mcps it's going to overload the context window of that agent and it's going to start to get confused and it'll just get distracted from the task you're asking it to do so ideally a solution that enables AI agents to integrate with a bunch of tools should really have a sort of routing component where the AI agent can call a tool first to request a list of available tools especially tools that are relevant to whatever it's trying to do and then this routing component returns that list to the agent and then the agent actually calls the relevant tool this way we're not passing a full list of tools in every single agent API call because that again just overwhelms the context window and leads to worse performance so for me personally after seeing this limitation with mCP I don't see myself working on it until they add a stateless version because I think serverless functions are a perfect fit for agent tool calling and that's ultimately the majority of the interactions that we want to empower through mCP so if they do come up with a way to make this very transactional exchange it starts to make sense to me but until then I don't see the value in servers implementing a whole new API and especially deploying in a new way if they're currently running in a serverless environment so I'm going to be on the lookout for alternative options to mCP so let me know in the comments if you have something in mind or if you've used the tools similar to this like wildcard agents. Json that you seem to like as always thanks for watching and I'll see you in the next one take care