Started on working on an alternative protocol, which lets agents call native endpoints directly (HTTP/CLI/WebSocket) via “manuals” and “providers,” instead of spinning up a bespoke wrapper server: https://github.com/universal-tool-calling-protocol/python-ut...
even connects to MCP servers
if you take a look, would love your thoughts
The primary differentiator is that MCP includes endpoint discovery. You tell the LLM about the general location of the MCP tool, and it can figure out what capabilities that tool offers immediately. And when the tool updates, the LLM instantly re-learns the updated capability.
The rest of it is needlessly complicated (IMO) and could just be a bog standard HTTP API. And this is what every MCP server I've encountered so far actually does, I haven't seen anyone use the various SSE functionality and whatnot.
MCP v.01 (current) is both a step in the right direction (capability discovery) and an awkward misstep on what should have been the easy part (the API structure itself)
The actual thing that's different is that an OpenAPI spec is meant to be an exhaustive list of every endpoint and every parameter you could ever use. Whereas an MCP server, as a proxy to an API, tends to offer a curated set of tools and might even compose multiple API calls into a single tool.
Everyone in this thread is aware that LLMs aren't performing our jobs.
MCP discoverability is designed to be ingested by an LLM, rather than used to implement an API client like OAI specs. MCP tools describe themselves to the LLM in terms of what they can do, rather than what their API contract is.
It also removes the responsibility of having to inject the correct version of the spec into the prompt from the user, and moves it into the protocol.
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.
https://github.com/universal-tool-calling-protocolBecause the LLM can't "just connect" to an existing API endpoint. It can produce input parameters for an API call, but you still need to implement the calling code. Implementing calling code for every API you want to offer the LLM is at minimum very annoying and often error-prone.
MCP provides a consistent calling implementation that only needs to be written once.
(without needing an MCP server that adds extra security vulnerabilities)
I'll spare the audience the implied XKCD link
Both serve a different purpose, but both can achieve the exact same thing.