I personally wouldn't be surprised if the http calling abilities of LLMs end up killing MCP, or at least greatly reducing its use. If you train LLMs to start interacting with REST APIs as a great way to make them do more then a lot of the MCP use cases go away.
LLM already exist that capabilities since chatgpt GPT3.5 Just they don't have tools and then, tools are simply introduced by tool calling specs and it works fine already. MCP is a wrapper around that specs nothing new
MCP was specifically created so LLMs can have a better understanding (better context). An app or user needs completely different endpoints than LLMs.
You are fundamentally misunderstanding what is happening here and how this is all works.
"HTTP calling abilities of LLMs" is not some magic, new feature that is deeply integrated into LLMs. It's just a tool call like everything else - i.e. you prompt the LLM to return a JSON object that conforms to a schema.
MCP is also doing this exact same thing. It's just a wrapper protocol that tries to take care of all the details so that we don't have to deal with a million custom protocols that all accomplish the same thing but are all incompatible.
HATEOAS FTW
I mean the fact that I can bring an API spec, MCP protocol spec, and MCP SDK spec into context and say "make me an MCP server where each route equals a tool" and have that bootstrapped in <5 minutes as a starting point is pretty nice. Then you can just start chaining stuff together.
I have a tool that builds HTTP requests. LLMs can use that just fine, IF they know the API spec they should connect to. And that is the problem. If you are then required to pass the specs of dozens of APIs, you are polluting the context with too much useless info. MCP simplifies that