Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

I still prefer MCP over skills

david.coffee

Post reply on HN
Print view View original

291–300 of 415 posts

Re: I still prefer MCP over skills

#291

Post by theshrike79 »

morgaesis wrote: post #285
theshrike79 wrote: post #271

Earlier quoted context omitted.

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 reco…

These people aren’t doing bash loops, they’re regular non-technical people who just want to use an AI Agent to access services and aggregate data.

If people accidentally delete stuff, they tend to notice it and we can roll back. If an agent does a big whoops, it’s usually BIG one and nobody notices because it’s just humming away processing stuff with little output.

An accountant might have access to 5 different clients accounts, they need to do their work. They can, with their brain, figure out which one they’re processing and keep them separate.

An AI with the same access via MCP might just decide to “quickly fix” the same issue in all 5 accounts to be helpful. Actually breaking 7 different laws in the process.

See the issue here?

(Yes the AI is approved for this use; that’s not the problem here)

Re: I still prefer MCP over skills

#292

Post by arondeparon »

theshrike79 wrote: post #271
tow21 wrote: post #114

This 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,…

[dead]

Re: I still prefer MCP over skills

#294

Post by radiospiel »

_pdp_ wrote: post #181
siva7 wrote: post #179

Earlier quoted context omitted.

> MCP adds friction, imagine doing yourself the work using the average MCP server. Why on earth don't people understand that MCP and skills are complementary concepts, why? If people argue over MCP v. Skills they clearly don't understand either deeply.

I won't be surprised if MCP start shipping skills. They already ship prompts and other things exposed as resources. It is not even difficult to do with the current draft as skills can be exposed by convention without protocol changes. Future version of the protocol can easily expose skills so that MCPs can acts like hubs.

Doesn't it already? https://modelcontextprotocol.io/specification/2025-11-25/ser...

Re: I still prefer MCP over skills

#295

Post by socketcluster »

I prefer skills with simple curl commands. It's easy. You just need to create a server with HTTP endpoints and Claude (or other LLM) can call them with the curl commands you provide in your skills files. Claude is really good with curl and it's a well known HTTP client so what Claude is doing is more transparent to the user.

Also, with skills, you can organize your files in a hierarchy with the parent page providing the most general overview and each child page providing a detailed explanation of each endpoint or component with all possible parameters and errors. I also made a separate page where I list all the common issues for troubleshooting. It works very well.

I created some skills for my no-code platform so that Claude could access and make changes to the control panel via HTTP. My control panel was already designed to update in real-time so it's cool to watch it update as Claude creates the schema and adds dummy data in the background.

I spent a huge amount of effort on refining my HTTP API to make it as LLM-friendly as possible with flexible access control.

You can see how I built my skills marketplace from the docs page if anyone is interested: https://saasufy.com/

Re: I still prefer MCP over skills

#296

Post by bitexploder »

brabel wrote: post #192
noodletheworld wrote: post #164

Earlier quoted context omitted.

> MCP is the absolute best and most effective way to integrate external tools into your agent sessions Nope. The best way to interact with an external service is an api. It was the best way before, and its the best way now. MCP doesn't scale and it has a bloated unnecessarily complicated spec. Some MCP servers are good; but in general a new bad way of interacting with external services, is not the best way of doing i…

You haven’t actually done that have you. If you did, you would immediately understand the problems MCP solves on top of just trying to use an API directly: - easy tool calling for the LLM rather than having to figure out how to call the API based on docs only. - authorization can be handled automatically by MCP clients. How are you going to give a token to your LLM otherwise?? And if you do, how do you ensure it does…

An authnz aware egress proxy that also puts guard rails on MCP behavior?

Re: I still prefer MCP over skills

#297

Post by mbesto »

prohobo wrote: post #138
antirez wrote: post #108

Don'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…

The way I see it is more like this:

- Skills help the LLM answer the "how" to interact with API/CLIs from your original prompt

- API is what actually sends/receives the interaction/request

- CLI is the actual doing / instruct set of the interaction/request

- MCP helps the LLM understand what is available from the CLI and API

They are all complementary.

Re: I still prefer MCP over skills

#298

Post by _pdp_ »

radiospiel wrote: post #294
_pdp_ wrote: post #181

Earlier quoted context omitted.

I won't be surprised if MCP start shipping skills. They already ship prompts and other things exposed as resources. It is not even difficult to do with the current draft as skills can be exposed by convention without protocol changes. Future version of the protocol can easily expose skills so that MCPs can acts like hubs.

Doesn't it already? https://modelcontextprotocol.io/specification/2025-11-25/ser...

these are prompts - similar yes - but not the same

Re: I still prefer MCP over skills

#299

Post by pjm331 »

theshrike79 wrote: post #276
jjice wrote: post #274

Earlier quoted context omitted.

> In an organisation we can’t limit MCP access. Why not? I'd imagine that you could grant specific permissions upon MCP auth. Is the issue that the services you're using don't support those controls, or is it something else?

I haven’t seen a single major MCP provider that would let us limit access properly Miro, Linear, Notion etc… They just casually let the MCP do anything the user can and access everything. For example: Legal is never letting us connect to Notion MCP as is because it has stuff that must NEVER reach any LLM even if they pinky swear not to train with our stuff. -> thus, hard deterministic limits are non-negotiable.

it's straightforward to spin up a custom MCP wrapper around any API with whatever access controls you want

the only time i reach for official MCP is when they offer features that are not available via API - and this annoys me to no end (looking at you Figma, Hex)

Re: I still prefer MCP over skills

#300

Post by 0xbadcafebee »

I have vibe-coded 4 different software projects recently, on multiple platforms. I added search, RAG, ticketing, notifications, voice, and more features to them, in 2 minutes. All I had to do was implement MCP client, and suddenly all that other complex functionality "just worked", both locally and remotely.

Skills would have required me to 1) add all the skill files to all those projects (and maintain all those files), and 2) install software tools (some of these tools don't have CLIs) to be usable by the skills. Not to mention: the skills aren't deterministic! You have to iterate on a skill file for a while to get the LLM to reliably use it the way you want.

Post reply on HN