Universal Tool Calling Protocol (UTCP)
30 comments
·August 18, 2025thecupisblue
smokel
While I might agree with your standpoint, how is this different from also influencing?
I've seen a lot of influencers suggest "100% assembly", "JavaScript only", "no SQL", which seem quite similar.
pvtmert
Soon, they will discover APIs. (Application Programming Interfaces). Where programs interact with each other with given contracts/protocols/prototypes.
/pun
blef
Never heard of it. Is API the thing we develop for MCPs to interact with?
_zoltan_
yes but we need a lot of SOAP and XML. soon. /s :)
mrheosuper
Then MSFT discovers COM.
orphea
That's fine. Wait until AI bros discover it (and call it "Context Orchestration Mechanisms" or something).
IanCal
The common but lazy joke. This is about connecting agents which have a specific set of requirements about the apis they can call and existing APIs.
otabdeveloper4
Sounds complex. We'll need an AI-enabled Google or Microsoft to figure this stuff out for us and sell as a cloud subscription service.
donperignon
I have the same feeling as 2010-2015 with the js ecosystem craziness. These half baked ideas. Please we need to stop, we don’t need extra layers of abstraction and tooling that is not really solving any problem, it’s just ego tripping to create something and to get GitHub stars.
IanCal
I disagree. I think it’s worthwhile trying these things out to see what’s working and what isn’t. We can sit and think and discuss all we want but sometimes you need to build something and try.
thrown-0825
none of it is working, MIT just released a paper showing that the overwhelming majority of orgs adopting llm workflows have seen no benefit
null
TZubiri
Maybe we can release a buzzword thing called Tool Calling Protocol. And it's just TCP.
Or Contextual Shared Variables
Or eXecution Model Language
or..
franky47
Context Sharing System and Heuristic Transformers Machine Learning are also promising.
Razengan
Please fund my Extensible eXpertise Enhancements
taneq
Damn these Tool-related Language Additions.
gldnspud
We probably don’t need another tool calling protocol unless it is also a tool composition protocol.
Armin Ronacher has recently been making some good points about tool composition: https://lucumr.pocoo.org/2025/8/18/code-mcps/
fzeindl
Some developers love to implement Rube-Goldberg-machines as tooling.
Whenever they need to make two or three manual steps or configurations, they rather develop an abstraction layer where you just have to press one button to perform them.
Until that button needs to be accompanied by another manual action. Then they will again develop an abstraction which encapsulates the press of the button along with the augmenting action and is triggered by the pressing of a superior button.
Example: Docker->Kubernetes->Helm or any other tooling that uses YAML to write YAML.
ckbkr10
The assumption that many decade old tools might adopt a year old protocol just to improve handling with agents.
That's optimism
vasachi
Initial commit: Jun 24, 2025. Already has a migration path from 0.x to 1.x.
Why am I feeling so old now?
On a more serious note, do any models support this?
evertedsphere
> Initial commit: Jun 24, 2025. Already has a migration path from 0.x to 1.x.
because that is perfectly reasonable to the llm that wrote that readme
thrown-0825
we should have age verification to post on HN
iamsaitam
It has "universal" in the name so this must be it, right?
brabel
Why is everyone complaining, this is great and a much needed improvement over MCP. MCP is not yet the "definitive answer", perhaps there's time to replace it with something better.
thrown-0825
as is tradition the younger generation of devs are going to get burned by hype vaporware and create a whole ecosystem of orphaned protocols and tools
reminds me of the early 2000’s and all the nosql trash
DataDaemon
I'm tired boss [meme]
microsoftedging
Obligatory XKCD: https://xkcd.com/927/
TickleSteve
maybe we could implement a UTCP->REST bridge for another unnecessary abstraction layer..
/s
null
Always the same with every tech hype-train.
People start developing protocol, standards and overengineering abstractions to get free PR and status. Since AI hype started we have seen so many concepts built upon the basic LLM, from Langchain to CoT chains to MCP to UTCP.
I even attended a conference where one of the speakers was adamant that you couldn't "chain model responses" until Langchain came out. Over and over again, we build these abstractions that distance us from the lower layers and the core technology, leaving people with huge knowledge gaps and misunderstanding of it.
And with LLM's, this cycle got quite fast and it's impact in the end is highly visible - these tools do nothing but poison your context, offering you less control over the response and tie you into their ecosystem.
Every time I tried just listing a list of available functions with a basic signature like:
fn run_search(query: String, engine: String oneOf Bing, Google, Yahoo)
it provided better and more efficient results than poisoning the context with a bunch of tool definitions because "oooh tool calling works that way".
Making a simple monad interface beats using langchain by a margin, and you get to keep control over its implementation and design rather than having to use a design made by someone who doesn't see the pattern.
Keeping control over what goes into the prompt gives you way better control over the output. Keeping things simple gives you a way better control over the flow and architecture.
I don't care that your favorite influencer says differently. If you go and build, you'll experience it directly.