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 working in a range of environments which need controls and management, do you have a more defensive risk tolerance ... then by the time you wrap CLIs into a form that are suitable you will have reinvented a version of the MCP protocol. You might as well just use MCP in the first place.

Aside - yes, MCP in its current iteration is fairly greedy in its context usage, but that's very obviously going to be fixed with various progressive-disclosure approaches as the spec develops.

We can trust humans not to do stupid things. They might accidentally delete maybe two items by fat-fingering the UI.

An Agent can delete a thousand items in a second while doing 30 other things.

With bespoke CLI tools we can configure them so that they cannot access anything except specific resources, limiting the possible blast radius considerably.

Why not? I'd imagine that you could grant specific permissions upon MCP auth. Is the issue that the services you're using don't support those controls, or is it something else?

Miro, Linear, Notion etc… They just casually let the MCP do anything the user can and access everything.

For example: Legal is never letting us connect to Notion MCP as is because it has stuff that must NEVER reach any LLM even if they pinky swear not to train with our stuff.

-> thus, hard deterministic limits are non-negotiable.

the only time i reach for official MCP is when they offer features that are not available via API - and this annoys me to no end (looking at you Figma, Hex)

I needed to access Github CI logs. I needed to write Jira stories. I didn't even bother glancing at any of the several existing MCP servers for either one of them - official or otherwise. It was trivial to vibe code an MCP server with precisely the features I need, with the appropriate controls.

Using and auditing an existing 3rd party MCP server would have been more work.

MCP provides you a clear abstracted structure around which you can impose arbitrary policy. "identity X is allowed access to MCP tool Y with reference to resource pool Z". It doesn't matter if the upstream MCP service provides that granularity or not, it's architecturally straightforward to do that mapping and control all your MCP transactions with policies you can reason about meaningfully.

CLI provides ... none of that. Yes, of course you can start building control frameworks around that and build whatever bespoke structures you want. But by the time you have done that you have re-invented exactly the same data and control structures that MCP gives you.

"Identity X can access tool Y with reference to resource pool Z". That literally is what MCP is structured to do - it's an API abstraction layer.

I have a configuration file that defines the exact resources the CLI can access. It programmatically checks and blocks access to any resource that's not whitelisted. There's no way for the Agent to get around that without some major fuckery.

The problem with your MCP example is that Identity X has access to most of the data, because humans need that. But when an agent uses MCP with Identity X credentials we need to be able to deterministically block it from accessing anything but very specific resources.

I can definitely delete a thousand items with a typo in my bash for loop/pipe. You should always defend against stupid or evil users or agents. If your documents are important, set up workflows and access to prevent destructive actions in the first place. Not every employee needs full root access to the billing system; they need readonly access to their records at most.

If people accidentally delete stuff, they tend to notice it and we can roll back. If an agent does a big whoops, it’s usually BIG one and nobody notices because it’s just humming away processing stuff with little output.

An accountant might have access to 5 different clients accounts, they need to do their work. They can, with their brain, figure out which one they’re processing and keep them separate.

An AI with the same access via MCP might just decide to “quickly fix” the same issue in all 5 accounts to be helpful. Actually breaking 7 different laws in the process.

See the issue here?

(Yes the AI is approved for this use; that’s not the problem here)

Over the last few months, this pattern of discussion has become pervasive on HN.

Point.

Counterpoint.

(Not finding a flaw with the counterpoint) "Yeah, but most people aren't smart enough to do it right."

I see it in every OpenClaw thread. I see it here now.

I also saw it when agents became a thing ("Agents are bad because of the damage they can do!") - yet most of us have gotten over it and happily use them.

If your organization is letting "regular non-technical" people download/use 3rd party MCPs without understanding the consequences, the problem isn't with MCP. As others have pointed out in this thread, you can totally have as secure an MCP server/tool as a sandboxed CLI.

Having said that, I simply don't understand yours (and most of others') examples on how CLI is really any different. If the CLI tool is not properly sandboxed, it's as damaging as an unsecured MCP. Most regular non-technical people don't know how to sandbox. Even where I work, we're told to run certain agentic tools in a sandboxed environment. Yet they haven't set it up to prevent us from running the tools without the sandbox. If my coworker massively screws up, does it make sense for me to say "No, CLI tools are bad!"?

I _can_ make a custom CLI, a custom MCP wrapper and whatever else to limit the things agents can access. But why do I need to? Am I the only one in the world who doesn't want to let ChatGPT run wild on our internal Notion without any hard limitations? We pay them ungodly amounts every month for the service and basic safeties aren't included unless we build them in.

KPT is a language app specifically targeted at explainable verb conjugation for highly inflected/agglutinative languages. Currently works for Finnish, Ukrainian, Welsh, Turkish and Tamil.

These are really hard languages to learn for most speakers of European languages, particularly English - we're not used to complex verb conjugations, they're hard to memorise and the rules often feel quite arbitrary. Every other conjugation practice app just tells you right/wrong with no explanation, which doesn't really help you learn when there are literally hundreds of rules to get right.

