3 ms·

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

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?

gdecaso 1y ago
[dead]
graerg 1y ago
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.
mkagenius 1y ago
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.
- sureglymop 1y ago
  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?
  - falcor84 1y ago
    From my perspective, remote MCP servers are gradually becoming the norm for external services.
  - mkagenius 1y ago
    Not quite sure I get what you mean by 'MCP server for that API locally'. Locally you just need a consumer/client, isn't?
    - sureglymop 1y ago
      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.

gdecaso 1y ago

[dead]

graerg 1y ago

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.

mkagenius 1y ago

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.

sureglymop 1y ago
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?
- falcor84 1y ago
  From my perspective, remote MCP servers are gradually becoming the norm for external services.
- mkagenius 1y ago
  Not quite sure I get what you mean by 'MCP server for that API locally'. Locally you just need a consumer/client, isn't?
  - sureglymop 1y ago
    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.