On "Zero reuse of existing API surfaces", I read this insightful Reddit comment on what an LLM-Tool API needs and why simply OpenAPI is not enough [1].
On "Too Many Options"... at the beginning of this week, I wrote an MCP server and carefully curated/coded a MCP Tool surface for it. By my fourth MCP server at the end of the week, I took a different approach and just gave a single "SQL query" endpoint but with tons of documentation about the table (so it didn't even need to introspect). So less coding, more prose. For the use case, it worked insanely well.
I also realized then that my MCP server was little more than a baked-in-data-plus-docs version of the generalized MotherDuck DuckDB MCP server [2]. I expect that the power will be in the context and custom prompts I can provide in my MCP server. Or the generalized MCP servers need to provide configs to give more context about the DBs you are accessing.
Thanks for posting the reddit comment, it nicely explains the line of thinking and the current adoption of MCP seems to confirm this.
Still, I think it should only be an option, not a necessity to create an MCP API around existing APIs. Sure, you can do REST APIs really badly and OpenAPI has a lot of issues in describing the API (for example, you can't even express the concept of references / relations within and across APIs!).
REST APIs also don't have to be generic CRUD, you could also follow the DDD idea of having actions and services, that are their own operation, potentially grouping calls together and having a clear "business semantics" that can be better understood by machines (and humans!).
My feeling is that MCP also tries to fix a few things, we should consider fixing with APIs in general - so at least good APIs can be used by LLMs without any indirections.
On "Zero reuse of existing API surfaces", I read this insightful Reddit comment on what an LLM-Tool API needs and why simply OpenAPI is not enough [1].
On "Too Many Options"... at the beginning of this week, I wrote an MCP server and carefully curated/coded a MCP Tool surface for it. By my fourth MCP server at the end of the week, I took a different approach and just gave a single "SQL query" endpoint but with tons of documentation about the table (so it didn't even need to introspect). So less coding, more prose. For the use case, it worked insanely well.
I also realized then that my MCP server was little more than a baked-in-data-plus-docs version of the generalized MotherDuck DuckDB MCP server [2]. I expect that the power will be in the context and custom prompts I can provide in my MCP server. Or the generalized MCP servers need to provide configs to give more context about the DBs you are accessing.
[1] https://www.reddit.com/r/mcp/comments/1jr8if3/comment/mlfqkl... [2] https://github.com/motherduckdb/mcp-server-motherduck