On my first couple days of writing MCP servers, I made ones that bind APIs (DataBento, Buttplug.io). I thought that was the point. These were my immediate takeaways:
1) I need an auto-binder (eg OpenAPI) or a better binding system like this UTCP is trying to be
2) I need a secure sandbox, for the system and even for the APIs (like a UAT env)
I’ve continued to make MCP servers and tools and realized (1) was a fallacy. Most APIs were not made for computers; they were made for humans to allow other humans to connect to their code.
It’s hard to explain, but it’s an ergonomic thing. An API to a database might have things like paging and filtering. The design might have to fit into a URL and you want to simplify or hide things. LLMs don’t care.
My insight was similar to this article wrt code. An LLM doesn’t need a cute API to a dataset. They can code so you don’t need to give them an API, you give them a SQL endpoint (my focus), or a Python venv, or a bash prompt.
Then akin to UTCP manuals, the user and LLM can develop tool descriptions and code helpers (in SQL, Views and stored procedures) to make them better at doing whatever they need to do. Maybe there’s a main tool description and then a supplementary user-specific one too.
So I’m taking a DuckDB, loading data and locking it down, and give a single SQL endpoint that returns a DB table in CSV. Then work with the LLMs to make tool descriptions and helpers in agentic loops.
So I think what y’all are working on is cool, but the power isn’t in the API connection itself, but how the LLM effectively uses it. But you can build that agentic-assist part into the product; or somebody wraps something around it.