一句话定义：UTCP（Universal Tool Calling Protocol，通用工具调用协议）是一套统一描述"工具该怎么调"的开放约定，让大语言模型（LLM）直接调用本地或远程的工具，而不必先给每个工具套一层专门的服务器。
它怎么工作
现在让智能体用工具，常见做法是给每个工具写一个"转接头"：把工具包进一个服务进程，客户端按固定协议跟它说话，它再去调真正的工具。这有点像所有店铺都得先装一部统一总机，你想买东西得先拨总机，再让总机转到柜台。
UTCP 只统一"怎么描述"，不统一"怎么通话"。工具提供方发布一份说明书（通常是一份 JSON 文档），写清楚工具名、用途、参数，以及实际怎么调——是发一个 HTTP 请求、跑一条命令行、调一次 gRPC，还是执行本地脚本。模型读完说明书生成参数，运行时按说明书里写的原生方式直接发起调用。
和 MCP 的差别
MCP（Model Context Protocol）统一的是传输与交互，通常要跑一个 MCP Server 把工具包装进去；UTCP 统一的是描述，传输保持原样。粗略地说，一个是统一插座，一个是统一说明书。
| 维度 | MCP | UTCP |
|---|---|---|
| 统一对象 | 协议与传输 | 工具描述格式 |
| 是否需要包装服务 | 通常需要 | 不需要，直连原生接口 |
| 已有 API 的改造成本 | 写一层适配 | 写一份描述 |
| 代价 | 多一跳、多一个进程要维护 | 调用方自己实现各类调用，鉴权和密钥也落在调用方 |
两者不是替代关系。需要会话状态、资源管理、集中鉴权的场景，MCP 的集中式设计更省心；只想让已有的 API、脚本、内网服务被模型用起来，UTCP 的"零包装"更轻。
Ruby 实现为什么值得关注
UTCP 最早在 Ruby 生态里被提出和推广。这件事本身就说明问题：Ruby 不在这一轮 AI 热潮的中心，却是 Web 后端、运维脚本、内部工具的重镇。连这种"胶水语言"都能用很少的代码实现，说明工具调用并不依赖重型运行时——它更像是给现有代码补一份机器可读的说明书。Ruby 社区"约定优于配置"的风格，也解释了 UTCP 为什么选"只描述、不接管"的路线。
对不同人的意义
对工程师：不必为每个内部接口写适配服务，先把描述和权限边界定清楚；但安全要自己兜住——哪些工具能跑、谁来授权、密钥存在哪里，协议本身不会替你解决。具体的描述字段和调用类型，以官方页面为准。
对普通职场人：你常用的内部系统、脚本、报表命令，可能因为有人写了一份说明书，就被助手直接调用。瓶颈会从"谁来接线"变成"该不该让它接、接了出事谁负责"。