UTCP: A safer, scalable tool-calling alternative to MCP
Posted by juanviera23@reddit | LocalLLaMA | View on Reddit | 110 comments

Posted by juanviera23@reddit | LocalLLaMA | View on Reddit | 110 comments
karaposu@reddit
I seriously think MCP is being popular due to FOMO. And it is a ridiculous way. So yeah now I am checking this out.
MostlyRocketScience@reddit
Same for Langchain. For 80% of usecases it is easier to just use the LLM api directly. But everyone was using it due to FOMO.
karaposu@reddit
We actually created our own framework called llmservice (you can find it on pypi). And you will see this line in the readme:
"LangChain isn't a library, it's a collection of demos held together by duct tape, fstrings, and prayers."
And we actively maintaining it and never needed langchain. Check it out and let me know what you think
bornfree4ever@reddit
LLMService: A Principled Framework for Building LLM Applications
LLMService is a Python framework designed to build applications using large language models (LLMs) with a strong emphasis on good software development practices. It aims to be a more structured and robust alternative to frameworks like LangChain.
Key Features:
BaseLLMService
class that users can subclass to implement their custom service logic, keeping LLM-specific logic separate from the rest of the application.How it Works (Simplified):
prompts.yaml
file to define reusable prompt "units" with placeholders.BaseLLMService
and define methods that orchestrate the LLM interaction. This involves:generation_engine
to invoke the LLM.generation_result
object containing the LLM's output and other relevant information.In essence, LLMService provides a structured, error-resilient, and modular way to build LLM-powered applications, encouraging best practices in software development.
karaposu@reddit
thanks feeding it. But LLMs are really bad with such evaluation and depending on your prompt o3 would hate the framework or love it. I dont know if Gemini is more objective or not
Dudmaster@reddit
Personally I use it because I want my SaaS to be able to swap out a dozen different providers (both LLM and embedding) - particularly with embedding providers like OpenRouter that don't implement the OpenAI standard so langchain is my optimal choice. I honestly love it and I've been writing my own pipes and stuff
teh_spazz@reddit
100%
MCP is not easy and simple to use. It's probably the most frustrating protocol I've had to work with.
eleqtriq@reddit
It’s in the early stages meant for devs. These servers will be prepackaged in easier ways soon enough. Both Anthropic and MS already have solutions.
teh_spazz@reddit
What's MS' solution?
keepthepace@reddit
I wish someone told me that reading the doc would just be a waste of time. Seriously, I had to reverse engineer examples to understand it. And it is trivial!
I think I could write a one page doc of it that would explain everything that needs to be explained.
OrbitalOutlander@reddit
Why? What problems are you encountering? Most of what I am encountering isn’t functional but difficulty in finding a well written tool.
teh_spazz@reddit
It's "standardized" in the sense that it's basically giving access to APIs, but the LLMs have to actually be able to utilize the APIs properly. The standardization is just a method of connecting to an API, but nothing after that. I have them set up and running, but I can't rely on them for complex tasks.
clduab11@reddit
What do you use to query your LLMs with?
I entered this thread ready to be like that comic strip (xkcd) where it's like "Yes, you are all wrong" to a massive crowd of people. But admittedly, in reading some of the responses, now my mind's a bit more open.
Initially, this xkcd comic came to mind when seeing this. But hopefully, things can be taken out of this type of protocol that reduces the complexity of tool/function call usage. Idk, I use Msty and I've used Cogito and I forget the name offhand, but the model on HF specifically dedicated to tool/function-call (I think it's a finetuned Llama3.2 model tho?), and I usually don't have problems with it, like, ever. There are occasionally times where the LLM forgets to call the tool or returns no search queries, but that's nothing a little prompt engineering can't cure or re-querying the model.
What I hope UTCP and other initiatives like it accomplishes is the radical simplification of needing to steer the LLMs forward, but I'd still argue MCP accomplishes this and with everyone jumping on board, there are MANY opportunities to improve the protocol and Anthropic being the progenitor of it, I trust more than say, Microsoft or Google (even though I love my Gemini/Gemma3 models). There are also many areas of opportunity for people utilizing MCP to implement it in a more user-friendly fashion (Cline had the head start with MCP Marketplace, and Roo Code are jumping onto this in recent versions).
So I get what a lot of people are saying in here, but I'd still wager that MCP has a LOT of utility to eek out of it, and why not make it better since everyone went to jump on that ship first? Let's make sure the ship doesn't sink with all the people jumping on board before we start building new boats.
teh_spazz@reddit
I have tried Msty, anythingLLM, open webui, Librechat and have successfully gotten the MCPs to connect and load into the programs for all of them. Variety of different ones, too. There’s limited continued success in using them. For instance, I want to edit a line in a database in notion. Unless I perfectly sequence pulling it up, it’ll fail. I’ve tried prompt constructing to get it right, feeding the information before hand, specifying exact details, nothing gets me consistency.
Using MCP for more “global” tasks like, look in my OneDrive and list out the file names typically works. But sequencing things is hard to get reproducibility.
clduab11@reddit
Ahhhhh, I see where you're coming from now.
I don't really have these issues; I use rUv's Claude-Flow with my Claude Max subscription and I can just deploy swarms to target the code snippet in question and by the nature of how it all works, it'll find the line in question (in VSCode that is; my database stuff is with Supabase, because I have a Supabase MCP with custom prompt instructions and mode-specific instructions that have project IDs and the like already pre-prompted in).
So naturally, I'm probably showing a lot of MCP bias, but I have a dozen MCP servers I just got configured and working correctly with all the fixings (operators, flags, etc)...and since my MCP integrator mode inside Roo Code (using rUv's Claude-SPARC npx command) is an absolute research GOD with Perplexity/Firecrawl/Kagi/Tavily/Brave (utilizing a tool called mcp-omnisearch), and with everyone else (including Docker and a LOT of big names jumping on board), I stay pretty steadfast in arguing for continued development of MCP writ large, and things like UTCP can be adapted either on the MCP protocol side, or the app development side.
teh_spazz@reddit
I'm being cheap. We're in LocalLLaMA after all...If I use the high powered models backed with a subscription of course I'll have an easier time.
clduab11@reddit
Fair enough entirely. So what does your configuration and stuff look like from the local side? I upped my GitHub membership all the way to the max to try what they're doing, but they're just copying Cline/Roo Code by this point, so I nixed it pretty quick.
The closest I could ever come was getting Qwen2.5-Coder-14B to make some simple Python simulations in VSCode with Roo Code, but I had to neuter its context and run it at Q4_K_M, which I don't like running coding models (personally) below six-bit and with a neutered context anyway.
I've debated on waiting and seeing (or maybe it's already out there) about trying to use maybe a quantized Gemma3-9B w/ KV caching and a Qwen3 speculative decoder riding bitch via LM Studio, sending it headless to my VSCode, but with Roo Code's prompting behind the curtains, I would surmise it'd probably outdo Coder-14B for a bit, and then crash/burn even harder than Slider thought Maverick did with Charlie.
I'm definitely all about some local coding options, or wanting to be, but a finetuned Claude Code gist is just...eye-bleedingly good, especially with agentic swarms. I've had to kick other hobbies just to pay for it 🥲.
SilentLennie@reddit
How smart the model is, how good it is as handling tool calls, how you chopped up your service in easily workable parts, not having to many of them and how well crafted your descriptions are all of that matters.
OrbitalOutlander@reddit
Oh yeah! I totally have those sorts of problems too. It’s frustrating!
BidWestern1056@reddit
it's so wrapped up in a specific methodology that stems from the anthropic sdk playbooks. it's always felt more like a way for them to kind of control the way people are doing things rather than building a useful practical protocol with a small set of primitives that actually can scale and combine in meaningful ways.
teh_spazz@reddit
God yes. I feel so vindicated reading all these comments.
Illustrious-Lake2603@reddit
Dang, im literally trying to install it and have No Clue what Im doing. I dont even know what an MCP is! I just want my code to be easy to edit with LLM
mintybadgerme@reddit
I think that's a common refrain. :)
pokemonplayer2001@reddit
You don't want an API for your API?
🤣
KallistiTMP@reddit
That and lack of an established industry standard.
A shitty standard that everyone begrudgingly agrees to support is way, way better than no standard.
platistocrates@reddit
Agree
freecodeio@reddit
Honestly mcps have done more damage to this industry than good. it's like the whole thing was built by some mediocre developers.
This one looks nicer and more straight to the point. I still think tool calling can be simplified evem more and there's a lot of unnecessary complexity, but as time passes things will settle and this is a good way forward.
Dudmaster@reddit
Imo, tool calling specifically is just another form of OpenAPI but for some reason specifically designed for LLMs, and I haven't been able to figure out that reason
For things beyond tools like resources or prompts that makes sense, but just tools alone I don't see the issue with using OpenAPI
razvi0211@reddit
I'd love any concrete feedback! If you have some ideas to reduce the complexity please hit me up, or open an issue on the github 🙏
Even though I started this project, I'd love to have the community as involved as possible, and I'm sure there's plenty to things to be improved.
121507090301@reddit
Not OP but I personally just wanted the AIs to be able to write, edit and manage the tools themselves, so full access to coding tools and ways to interact with what they write (including their own conversations/thoughts). My own personal setup (that is very small and basic and built to understand AI while not having access to very good models for these things) allows the AI to make python programs, save, edit (in very early development still) and run them, but I guess I need a better way to make sure the AIs know what they have access to, so I wanted to add some memory to tie these programs into it but I don't have that much time, so...
...I also think it looks cooler if the Ai doesn't need to use json to send requests but just changes the programs the AI made as needed. lol
SkyFeistyLlama8@reddit
I'm happy to see there's no first mover advantage in this field. Let the first mover fall face first into a ditch.
MCP made tool calling services available to LLMs but it wasn't easy, reliable or secure.
Mediocre-Method782@reddit
The early bird gets the worm but the second mouse gets the cheese
ei23fxg@reddit
Its a trap!
keepthepace@reddit
It drove me crazy that to find a description of the packets communication I had to find a blogpost of someone reverse engineering it.
Marksta@reddit
Most likely. Or maybe some really good devs were pulling a Javascript, took 1 week to to rush it out the door.
BidWestern1056@reddit
ive been working on npc toolkit since \~6 months before mcp came out and have aimed to try to build a cross-language protocol that makes use of Jinja and YAML to let users combine script snippets from python and (still to come) node, r, sql with natural language templated statements that simplifies the output handling and removes a lot of boilerplate around prompting. e.g. a tool for executing sql on the user's local history database:
https://github.com/NPC-Worldwide/npcsh/blob/main/npcsh/npc_team/jinxs/sql_executor.jinx
im aiming towards these jinxs (jinja execution templates) and agents being defined in a data layer like way like similar to how one can arrange sql models within a dbt ecosystem.
i dont know if i would say that this is more simplified than the way this new library does it but i am trying to get us to think beyond the individual languages and to treat agents, agent teams, and the tools they have access to in this data-layer like way.
core library here: https://github.com/NPC-Worldwide/npcpy
have finished most of my phase 1 for this project--last item being a semantic knowledge graph evolver that i have to finish in the next week cause im trying to submit a paper on it so forcing myself to do so--and about to enter the phase 2 focused largely on expanding on this data layer's capabilities
JShelbyJ@reddit
Isn’t this just an openapi spec with extra steps?
Why not just build a wrapper that converts openapi specs to tool calls?
arcticfox@reddit
This is what happened during the .com era playing out again. A lack of frameworks resulted in developers writing framework-level code for each project they develop. The lack of frameworks generates an incentive to building your own framework by abstracting framework-level code from the projects you have already completed. Everyone decides that they should do this, which results in the release of a whole lot of frameworks that are overly coupled to their original application, none of which works well. This begins the cycle of using one framework on a project, discovering that it is rife with problems (because it's not abstracted well), and then switching to another framework on their next project. The cycle repeats.
slowphotons@reddit
Interesting. Who came up with this protocol? I’m not finding any kind of “who we are” or indication of affiliation on the GitHub page. Maybe I haven’t looked hard enough yet.
Balance-@reddit
Yeah that’s really suspicious. I want to know who makes the shots.
Lesser-than@reddit
You gotta admit its a bit commical, to already have yet another std, this appears close enough to mcp that it might not ruffle too many feathers in the long run. I still think all of this is still too early and we are going to do things differently in a year or 2 any way. The giant push for mcp is over, long live UTCP!
platistocrates@reddit
A resounding "YES!" emanates from the depths of my being.
keepthepace@reddit
I have many criticism on MCP (mostly its documentation) but after diving into it, and understanding its slightly overcomplicated logic, I would argue that we don't need that, that MCP does already have it but use a misleading way to present it.
When you use a MCP "server" with the stdin/stdout transport layer, what you have is actually what we typically refer to as a "plugin", and runs locally.
It tells you "here is the list of tools you can call with these arguments" and you can tell it "call tool X with arguments A" and have the locally running plugin (typically a super simple python script that any LLM knows to generate) do the actual API call for you.
I think MCP is badly done, badly advertised, but it does the trick. If we want to get rid of it, we don't actually have to replace it with anything: OpenAI's tool use syntax (which is used by every endpoint at this stage) already covers most of what needs to be done: list tools with their parameters syntax, give function names and args in answers. MCP is actually OpenAI's tool use syntax + "serialize that in JSON through stdin/stdout or through SSE". Plus a lot of very confusing fluff to hide the triviality of it.
UTCP is a bad idea IMHO because it will ever allow to call APIs that are already trivial to call and will always miss the more complicated ones. (Go ahead, try to make it download youtube videos' audio or manage a Matrix session). Better accept you will need a trivial script most of the time and occasionally a bigger one for a variety of hard to predict cases.
smahs9@reddit
Just adding that being able to use an external registry for serving tool definitions (an external openapi schema server for example) would in practice allow enabling a lot of legacy APIs for tool calling. One aspect missing though is the data security definition (similar to the RFC posted in another comment).
TorontoBiker@reddit
I feel like we’re reinventing the SOA registry. Which is fine - we can reuse a lot of what that did. It was pretty good stuff in lots of ways. And now can be made better.
Drevicar@reddit
AI over WSDL.
potatolicious@reddit
It also enables tool calling in a lot of other (more restrictive) execution contexts. For example mobile OSes don't allow apps to just run (nor would you want it to for a bunch of memory and battery life reasons), and so having tool discovery be an endpoint unto itself was always a bad design.
Accomplished_Mode170@reddit
Open to comments too; but 💯 on dynamic JSON w/ required optional fields
Even aligns to Anthropic’s official Typescript definition
SGmoze@reddit
MCP is a fancy abstraction. Change my mind.
eleqtriq@reddit
Why? Sometimes abstractions, even fancy ones, are needed. Change my mind.
Expensive-Apricot-25@reddit
i never understood why mcp couldn't have just been a standardized API
eleqtriq@reddit
Explain how you think it would work
Reason_He_Wins_Again@reddit
https://xkcd.com/927/
dhamaniasad@reddit
The oauth setup for remote MCP servers makes me want to pull my hair out
topperge@reddit
Can you expand on this more? I work in the identity industry and truly want to better understand the challenges you're seeing.
dhamaniasad@reddit
So the dynamic client registration thing is especially painful. I've tried to build a remote MCP server multiple times with Claude Code and o3 pro and they've failed repeatedly. There's no way I will write that code myself because even before this oauth was never fun, but this is just also riddled with bugs, ChatGPT Connectors require their own specific implementation, Claude web app expects its own thing, half the clients support SSE, other half support streaming, it's a stateful protocol, it's just a mess. FastMCP exists but it doesn't support auth which kinda defeats the purpose of a framework like that.
MCP the idea is amazing. The execution leaves a lot to be desired IMO.
Accomplished_Mode170@reddit
working on abstracting away via Industry WG
e.g. 1:1 on Identity:Action via JWST
I.e. hash the request, then generate/consume token
BidWestern1056@reddit
agreed, have always been baffled by everyone's obsession with it. tried to include it with npc tools several times but it just always was such a hassle
GatePorters@reddit
Because they didn’t build that for you, they built it for large companies like Google, X&OAI, and Meta.
They know they aren’t competitive for tech or models, so they are going competitive for industrial inference pipelines.
They made circuit-tracer too
Ylsid@reddit
I do! It's because Anthropic made it!
Jon_vs_Moloch@reddit
MCP does more than “surface tools”.
platistocrates@reddit
I want it to do less.
Jon_vs_Moloch@reddit
Well that’s cool; I was trying to shed light on the “I never understood the stateful server” part. I agree that it’s cool that there are lighter alternatives, not everything needs a whole-ass server bundled with it
Amgadoz@reddit
Less is More for Protocols
juanviera23@reddit (OP)
exactly!
homarp@reddit
let's combine it with UIP (Universal Intelligence Protocol) and we're good to go.
Although, sometimes UUDP (Universal User Discussion Protocol) might also be useful.
additionalpylon1@reddit
I'll give it a shot. First look... this is very promising.
TheTerrasque@reddit
So how does this actually work with the (say) openai api tool calling functionality? This seems less structured and more complex to implement in the client / agent. MCP already have a very structured way that transfers well to tool calling, and the client / agent only needs to deal with http (or cli in some cases), while with this it seems both more random what it takes, and a lot more logic on the client / agent side. Or is it expected that llm's will write their own code that the agent then executes?
Is there a comparison on # of successful calls on both protocols?
Longjumping_Try4676@reddit
https://xkcd.com/927/
arman-d0e@reddit
Cultish cb. I
IWillAlwaysReplyBack@reddit
Nice work on the release.
Just curious - in what way is this safer than an MCP?
TracerBulletX@reddit
Hot take maybe but Anthropic actually kind of sucks at the web stack, their APIs have always been questionable.
sunomonodekani@reddit
I hope one day it will simplify to the level of being like an API and stop embracing these protocols created by any crazy person with a Github account and the money to buy bots on reddit
RevoDS@reddit
https://xkcd.com/927/
pseudonerv@reddit
yeah, we have a relatively good, never perfect, abstraction layer of computing. That's called POSIX.
geenob@reddit
Yet everyone feels compelled to could a bunch of abstraction slop on top of it. It might surprise people to learn that interacting with the POSIX API at a lower level can be cleaner and easier than interacting with big sloppy frameworks. I say that as someone who has done a fair amount of mcp development.
potatolicious@reddit
Eh, I think that's... mostly fine? More often than not you have 15 competing standards, but over time 90% of everything gravitates to 1-2 standards and the others become obscure footnotes with some nerdy fans.
And... that seems fine?
dodiyeztr@reddit
Hehe I didn't realize it was here
platistocrates@reddit
At this stage, something needs to kill MCP.
At this stage, ecosystem is immature and needs more diversity.
nrkishere@reddit
Any "open" protocol, that is supposed to be universal standard, shouldn't be managed by commercial organizations. This leads to movement in a direction that favors the commercial org behind it, even if it is open source in paper. This is why I don't prefer MCP. A2A has already moved to linux foundation. Hope that this one gets more adoption and moves to linux or apache foundation
FriskyFennecFox@reddit
I'm yet to find a use case for these protocols. Between learning documentation of such protocols and asking an LLM to write a specialized script, the latter is always quicker.
unknown_history_fact@reddit
This is a proposal to open specs. Not "open standard", yet
sannysanoff@reddit
The MCP contains tool calls, but not only tool calls: it contains some resources and roots, so it tries to provide some virtual filesystem for tools to operate on. Other issue, it's rarely used.
However, did you know that tool can call back LLM to get some generic AI services, using same bi-directional protocol? Ask user for some additional details?
Basically name says, "model context protocol" (to extend context) vs "tool-call-only" protocol.
UTCP benefits most for http(s)-provided services. For CLI/TCP/everything else, you'll need to tweak config same way like MCP now, because no discovery for those, you'll even more complex configs than MCP has, just read the docs.
I think we'll benefit from both simultaneously. MCP haters gonna hate.
IngwiePhoenix@reddit
Gives me JavaScript vibes; re-inventing a wheel that's spinning quite fine and, by now, very well tested ... for the sake of reinventing it.
I could be wrong. But that's just my impression. o.o
mikewasg@reddit
In my opinion, the concept of UTCP is much better than MCP.
miscellaneous_robot@reddit
where's the RFC?
phovos@reddit
No RFC, this is a repeat of MCP if there is not even a fucking bourbaki and or bnf containing RFC.
K4Unl@reddit
https://xkcd.com/927
LelouchZer12@reddit
Yet another standard... reminds me of some xkcd
cbterry@reddit
Nice, though I never used MCP because it was easier to convert the code to run on my local agent.
premium0@reddit
Calling these protocols is so comical. You don’t need this shit to invoke an API.
Ok_Doughnut5075@reddit
Generally speaking, protocolization is about standardizing a way people do things rather than making that thing possible in the first place. EX. xml-rpc, SOAP, REST all offered standardized ways to do things people could already do
UnionCounty22@reddit
But but you don’t want a file system MCP when the agent already has that built in? Whaaat
f1datamesh@reddit
This seems to address some of my frustrations with MCP. I will check this out. I think we will have a few different takes on tool calling like this and MCP and hopefully we all then standardize on the best protocol. So far, this is great, so better than MCP!
Great work!
ParaboloidalCrest@reddit
Glad I never got around to learning MCP. And who knows, maybe I'll sleep on that one too. Dirty Python script FTW! for now.
SkyFeistyLlama8@reddit
I'm not a fan of abstractions because you don't know what the LLM stack is doing or returning. If you're using cloud LLMs, it's just an HTTP request. You have system prompt, you have context tokens, send to LLM and you get reply.
It really is that simple. Wrap it up in your own workflows to maintain control instead of leaving it to Langchain or whatever to do the logic for you.
As for MCP, it's yet another example of the abstraction-heavy thinking that led to frameworks like Langchain.
Ryuuzake@reddit
how to use this with Windsurf?
ilintar@reddit
The sad thing is, unless some big backer adopts it, this won't beat MCP :( MCP only got so popular because Anthropic was behind it.
dung11284@reddit
finally no more shitty server lag from tool call
photonenwerk-com@reddit
I especially like scaling to hundreds/thousands of tools:
nontrepreneur_@reddit
Not sure why this isn’t a link (or maybe it’s an issue with the Reddit mobile app)…
https://github.com/universal-tool-calling-protocol
BraceletGrolf@reddit
Does this handle multi-shot better than MCP ? I think without good multi-shot support such standards will hit a wall
Asleep-Ratio7535@reddit
Great, I was hoping the tool call plugin would include a tool definition and tool execution, and then add it to the list in the system prompt.
bbbar@reddit
Does Python SDK also require the installation of Node.js like in the MCP case?
dodiyeztr@reddit
Mandatory xkcd reference: https://xkcd.com/927/
-lq_pl-@reddit
Why does this not have pydantic_ai integration.
razvi0211@reddit
I'm not primarily a python dev, but thanks for the heads up, I'll look into it!
Also any contributions are super welcome!
s_arme@reddit
Finally, MCP done the right way!
juanviera23@reddit (OP)
python client: https://github.com/universal-tool-calling-protocol/python-utcp
Accomplished_Mode170@reddit
This looks not dissimilar from an Industry WG RFC on zero-trust MCP; bringing this up with Anthropic next week
Literally had folks threatening a hard fork; because dynamic schemas and optional JSON fields say we can do better