Readit Newsjuanviera23 commented on Universal Tool Calling Protocol (UTCP) github.com/universal-tool... · Posted by u/edweis
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/
hulloo
I think this is really good feedback and something we'll look into, thank you for sharing!
juanviera23 commented on Universal Tool Calling Protocol (UTCP) github.com/universal-tool... · Posted by u/edweis
Cmd+F "modern"
"The Universal Tool Calling Protocol (UTCP) is a modern, flexible, and scalable standard for defining and interacting with tools across a wide variety of communication protocols."
Into the trash it goes.
hey man, I get it, we're using fancy words
But we're real people working on a real protocol that we feel improves on the status quo, and calling it 'trash' because it doesn't fit your vernacular is unnecessary, and dare I say hurtful
So pls, if you have feedback, happy to improve on it, but don't just dismiss it
juanviera23 commented on MCP doesn't need tools, it needs code lucumr.pocoo.org/2025/8/1... · Posted by u/the_mitsuhiko
What you're building makes a lot of sense to me. The communication indirection MCP use frequently introduces bothers me, as well as the duplication of effort when it comes to e.g. the OpenAPI spec. I'll keep an eye on this repo and plan to give it a spin sometime (though I wish there was a typescript version too).
there is a TS version actually, all the SDKs are here: https://github.com/universal-tool-calling-protocol
juanviera23 commented on MCP doesn't need tools, it needs code lucumr.pocoo.org/2025/8/1... · Posted by u/the_mitsuhiko
> idk why we need MCP servers when LLMs can just connect to the existing API endpoint
Because 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.
yupp that's what UTCP does as well, standardizing the tool-calling
(without needing an MCP server that adds extra security vulnerabilities)
UTCP Contributor here.
I understand your frustrations of people adding abstractions on existing infrastructure for no reason, but UTCP is actually trying to avoid exactly that.
Picture the following scenario. You create an agent that your users should use in their daily life. Now you want your users to be able to do more than generate text. A.k.a. call tools.
How do you do this?
Option 1: you implement your own infrastructure allowing them to call whatever tools you custom infra supports. -> less flexibility on the user side of what tools they can use
Option 2: you use an MCP client. Now your users can add any tool they want as long as it has MCP support. This however adds an extra layer of infra. Agent -> MCP Server -> Original Tool (maybe a REST API, or a CLI command, etc.)
Option 3: you use the UTCP client. Now your users can add any tool that uses any communication protocol. Agent -> Original tool (maybe a REST API, CLI command, MCP server, etc.)
TLDR, UTCP is about security and not rebuilding existing infrastructure. There are plenty of communication protocols to get anything you can imagine done on the internet. We should use those and write interfaces and wrappers using those, not MCP. That is what UTCP does. It allows agents to use existing infra, communication protocols and security.
We're fully community-driven OSS, and just aiming to make a protocol that is useful for people
Hope this makes sense and happy building <3