I think skills are just a marketing ploy. There is nothing preventing a MCP from serving skills.
I still prefer MCP over skills
281–290 of 415 posts
Re: I still prefer MCP over skills
#282Don't focus on what you prefer: it does not matter. Focus on what tool the LLM requires to do its work in the best way. MCP adds friction, imagine doing yourself the work using the average MCP server. However, skills alone are not sufficient if you want, for instance, creating the ability for LLMs to instrument a complicated system. Work in two steps: 1. Ask the LLM to build a tool, under your guide and specification…
Although the author is coming from a place of security and configuration being painful with Skills, I think the future will be a mix of MCP, Agents and Skills. Maybe even a more granular defined unit below a skill - a command... These commands would be well defined and standardised, maybe with a hashed value that could be used to ensure re-usability (think Docker layers). Then I just have a skill called: - github-rev…
Commands are already a thing, but they're falling out of favor because a user can just invoke a skill manually instead.
Re: I still prefer MCP over skills
#283Earlier quoted context omitted.
Why are they not calling APIs directly with strictly defined inputs and outputs like every other internal application? The story for MCP just makes no sense, especially in an enterprise.
MCP really only makes sense for chatbots that don’t want to have per session runtime environments. In that context, MCP makes perfect sense. It’s just an adapter between an LLM and an API. If you have access to an execution engine, then yes CLI + skills is superior.
actually local MCP just spawns a subprocess and talks via stdin/stdout.. same as CLI tool.
Extra layer is only for remote case.
This might help if interested - https://vectree.io/c/implementation-details-of-stdio-and-sse...
Re: I still prefer MCP over skills
#284Don't focus on what you prefer: it does not matter. Focus on what tool the LLM requires to do its work in the best way. MCP adds friction, imagine doing yourself the work using the average MCP server. However, skills alone are not sufficient if you want, for instance, creating the ability for LLMs to instrument a complicated system. Work in two steps: 1. Ask the LLM to build a tool, under your guide and specification…
> For instance it does not make sense to have an MCP to use git. What if you don’t want the AI to have any write access for a tool? I think the ability to choose what parts of the tool you expose is the biggest benefit of MCP. As opposed to a READ_ONLY_TOOL_SKILL.md that states “it’s important that you must not use any edit API’s…”
Anyone who's ever `DROP TABLE`d on a production rather than test database has encountered the same problem in meatspace.
In this context, the MCP interface acts as a privilege-limiting proxy between the actor (LLM/agent) and the tool, and it's little different from the standard best practice of always using accounts (and API keys) with the minimum set of necessary privileges.
It might be easier in practice to set up an MCP server to do this privilege-limiting than to refactor an API or CLI-tool, but that's more an indictment of the latter than an endorsement of the former.
Re: I still prefer MCP over skills
#285This argument always sounds like two crowds shouting past each other. Are you a solo developer, are you fully in control of your environment, are you focused on productivity and extremely tight feedback loops, do you have a high tolerance for risk: you should probably use CLIs. MCPs will just irritate you. Are you trying to work together with multiple people at organizational scale and alignment is a problem; are you…
In an organisation we can’t limit MCP access. It’s all or nothing. Everything the user can touch, the MCP can touch. We can trust humans not to do stupid things. They might accidentally delete maybe two items by fat-fingering the UI. An Agent can delete a thousand items in a second while doing 30 other things. With bespoke CLI tools we can configure them so that they cannot access anything except specific resources,…
> We can trust humans not to do stupid things.
hold my beer
I can definitely delete a thousand items with a typo in my bash for loop/pipe. You should always defend against stupid or evil users or agents. If your documents are important, set up workflows and access to prevent destructive actions in the first place. Not every employee needs full root access to the billing system; they need readonly access to their records at most.
Re: I still prefer MCP over skills
#286Earlier quoted context omitted.
A CLI can just be a RPC call to a daemon, exact same pattern apply. In fact my most important CLI based skill are like this.. a CLI by itself is limited in usefulness.
In other words, a wrapper around an MCP that's less verbose.
"MCP" here is not needed.
Re: I still prefer MCP over skills
#287Earlier quoted context omitted.
If you have an API with thousands of endpoints, that MCP description is going to totally rot your context and make your model dumb, and there's no mechanism for progressive disclosure of parts of the tool's abilities, like there is for CLIs where you can do something like: tool --help tool subcommand1 --help tool subcommand2 --help man tool | grep "thing I care about" As for stateful behavior, say you have the google…
Nobody said anything about an API with thousands of endpoints. Does that even exist? I've never seen it. Wouldn't work on it if I had seen it. Such is the life of a strawman argument. Further, isn't a decorator in Python (like @mcp.tool) the easy way to expose what is needed to an API, if even if all we are doing is building a bridge to another API? That becomes a simple abstraction layer, which most people (and LLMs…
Cloudflare wrote a blog post about this exact case. The cloud providers and their CLIs are the canonical example, so 100% not a strawman.
Re: I still prefer MCP over skills
#288> Context Bloat: Using a skill often requires loading the entire SKILL.md into the LLM’s context window, rather than just exposing the single tool signature it needs. It’s like forcing someone to read the entire car’s owner’s manual when all they want to do is call car.turn_on(). MCP has severe context bloat just by starting a thread. If harnesses were smart enough to, during install time, summarize the tools provide…
> A solution is to have the agent run a cli tool to access mcp services. lol and why do you need mcp for that, why cant that be a classic http request then?
I use this pattern with mcp-cli, and I do that instead of a curl request for two reasons: 1) not leaking my creds into the agent session, and 2) so I can allowlist / denylist specific tools on an MCP server, which I can't do as easily if I give the agent an API token and curl.
Re: I still prefer MCP over skills
#289Earlier quoted context omitted.
You can make it compose by also giving the agent the necessary tools to do so. I encountered a similar scenario using Atlassian MCP recently, where someone needed to analyse hundreds of Confluence child pages from the last couple of years which all used the same starter template - I gave the agent a tool to let it call any other tool in batch and expose the results for subsequent tools to use as inputs, rather than d…
The agent cannot compose MCPs. What it can do is call multiple MCPs, dumping tons of crap into the context and then separately run some analysis on that data. Composable MCPs would require some sort of external sandbox in which the agent can write small bits of code to transform and filter the results from one MCP to the next.
This is confusing to me. What is composability if not calling a program, getting its program, and feeding it into another program as input? Why does it matter if that output is stored in the LLM's context, or if it's stored in a file, or if it's stored ephemerally?
Maybe I'm misunderstanding the definition of composability, but it sounds like your issue isn't that MCP isn't composable, but that it's wasteful because it adds data from interstitial steps to the context. But there are numerous ways to circumvent this.
For example, it wouldn't be hard to create a tool that just runs an LLM, so when the main LLM convo calls this tool it's effectively a subagent. This subagent can do work, call MCPs, store their responses in its context, and thereby feed that data as input into other MCPs/CLIs, and continue in this way until it's done with its work, then return its final result and disappear. The main LLM will only get the result and its context won't be polluted with intermediary steps.
This is pretty trivial to implement.
Re: I still prefer MCP over skills
#290We use MCP at work. In my team of about 6 people, everyone has Claude access, but about half of us are non-engineers. I built an MCP over our backend and Clickhouse, and setup a Claude Project with instruction (I'm assuming this count as skill?). The instruction is mostly for enriching the analytics data that we have, e.g. hinting Claude to prefer certain datasets for certain questions.
This allows the non-engineers (and also engineers) to use Claude Desktop to do day-to-day operations (e.g. ban user X for fraud) and analytics (e.g. how much revenue we made past 7 days? Any fraud patterns?). The MCP helps to add audit, authorization, and approval layer (certain ops action like banning user will require approval).