20 ms·
Universal Tool Calling Protocol (UTCP)
- pvtmert 1y agoSoon, they will discover APIs. (Application Programming Interfaces). Where programs interact with each other with given contracts/protocols/prototypes. /pun
- otabdeveloper4 1y agoSounds complex. We'll need an AI-enabled Google or Microsoft to figure this stuff out for us and sell as a cloud subscription service.
- blef 1y agoNever heard of it. Is API the thing we develop for MCPs to interact with?
- _zoltan_ 1y agoyes but we need a lot of SOAP and XML. soon. /s :)
- mrheosuper 1y agoThen MSFT discovers COM.
- orphea 1y agoThat's fine. Wait until AI bros discover COM (Context Orchestration Mechanisms).
- IanCal 1y agoThe 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.
- razvi0211 1y agoFunnily enough, thats exactly what UTCP is. Its just a way to let your AI leverage existing APIs instead of doing any wrapper protocols (like MCP) for the tool call. The protocol is only for discovery. It gets out of the way for the actual call
- donperignon 1y agoI 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.
- deleted 1y ago[deleted]
- TZubiri 1y agoMaybe we can release a buzzword thing called Tool Calling Protocol. And it's just TCP. Or Contextual Shared Variables Or eXecution Model Language or..
- IanCal 1y agoI 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 1y agonone of it is working, MIT just released a paper showing that the overwhelming majority of orgs adopting llm workflows have seen no benefit
- TickleSteve 1y agomaybe we could implement a UTCP->REST bridge for another unnecessary abstraction layer.. /s
- deleted 1y ago[deleted]
- fzeindl 1y agoSome 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 1y agoThe assumption that many decade old tools might adopt a year old protocol just to improve handling with agents. That's optimism
- esafak 1y agoIncreased abstraction is why we don't all program in assembly any more.
- fzeindl 1y agoAgreed, but my point is that an abstraction should provide discernible gain of value, not merely roll a handful of operations of the same level into one.
- Joker_vD 1y agoOr, to re-word it in the words of the parent comment, that's why we don't write write programs in assembler that output even more assembler.
- DataDaemon 1y agoI'm tired boss [meme]
- iamsaitam 1y agoIt has "universal" in the name so this must be it, right?
- microsoftedging 1y agoObligatory XKCD: https://xkcd.com/927/ https://xkcd.com/927/
- vasachi 1y agoInitial 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 1y ago> 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 1y agowe should have age verification to post on HN
- brabel 1y agoWhy 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.
- gldnspud 1y agoWe 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/ https://lucumr.pocoo.org/2025/8/18/code-mcps/
- deleted 1y ago[deleted]
- juanviera23 1y agohulloo I think this is really good feedback and something we'll look into, thank you for sharing!
- thecupisblue 1y agoAlways 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.
- deleted 1y ago[deleted]
- smokel 1y agoWhile 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.
- thecupisblue 1y agoTechnically yes, and I've caught myself in a bit of a paradoxal conundrum :) Think there is a curve of "reason" to apply when someone is advocating something like this, especially about technology and abstractions. While in most places adding abstractions to core technology makes sense since "it makes it easier to use/manage/deploy" and it is reasonable to use it, LLM's are a quite different case than usual. Because usually going downstream makes it harder (i.e. going 100% assembly or 100% JS is a harder thing), but going 100% pure LLM is an easier thing - you don't have to learn new frameworks, no need to learn new abstractions, it is shareable, easy to manage and readable by everyone. In this case, going upstream is what makes it harder, turns it into code management, makes it harder to reason about and adds inevitable complexity. If you add a new person on your team and they see that you are using 100% assembly, they have to onboard to it, learn how it works, learn why this was done this way etc etc. If you add a new person to your team and you see that they are using all these tools and abstractions on top of LLMs its the same. But if you are just using the core tech, they can immediately understand what is going on. No wrapped prompts, magic symbols, weird abstractions - "oh this is an agent but this is a chain while this is a retriever which is also an agent but it can only be chained to a non-retriever that uses UTCP to call it". So as always, it is subjective and any advocacy needs to be applied to a curve of reason - in the end, does it make sense?
- thrown-0825 1y agoas 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
- zorobo 1y agoI promise, it's the last one we'll ever need https://en.wikipedia.org/wiki/The_Last_One_%28software%29 https://en.wikipedia.org/wiki/The_Last_One_%28software%29
- sethaurus 1y agoOne really nice thing about using LLMs as components is that they just generate text. We've taught them to sometimes issue JSON messages representing a structured query or command, but it still comes out of the thing as text; the model doesn't have any IO or state of its own. Then the actual program can then decide what, if anything, to do with that structured request. I don't like the gradual reframing of the model itself as being in charge of the tools, aided by a framework that executes whatever the model pumps out. It's not good to abstract away the connection between the text-generator and the actual volatile IO of your program.
- dmos62 1y agoWhat kind of abstractions around llm-io would you prefer?
- dmos62 1y agoSo this basically says either have the tool implement this inteface or write a wrapper (which would be the equivalent of writing an MCP server), right? So this is slightly more general than MCP, or am I missing something?
- OutOfHere 1y agoWill UTCP work with OpenAI models despite their absence of general support for MCP?
- koakuma-chan 1y agoIn general models themselves don't support MCP, it's wrappers around models that do.
- brap 1y agoYou know I really don’t get it. I must be missing something obvious. Any “tool protocol” is really just a typed function interface. For decades, we’ve had dozens (hundreds? thousands?) of different formats/languages to describe those. Why do we keep making more? Does it really matter who is calling the function and for which purpose? Does it matter if it’s implemented by a server or a command line executable? Does the data transport protocol matter? Does “model” matter? interface HelloSayer { /** Says hello **/ String sayHello(); } Here’s your tool protocol bro
- donperignon 1y agogood job! 3k github stars for you sir!!!
- dmos62 1y agoIf you were to try to implement what you described, you'd figure out what you missed quickly. Namely, that you have to interface your interface to a text interface.
- tucnak 1y agoThis is insane! We've been training models to write and edit code, and now this? These guys should read this (CodeAct) paper https://arxiv.org/abs/2402.01030 https://arxiv.org/abs/2402.01030 > LLM agents are typically prompted to produce actions by generating JSON or text in a pre-defined format, which is usually limited by constrained action space (e.g., the scope of pre-defined tools) and restricted flexibility (e.g., inability to compose multiple tools). This work proposes to use executable Python code to consolidate LLM agents' actions into a unified action space (CodeAct). Integrated with a Python interpreter, CodeAct can execute code actions and dynamically revise prior actions or emit new actions upon new observations through multi-turn interactions. Our extensive analysis of 17 LLMs on API-Bank and a newly curated benchmark shows that CodeAct outperforms widely used alternatives (up to 20% higher success rate). The encouraging performance of CodeAct motivates us to build an open-source LLM agent that interacts with environments by executing interpretable code and collaborates with users using natural language. To this end, we collect an instruction-tuning dataset CodeActInstruct that consists of 7k multi-turn interactions using CodeAct. We show that it can be used with existing data to improve models in agent-oriented tasks without compromising their general capability. CodeActAgent, finetuned from Llama2 and Mistral, is integrated with Python interpreter and uniquely tailored to perform sophisticated tasks (e.g., model training) using existing libraries and autonomously self-debug.
- meindnoch 1y agoCmd+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.
- deleted 1y ago[deleted]
- juanviera23 1y agohey 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
- aktau 1y agoBut there is a grain of truth to their commentary. "Modern" gets old fast, it probably shouldn't be used, just like "new" shouldn't be used in project/library names. IMHO, removing "modern, flexible and scalable" would improve that line. I've diagonally read through the README, and for my taste there is overuse of "soft" adjectives (simple, easy, ...) which makes me (an engineer) discard it as marketing-driven.
- kmac_ 1y agoIn my opinion, there's a lot of unnecessary criticism here. The entire AI field is in a discovery phase, with new ideas, approaches, and methods emerging at many levels, including models and APIs. Right now, we don't even have a single standardized API for model responses (OpenAI's Chat Completions API is the de facto standard, but it's not formally standardized, lacks reasoning responses, and caching remains unclear, etc.). So some ideas from projects like this could stick and contribute something new.
- razvi0211 1y agoAgreed! Right now, there's only one way to do tool calling, and that's MCP. I'm not happy with MCP, so I want alternatives so in the end we can all choose or create the best option. We're talking about the infrastructure of the future right now, and I dont want to rebuild everything that works, just because MCP told be to.
- pinoy420 1y ago[dead]
- esafak 1y agoBy not using a server as an interface, UTCP more tightly couples the caller to the tool. For example, a search MCP server could make the search provider an optional parameter to be dynamically selected without breaking the contract. With UTCP you can not do that. Given that tool calling usually does not constitute the bulk of a typical LLM query's time, I think optimizing the latency by eliminating the interface is an unwise architectural choice. Interfaces are good things.
- razvi0211 1y agoIt's not about latency. It's about security and 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 our interfaces and wrappers using those, not MCP. That is what UTCP does. It allows agents to use existing infra, communication protocols and security.
- juanviera23 1y agoHi HN, 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