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.
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.
Codex is the only mainstream harness that does not implement this in the client.
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.
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.
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 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.
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.
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.
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?
A user getting a skill via a plugin and wants to keep it in sync with the source has the same problem. Next update/sync wipes out their changes.
Skills delivered via file system download/git are like Deck.final.v2.real-final.2026-10-01.published.pptx. Skills delivered via MCP over HTTP are "live" and dynamic.
An HTTP MCP server is just a server returning text. The MCP prompt can be a template. It can have placeholders. I can build a UI to allow the user who logs in to customize the prompt/skill by filling in the placeholders. If they don't put a value for the placeholder, I render it to the HTTP response stream with defaults. I can dynamically render the skill, tailored for each user like I can render JSON or HTML for each logged in user. MCP Prompts just returns text. I can render any text I want on a server. I can return a different, more suitable skill text for the user. I can personalize it based on their workflow. The base template is always up to date for every user, etc.
Try it. Go write an MCP HTTP endpoint delivering a prompt. Now make that dynamic and serve different text back based on different users. Now your users are in different teams. Render variants of the same prompt/skill by team. It's powerful.
Use your imagination.
It is only going to continue to proliferate in usage and adoption.
Do you mean the Roy Fielding "REST" or the HTTP API "REST"?
Calling the latter "REST" is wrong. It's like calling a hermit crab a snail.
Edit: I forgot to mention, the former is gaining relevance as the elusive evolvable clients are now a thing.
If you can build the ultimate evolvable client, then you can collapse all UI into a single client.
Basically Roy Fielding told us to build an API that can only be operated by a human like intelligence, nobody could implement that because such an intelligence did not exist (hence the switch to imperfect HTTP APIs), and now that LLMs are a thing, said human like intelligence exists. This means Roy Fielding wasn't wrong, he was 25 years too early and ironically people should be building real REST APIs in the pendantic academic sense from today on and not the "pragmatic" HTTP API.
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.
“When a favor becomes too large to repay, the gratitude turns to resentment.”
Good luck
We need a dunning-kruger for empathy: people least able to imagine situations not their own trying hardest to influence others.
lmao not sure if you are being sarcastic but that guy is joker and a poster child of ai psychosis .