Decent point - but - the same could be said for skills. You can have enterprise skills that don't require use of MCP.
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.
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.
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 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