Right but if you read that page you quickly come to the quote "Parliament can make or unmake any law". Technically there is judicial review now, so there is some restrictions, but not like in a USA style constitution.
This is a ridiculous article and reeks of insecurity at the top at Vercel. You cannot expect to reap the benefits of open source software without accounting for the costs.
no, it's all about auth. MCP lets less-technical people plug their existing tools into agents. They can click through the auth flow in about 10 seconds and everything just works. They cannot run CLIs because they're not running anything locally, they're just using some web app. The creator of the app just needed to support MCP and they got connectivity with just about everything else that supports MCP.
Write better CLIs for the agents of the less-technical people. The MCPs you're talking about don't exist yet either. This doesn't seem complicated; MCP seems like a real dead end.
How are those CLIs being installed and run on hosted services? You'll need to sandbox them and have a way to install them automatically which seems difficult. How does the auth flow work? You'd need to invent some convention or write glue for each service. These are far more complicated than just using MCP, regardless of the benefits of the protocol itself.
I think a big part of why this discussion is coming up again and again is that people assume the way they are using AI is universal, but there's a bunch of different ways to leverage it. If you have an agent which runs within a product it usually cannot touch the outside world at all by design, you do not need an explicit sandbox (i.e. a VM or container) at all because it lives in an isolated environment. As soon as you say "we use CLIs not MCP" well now you need a sandbox and everything else that goes along with it.
If you can tell ahead of time what external connectors you need and you're already sandboxing then by all means go with CLIs, if you can't then MCP is literally the only economical and ergonomic solution as it stands today.
> ...people assume the way they are using AI is universal
This is what led me back to MCP. Our team is using Claude CLI, Claude VSCX, Codex, OpenCode, GCHP, and we need to support GH Agents in GH Actions.
We wanted telemetry and observability to see how agents are using tool and docs.
There's no sane way to do this as an org without MCP unless we standardize and enforce a specific toolset/harness that we wrap with telemetry. And no one wants that.
Sure. But if you geoblock all use on Russian controlled land, you're also blocking Ukrainian use on Russian controlled land. I have no idea if that would cause issues or not, but it's not that far fetched to imagine it might.
I know this is a meme but for those at home the whole point of a war is to cross over the front line into the opponent's territory and capture it. If your comms are disabled when you cross the front you can't really fight. So "just disable Starlink within Russian territory" does not solve anything.
You can have a hybrid approach - deny access in that area by default but have a secure way to whitelist specific terminals for short periods (mission duration)
The issue isn't Russians using Starlink inside Russia (they have other option, e.g. wired system, etc. there); the issue was their using it for drones and other combat operations inside Ukraine (including Ukrainian territory presently held by Russia).
The point is that in order for Russians to use Starlink in combat operations in Ukraine, they first have to import them to Russia. All non-whitelisted Starlink terminals entering Russia should be immediately bricked to prevent this. It's an important part for denying Russians the use of Starlink.
It's beyond sickening what none of you even bother with the idea what a civilian service should not be used by the military, especially in the zone of the conflict - by any side.
SpaceX is a privately-owned defense services company. Their #1 client is the United States. Their launches out of Vandenberg occur because the United States Space Force allows them to happen.
Are you on their board? Who are you to make the call that the product they are offering is a "civilian" (only?) service?
It knows this because it knows where it isn't. By subtracting where it is from where it isn't, or where it isn't from where it is (whichever is greater), it obtains a difference, or deviation.
I think what's actually funnier is that the satellite shooting the laser has to know where the terminal is with pin point accuracy too. So it's pretty easy to cut off targeting to a vast chunk of the planet.
The issue with these LLM-targeting DSLs is that you have to waste a bunch of your context window explaining the grammar and semantics to the LLM, whereas they already speak existing programming languages because they've seen so much existing code. This usually negates the benefits of the DSL.
it is straightforward to build this for real, here is my nearly one-shotted tldraw clone from a couple of weeks ago, https://x.com/c_pick/status/2028669568403578931 - the implementation side never saw the code, only the spec (in reality it did see the tldraw code in its training data, but you can't escape that anymore)
I wonder about this training data. There's so much profit from open source code in training data, actually the most of the code it was taught was open source, shouldn't it be then free? Or at least open weight?
This is satire, but I actually have built something that can do this extremely well as an unintentional side effect. I will not be building my business around this capability however
But that's the current primary use case for AI. We aren't anywhere close to being able to sanitise input from hostile third parties enough to just let people start inputting prompts to my own system.
there's a whole world of AI tools out there that don't focus on developers. These tools often need to interact with external services in one way or another, and MCP gives those less technical users an easy way to connect e.g. Notion or Linear in a couple of clicks, with auth taken care of automatically. CLIs are never replacing that use case.
I don't doubt that CLIs + skills are a good alternative to MCP in some contexts, but if you're building an app for non-developers and you need to let users connect it to arbitrary data sources there's really no sensible, safe path to using CLIs instead. MCP is going to be around for a long time, and we can expect it to get much better than it is today.
>we can expect it to get much better than it is today
Which is not a high bar to clear. It literally only got where it is now because execs and product people love themselves another standard, because if they get their products to support it they can write that on some excel sheet as shipped feature and pin it on their chest. Even if the standard sucks on a technical level and the spec changes all the time.
You could strip away 90% of the spec and it would be even more useful. In fact standardizing the tool definitions and prompt formats would probably have done more if you're serious about supporting a certain set of tools between various LLM providers.
