This was the easiest call and many like me made it in March[0] among all of the anti-MCP wave of influencers claiming it dead (many, many prominent folks in tech including Garry Tan). Literally every tech influencer in every social feed in March was calling MCP dead and crowning CLI the winner (completely ignoring every reasonable argument around security, observability/telemetry, ease of deployment and operations, etc.)
A direct quote from March, 2026[1]:
> If you’re still not convinced that a lot of this discourse [regarding the death of MCP] lacks nuance and is just hype, congrats on buying into the current AI-influencer FOMO hype cycle; see you in 6 months when the influencers move on to the next revelation of the moment to stay relevant and get your eyeballs and dollars.
It was fairly obvious why MCP would be needed once AI engineering and uptake moved beyond the solo developer and single harness stack of "what works for Me" versus "what works for My Team", particularly in an enterprise context. The key mistake people made was thinking in terms of their own workflows and own local stacks instead of a team's workflow and a team's operational stack. There was also an ignorance of MCP's stateless HTTP mode (yes, it was already a thing in March; the 2026-07-28 revision of the spec just prioritizes it as the primary focus moving forward) versus local `stdio`.
My biggest complaint right now is that OpenAI has still refused to implement the MCP Prompts spec[2] and in general, the major clients have spotty implementation for some of the features in the spec.
I’m still not entirely sold. I do hear you about team workflows, I’m just not sure MCP does that dramatically better (as of today).
I can see the snap appeal. One protocol, we can chuck an auth reverse proxy in front of all the MCPs, compliance has their integration point, etc.
I don’t think MCP is structured enough to give a huge edge over bash there. Looking at MCP messages, they aren’t immediately more legible than a bash command, output and exit code. You also don’t own a lot of the MCP servers you use, so backtracking for audits will require knowing what MCP commands did what back then.
I do suspect something more like MCP than bash will be the winner. MCP just feels very open source rather than enterprise. Eg I don’t think I’ve seen any sort of privilege escalation and logging scheme. The enterprise will want some sort of “request admin privileges” scheme. Likewise they’ll probably want more context on ACP requests; who is calling this MCP, using what agent, and for what project?
CharlieDigital · · focus · HN ↗
A direct quote from March, 2026[1]:
It was fairly obvious why MCP would be needed once AI engineering and uptake moved beyond the solo developer and single harness stack of "what works for Me" versus "what works for My Team", particularly in an enterprise context. The key mistake people made was thinking in terms of their own workflows and own local stacks instead of a team's workflow and a team's operational stack. There was also an ignorance of MCP's stateless HTTP mode (yes, it was already a thing in March; the 2026-07-28 revision of the spec just prioritizes it as the primary focus moving forward) versus local `stdio`.My biggest complaint right now is that OpenAI has still refused to implement the MCP Prompts spec[2] and in general, the major clients have spotty implementation for some of the features in the spec.
[0] <a href="https://news.ycombinator.com/item?id=47380270">https://news.ycombinator.com/item?id=47380270
[1] <a href="https://chrlschn.dev/blog/2026/03/mcp-is-dead-long-live-mcp/" rel="nofollow">https://chrlschn.dev/blog/2026/03/mcp-is-dead-long-live-mcp/
[2] <a href="https://github.com/openai/codex/issues/5059" rel="nofollow">https://github.com/openai/codex/issues/5059
everforward · · focus · HN ↗
I can see the snap appeal. One protocol, we can chuck an auth reverse proxy in front of all the MCPs, compliance has their integration point, etc.
I don’t think MCP is structured enough to give a huge edge over bash there. Looking at MCP messages, they aren’t immediately more legible than a bash command, output and exit code. You also don’t own a lot of the MCP servers you use, so backtracking for audits will require knowing what MCP commands did what back then.
I do suspect something more like MCP than bash will be the winner. MCP just feels very open source rather than enterprise. Eg I don’t think I’ve seen any sort of privilege escalation and logging scheme. The enterprise will want some sort of “request admin privileges” scheme. Likewise they’ll probably want more context on ACP requests; who is calling this MCP, using what agent, and for what project?
CharlieDigital · · focus · HN ↗
MCP over HTTP buys you server side telemetry, composability, remotely held credentials (security), etc.
MCP is about enterprise control of the server side; no advantages on the client side at all.