Comment by CharlieDigital
4 days ago
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.
Everyone is so afraid of being left behind in this period of rapid AI change. The influencers are exploiting that to create anxiety and fear of missing trends.
I follow several influencers from pre-AI times who were (or were trying to become) social influencers thought leader types. People like Theo or many of the JavaScript and training course people. Following them was helpful to follow the trends that more chronically online juniors would be picking up and pushing at the workplace, which set me up in a better position to understand and then defend against it.
All of them, every single one, have dropped their previous influencer topic and pivoted to being AI influencer. Every time I see a post they’re either saying you need to adopt a new trend or that last month’s trend is dead. “Prompting is dead! Graphs are the future!” or “Claude Code is OVER! This new harness is 10X better”
MCP was one of these topics. Everyone went from telling you that you needed to use MCP or be left behind, to declaring that MCP was dead almost in unison.
The only pro-MCP holdouts were the influencers who had built their own MCP courses for sale.
It kind of repulses me when these people will make a video about anti-AI sentiment and splice in an ad for an AI tool at the halfway mark.
Do content creators have a lot of say over what advertising gets spliced in to their creation?
2 replies →
> My biggest complaint right now is that OpenAI has still refused to implement the MCP Prompts spec
MCP servers provide three things: tools, resources, and prompts. Of these, tools seem to be the only part implemented consistently across major clients like ChatGPT, Claude.ai, Claude Code, etc.
For prompts and resources, there doesn't seem to be a common understanding of how clients are supposed to consume them.
For example, if an MCP server exposes resources, Claude Code can discover them and consume them when needed without you explicitly asking for a specific resource. Claude.ai behaves differently. It doesn't automatically discover and consume those resources. Instead, it gives you a way to manually add an MCP resource to the prompt.
So while MCP defines tools, resources, and prompts at the protocol level, the actual user experience for resources and prompts varies quite a bit across clients.
In practice, the problem with resources is that many resource collections are too large to list exhaustivley, and if that's the case you will need to need to implement a proper search tool anyways (as the Completions utility isn't a good fit), at which point there is little use in also implementing all of that as a resource, rather than `list_`,`search_`,`get_` for a resource.
That feels like it should be the obvious use case for something like a `?q` query param, formalized or not, but it seems like nobody working on the spec and libraries ever considered query params as a use case, since they're still broken in the Typescript library.
The idea of "model controlled", "application controlled" and "user controlled" for tool, resources and prompts (respectively) was aligned with the chat interface. It breaks for the autonomous agent paradigm where the agency is the user and the lines are blurred. Unfortunately MCP has been mostly relegated to tool calling leaving potentially powerful capabilities on the table due to lac of client support for them.
I disagree on Prompts since virtually all of the mainstream harnesses implement them: Cursor, Claude, OpenCode, Copilot. Prompts are very clearly just a remotely delivered `/` command and it is easy to see why this is really powerful (single entry point, no need to update/sync skills, dynamic sets by audience, dynamic construction of the payload by audience, etc). For all intents and purposes, it should be viewed as an analog to local, text-only skills.
Codex is the only mainstream harness that does not implement this in the client.
Prompts I am not that sold on but it seems silly to not implement it in clients.
A good use case for resources is small amounts of commonly needed state that can be fetched and proactively updated by the mcp server, saving latency when the model requests it.
Prompts is possibly one of the most useful enterprise features for MCP.
Dynamically target sets of `/` commands to teams in an enterprise by their identity+claims? Legal team gets a set of skills? Finance team gets another just by their roles? Always up-to-date delivery of what are effectively remotely served skills? Telemetry on who is using which skill? Server-side rendering of skills so that common skills can be composed? With placeholders replaced by user- or team-custom options? Easy to ship new skills as long as the user has connected the MCP? Easy to retire skillsets that are outdated across the entire enterprise?
MCP Prompts is one of the most powerful capabilities in the spec for enterprises.
OpenAI team: if you are angling for enterprise, you need to get this solved. Your FDEs are going to make a killing getting this set up for enterprises. Build an enterprise skills management platform around this that's integrated to their directory. Streamlined setup of the MCP via MDM. Telemetry on enterprise wide usage of curated skills across the enterprise, by team, by individual. You need this.
An MCP server should be self-describing, so I use prompts to deliver skills or skill-like context.
[dead]
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?
MCP is about the server side, not the client side.
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.
You’re out of the loop! I’ve myself implemented access escalation on top of MCP and it’s not rocket science. It’s already being used by Enterprise everywhere!
To be fair, the MCPs of 8 months ago are not the MCPs of today. You had to mess around with headers and .env files and local npm proxies and other bullshit only cli jockeys would tolerate. The MCPs of today are fully remote, stateless, oauth enabled, and integrated much more nicely into the the user experience. Click a button and it works.
I do agree, the "MCPs are dead" narrative was overblown, but there were legit reasons we weren't ready to go all in on them back then.
You could serve MCP over HTTP 8+ months ago and deal with none of that? Lots of people did? Especially internally within Enterprise
With stateless MCP, the MCP rube goldberg everyone was calling dead in March is effectively dead though.
MCP was already stateless capable in March. All the build I was doing was already stateless HTTP (which is why it felt certain that it was the future).
These reason why they were proclaiming MCP dead and crowning CLI the influencer is that they aren't serious people. They're either vibe coders who never knew what the meaning of engineering for production or they are those who chose to forget the meaning because it fits their chosen vibe coder narrative.
>It was fairly obvious why MCP would be needed once AI engineering and uptake moved beyond the solo developer and single harness stack
This was already happening back in March. Lesser technical users were looking to hook up web LLMs to various SaaS apps so they could pull data in.
It was quite surprising people were forming such strong opinions when there were very clear and objective differences in use case.
There is no reason to think about team workflows. Focus on your workflow. Your own custom local workflow is basically your competitive advantage as an employee. The moment everyone else can do exactly the same things you do, there is no reason to really keep you around.
The game has changed in the AI era. Horde secrets, skills, custom processes. Don’t share everything. Stop giving things away or you will have nothing left.
If that works for you great but I am where I am in my career by helping everyone I can around me. Making my team and the company better pays dividends and you stand out from people that only work for themselves.
This is now an outdated mentality in the AI era, where people will quickly use whatever you put out to make themselves better but little to no benefit will return to you beyond maybe a fuzzy feeling. People already feel proud just prompting huge projects out and claiming it as their own work. You will not be recognized.
“When a favor becomes too large to repay, the gratitude turns to resentment.”
1 reply →
Yep, number of new MCP servers this month is on track to be the highest it has ever been: https://bloomberry.com/data/mcp/
"MCP" is the new "API" (MCP over streaming HTTP, after all, is just an API with a structured payload wrapper and defined interactions).
It is only going to continue to proliferate in usage and adoption.
With the v2 spec, MCP became a lot closer to APIs by becoming stateless. And there is now a push to use HTTP verbs more extensively to improve caching even better in v3. MCP is converging into APIs but wit great auth and auditing
10 replies →
Yeah I always just thought of MCP as best for the average user and then CLI as one of the tools of choice for power users. Never had to be one or the other, I use both daily
Decent point - but - the same could be said for skills. You can have enterprise skills that don't require use of MCP.
Sure, but now you have a distribution and telemetry challenge.
It's hard to customize those skills. How can I tweak my skill a bit to match my workflow? With MCP Prompts over HTTP, this is easy: you can server render the text with my personalization specific to me.
It's hard to tell which skills are being used. With MCP over HTTP, each Prompt call, each Tool call is an HTTP request and you get telemetry on activation. You can server compose the response and ask the agent requesting it to return a score on how useful it is, too. Or ask it to call another endpoint to rate the skill.
Enterprise skills delivered to the disk you cannot do this. If a skill is flawed or outdated, you cannot revoke the skill at an enterprise level. MCP Prompts: it's easy to do.
"It's hard to customize those skills."
I don't see what you mean?
An MCP and a skill are just two ways of distributing capabilities.
For telemetry ... well the agent should still have it's http logs? Also, I'm not sure MCP Telemetry is the primary point of concern for most things? Like thats a skill debugging thing?
5 replies →
I mean it was a pretty classic hype cycle - MCP was massively inflated, the blowback was also inflated, and now we're in the happy state where there are same cases where it's genuinely better and differentiated and everyone will keep iterating on it. (statelessness was a big step forward).
Either way still seems like the issue is people giving influencers too much power over them.
> The key mistake people made was thinking in terms of their own workflows and own local stacks
We need a dunning-kruger for empathy: people least able to imagine situations not their own trying hardest to influence others.
Important to remember most ai influencers are a joke and spewing nonsense, claiming things are “over” is one of the only reliable and viable ways to for a person not at OpenAI/anthropic to actually make money in this wave.
I was watching something on YouTube last night and it really reminded me of informercials from the 80s/90s. Imagine trying to divine actual useful information about business, technology, and industry from infomercials..
> prominent folks in tech including Garry Tan
lmao not sure if you are being sarcastic but that guy is joker and a poster child of ai psychosis .
I agree with your sentiment to degrees, but he is indeed prominent in the tech industry with many folks that will follow his lead.