I still prefer MCP over skills • Hacker News Board

Re: I still prefer MCP over skills

#351

Post by hadlock » Fri, Apr 10, 2026, 5:37 PM UTC

xyzzy123 wrote: post #202

prohobo wrote: post #159

Earlier quoted context omitted.

Right, that feels like something you'd do with a script and some API calls. MCP is more for a back and forth communication between agent and app/service, or for providing tool/API awareness during other tasks. Like MCP for Jira would let the AI know it can grab tickets from Jira when needed while working on other things. I guess it's more like: the MCP isn't for us - it's for the agent to decide when to use.

I just find that e.g. cli tools scale naturally from tiny use cases (view 1 ticket) to big use cases (view 1000 tickets) and I don't have to have 2 ways of doing things. Where I DO see MCPs getting actual use is when the auth story for something (looking at you slack, gmail, etc) is so gimped out that basically, regular people can't access data via CLI in any sane or reasonable way. You have to do an oauth dance invo…

>while ensuring you can't do inconvenient things like say, bulk exporting your own data

I think this is the key; I want my analysts to be able to access 40% of the database they need to do their job, but not the other 60% parts that would allow them to dump the business-secrets part of the db, and start up business across the street. You can do this to some extent with roles etc but MCP in some ways is the data firewall as your last line of protection/auth.

Re: I still prefer MCP over skills

#352

Post by mikemiles » Fri, Apr 10, 2026, 5:40 PM UTC

[dead]

Re: I still prefer MCP over skills

#353

Post by localhost3000 » Fri, Apr 10, 2026, 5:46 PM UTC

How I think about this:

If you're using an agent in a shell environment with unfettered internet access and code execution: CLI + Skills.

If you're using a hosted agent on a website or in an app without code execution and limited/no internet access: MCP.

We want both patterns. Folks who are agro about MCP do ~all of their work in the former, so it seems pointless. Most people interact with agents in the later.

Re: I still prefer MCP over skills

#354

Post by prohobo » Fri, Apr 10, 2026, 5:56 PM UTC

throwanem wrote: post #341

prohobo wrote: post #333

Earlier quoted context omitted.

Just give us a taste of what we'd be paying for? I'm sure you're an expert but before I commit to 2+ years of consultation I'd like to see your approach.

I've already pointed this out as the silly, purposeless argument it's become. (Or more become.) Even I at this point can't figure out who is advocating what or why, other than for the obvious ego reasons. You're bikeshedding at each other and wasting all the time and effort it requires, because no one else is enjoying it any more than you two are: if anything you have left your audience more confused than we began, b…

I don't get it, you joined this thread to call me an idiot with a meme, and now you're talking about being a neutral arbiter for a technical discussion that I supposedly ruined.

More than anything I'm getting frustrated with HN discussions because people just insinuate that I'm stupid instead of making substantive arguments reasoning how what I'm saying is wrong.

Are we performing for an audience or having a discussion?

Re: I still prefer MCP over skills

#355

Post by bloppe » Fri, Apr 10, 2026, 6:03 PM UTC

Every CLI can be expressed as an API and vice versa. Thus every skill can be expressed as an MCP server and vice versa. Any argument about the technical or practical merits of one over the other is willfully ignoring the fact that you can always use exactly the same patterns in one vs. the other.

So it's really all about availability or preference. Personally, I don't think we needed a whole new standard with all its complexities and inevitable future breaking changes etc.

Re: I still prefer MCP over skills

#356

Post by [deleted] » Fri, Apr 10, 2026, 6:07 PM UTC

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…

[deleted]

Re: I still prefer MCP over skills

#357

Post by CuriouslyC » Fri, Apr 10, 2026, 6:14 PM UTC

Eldodi wrote: post #313

CuriouslyC wrote: post #231

Earlier quoted context omitted.

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" -> not true anymore with Tool_search. The progressive discovery and context bloat issue of MCP was a MCP Client implementation issue, not a MCP issue. "MCPs needs to be wrapped to be composed." -> Also not true anymore, Claude Code or Cowork can chain MCP calls, and any agent using bash can also do it with mcpc "MCPs needs to implement stateful behavior, shell + cli gives it to y…

Just to poke some holes in this in a friendly way:

* What algorithm does tool_search use?

* Can tool_search search subcommands only?

* What's your argument for a harness having a hacked in bash wrapper nestled into the MCP to handle composition being a better idea than just using a CLI?

