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.
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?
I sync a skill in a file with my repo. I can't edit that skill. I can't combine that skill. I can't customize the skill without affecting the other folks on my team or I have to put that in a gitignore.
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.
You can't do it in a team environment. You are missing the key point. Teams.
Please, go build the simplest MCP server you can that serves a prompt. Now make it dynamic by user. Now let you users share a common template. Now look at the telemetry you see on the server when someone uses the skill. Now add a flag to turn some on and off. Now imagine you are in an enterprise and you want to centrally manage all skills across the teams mapping some skills to some teams, revoke skills, force update skills, compose skills by user automatically using rules.
Please. Just try it. You can literally vibe code this in a few minutes and connect the dots.
A file on disk is static. An HTTP request-response for text is not. Build just one prompt endpoint. Now imagine dynamically injecting text into the skill as well because it's just HTTP.
You are arguing why we need web servers when we can just email text files to each other, save them on disk, and open them in Notepad. Do you not understand the power of using an HTTP server for sending text?
I built an MCP server almost on the first day MCP came out; and have built many.
I have been working on 'teams' with MCP since then.
Similarly with 'skills'.
I have been working with NLP and AI for decades.
I've worked (a little bit) with one of the 'Godfathers of AI'
And FYI (although I can't be certain obviously) odds are I have been coding since before you were born.
By your answers - don't seem to have demonstrated a grasp of the technology in question, and are glibly project as though you have some kind of insight.
The 'general service concept' you are describing can be quite useful, yes, but at that level of sophistication - especially with 'user management', and the inherent issues around that aka privileges, SSO, telemetry, whatever etc. - that would likely be best used as a common service, accessed via regular REST calls. The 'agent instructions' for that service would be trivially described in a 'skill'.
Alternatively, a 'skill' which merely instructs the Agent on how to use a local tool via CLI (which can be anything really), is very useful as well. Almost universally so.
After that 'skills' oriented towards REST services and local CLI tooling - MCP has little to no value.
The only scenario in which we continue to use MCPs, are for those published by 3rd parties, for which MCP provides a relatively plug-and-play solution. But even then, if MCP were to be deprecated, everyone would merely switch to rest/cli-facing skills, and nothing would be lost.
MCP has a bit of value due to it's incumbency, but it never existed, nobody would invent it today, it really doesn't solve any real problem, given how much better AI is at using standard tooling.
> I built an MCP server almost on the first day MCP came out
Build the Prompts implementation and try it. Built a user interface to compose prompts together (e.g. like old school server side includes) so you can inject a standard fragment into multiple MCP prompts. Add a telemetry layer and a dashboard to show which skills are being used and by whom.
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
bluegatty · · focus · HN ↗
CharlieDigital · · focus · HN ↗
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.
bluegatty · · focus · HN ↗
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?
CharlieDigital · · focus · HN ↗
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.
bluegatty · · focus · HN ↗
You can trivially build a skill that uses a set of customizable, per user values.
You can also build a (non-MCP) 'gateway' to do those things you just described, and not have it bound or limited by 'MCP' at all.
We already do both things.
I don't see what MCP has to do with any of this; it's a standard, that has very narrow value.
CharlieDigital · · focus · HN ↗
Please, go build the simplest MCP server you can that serves a prompt. Now make it dynamic by user. Now let you users share a common template. Now look at the telemetry you see on the server when someone uses the skill. Now add a flag to turn some on and off. Now imagine you are in an enterprise and you want to centrally manage all skills across the teams mapping some skills to some teams, revoke skills, force update skills, compose skills by user automatically using rules.
Please. Just try it. You can literally vibe code this in a few minutes and connect the dots.
A file on disk is static. An HTTP request-response for text is not. Build just one prompt endpoint. Now imagine dynamically injecting text into the skill as well because it's just HTTP.
You are arguing why we need web servers when we can just email text files to each other, save them on disk, and open them in Notepad. Do you not understand the power of using an HTTP server for sending text?
bluegatty · · focus · HN ↗
I have been working on 'teams' with MCP since then.
Similarly with 'skills'.
I have been working with NLP and AI for decades.
I've worked (a little bit) with one of the 'Godfathers of AI'
And FYI (although I can't be certain obviously) odds are I have been coding since before you were born.
By your answers - don't seem to have demonstrated a grasp of the technology in question, and are glibly project as though you have some kind of insight.
The 'general service concept' you are describing can be quite useful, yes, but at that level of sophistication - especially with 'user management', and the inherent issues around that aka privileges, SSO, telemetry, whatever etc. - that would likely be best used as a common service, accessed via regular REST calls. The 'agent instructions' for that service would be trivially described in a 'skill'.
Alternatively, a 'skill' which merely instructs the Agent on how to use a local tool via CLI (which can be anything really), is very useful as well. Almost universally so.
After that 'skills' oriented towards REST services and local CLI tooling - MCP has little to no value.
The only scenario in which we continue to use MCPs, are for those published by 3rd parties, for which MCP provides a relatively plug-and-play solution. But even then, if MCP were to be deprecated, everyone would merely switch to rest/cli-facing skills, and nothing would be lost.
MCP has a bit of value due to it's incumbency, but it never existed, nobody would invent it today, it really doesn't solve any real problem, given how much better AI is at using standard tooling.
CharlieDigital · · focus · HN ↗