[flagged]
I still prefer MCP over skills
251–260 of 415 posts
Re: I still prefer MCP over skills
#252Don'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…
I feel like the MCP conversation conflates too many things and everyone has strong assumptions that aren't always correct. The fundamental issue is between one-off vs. persistent access across sessions: - If you need to interact with a local app in a one-off session, then use CLI. - If you need to interact with an online service in a one-off session, then use their API. - If you need to interact with a local app in a…
Hard disagree. Apis and clis have been THOROUGHLY documented for human consumption for years and guess what, the models have that context already. Not only of the docs but actual in the wild use. If you can hook up auth for an agent, using any random external service is generally accomplished by just saying “hit the api”.
I wrap all my apis in small bash wrappers that is just curl with automatic session handling so the AI only needs to focus on querying. The only thing in the -h for these scripts is a note that it is a wrapper around curl. I havent had a single issue with AI spinning its wheels trying to understand how to hit the downstream system. No context bloat needed and no reinventing the wheel with MCP when the api already exists
Re: I still prefer MCP over skills
#253I like skills because they rely on the same tools which humans rely upon. A well-written skill can be read and used by a human too. A skill is just a description for how to use an existing CLI tool. You don't need to write new code for the LLM to interact with some system. You just tell the LLM to use the same tool humans do. And if you find the CLI is lacking in some way, you can improve it and direct human usage be…
[dead]
Re: I still prefer MCP over skills
#254Earlier quoted context omitted.
idk, just have a standard internet request tool that skills can describe endpoints to. like you could mock `curl` even for the same CLI feel
Now you’ve replicated MCP but with extra steps and it’s harder to debug.
Its actually simpler since the skill can be 100% a MD file.
Re: I still prefer MCP over skills
#255Earlier quoted context omitted.
> Focus on what tool the LLM requires to do its work in the best way. I completely agree with you. There was a recent finding that said Agents.md outperforms skills. I'm old school and I actually see best results by just directly feeding everything into the prompt context itself. https://vercel.com/blog/agents-md-outperforms-skills-in-our-...
How do you shut off particular api calls with an agents.md?
I personally use tool calling for APIs, so really not sure (I don't use agents.md per se, I directly stuff info into the context window)
Re: I still prefer MCP over skills
#256We had a contention between MCP / Skills for our product and ended up offering both. We built a CLI tool that could interface with the MCP server [1]. It seems redundant but our app is a coding app on iOS (Codea), and the issue with offering a plain MCP server meant that the agentic coding harness found it harder to do its job.
With the CLI the agent could check out the project, work on it locally with its standard file editing / patching / reading tools, then push the work back to device. Run and debug on device, edit locally, push.
With MCP the agent had to query the MCP server for every read and write and was no longer operating in its normal coding loop. It still works, though, and as a user you can choose to bypass the CLI and connect directly via MCP.
The MCP server was valuable as it gave us a consistent and deterministic language to speak. The CLI tool + Skill was valuable for agentic coding because it allowed the coding work to happen with the standard editing tools used by agents.
The CLI also gave us device discovery. So the agent can simply discover nearby devices running Codea and get to work, instead of a user having to add a specific device via its IP address to their agent.
Re: I still prefer MCP over skills
#257Don'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…
[dead]
Re: I still prefer MCP over skills
#258Occams Razor spares none. Everything will go to the simplest and most convenient, often both, despite the resistance of the complexity lovers. Sorry MCP, you are not as simple as CLI/skill/combination, and no, you are not more secure just because you are buried under 3 level of spaghetti. There are no reason for you to exist, just like Copilot. I don't just wish, but know you'll go into obscurity like IE6.
i use mcp for security. you can have an airgapped agent that can still call online tools. for example, web search. however it can't get infected because there is no internet access. the worst you can do is put your secrets in the web search box
You can have that with CLI.
MCP is just a wrapper on top, there are no inherent differences other than complexity on top.
How do you think MCP work under the hood?
Re: I still prefer MCP over skills
#259Occams Razor spares none. Everything will go to the simplest and most convenient, often both, despite the resistance of the complexity lovers. Sorry MCP, you are not as simple as CLI/skill/combination, and no, you are not more secure just because you are buried under 3 level of spaghetti. There are no reason for you to exist, just like Copilot. I don't just wish, but know you'll go into obscurity like IE6.
Thanks for the 3x context usages because it need to follow the installation steps. and extra credit for the auth token leaks because it is sent in every call as context.
Anything you said here just demonstrate that you don't really understand the differences between MCP and CLI.
MCP is just wrapper on top of API layer that RCP to a worker/daemon. That API layer itself can be the CLI. You get no more context usage, and no extra security impact, because fundamentally the model are the same, just without the fluff.
You are probably thinking of CLI as in "oh I must pass everything and it is stateless", only some need to be like that.
Re: I still prefer MCP over skills
#260Don't they both solve different problems? This tribalism makes no sense.