Hacker News Reader

Comment by mmasu | Hacker News Reader

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.

View on HN

What is an example of something that is unsafe to consume via API or CLI?

Isn't MCP _an API_?

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.

It is.

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.

Yes, MCP is an API.

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.

Ahh so it's the 2025 name for CORBA? just kidding, I meant SOA /s

But your answer is the first one that seems to be relevant, so thank you.

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.

Reply on news.ycombinator.com