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

91–100 of 415 posts

Re: I still prefer MCP over skills

#91

Post by stingraycharles »

notpushkin wrote: post #79
stingraycharles wrote: post #74

Earlier quoted context omitted.

I often just put direct curl commands in a skill, the agent uses that, and it works perfectly for custom API integrations. Agents are perfectly capable of doing these types of things, and it means the LLM just uses a flexible set of tools to achieve almost anything.

I think this is the best of both worlds. Design a sane API (that is easy to consume for both humans and agents), then teach the agents to use it with a skill. But I agree with the author on custom CLI tooling. I don’t want to install another opaque binary on my machine just to call some API endpoints.

Obviously opaque binaries are hardly an improvement over MCP, but providing a few curl + jq oneliners to interact with a REST API works great in my experience. Also means no external scripts, just a single markdown file.

Re: I still prefer MCP over skills

#92

Post by olalonde »

Aperocky wrote: post #38

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

That's "Worse is better" rather than "Occam's razor".

Re: I still prefer MCP over skills

#94

Post by insin »

notpushkin wrote: post #81
oblio wrote: post #71

Earlier quoted context omitted.

Does MCP support authentication, SSO?

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 tokens, so there's just a bit of light friendly owl finishing on top.

Source: I just implemented this for our (F100) internal provider and model agnostic chat app. People can't seem to see past the coding agents they're running on their own machines when MCP comes up.

Re: I still prefer MCP over skills

#95

Post by gum_wobble »

nextaccountic wrote: post #90

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

Re: I still prefer MCP over skills

#97

Post by lifeisstillgood »

I agree for a slightly different reason - human stupidity.

Despite many decades of proof that automation simplifies and reveals the illogical in organisations, digitisation has mostly stopped at below the “CXO” level - and so there are not APIs or CLIs available to anyone - but MCP is cutting through

Just consider:

Throughout companies large and small, Agile is what coders do, real project managers still use deadlines and upfront design of what will be in the deadline - so any attempt to convert the whole company to react to the reality of the road is blocked

Reports flow upwards - but through the reporting chain. So those PowerPoints are … massaged to meet to correct story, and the more levels it’s massaged the more it fails to resemble reality. Everyone knows this but managing the transition means potentially losing control …

There are plenty of digitisationmprojects going on - but do they enable full automation or are they another case of an existing political arena building its own political choices in software - “our area in a database to be accessed via an UI by our people” - almost never “our area to be used by others via API and totally replacing our people”.

(I think I need to be more persuasive

Re: I still prefer MCP over skills

#98

Post by mathis-l »

nextaccountic wrote: post #90

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

At least when working with local MCP servers I solved this problem by wrapping the mcp tools inside an in-memory cache/store. Each tool output gets stored under a unique id and the id is returned with the tool output. The agent can then invoke other tools by passing the id instead of generating all the input. Adding attribute access made this pretty powerful (e.g. pass content under tool_return_xyz.some.data to tool A as parameter b). This saves token costs and is a lot faster. Granted, it only works for passing values between tools but I could imagine an additional tool to pipe stuff into the storage layer would solve this.

Re: I still prefer MCP over skills

#99

Post by yawnxyz »

woeirua wrote: post #62
yawnxyz wrote: post #24

Earlier quoted context omitted.

skills can have code bundled with them, including MCP code

The agent still doesn’t have an execution environment. It can’t execute the code!

well that's harness territory! give it the right harness/environment!!

Re: I still prefer MCP over skills

#100

Post by soco »

alierfan wrote: post #7

This isn't a zero-sum game or a choice of one over the other. They solve different layers of the developer experience: MCP provides a standardized, portable interface for external data/tools (the infrastructure), while Skills offer project-specific, high-level behavioral context (the orchestration). A robust workflow uses MCP to ensure tool reliability and Skills to define when and how to deploy those tools.

Also, the skills can be ignored or thwarted if the LLM feels like, while a policy at the MCP server level stays there.
Post reply on HN