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

181–190 of 415 posts

Re: I still prefer MCP over skills

#181

Post by _pdp_ »

siva7 wrote: post #179
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…

> 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.

Re: I still prefer MCP over skills

#182

Post by insin »

siva7 wrote: post #179
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…

> 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.

The more things change in tech, the more they stay the same.

The shoe is the sign. Let us follow His example!

Cast off the shoes! Follow the Gourd!

Re: I still prefer MCP over skills

#184

Post by noodletheworld »

prohobo wrote: post #180
frotaur wrote: post #175

Earlier quoted context omitted.

Why couldn't the calendar app expose in an API the read_calendar and update_calendar functionalities, and have a skill 'use_calendar' that describes how to use the above? Then, the minimal skill descriptions are always in the model's context, and whenever you ask it to add something to the calendar, it will know to fetch that skill. It feels very similar to the MCP solution to me, but with potentially less bloat and…

Why would I do that if the MCP already handles it? The MCP exposes the API with those tools, it explains what the calendar app is and when to use it. Connected MCP tools are also always in the model's context, and it works for any AI agent that supports MCP, not just Claude Code.

> The MCP exposes the API with those tools, it explains what the calendar app is

So does an API and a text file (or hell, a self describing api).

Which is more complex and harder to maintain, update and use?

This is a solved problem.

The world doesnt need MCP to reinvent a solution to it.

If we’re gonna play the ELI5 game, why does MCP define a UI as part of its spec? Why does it define a bunch of different resource types of which only tools are used by most servers? Why did not have an auth spec at launch? Why are there so many MCP security concerns?

These are not idle questions.

They are indicative of the “more featurrrrrres” and “lack of competence” that went into designing MCP.

Agents, running a sandbox, with normal standard rbac based access control or, for complex operations standard stateful cli tooling like the azure cli are fundamentally better.

Re: I still prefer MCP over skills

#185

Post by kohlerm »

Yeah well. MCPs are better for use cases where remote access is required, but for development use cases what you need in the majority of use cases is to manipulate local files. Skills are just the more natural solution here. You can argue whether Skills should come with more type information (MCPs are slightly better here), but otherwise it seems pretty clear to me that if you do not need remote access then MCPs are not really needed.

Re: I still prefer MCP over skills

#186

Post by prohobo »

noodletheworld wrote: post #184
prohobo wrote: post #180

Earlier quoted context omitted.

Why would I do that if the MCP already handles it? The MCP exposes the API with those tools, it explains what the calendar app is and when to use it. Connected MCP tools are also always in the model's context, and it works for any AI agent that supports MCP, not just Claude Code.

> The MCP exposes the API with those tools, it explains what the calendar app is So does an API and a text file (or hell, a self describing api). Which is more complex and harder to maintain, update and use? This is a solved problem. The world doesnt need MCP to reinvent a solution to it. If we’re gonna play the ELI5 game, why does MCP define a UI as part of its spec? Why does it define a bunch of different resource…

How would the AI know about the calendar app unless you make the text file and attach it to the session?

Self-describing APIs require probing through calls, they don't tell you what you need to know before you interact with them.

MCP servers are very simple to implement, and the developers of the app/service maintain the server so you don't have to create or update skills with incomplete understanding of the system.

Your skill file is going to drift from the actual API as the app updates. You're going to have to manage it, instead of the developers of the app. I don't understand what you're even talking about.

Re: I still prefer MCP over skills

#188

Post by rd42 »

I think the key problem is that usage of MCP servers is not 'baked' into the LLM training - but API's and CLI's are already a part of training. So to use your MCP server, the LLM has to use additional intelligence which could have been used to do the actual work instead.

Re: I still prefer MCP over skills

#189

Post by noodletheworld »

prohobo wrote: post #186
noodletheworld wrote: post #184

Earlier quoted context omitted.

> The MCP exposes the API with those tools, it explains what the calendar app is So does an API and a text file (or hell, a self describing api). Which is more complex and harder to maintain, update and use? This is a solved problem. The world doesnt need MCP to reinvent a solution to it. If we’re gonna play the ELI5 game, why does MCP define a UI as part of its spec? Why does it define a bunch of different resource…

How would the AI know about the calendar app unless you make the text file and attach it to the session? Self-describing APIs require probing through calls, they don't tell you what you need to know before you interact with them. MCP servers are very simple to implement, and the developers of the app/service maintain the server so you don't have to create or update skills with incomplete understanding of the system.…

[flagged]

Re: I still prefer MCP over skills

#190

Post by throwup238 »

linkregister wrote: post #75
Aperocky wrote: post #42

Earlier 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 is a wrapper around it. The CLI-daemon RPC pattern is much older and is used all over the place in modern systems.
Post reply on HN