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

131–140 of 415 posts

Re: I still prefer MCP over skills

#131

Post by [deleted] »

insin wrote: post #94
notpushkin wrote: post #81

Earlier quoted context omitted.

It supports OAuth, IIRC. But I suppose the internal chatbot itself would require auth, and pass that down to the tools it calls.

The chatbot app initiates an OAuth flow, user SSOs, chatbot app receives tokens to its callback URL, then tool calls can access whatever the user can access. If you use the official MCP SDK, it has interfaces you implement for auth, so all you need to do is kick off the OAuth flow with a URL it figures out and hands you, storing the resulting tokens and producing them when requested. It also handles using refresh tok…

[deleted]

Re: I still prefer MCP over skills

#132

Post by walthamstow »

bikelang wrote: post #33
grensley wrote: post #15

The "only skills" people are usually non-technical and the "only CLI" people are often solo builders. MCP makes a lot of sense for enterprise IMO. Defines auth and interfaces in a way that's a natural extension of APIs.

I think many of us have been burned by the absolutely awful and unstable JIRA MCP and found that skills using `acli` actually work and view the rest of the MCP space thru that lens. Lots of early - and current! - MCP implementations were bad. So it’s an uphill battle to rebuild reputation.

`acli` doesn't cover Confluence and I found it limited compared to the MCP by sooperset on GitHub.

Re: I still prefer MCP over skills

#133

Post by EugeneOZ »

> Skills are great for pure knowledge and teaching an LLM how to use an existing tool. But for giving an LLM actual access to services, the Model Context Protocol (MCP) is the far superior

That's it. For some things you need MCP, for some things you need SKILLs - these things coexist.

Re: I still prefer MCP over skills

#134

Post by dgb23 »

usrbinbash wrote: post #86

> The core philosophy of MCP is simple: it’s an API abstraction. The LLM doesn’t need to understand the how; it just needs to know the what. Wrong. It needs to "understand" both these things. The only difference is where and how the strings explaining them are generated.

That's an important point.

Whether it's tools, MCP or skills: they are fundamentally all just prompts. Even if the LLM is trained to recognize those and produce the right shape of tokens that validate most of the time.

But I wouldn't use the word "understand" here, because that builds the wrong intuition. I think a more useful term would be "get guided by" or "get nudged by". Even "recognize" is slightly misleading, because it implies too much.

Re: I still prefer MCP over skills

#135

Post by ok_dad »

nostrebored wrote: post #59
ok_dad wrote: post #39

Earlier quoted context omitted.

MCP is an API with strictly defined inputs and outputs.

This is obviously not what it is. If I give you APIGW would you be able to implement an MCP server with full functionality without a large amount of middleware?

I’ve implemented an MCP tool calling client for my application, alongside OAuth for it. It was hard but no harder than anything else similar. I implemented a client for interference with the OpenAI API spec for general inference providers, and it was similarly as hard. MCP. SDKs help make it easy; MCP servers are dead simple. Clients are the hard part, IMO.

MCP is basically just an RPC API that uses HTTP and JSON, with some other features useful for AI agents today.

Re: I still prefer MCP over skills

#136

Post by ok_dad »

oblio wrote: post #71
ok_dad wrote: post #39

Earlier quoted context omitted.

MCP is an API with strictly defined inputs and outputs.

Does MCP support authentication, SSO?

Yes it’s literally just standard OAuth that’s defined in the MCP spec. I spent this week implementing an auth layer for my app’s MCP client gateway.

Re: I still prefer MCP over skills

#138

Post by prohobo »

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 persistent manner, and if that app provides an MCP server, use it.

- If you need to interact with an online service in a persistent manner, and if that app provides an MCP server, use it.

Whether the MCP server is implemented well is a whole other question. A properly configured MCP explains to the agent how to use it without too much context bloat. Not using a proper MCP for persistent access, and instead trying to describe the interaction yourself with skill files, just doesn't make any sense. The MCP owner should be optimizing the prompts to help the agent use it effectively.

MCP is the absolute best and most effective way to integrate external tools into your agent sessions. I don't understand what the arguments are against that statement?

Re: I still prefer MCP over skills

#139

Post by dgb23 »

robotobos wrote: post #2

Despite thinking this is AI-generated, I agree but everything has a caveat. Skills are good for instilling non-repeatable, yet intuitive or institutional knowledge. MCP’s are great for custom, repeatable tasks. After 5-10 runs of watching my LLM write the same exact script, I just asked it to hardcode the solution and make it a tool. The result is runs are way faster and repeatable.

I would go further than this. Call the script yourself (or via some other mechanism/program) and then give the results to the LLM.

The majority of processes don't need nearly as many decision making points as an agent could deal with and look somewhat like this:

1. gather raw information => script

2. turn it into structured data => script

3. produce an actionable plan => script/user/agent (depends)

4. validate the plan => user

5. narrow down the implementation workflow and the set of tools needed => user/agent

6. follow workflow iteratively => user/agent

Doesn't need to be this exact shape, but the lesson I learned is to quasi front load and structure as much as possible with scripts and data. That can be done with agent assistance as well, for example by watching it do the task, or a similar one, in freeform at first.

Re: I still prefer MCP over skills

#140

Post by anaisbetts »

bijowo1676 wrote: post #66

MCP pollutes the context, if you dont care about wasting context token for all MCP tools, go ahead and use MCP, but you should know that cli tool+skill can perfectly replace it with less token overhead and better matching due to skill's front matter

Sure but on the flip side, skills not being in context means that for many harnesses, the model simply never finds them. Whether MCP or Skills are "better" depends extremely heavily on the context management functionality of your harness because if you use a relatively naive harness (i.e. one that implements MCP and Skills in a straightforward way), MCPs will generally be more effective, especially if your model is local-only (i.e. dumb), but at the cost of context.
Post reply on HN