Comment by ford
17 hours ago
Basically MCP is little more than a brand name for "APIs LLM's can use". This means more services are creating APIs, because xyz company who's never been super tech forward doesn't want their tools to be obsolete when everyone uses agents.
Overall, I am in favor of this goal. I'm not sure this is the protocol I'd choose to accomplish it, but it's the one people hear about, and the one they're using.
Yeah it was quite weird seeing "Many of these companies don't even have an external API!" given MCP is literally a protocol for an external API. Not a good one in my opinion but it indeed has mindshare.
Yes. But that's dangerous for end users. It enables lock in. All it does is context management, so skills are much better choice
"and the one they're using." no it's not.
Agents are just making REST calls and that's it.
The best thing a company can do to make their stuff 'agent ready' is to make sure the lllm.txt docs are clear-cut and ready for the AI with clear instructions for agentic use.
'MCP' is frankly a hurdle.
Now - it probably does make sense to add MCP, because it's not expensive at all, and some will like that use case, it maybe garners a bit more attention .
MCP is a 'weak externalization' - people are using it because others are using it, and it's a 'workable' but 'not strong' solution.
It could very well entrench itself however.
It's that extra amazon box that wrap the actual box that wrap the thing you ordered. Except you're doing the wrapping.
I would say the truth[tm] is likely somewhere in the middle ground. Right now corporate MCP deployments happen to satisfy two very specific stopgap niches:
The first one is a business benefit. Enterprises tend to have a lot of data siloes, and coordination between teams/departments/units just to learn that a given data set exists takes a LOT of time - even before you start to arrange suitable access to any of them.
The second one addresses a much deeper architectural chasm. We want to have our agents carry nearly-the-same-but-not-the-most-dangerous permissions as we do. No regulated business can risk unleashing agents with zero judgement capacity to wreck their systems, and on the other hand the existing identity systems are not geared for real-time dynamically adjusted user permissions. The need for so called "agent-aware IAM" is urgent. So instead of letting users connect to the internal APIs directly with their full suite of powers, MCP servers act as stand-ins for API gateways.
MCPs are not as flexible as full-fledged CLI tools, and that's a bit of a shame. But they can also become identity-aware proxies that enforce the intended permissions for agent-safe use. It will probably take years before IAM systems can adapt to the needs of the new world, and it will take another DECADE after that for the improved IAM systems to become universally available across the larger enterprises. So in a big way I agree with you:
> MCP is a 'weak externalization' - people are using it because others are using it, and it's a 'workable' but 'not strong' solution.
"Workable" is a load-bearing term. MCP servers are by no means perfect, but they are good enough for specific needs and allow to move the balancing point as needed while the world catches up.
I'm an engineer and prefer CLI or raw API access 99% of the time. But I also have decades of scars from infosec. The single biggest security threat for a business used to be an employee who could not get their job done. They found ways to work around the roadblocks. These days the single biggest threat is an employee who can not get their job done, but has an infinitely patient agent with vast latent capabilities at their disposal.
So this is thoughtful - but - MCP isn't actually a very good solution for corporate automation either.
Corporate automations face the same problems human driven agents use:
+ The 'tool' section of the chat is not the right place, and it's too limiting + The very concept of MCP server introduces a brittle layer - for what purpose?
CLI for local calls, REST for remote.
That's it.
We build security around that the same way we would otherwise.
Now -> 'better / standard' json type calling for both of those!
Sure! 'Agent Calling API' or something. Yes.
'Agentic Identity Standard'? Yes to that as well.
But MCP was 'the right solution for a period in LLMs that has been superceded.
If MCP did not exist today - we would not invent it. That's the strongest argument I think.
That mimetic thing…
I remember 10s of HN submissions where handlers were trying to get conversations about MCP going on HN back when there was almost nothing known about it and nothing to say.
It was always about tricking people into thinking there was authentic interest in it and it still is.
I suggest you implement an MCP server before adopting this as a firm technical opinion.
The opinion that more companies creating APIs is good?