Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I've thought of this as well but in reality, aren't MCP servers mostly just clients for pre existing APIs?

For example, the Kagi MCP server interacts with the Kagi API. Wouldn't you have a better experience just using that API directly then?

On another note, as the number of python interpreters running on your system increases with the number of MCP servers, does anyone think there will be "hosted" offerings that just provide a sort of "bridge" running all your MCP servers?



My understanding is MCP = original APIs + 1 more API

The additional API is /list-tools

And all the clients consume the /list-tools first and then rest of the APIs depending on which tool they want to call.


Yes. But in order to do that you run the MCP server for that API locally. Is it really worth doing that just to have the additional /list-tools, when it is otherwise basically just a bridge/proxy?


From my perspective, remote MCP servers are gradually becoming the norm for external services.


Not quite sure I get what you mean by 'MCP server for that API locally'.

Locally you just need a consumer/client, isn't?


Check out the overview in the MCP spec. Locally you run the "host application" (e.g. ollama or Claude Desktop). Then you have clients which are inside the host application and maintain 1:1 connections with servers.

Then you have servers, which are separate processes running on your machine that the clients connect to. For example, you program a server to "manipulate your local filesystem" in python and then run it locally.

Most MCP servers are written for python or node and to install and use them you run them locally. They then are like a "bridge" to whichever API they abstract.


This has been my take, and maybe I'm missing something, but my thinking has been that in an ideal case there's an existing API with an OpenAPI spec you can just wrap with your FastMCP instantiation. This seemed neat, but while I was trying to do authenticated requests and tinkering with it with Goose I ended up just having Goose do curl commands against the existing API routes and I suspect with a sufficiently well documented OpenAPI spec, isn't MCP kinda moot?

On the other hand, in the absence of an existing API, you can implement your MCP server to just [do the thing] itself, and maybe that's where the author sees things trending.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: