UTCP (Universal Tool Calling Protocol) es una especificación abierta que describe en un «manual» JSON las herramientas que ya existen, con lo que el cliente necesita para llamarlas por su protocolo nativo. La diferencia con MCP está en quién llama a la API: con MCP, un servidor intermedio; con UTCP, el propio cliente.
Este artículo es un extracto de nuestra guía en español sobre MCP vs UTCP, escrita contra la especificación MCP 2026-07-28 y UTCP 1.1, con datos consultados el 8 de noviembre de 2026.
Qué es UTCP
UTCP es un formato para describir herramientas y la forma de llamarlas, más unos SDK cliente que saben leerlo. No define mensajes propios: por la red viaja la petición HTTP, el comando o el evento del protocolo original.
El modelo no llama a una API por sí solo: genera una llamada a herramienta y un código la ejecuta. Con MCP, ese código es un cliente MCP que habla con un servidor MCP. Con UTCP, el cliente obtiene un manual y llama a la API directamente.
Un manual tiene este aspecto. Es el ejemplo que da la propia documentación para servirlo en GET /utcp desde una API existente:
{
"manual_version": "1.0.0",
"utcp_version": "1.0.1",
"tools": [{
"name": "get_weather",
"description": "Get current weather for a location",
"inputs": {
"type": "object",
"properties": {"location": {"type": "string"}},
"required": ["location"]
},
"tool_call_template": {
"call_template_type": "http",
"url": "http://localhost:8000/weather",
"http_method": "GET"
}
}],
"auth": {
"auth_type": "api_key",
"api_key": "${WEATHER_API_KEY}",
"var_name": "appid",
"location": "query"
}
}
Literal de utcp.io, Quick Start, «Option B: Add a discovery endpoint to your existing API». No lo hemos ejecutado.
El manual declara una herramienta, get_weather, con su esquema de entrada y una plantilla de llamada (tool_call_template) que dice cómo invocarla. El bloque auth describe la autenticación, pero el secreto no está escrito: ${WEATHER_API_KEY} es un marcador que el cliente sustituye con un valor de su propia configuración. Los plugins estables de la 1.1 son HTTP, SSE, CLI, texto y MCP.
MCP vs UTCP, criterio a criterio
MCP estandariza la conversación entre cliente y servidor. UTCP estandariza la descripción de la herramienta y se aparta de la llamada. Por eso con MCP hay un salto más, y con UTCP el cliente carga con más trabajo. Lo de MCP sale de la especificación y lo de UTCP, de su documentación y sus repositorios.
| Criterio | MCP 2026-07-28 | UTCP 1.1 |
|---|---|---|
| Transporte | JSON-RPC 2.0 sobre stdio (proceso local) o Streamable HTTP (remoto). Un único formato de mensajes | El de cada herramienta (HTTP, SSE, CLI, texto, MCP). No hay mensaje UTCP en la red |
| Autenticación | Opcional. En HTTP, OAuth 2.1 con el servidor como resource server. En stdio, credenciales del entorno | El manual declara el esquema (api_key, basic, oauth2) con marcadores ${VAR} y el cliente pone el valor |
| Latencia | Un salto más (cliente, servidor, API) | Sin salto intermedio. En la única medición independiente, unos 0,5 ms menos |
Dos consecuencias. Las credenciales viven en cada cliente (con MCP, en el servidor o delegadas por OAuth). Y UTCP solo trata herramientas, sin resources, prompts, elicitación, Tasks ni MCP Apps. La diferencia de latencia es de medio milisegundo y, frente a un modelo que tarda segundos en responder, nuestra lectura es que no decide nada.
Con UTCP la confianza pasa al cliente. La documentación de seguridad de UTCP reconoce riesgo de inyección en la sustitución de variables y que el protocolo CLI es de alto riesgo. A nuestro juicio, ninguno de los dos es más seguro por diseño: cambia lo que hay que endurecer, el servidor o el cliente.
Cuándo usar cada uno
Si el cliente de IA no es tuyo, MCP. Si es tuyo y ya tienes la API bien descrita, UTCP merece una evaluación. Es nuestra recomendación, no un dato de las fuentes. En Nortia Logística, la empresa ficticia del curso:
| Situación | Elegimos | Por qué |
|---|---|---|
| Soporte consulta pedidos y facturas desde Claude o ChatGPT, y los abonos necesitan aprobación | MCP | Esos clientes hablan MCP. Hay OAuth por usuario y elicitación para aprobar |
| Un script interno del almacén, en Python, lee 5 endpoints de una API REST con OpenAPI (supuesto para el ejemplo) | UTCP, o una llamada directa | Nortia controla el cliente y el manual sale del OpenAPI. Se ahorra un servicio sin perder nada |
| Transportistas externos usarán las herramientas con clientes que Nortia no conoce | MCP | No controlas el cliente, así que pesa más el estándar de conexión y autorización |
La guía completa incluye lo que este extracto deja fuera: los diagramas de la misma llamada con MCP y con UTCP, el flujo de credenciales con OAuth 2.1, la tabla de capacidades de MCP sin equivalente en UTCP, la medición de latencia y de tokens, los datos de adopción (descargas, estrellas, gobernanza y estado del RFC), el soporte real en Claude y ChatGPT, cómo usar UTCP y MCP juntos con sus puentes y qué deja sin contar el reel de KodeKloud. Léela en DesarrolloMCP: MCP vs UTCP.
Si quieres aprender MCP desde cero, el curso de DesarrolloMCP tiene el nivel Básico gratis (14 lecciones, sin tarjeta), en español.
Top comments (0)