maybe to have a global market share, but there are plenty of players that picked up pace when they “decided” to build cars (Japan? South Korea? and many more) or electronics. Having a good sovereign model in 10/20 years might not need having the absolute best there is, and perhaps future optimizations will make building one not as prohibitively expensive as it is today. Keeping some sort of homebrew capacity now is definitely better than having none
In enterprise MCP allows users to access resources that could either be unsafe or impractical to consume via API or CLI. It is a powerful pattern, supported by virtually all clients (Cursor, Claude Code, Codex, whatever) and easily implemented in custom harnesses. If you don’t need it you don’t, but it has many useful applications. Stateless will make it a lot more practical to expand applications.
MCP serves a single purpose: If you ask some company for API support for some stuff you can do via web UI but not API, they might say no for many reasons. But when you ask for MCP, suddenly you trigger AI FOMO and it will be available right away.
Previously, it was an API with a weird stateful standard; now it is essentially a bog-standard stateless JSON-RPC API with conventions for tool discovery, long-running tasks and multi-round-trip requests
If you wrote your own JSON-RPC API for an LLM, you would probably eventually end up with something that looks very much like the standard they're describing.
Its more targeted? Sure I can allow an LLM to access CLI, but then it will try to pipe to other command, write scripts etc. MCP is simply request/response. Its not really that technically different, but the way you and LLMs interact with it allows for easier control. IMHO.
I don't get it. I thought the advantage is that you have a client as a library with integrated auth & other tech stuff handled so you can just focus on using the API? Because otherwise you could just use REST with basic endpoint code.
also, the same metric can be used in different ways and for different purposes across a business, so you might need different validation rules and definitions.
Maybe one separate semantics validation layer could help, but costs 2x or possibly Nx if you need to recover and turn a wrong query into a correct one