The interesting part was using an LLM to create a complete machine-executable set of conjugation rules, which are optimized for human explainability, and an engine to diagnose which rule is at fault when you get it wrong. There's several hundred rules needed for each language in order to cover all exceptions.

NB as a bonus it also works fully offline because my best practice hours are when I'm travelling and have poor connectivity.

How do you see yourself against someone like delve.co?

What I'm trying to do differently is depth of context. Humadroid learns about your company first - how you operate, your stack, your processes. From there it generates control descriptions that are actually actionable for your setup, and policies that need minimal review rather than a full rewrite.

Whether that's enough differentiation? Ask me in a year.

Seems an odd omission for a ruggedised outside modem - the Unifi also seems to not support external antennae.

(I'd also prefer a unifi version just so it fits in the with rest of the networking infra I have in the mökki.)

If you mean the standard routers (like the Rutx50), Teltonika itself sells external enclosures with antennas. https://www.teltonika-networks.com/products/accessories/ante...

Seems weird to cripple the product by not allowing me to (optionally) disable the internal antenna and instead use and tune an external antenna. And I suspect that is likely to make a difference when you are on the edge of coverage, but you know exactly where the relevant cell tower is, a few km away.

Azure is a product all right, but there’s nothing particularly better there than anywhere else.

They are one of the few companies actually making money with AI as they have intelligently leveraged the position of Office 365 in companies to sell Copilot. Their AI investment plans are, well, plans which could be scaled down easily. Worst case scenario for them is their investment in OpenAI becoming worthless.

It would hurt but is hardly life threatening. Their revenue driver is clearly their position at the heart of entreprise IT and they are pretty much untouchable here.

And even then, if that happens when the bubble pops, they'll likely just acquire OpenAI on the cheap. Thanks to the current agreement, it already runs on Azure, they already have access to OpenAI's IP, and Microsoft has already developed all their Copilots on top of it. It would be near-zero cost for Microsoft at that point to just absorb them and continue on as they are today.

Microsoft isn't going anywhere, for better or for worse.

Despite them pissing off users with Windows, what HN forgets, is they aren't Microsoft's customer. The individual user/consumer never was. We may not want what MS is selling, but their enterprise customers definitely do.

Google is only place that serves the enterprise (Workspace for productivity, Cloud for IT, Devices for end users) AND conducts meaningful AI research.

AWS doesn't (they can sell cloud effectively, but don't have any meaningful in-house AI R&D), Meta doesn't (they don't cover enterprise and, frankly, nobody trusts Zuck... and they're flaky.

Oracle doesn't. They have grown their cloud business rapidly by 1) easy button for Oracle on-prem to move to OCI, and 2) acting like a big colo for bare metal "cloud" infra. No AI.

Open AI has fundamental research and is starting to have products, but it's still niche. Same as Anthropic. They're not in the same ball game as the others, and they're going to continue to pay billions to the hyperscalers annually for infra, too.

This is Google's game to lose, imho, but the biggest loser will be AWS (not Azure/Microsoft).

Tesla (P/E: 273, PEG: 16.3) the car maker without robots, robotaxis is less than 15% of the Tesla valuation at best. When the AI hype dies, selloff starts and negative sentiment hits, we have below $200B market cap company.

It will hurt Elon mentally. He will need a hug.

Typescript, however, does scale pretty well. But now you've added a compiler and bundler, and might as well use some framework.

I’ve written some pretty complicated vanilla JS and it works fine. I’m not dealing with other people crappy code however so YMMV.

At this point there are several large Rust UI libraries that try to replicate this pattern in web assembly, and they all had enough time to appear and mature without the underlying JSX+hooks model becoming outdated. To me it’s a clear sign that JS world slowed down.

Server-side components became a thing, as well as the React compiler. And libraries in the React (and JS at large) ecosystem are pretty liberal with breaking changes, a few months is enough to have multiple libraries that are out-of-date and whose upgrade require handling different breaking changes.

React Native is it own pit of hell.

It did slow down a little since a few years ago, but it's still not great.

I also don’t ‘KTH-Trust’ Meta of all corporations to have a compile step for a web technology.

And since you are now filling in two tax returns for different countries, with different tax allowances across rental income and work income which interact in decidedly non-linear fashion, you probably need to make sure both country A and B have no confusion about where your work income was earned.

Having spent the last 8 years obsessively counting days across the UK and Finland (and every other country I have visited) exactly to account for this scenario, I am very sympathetic to attempts to solve this problem space!

But then, that's because you own property in country A, not because you're a citizen of country A! The same would happen if you were a citizen of country B, lived and worked in country B, but bought a house to rent out in country A.

Physical goods you can hold until tariffs are paid.

Services are paid for by invoices between two corporate entities whose legal domicile may have nothing to do with the real country of origin of the services.

Lots of European SaaS providers invoice US customers from their US subsidiary - impossible to distinguish the transaction in order to put a tariff on it.

Definitely will be using your app.

"the hoi polloi" grates every time I read it. "hoi polloi" literally means "the many", so this is an awkward pleonasm, "the the many", amounting to a lack of quality in a piece of writing.