Ruby UTCP: A Scalable, Secure Alternative for Tool Calling

What Is Ruby UTCP

Ruby UTCP brings UTCP 1.1 (Universal Tool Calling Protocol) to the Ruby ecosystem, providing applications and AI agents with a standardized mechanism for tool discovery and invocation. Unlike MCP (Model Context Protocol), which has gained significant traction recently, Ruby UTCP emphasizes letting agents access tools directly through native protocols — without the need for an additional middleware layer.

The project launched on Product Hunt and received 85 upvotes, ranking 7th for the day, listed under the Open Source, Artificial Intelligence, and GitHub categories. It was developed by Juan Viera Garcia and other contributors, is fully open source, and was built specifically for the Ruby community.

UTCP (Universal Tool Calling Protocol) is an open protocol specification designed to standardize how AI agents interact with external tools. Its core philosophy is that agents should invoke tools directly over the target service's native transport protocol, rather than relying on a unified middleware proxy for translation. UTCP 1.1 is the current version of the protocol and defines foundational specifications for tool registration, capability manifests, invocation conventions, and response formats. Compared to MCP's "unified server-side wrapping" approach, UTCP acts more like a meta-protocol: it describes how to describe tools, leaving the specifics of communication to each transport layer. This design allows a single tool definition to be reused across HTTP, gRPC, WebSocket, and other transports — the protocol itself is not tightly bound to any single communication method.

Multi-Transport Support Is the Standout Feature

The most striking aspect of Ruby UTCP is its native support for 12 transport protocols, covering today's major communication paradigms:

• HTTP
• CLI (command-line invocation)
• WebSocket
• gRPC
• GraphQL
• MCP (compatible with Model Context Protocol)
• WebRTC

This broad transport layer coverage means developers no longer need to introduce multiple tool-calling frameworks for different scenarios. Whether it's a traditional HTTP REST interface, a low-latency gRPC service, or real-time WebSocket and WebRTC connections — all can be invoked under a single protocol specification.

Notably, Ruby UTCP includes MCP as one of its supported transports, which signals that it isn't trying to wholesale replace MCP. Instead, it offers a higher-level, more inclusive abstraction — one that's compatible with the MCP ecosystem while extending into native protocol scenarios that MCP currently struggles to cover.

How UTCP and MCP Differ in Positioning

Over the past year, MCP has become an important protocol for connecting large language models with external tools. However, it primarily revolves around a standardized server-side wrapping approach. UTCP takes a different stance: it advocates for AI agents to discover and invoke tools as close to the native protocol as possible, reducing the overhead and expanded attack surface that comes with protocol translation.

The project positions itself as a "scalable, more secure alternative" to MCP. The scalability claim refers to multi-transport support and programmable multi-tool workflows; the security claim relates to reducing middleware layers and relying directly on native authentication mechanisms. Of course, these are the project's own stated positions — actual security and scalability will need to be validated in real production environments.

MCP (Model Context Protocol) was introduced by Anthropic in late 2024, designed to give large language models a standard interface for accessing external context and tools. MCP's architecture centers on the "MCP Server": tool providers wrap themselves into MCP-compliant servers, and models or agents communicate with them through a unified MCP client. This centralized abstraction lowers the barrier to entry but introduces an additional protocol translation layer — native REST, gRPC, and other interfaces must first be wrapped as MCP services before they can be accessed. UTCP criticizes this pattern for introducing unnecessary intermediaries, arguing that each proxy layer added means a larger attack surface and more latency overhead. The two are not purely at odds: as noted above, Ruby UTCP already includes MCP as a supported transport protocol, suggesting that in practice the two are more likely to complement each other than to serve as direct replacements.

Key Capabilities for AI Agents

Beyond its transport breadth, Ruby UTCP also provides a set of practical capabilities tailored to AI agent scenarios:

Streaming and Authentication

Support for streaming means agents can receive results incrementally when invoking long-running tools or LLM interfaces, rather than waiting for a full response — which is critical for interactive experiences. The built-in auth mechanism addresses permission and identity management in tool calls.

OpenAPI Auto-Discovery

Through OpenAPI discovery, Ruby UTCP can automatically parse interface definitions that conform to the OpenAPI specification, quickly transforming existing REST APIs into tools that agents can call. This dramatically lowers the barrier to integrating legacy services into the agent ecosystem.

OpenAPI (originally Swagger) is the most widely used specification for describing REST APIs, defining paths, parameters, request bodies, and response structures in JSON or YAML. Most modern web frameworks — including Rails — can automatically generate OpenAPI 3.x-compliant documentation. Ruby UTCP's OpenAPI discovery feature takes advantage of this: it parses OpenAPI documents exposed by existing services, automatically extracts callable endpoints, and converts them into UTCP tool definitions that agents can search and invoke. This means a Rails application with complete OpenAPI documentation could theoretically be integrated into an agent ecosystem without any changes to business logic, dramatically shortening the AI modernization cycle for existing services.

CodeMode Programmable Workflows

CodeMode allows developers to orchestrate programmable multi-tool workflows, enabling agents to chain multiple tool calls and combine logic within a single task. This kind of capability is one of the core battlegrounds in the current Agent framework space, and it's what distinguishes Ruby UTCP from a simple tool gateway.

What This Means for the Ruby Ecosystem

For a long time, open-source tools for AI agents and tool calling have been concentrated in the Python and JavaScript ecosystems, leaving Ruby developers without a ready-made standardized solution. Ruby UTCP fills that gap, enabling Rails applications and Ruby services to integrate natively into modern AI agent architectures.

For teams already building backends in Ruby, this means they can implement tool discovery, protocol invocation, and multi-tool orchestration within their familiar tech stack — without migrating to another language or pulling in heavyweight dependencies.

Questions Worth Watching

As a newly launched open-source project, Ruby UTCP currently reads more as a demonstration of capabilities and vision. The maturity of its support for 12 transport protocols, the stability of CodeMode under complex workflows, and the actual validity of its "more secure than MCP" claim all still need real-world community feedback.

With only 1 comment so far, the project is clearly in its early stages of adoption. For developers tracking the evolution of AI tool-calling protocols, Ruby UTCP offers an interesting case study in how the UTCP approach and the MCP approach might compete — and coexist.