Live data from Hacker News

When does MCP make sense vs CLI?

ejholmes.github.io

181–190 of 301 posts

Re: When does MCP make sense vs CLI?

#181
post #165

Earlier quoted context omitted.

I always get a kick out of seeing MCP wrappers around CLI’s.

They make a big difference. For example if you use the Jira cli, most LLMs aren’t trained on it. A simple MCP wrapper makes a huge difference in usability unless you’re okay having the LLM poke and prod a bunch of different commands

Do you mean wrap the CLI with an MCP? I don't get that approach. I wrapped the Jira cli with a skill. It's taken a few iterations to dial it in but it works pretty damn well now.

I'm good, yet my coworkers keep having problems using the Atlassian MCP.

Re: When does MCP make sense vs CLI?

#182
Recently, I was wondering why http API don’t make use of the body of a http OPTIONS query to discover what an endpoint does.

It’s easy enough to send back the openapi definition for that endpoint only.

Also, when calling an endpoint, instead of a simple 404, we could have a 303 see others, or short description of all available endpoints

Re: When does MCP make sense vs CLI?

#183

There is nothing wrong with MCP, it's just that stdio MCP was overengineered. MCP's Streamable HTTP with OAuth discovery is the best way to ship AI integration with your product nowadays. CLIs require sandboxing, doesn't handle auth in a standard way and it doesn't integrate to ChatGPT or Claude. Look at Sentry, they just ship a single URL https://mcp.sentry.dev/mcp and you don't need anything else. All agents that s…

Could you expand on this some more? I'm not quite following.

I agree with the sandboxing challenge of a CLI, although I think any CLI (or MCP) wrapping an http API should be subject to a sane permissioning system that's a first class concept in the API itself. That's in my opinion the correct way to limit what different users/tools/agents can do.

But I don't fully understand the Streamable HTTP point.

Re: When does MCP make sense vs CLI?

#186

> I tried to avoid writing this for a long time, but I'm convinced MCP provides no real-world benefit IMO this is 100% correct and I'm glad someone finally said it. I run AI agents that control my entire dev workflow through shell commands and they are shockingly good at it. the agent figures out CLI flags it has never seen before just from --help output. meanwhile every MCP server i've used has been a flaky process…

How do you segregate the CLI interface the LLM sees versus a human? For example if you’d like the LLM to only have access to read but not write data. One obvious fix is to put this at the authz layer. But it can be ergonomic to use MCP in this case.

I've been running Claude Code in a Docker compose environment with two containers - one without Claude that has all the credentials setup and a Claude container which transparently executes commands via ssh. The auth container then has wrappers which explicitly allow certain subcommands (eg. `gh api` isn't allowed). The `gh` command in the Claude container is just a wrapper script which bassically `ssh auth-container gh-wrapper`.

Lots of manual, opinionated stuff in here, but it prevents Claude from even accessing the credentials and limits what it can do with them.

Re: When does MCP make sense vs CLI?

#187
post #173
post #130

Earlier quoted context omitted.

I avoid most MCPs. They tend to take more context than getting the LLM to script and ingest ouputs. Trying to use JIRA MCP was a mess, way better to have the LLM hit the API, figure out our custom schemas, then write a couple scripts to do exactly what I need to do. Now those scripts are reusable, way less context used. I don't know, to me it seems like the LLM cli tools are the current pinnacle. All the LLM companie…

For Jira/Confluence, I also struggled with their MCPs. JIRA’s MCPs was hit or miss and Confluence never worked for me. We don’t use the cloud versions, so not sure if they work better with cloud. On the other hand, i found some unofficial CLIs for both and they work great. I wrote a small skill just to give enough detail about how to format Epics, Stories, etc and then some guidance on formatting content and I can ge…

I deal with a ton of different atlassian instances and the most infuriating thing to me about the mcp configuration is that atlassian really thinks you should only have one atlassian instance to auth against. Their mcp auth window takes you to a webpage where you can’t see which thing you are authoring against forcing you to paste the login page url into an incognito window. Pretty half baked implementation.

I noticed that it’s better for some things than others. It’s pretty bad at working with confluence it just eats tokens but if you outlay a roadmap you want created or updated in Jira it’s pretty good at that

Re: When does MCP make sense vs CLI?

#188

The problem with CLIs is that unless it's a super well documented CLI like `gh`, the LLM will have a hard time figuring out how to use it from `--help` alone unless it's a really simple tool. If you want to do something complex, like create a JIRA issue, you either need to put the full issue schema in `--help` so that the LLM knows how to pass an issue or else you can use MCP which bakes tool schemas into the protoco…

That's easily solved by wrapping it in a skill. And every time it fails, once you are done you ask it to update the skill with what it learned. A couple iterations later and it will be solid.

Re: When does MCP make sense vs CLI?

#189
post #127

Earlier quoted context omitted.

Im still struggling with understanding when MCP works better. I move everything to cli after a while. Can you give me more concrete examples? Because I don’t doubt you, I just don’t understand.

Most APIs and CLIs are not setup with clear separation of permissions, and when they have those permissions are mostly designed around human access patterns and risks, not LLM ones. The primary example of course being read-only vs write access. MCPs have provided any easy way to side-step that baggage. e.g. in an MCP, you have tools, those tools are usually binned into "read" vs "write". Given that, I can easily conf…

That makes some sense. But one can make the argument given how easy it is to create CLI tools and add new API endpoints, enhancing them is still a better approach than creating and MCP.

I'm not pro or anti-MCP myself. I just haven't had a lot of success using them yet. I've been struggling to find the right balance and every path has lead me to a CLI tool (optionally paired with a skill).

Now I'm not using my cli tools in Claude Chat proper, but I'm not using MCPs either because they just keep failing me. This could very well be a me problem, but I'm still looking for that "ah-ha" moment.

Maybe I'm misunderstanding you, but the way you describe MCP sure sounds like it's just another RPC endpoint. Those are easy to add using traditional methods. Why deal with all the overhead of MCP for those cases?

Re: When does MCP make sense vs CLI?

#190
Even for Openclaw, the response API is a better way to interact with it adhoc. I tell Cursor how to contact OC with a bearer key, and they work things out in the background when I'm building something for Openclaw.
Post reply on HN