Hacker News Reader

Comment by panghy | Hacker News Reader

Honestly MCP is geared mainly for the non-technical folks who don't understand a thing about REST or OpenAPI (otherwise, of course folks can just ask models to search/parse/code/parse and get things done -- don't need to ask for an MCP endpoint at all). Models also do a lot better with tool calls than asking them to string together instrospection, web-search, curl, etc. (that's a lot of tokens) rather than having the endpoint expose a single URL that the model can take, auth, understand, and use.

I maintain https://endara.ai and you can very quickly introduce a ton of capabilities for Claude/Cursor/ChatGPT by configuring all the stuff you use in a single place (and slicing them with profiles if needed).

View on HN

The user experience for a rest api and for mcp can be the same. For MCP, you have to give the mcp server url. For REST, you could provide a url to the openapi spec. The open API spec has everything you'd need - oauth url + all the endpoints and params.

Most chat products will just have a directory of connectors anyways - so for non technical folks they won't even here the term MCP or REST, they'll just "Install the Gmail plugin".

Yep. There's already a well-established system of `.well-known` URL paths to support things like API spec discover, auth discovery, etc. Why re-invent those wheels?

Like many things in this fashion industry, how else do you get new conference subjects, consulting gigs, books,...?

Because while an agent can indeed call a REST API directly using some other tool ( probably curl) what LLMs are good at is calling tools, and all MCP is doing is turning an API into a tool and standardizing authorization, which if you go the API route can be a nightmare as auth is not even mentioned in OpenAPI specs, usually, so the agent has to figure out how to do auth, and it will necessarily have access to your token and maybe even credentials, so it can easily leak it to attackers your agent happens to visit by just asking for it. I can’t believe anyone who has tried to give agents access to APIs in a sane manner hasn’t concluded that something on the lines of MCP is absolutely necessary.

OpenAPI 3.0 has auth. You can turn OpenAPI specs into tool calls just as well, without giving your agents access to call curl and without leaking credentials.

The problem is often that OpenAPI schemas are often incomplete, since they used to be useful to humans even in an incomplete state.

MCP basically requires you to do the equivalent work of getting your OpenAPI schema complete. It’s just much easier to sell to your managers.

I guarantee you any LLM will be perfectly capable of navigating HTTP auth [1] which has been around since 1999.

You could use `curl`, or you could bake an HTTP client tool into the agent harness which operates at a more abstract level. The agent would just have a tool that looks a lot like the Fetch API [2] and the harness could simply be configured to inject credentials using the various well-established patterns that have long existed, allow / deny certain methods, etc. The thing is, everything you can do with MCP could also simply be done with REST, so neither is inherently better than the other, I just don't like the proliferation of needless standards.

[1]: https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/Aut...

[2]: https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API/U...

You can’t be seriously proposing HTTP auth (you probably mean basic auth??) as a solution!? Just hand your raw credentials to the LLM, what could go wrong?

Letting the harness inject the credentials implies not exposing them to the LLM.

Besides, the current state of MCP authentication almost always involves just hard coding secrets in .claude/settings.json so it's not like that's doing a great job keeping the creds away from the LLM anyway. All I'm saying is that MCP auth offers no advantage.

I think by now even non-technical vibe coders have enough of an overview on REST APIs

Reply on news.ycombinator.com