Yes, this has been the gradual evolution of AI context and tooling. Same thing is occurring with some of the use cases of a vector DB and RAG. Once you can have the agent interact with the already existing conventional data store using existing queries, there is no point in introducing that work flow for inference.

A lot of the reasons to use MCP are contained in the architecture document (https://modelcontextprotocol.io/specification/2025-11-25/arc...) and others. Among them, chief is security, but then there's standardization of AI-specific features, and all the features you need in a distributed system with asynchronous tasks and parallel operation. There is a lot of stuff that has nothing to do with calling tools.

For any sufficiently complex set of AI tasks, you will eventually need to invent MCP. The article posted here talks about those cases and reasons. However, there are cases when you should not use MCP, and the article points those out too.

I am creator of HasMCP (my response could have a little bias). Not everyone has home/work computer by preference mostly. I know a lot of people just use iPad or Android tablet in addition to their phone. They still use applications to work on the things. This number is not a small amount of people. They need to access openworld data or service specific data. This is where MCP is still the one of the best ways.

It tries to standardize the auth, messaging, feedback loop where API can't do alone. A CLI app can do for sure but we are talking about a standard maybe the way is something like mcpcli that you can install your phone but still would you really prefer installing bunch of application to your personal device?

Some points that MCP is still not good as of today:

- It does not have a standard to manage context in a good way. You have to find your hack. The mostly accepted one search, add/rm tool. Another one is cataloging the tools.

- lack of client tooling to support elicitation on many clients (it really hurts productivity but this is not solved with cli too)

- lack of mcp-ui adoption (mcp-ui vs openai mcp app)

I would suggest keep building to help you and your users. I am not sponsor of MCP, just sharing my personal opinion. I am also creator HasCLI but kindly biased for MCP then CLI in terms of coverage and standardization.

For the Agent to use CLI, don't we have to install CLI in the run-time environment first? Instead for the MCP over streamable HTTP we don't have to install anything and just specify the tool call in the context in't it?

CLI doesn’t work for your coworkers that aren’t technical.

Have you tried to use a random API before? It’s a process of trial and error.

With the MCP tools I use, it works the first time and every time. There is no “figuring out.”

It's significantly more difficult to secure random clis than those apis. All llm tools today bypass their ignore files by running commands their harness can't control.

> Why is this the right way to go? It's not solving the problem it looks like it's solving. If your challenge is that you need to communicate with a foreign API, the obvious solution to that is a progressively discoverable CLI or API specification --- the normal tool developers use.

That sounds like a hack to get around the lack of MCP. If your goal is to expose your tools through an interface that a coding agent can easily parse and use, what compels you to believe throwing amorphous structured text is a better fit than exposing it through a protocol specially designed to provide context to a model?

> The reason we have MCP is because early agent designs couldn't run arbitrary CLIs. Once you can run commands, MCP becomes silly.

I think you got it backwards. Early agents couldn't handle, and the problem was solved with the introduction of an interface that models can easily handle. It became a solved problem. Now you only argue that if today's models work hard enough, they can be willed into doing something with tools without requiring a MCP. That's neat, but a silly way to reinvent the wheel - poorly.

no, it's all about auth. MCP lets less-technical people plug their existing tools into agents. They can click through the auth flow in about 10 seconds and everything just works. They cannot run CLIs because they're not running anything locally, they're just using some web app. The creator of the app just needed to support MCP and they got connectivity with just about everything else that supports MCP.

Exactly this. I've made some MCP servers and attached tons of other people's MCP servers to my llms and I still don't understand why we can't just use OpenAPI.

Why did we have to invent an entire new transport protocol for this, when the only stated purpose is documentation?

By and large, it is a very simple protocol and if you build something with it, you will see that it is just a series of defined flows and message patterns. When running over streamable HTTP, it is more or less just a simple REST API over HTTP with JSON RPC payload format and known schema.

Even the auth is just OAuth.

It’s not a new protocol.

It’s JSON-RPC plus OAuth.

(Plus a couple bits around managing a local server lifecycle.)

Why the desire to reinvent the wheel every time? Agents can do it accurately, but you have to wait for them to figure it out every time, and waste tokens on non-differentiated work

The agents are writing the mcps, so they can figure out those http and ftp calls. MCP makes it so they dont have to every time they want to do something.

I wouldnt hire a new person to read a manual and then make a bespoke json to call an http server, every single time i want to make a call, and thats not a knock on the person's intelligence. Its just a waste of time doing the same work over and over again. I want the results of calling the API, not to spend all my time figuring out how to call the API

C

each ai need context management per conversation this is something that would be very clunky to replicate on top of http or ftp (as in requiring side channel information due session and conversation management)

Everyone looks at api and sure mcp seem redundant there but look at agent driving a browser the get dom method depends on all the action performed from when the window opened and it needs to be per agent per conversation

Can you do that as rest sure sneak a session and conversation in a parameter or cookie but then the protocol is not really just http is it it's all this clunky coupling that comes with a side of unknowns like when is a conversation finished did the client terminate or were just between messages and as you go and solve these for the hundredth time you'd start itching for standardization

You mean, why not ask the AI to "find a way to use FTP", including either using a tool, or writing its own code? Besides the security issues?

One simple reason is "determinism". If you ask the AI to "just figure it out", it will do that in different ways and you won't have a reliable experience. The protocol provides AI a way to do this without guessing or working in different ways, because the server does all the work, deterministically.

But the second reason is, all the other reasons. There is a lot in the specification, that the AI literally cannot figure out, because it would require custom integration with every application and system. MCP is also a client/server distributed system, which "calling a tool" is not, so it does stuff that is impossible to do on your existing system, without setting up a whole other system... a system like MCP. And all this applies to both the clients, and the servers.

Here's another way to think of it. The AI is a psychopath in prison. You want the psycho to pick up your laundry. Do you hand the psycho the keys to your car? Or do you hand him a phone, where he can call someone who is in charge of your car? Now the psycho doesn't need to know how to drive a car, and he can't drive it off a bridge. All he can do is talk to your driver and tell him where to go. And your driver will definitely not drive off a bridge or stab anyone. And this works for planes, trains, boats, etc, just by adding a phone in between.

Because protocols provide structure that increases correctness.

It is not a guarantee (as we see with structured output schemas), but it significantly increases compliance.

If AI is AI why does it need me to prompt it?

> If AI is AI

That "AI" got renamed to "AGI"

Tell me how many ways that print help message for a command you have seen and say "reusable" again. Mcp is exactly exists to solve this. The rest is just json rpc with simple key value pairs.

You can probably let llm guess the help flag and try to parse help message. But the success rate is totally depends on model you are using.