This would be awesome, but great CLIs would have already been valuable prior to the age of LLMs and yet most services didn't ship one. I think it is because services like Jira and others do not want to be too open. Ultimately, despite the current LLM/MCP craze, I think this won't change and MCP tools will start getting locked down and nerfed somehow, the same way APIs have in not so recent memory after there being a bit of a craze around those a decade+ back.

▲

xnorswap 12 hours ago | parent | next [-]

I agree with your conclusion that this stuff will get locked down again over time.

I think there's also another major reason people don't like to ship desktop software, and that's the cost of support of dealing with outdated tools, it can be immense.

Ticket as raised, "Why is my <Product> broken?"

After several rounds of clarification, it's established they're using a 6-year old version that's hitting API endpoints that were first deprecated 3 years ago and finally now removed...

It's incredibly expensive to support multiple versions of products. On-prem / self host means you have to support several, but at least with web products it's expected they'll phone-home and nag to be updated and that there'll be someone qualified to do that update.

When you add runnable executable tooling, it magnifies the issue of how old that tooling gets.

Even with a support policy of not supporting versions older than <X>, you'll waste a lot of customer support time dealing with issues only for it to emerge it's out-dated software.

▲

pferde 12 hours ago | parent | next [-]

If that took "several rounds of clarification", then the support they're paying for is worthless. Getting version of the application should be among the first bits of information collected, possibly even required for opening the ticket.

	▲	xnorswap 10 hours ago \| parent [-]
		You've never asked someone for a version and got back a version number for a completely different product? Obviously it depends on your audience, and 3 rounds is exaggerating for the worst case, but in previous places I've worked I've seen customer support requests where the first question that needed to be asked wasn't, "What version are you using?", it's "Are you sure this is our product you're using?". Actually getting version info out of that audience would have been at least an email explaining the exact steps, then possibly a follow up phone call to talk them through it and reassure them. If your reference is JIRA tickets or you're selling software to software developers, then you're dealing with a heavily filtered stream. Ask your CS team for a look at the unfiltered incoming mail, it might be eye-opening if you've not done it before. You might be surprised just how much of their time is spent covering the absolute basics, often to people who have had the same support multiple times before.

▲

bradgessler 12 hours ago | parent | prev [-]

A big problem with CLI tooling is it starts off seeming like it’s an easy problem to solve from a devs perspective. “I’ll just write a quick Go or Node app that consumes my web app’s API”

Fast forward 12-18 months, after several new features ship and several breaking API changes are made and teams that ship CLIs start to realize it’s actually a big undertaking to keep installed CLI software up-to-date with the API. It turns out there’s a lot of auto-updating infrastructure that has to be managed and even if the team gets that right, it can still be tricky managing which versions get deprecated vs not.

I built Terminalwire (https://terminalwire.com) to solve this problem. It replaces JSON APIs with a smaller API that streams stdio (kind of like ssh), and other commands that control browsers, security, and file access to the client.

It’s so weird to me how each company wants to ship their own CLI and auto-update infrastructure around it. It’s analogous to companies wanting to ship their own browser to consume their own website and deal with all the auto update infrastructure around that. It’s madness.

▲

linsomniac 10 hours ago | parent | prev | next [-]

I've had good luck with having Claude write little CLI tools that interact with Jira: "cases" prints out a list of my in-progress cases (including immediately printing a cached list of cases, then querying Jira and showing any stragglers), "other_changes" shows me tickets in this release that are marked with "Other changes" label, "new_release" creates a new release in Jira, our deployment database, and a script to run the release, etc...

I could imagine a subagent that builds a tool on demand when it's needed.

Claude is really good at building small tools like these.

▲

PanMan 2 hours ago | parent | prev | next [-]

Jira actually has both an MCP server and a CLI tool (called "acli"). I switched our claude code to the CLI (with a skill) from the MCP as it seems.. more efficient/quicker.

▲

ath92 14 hours ago | parent | prev | next [-]

Nobody shipped this because previously almost nobody could use CLI tools. Now you can just ask an llm to generate the commands which makes things much more accessible

	▲	gjvc 12 hours ago \| parent [-]
		"almost nobody"

▲

joshribakoff 10 hours ago | parent | prev | next [-]

The good news is that an llm will be really helpful in scraping your content locating alternative service providers or even creating your own solution so you can migrate away

▲

throwaway19268 10 hours ago | parent | prev [-]

CLI tools for online services like Jira etc. basically amount to an open and documented API which the attitude towards these probably unlikely to be changing anytime soon as you mention.