juanviera23

Would you pay to gain the ability to create forecasting models?

Examples:

1. You’re building a airplane ticket booking platform, and want to offer users forecasts of when ticket prices will go up or down in the next 30 days.

2. You have a retail shop, and want to build an internal dashboard that forecasts how many items of each type you need to buy next week, given how many you sold in the last month

3. You’re building an real estate investment platform, and want it to notify users how real estate prices will change over the next 5 years (given sq. m., distance, location, etc.)

Problem:

You want to add forecasting to the app or platform you’re building

However, you don’t know enough to build and deploy a production-grade ML model

What if you could have a platform that could autonomously train and deploy ML models for you?

Solution:

We propose a vibe coding platform (like https://lovable.dev/ )

To empower everyday users to train and deploy machine learning models to production without needing to know anything about the field

Should we build it?

the problem concretely is that they currently cannot get the right authentication for checking out, or sending a payment, because it is not standardized

so the question is, how can we help them achieve that?

Hi 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

hulloo I think this is really good feedback and something we'll look into, thank you for sharing!

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

there is a TS version actually, all the SDKs are here: https://github.com/universal-tool-calling-protocol

yupp that's what UTCP does as well, standardizing the tool-calling

(without needing an MCP server that adds extra security vulnerabilities)

I agree MCP has these flaws, idk why we need MCP servers when LLMs can just connect to the existing API endpoint

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

TL;DR: MCP routes tool calls through wrapper servers; UTCP describes the tool and then calls the tool’s native endpoint directly (HTTP/gRPC/WebSocket/CLI), keeping your existing auth/observability and cutting a hop.

Trade-offs: MCP centralizes policy & session semantics; UTCP pushes security to the tool boundary and provenance to manuals.

Curious where folks land on DX vs. infra complexity.

I agree, that's the problem

I'm not sure MCP was designed to be as popular as it is today

But given that it is, and that many people are deploying in critical production settings, all these problems should somehow be addressed, because right now it feels like a mess