Thanks!
MCP is taking a stateful approach, where every client maintains a 1:1 connection with a server. This means that for each user/client connected to your platform, you'd need a dedicated MCP server.
We're used to writing software that interfaces with APIs, as stateless and deployment agnostic. agents.json keeps it that way.
For example, you can write an web-based chatbot that uses agents.json to interface with APIs. To do the same with MCP, you'd spin up a separate lambda or deployed MCP server for each user.
Hmm but the OpenAPI MVP server just exposes the commands for each API it knows about to the agent - then the MCP server makes stateless API calls. Problem solved.
MCP isn't stateful in terms of connection with a downstream API server - only with a local bit of code that translates LLM tool calls to something else. There's no inherent coupling.
Looking at your get_tools() it does essentially the same thing as the OpenAPI MVP server but without being an MCP server - meaning now there are two standards where before there was one, and your tool is most usefully imagined as a local stdio MCP server.
Having said that... I think OpenAPI is exactly the right direction - it comes free with most ways of building an API or easily can, and once you have it interfaces are just a transform away.
And reflecting on your approach, perhaps it's quite a good way to on-board lots of organisations that might have been hesitant or left behind otherwise.