* Shell + CLI gives you basically infinite workflow possibilities via composition. Given the prior point, perhaps you could get a lot of that with hacked-in MCP composition, but given the training data, I'll take an agent's ability to write bash scripts over their ability to compose MCPs by far.

Re: I still prefer MCP over skills

#358

Post by troupo » Fri, Apr 10, 2026, 6:17 PM UTC

CuriouslyC wrote: post #242

prohobo wrote: post #235

Earlier quoted context omitted.

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

If you have an API with thousands of endpoints, that MCP description is going to totally rot your context and make your model dumb, and there's no mechanism for progressive disclosure of parts of the tool's abilities, like there is for CLIs where you can do something like: tool --help tool subcommand1 --help tool subcommand2 --help man tool | grep "thing I care about" As for stateful behavior, say you have the google…

> like there is for CLIs where you can do something like

Well, these will fail for a large amount of cli tools. Any and all combinations of the following are possible, and not all of them will be available, or work at all:

    tool                    some tools may output usage when no arguments are supplied
    tool -h                 some tools may have a short switch for help
    tool --help             some tools may have a long switch for help
    tool help               some tools may have help as a subcommand
    tool command            some tools may output usage for a command with no arguments
    tool command -h         some tools may have a short switch for command help
    tool command --help     some tools may have a long switch for command help
    tool help command       some tools may have a help command
    man tool                some tools may have man pages

examples:

    grep                    one-line usage and "type grep --help"
    grep -h                 one-line usage and "type grep --help"
    grep --help             extended usage docs
    man grep                very extended usage docs


    python                  starts interactive python shell
    python -h
    python --help           equivalent help output


    ps                      short list of processes
    ps -h                   longer list of processes
    ps --help               short help saying you can do, for example, `ps --help a`
    ps --help a             gives an extended help, nothing about a

    erl                     
    erl -h
    erl --help              all three start Erlang shell
    man erl                 No manual entry for erl

etc.

Not to say that MCPs are any better. They are written by people, after all. So they are as messy.

Re: I still prefer MCP over skills

#359

Post by throwanem » Fri, Apr 10, 2026, 6:21 PM UTC

prohobo wrote: post #354

throwanem wrote: post #341

Earlier quoted context omitted.

I've already pointed this out as the silly, purposeless argument it's become. (Or more become.) Even I at this point can't figure out who is advocating what or why, other than for the obvious ego reasons. You're bikeshedding at each other and wasting all the time and effort it requires, because no one else is enjoying it any more than you two are: if anything you have left your audience more confused than we began, b…

I don't get it, you joined this thread to call me an idiot with a meme, and now you're talking about being a neutral arbiter for a technical discussion that I supposedly ruined. More than anything I'm getting frustrated with HN discussions because people just insinuate that I'm stupid instead of making substantive arguments reasoning how what I'm saying is wrong. Are we performing for an audience or having a discussi…

I can't make heads nor tails of anyone's position in this mess, precisely because of its devolution into everyone yelling at one another. Yours happened to be the tail comment on this branch at the time I posted. Don't take it more personally than it was meant.

I understand why this website doesn't have DMs except among YC founders. But if it were otherwise, I'd have DMed you instead of posting that first comment publicly. The criticism I remain convinced has merit, but such things are better done in private. If I chose to make an example out of you over the other guy, it was because you looked like offering a better chance than he of redirecting this into the kind of discussion from which someone could conceivably learn something.

Re: I still prefer MCP over skills

#360

Post by pizzafeelsright » Fri, Apr 10, 2026, 6:22 PM UTC

1minusp wrote: post #302

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…

Feels to me like the toolchain for using LLMs in various tasks is still in flux (i interpret all of this as "stuff in different places like .md or skills or elsewhere that is appended to the context window" (i hope that is correct)). Shouldnt this overall process be standardized/automated? That is, use some self-reflection to figure out patterns that are then dumped into the optimal place, like a .md file or a skill?

The entire tooling ecosystem is in flux.

Looking forward, the future is ad-hoc disposable software that once would take a large team a dozen sprints to release.

Eventually it'll be use case -> spec -> validation -> result.

The tv show Stargate showed different controls that scientifically calculated and operated starships so all the operator had to do was point the controls in the direction of the destination. The ai/computer/hardware knows how to get to the result and that result is human driven.

I have evidence of this at work and in my own life with the key component being the tooling integration.