i personally was anti-MCP but they just work better in terms of tool search than a CLI, especially with the idea of tool nudging
pretty much
However, I don't think that's what is really hurting MCP, because it could evolve. What really killed it was the standards process and enterprise groups getting ahold of it. It went into spec writing and got adjudicated into uselessness all while enterprise authentication groups were figuring out the best angle to make money on it. I listened to a pitch from Okta on MCP and they wanted to charge out the nose for it for no good reason.
That may sound like an exaggeration, but it’s exactly what I see in our product.
Humans developing something already have context that agents don’t have yet. Most agents start a task with virtually no prior knowledge. And they start from zero every single time. That may improve in the future, but we’re not there yet.
Can agents get the job done? Yes. But without a thoughtfully implemented MCP server, they are awkwardly inefficient.
The problem is that the agent does not care. Its primary goal is to get the job done.
Maybe the agent is smart enough to choose the optimal path, but that strongly depends on the model being used. You also do not know who is on the other side. With a human-facing API, you can usually assume who is using it and what they want to achieve. Humans are generally lazy and tend to look for the most efficient solution.
An agent, however, will happily iterate through 1,000 users and fetch the online state for each one individually, even across multiple paginated requests if necessary.
You can provide an endpoint that returns the online states for all users at once. A human will most likely use that endpoint, but I have seen agents go completely wild on the other side. :D
At some point, you may get a response like “token limit reached.” But what do you do then? You give the agent more tokens and increase your bill, because you cannot even tell whether there was a more optimized way to achieve the same result.
In practice, this is a surprisingly tricky problem. :D
The article is semi right. Local MCPs that are made by enthusiasts wrapping an api they don’t own? Yes that is dead and should never have been a thing in the first place.
But MCP in its current direction and form is really an OAuth Protocol over http. And it has something other that other agent identity protocols don’t: client adoption
> Provide CLI -> API -> docs, in that order. LLMs already learned from man pages and StackOverflow.
So how is the agent going to know about your niche CLI? It's still going to use up context to learn your command line interface, same as for an MCP interface.
Agents only excel at CLIs if a particular CLI was part of their training data. The same would be true of well-known MCP interfaces.
> Alternative 2: Skills Pattern
> If MCP is "spreading all menus on the table upfront", Skills is "asking the librarian for only the book you need".
Or: Layer your MCP help commands, like a directory at a mall. The agent only looks up what it needs at the time.