I appreciate their reluctance towards MCP, but /something/ is better than nothing.
It’s suboptimal for the reasons the author outlines: but so is USB-C. So is NVME, so is HDMI.
We use these hugely successful technologies in spite of their flaws because they’re widely compatible and easy for the end user.
That’s why MCP is everywhere. It might not be performant, robust and uniform but it WILL get better over time.
And I’d much rather have the broad MCP ecosystem that we have now than seven or eight different “optimal” ways of plugging in an LLM to something useful.
Except there already was "something" that the creators of MCP just ignored.
Imagine a world where you could:
* Configure your favorite harness/chat client with any OpenAPI spec for an API that supports Oauth2.
* The harness would walk you through the Oauth flow and securely store the token.
* And then insert some tools for discovering the API methods and making requests in to the context.
* The agent could then formulate a request, call the request tool, and the harness would 1) makes sure it's allowed to make a request to that API, and 2) insert the Auth Token into the request.
It would be basically exactly the same way MCP is setup today, except all you would need is an OpenAPI spec. You wouldn't have setup a server for a janky new standard that's half implemented slightly differently by every harness/chat client.
_fw · · focus · HN ↗
It’s suboptimal for the reasons the author outlines: but so is USB-C. So is NVME, so is HDMI.
We use these hugely successful technologies in spite of their flaws because they’re widely compatible and easy for the end user.
That’s why MCP is everywhere. It might not be performant, robust and uniform but it WILL get better over time.
And I’d much rather have the broad MCP ecosystem that we have now than seven or eight different “optimal” ways of plugging in an LLM to something useful.
mikeocool · · focus · HN ↗
Imagine a world where you could:
* Configure your favorite harness/chat client with any OpenAPI spec for an API that supports Oauth2.
* The harness would walk you through the Oauth flow and securely store the token.
* And then insert some tools for discovering the API methods and making requests in to the context.
* The agent could then formulate a request, call the request tool, and the harness would 1) makes sure it's allowed to make a request to that API, and 2) insert the Auth Token into the request.
It would be basically exactly the same way MCP is setup today, except all you would need is an OpenAPI spec. You wouldn't have setup a server for a janky new standard that's half implemented slightly differently by every harness/chat client.
internetter · · focus · HN ↗
jasomill · · focus · HN ↗