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

231–240 of 415 posts

Re: I still prefer MCP over skills

#231

Post by CuriouslyC »

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…

MCP is less discoverable than a CLI. You can have detailed, progressive disclosure for a CLI via --help and subcommands.

MCPs needs to be wrapped to be composed.

MCPs needs to implement stateful behavior, shell + cli gives it to you for free.

MCP isn't great, the main value of it is that it's got uptake, it's structured and it's "for agents." You can wrap/introspect MCP to do lots of neat things.

Re: I still prefer MCP over skills

#232

Post by 0x696C6961 »

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.

If Atlassian put out a horrible CLI tool, would your conclusion be that "CLIs are bad"?

Re: I still prefer MCP over skills

#233

Post by yunwal »

neya wrote: post #204
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…

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

Re: I still prefer MCP over skills

#234

Post by [deleted] »

gum_wobble wrote: post #95
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?

[deleted]

Re: I still prefer MCP over skills

#235

Post by prohobo »

CuriouslyC wrote: post #231
prohobo wrote: post #138

Earlier quoted context omitted.

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…

MCP is less discoverable than a CLI. You can have detailed, progressive disclosure for a CLI via --help and subcommands. MCPs needs to be wrapped to be composed. MCPs needs to implement stateful behavior, shell + cli gives it to you for free. MCP isn't great, the main value of it is that it's got uptake, it's structured and it's "for agents." You can wrap/introspect MCP to do lots of neat things.

"MCP is less discoverable than a CLI" - that doesn't make any sense in terms of agent context. Once an MCP is connected the agent should have full understanding of the tools and their use, before even attempting to use them. In order for the agent to even know about a CLI you need to guide the agent towards it - manually, every single session, or through a "skill" injection - and it needs to run the CLI commands to check them.

"MCPs needs to implement stateful behavior" - also doesn't make any sense. Why would an MCP need to implement stateful behavior? It is essentially just an API for agents to use.

Re: I still prefer MCP over skills

#236

Post by CharlieDigital »

One thing that I have found is that the platforms are surprisingly poor at consistently implementing MCP, which is actually a pretty simple protocol.

Take Codex, for example, it does not support the MCP prompts spec[0][1] which is quite powerful because it solves a lot of friction with deploying and synchronizing SKILL.md files. It also allows customization of virtual SKILL.md files since it allows compositing the markdown on the server.

It baffles me why such a simple protocol and powerful capability is not supported by Codex. If anyone from OpenAI is reading this, would love to understand the reasoning for the poor support for this relatively simple protocol.

[0] https://github.com/openai/codex/issues/5059

[1] https://modelcontextprotocol.io/specification/2025-06-18/ser...

Re: I still prefer MCP over skills

#237

Post by insin »

losvedir wrote: post #211
insin wrote: post #176

Earlier quoted context omitted.

You can make it compose by also giving the agent the necessary tools to do so. I encountered a similar scenario using Atlassian MCP recently, where someone needed to analyse hundreds of Confluence child pages from the last couple of years which all used the same starter template - I gave the agent a tool to let it call any other tool in batch and expose the results for subsequent tools to use as inputs, rather than d…

But in the context of this discussion, Atlassian has a CLI tool, acli. I'm not quite following why that wouldn't have worked here. As a normal CLI you have all the power you need over it, and the LLM could have used it to fetch all the relevant pages and save to disk, sample a couple to determine the regular format, and then write a script to extract out what they needed, right? Maybe I don't understand the use case…

Not all agents are running in your CLI or even in any CLI, which is why people are arguing past each other all over the topic of MCP.

I implemented this in an agent which runs in the browser (in our internal equivalent of ChatGPT or Claude's web UI), connecting directly to Atlassian MCP.

Re: I still prefer MCP over skills

#238

Post by insin »

__alexs wrote: post #223
insin wrote: post #176

Earlier quoted context omitted.

You can make it compose by also giving the agent the necessary tools to do so. I encountered a similar scenario using Atlassian MCP recently, where someone needed to analyse hundreds of Confluence child pages from the last couple of years which all used the same starter template - I gave the agent a tool to let it call any other tool in batch and expose the results for subsequent tools to use as inputs, rather than d…

The agent cannot compose MCPs. What it can do is call multiple MCPs, dumping tons of crap into the context and then separately run some analysis on that data. Composable MCPs would require some sort of external sandbox in which the agent can write small bits of code to transform and filter the results from one MCP to the next.

At the level of the agent, it knows nothing about MCP, all it has is a list of tools. It can do anything the tools you give it let it do.

Re: I still prefer MCP over skills

#239

Post by CuriouslyC »

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.

CLIs are technically better for a number of reasons.

If an enterprise already has internal tooling with authn/z, there's no reason to overlay on top of that.

MCPs main value is as a structured description of an agent-usable subset of an API surface with community traction, so you can expect it to exist, be more relevant than the OpenAPI docs.

Post reply on HN