Comment by bluegatty
4 days ago
?
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.
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.
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.