MCP vs UTCP: qué es UTCP y cuándo usar cada protocolo

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. En la comparación MCP vs UTCP, la diferencia está en quién llama a la API: con MCP, un servidor intermedio; con UTCP, el propio cliente.

Llegamos al tema por un reel de KodeKloud del 2 de noviembre de 2026. Lo explica con un agente que crea incidencias en Jira, y en lo esencial es correcto. Pero en tres minutos no cabe todo, y aquí añadimos lo que deja fuera con datos consultados el 8 de noviembre.

Primero, dos palabras de contexto. MCP (Model Context Protocol) es el estándar con el que una aplicación de IA se conecta a un servidor que le ofrece herramientas. Una herramienta (tool) es una función que el modelo puede pedir que se ejecute, como «buscar una factura». El cliente es la parte del agente que hace esa conexión.

Vas a ver cómo funciona UTCP, en qué cambia una llamada, su adopción real y cuándo elegimos cada protocolo en Nortia Logística, la empresa ficticia del curso. Te ayudará saber cómo se reparten el trabajo host, cliente y servidor, que explicamos en la lección de arquitectura. Si dudas entre una API REST, el function calling y MCP, empieza por MCP vs API REST y function calling. Los términos de MCP los tienes en el glosario.

Qué es UTCP

UTCP es un formato para describir herramientas y la forma de llamarlas, más unos SDK cliente (bibliotecas para programar) que saben leerlo. No define mensajes propios. Cuando el agente usa una herramienta, por la red viaja la petición HTTP, el comando o el evento del protocolo original.

El reel lo cuenta con Jira. El modelo no llama a Jira por sí solo. Genera una llamada a herramienta y un código la ejecuta, que es el esquema del function calling.

Con MCP, ese código es un cliente MCP que habla con un servidor MCP. Atlassian publica uno remoto oficial, el Rovo MCP Server. Con UTCP, el cliente parte de la especificación OpenAPI de Jira (la descripción estándar de una API REST), obtiene un manual y llama a la API de Jira 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, que se llama con un GET HTTP a una URL. Cada herramienta lleva su nombre, 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.

Según la documentación 1.1, el cliente sigue estos pasos:

1. Descarga y valida el manual.
2. Registra sus herramientas.
3. Cuando el agente elige una, resuelve las variables de autenticación.
4. Llama al endpoint nativo con el plugin del protocolo que toque.

Los plugins estables de la 1.1 son HTTP, SSE (eventos que el servidor envía por una conexión abierta), CLI (comandos de terminal), texto y MCP. WebSocket está solo en el SDK de Python. gRPC, que el reel menciona, solo aparece en las implementaciones de Go y Rust.

¿Cuál es la diferencia entre MCP y UTCP?

MCP estandariza la conversación entre cliente y servidor, y 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.

En MCP, cliente y servidor se hablan con mensajes JSON-RPC 2.0, un formato de petición y respuesta en JSON. La petición que ejecuta una herramienta es tools/call. El transporte es el canal por el que viajan esos mensajes.

Míralo con Nortia. El agente de soporte quiere buscar una factura en la API REST interna de facturación, que usa OAuth. Con MCP pasa por el servidor nortia-facturacion:

sequenceDiagram
  participant A as nortia-agente-soporte
  participant S as nortia-facturacion
  participant F as API de facturación
  A->>S: tools/call buscar_factura (JSON-RPC)
  S->>F: petición HTTP con la credencial del servidor
  F-->>S: datos de la factura
  S-->>A: resultado de la tool
  Note over A,S: el servidor MCP aplica permisos y auditoría

Con UTCP, la API de facturación publica un manual y el agente la llama sin intermediario:

sequenceDiagram
  participant A as nortia-agente-soporte
  participant F as API de facturación
  A->>F: GET /utcp (una vez, se cachea)
  F-->>A: manual: tools y plantillas de llamada
  A->>F: petición HTTP que describe el manual
  F-->>A: datos de la factura
  Note over A,F: la credencial la pone el cliente

La tabla compara MCP 2026-07-28 con UTCP 1.1 criterio a criterio. Lo de MCP sale de la especificación y lo de UTCP, de su documentación y sus repositorios.

Antes de leerla, cuatro términos de MCP. stdio es el transporte local, en el que el cliente arranca el servidor como un proceso de tu máquina. Streamable HTTP es el transporte remoto, sobre HTTP. server/discover devuelve las versiones, capacidades e identidad del servidor, y tools/list, la lista de herramientas. El MCP Registry es el catálogo público de servidores MCP.

¿Quién guarda las credenciales en cada caso?

Con MCP las credenciales de la API viven en el servidor o se delegan por OAuth. Con UTCP viven en cada cliente. El reel dice bien que el manual no expone el secreto, y menciona que el cliente usa las credenciales configuradas, pero no explica la consecuencia: que cada cliente tiene que guardarlas.

OAuth 2.1 es el estándar para que una aplicación actúe en nombre de una persona sin conocer su contraseña. En MCP con transporte HTTP, el servidor es un resource server OAuth 2.1, es decir, solo atiende peticiones con un token que emite un servidor de autorización aparte. El cliente encuentra ese servidor de autorización en un documento que publica el servidor MCP, Protected Resource Metadata (RFC 9728), y la persona usuaria inicia sesión allí. El servidor habla con la API final con su propia credencial o con la que le delegan.

En UTCP, la guía para proveedores explica que el cliente resuelve los marcadores con su configuración, un .env o un almacén de secretos. La ventaja es que se reutiliza la autenticación que la API ya tiene. El coste es que cada cliente necesita sus credenciales, y la especificación no define un flujo de autorización por usuario como el de MCP.

flowchart LR
  subgraph M["Con MCP"]
    U1["Persona usuaria"] -->|"inicia sesión (OAuth 2.1)"| C1["Cliente MCP"]
    C1 -->|"token por usuario"| S1["Servidor MCP"]
    S1 -->|"credencial propia o delegada"| A1["API de facturación"]
  end
  subgraph T["Con UTCP"]
    MA["Manual: marcador FACTURACION_TOKEN"] -.->|"dice qué hace falta"| C2["Cliente UTCP"]
    E["Configuración del cliente (.env o almacén)"] -->|"valor real"| C2
    C2 -->|"credencial del cliente"| A2["API de facturación"]
  end

NiharDaily, autor de la única medición independiente de los dos protocolos que hemos encontrado, lo resume así: es aceptable para un agente interno y mala opción para software que distribuyes a clientes. Es su opinión, y la compartimos.

Qué partes de MCP no tienen equivalente en UTCP

UTCP solo trata herramientas. Todo lo demás que define MCP no tiene equivalente, y ninguna de las comparativas que hemos leído lo dice.

Prompts y sampling los descarta el propio proyecto en la sección de limitaciones de su plugin MCP. Elicitación, Tasks, Apps y suscripciones no aparecen en la documentación de UTCP que revisamos. Eso indica que no están, pero no demuestra que no se puedan construir encima. Si tu caso necesita algo de esta tabla, la lección de herramientas te ayuda a separar lo que es una tool de lo que no. Los resources y los prompts los explicamos en las lecciones de recursos y de prompts, y las MCP Apps, en este artículo.

¿Es UTCP más rápido o gasta menos tokens?

Es algo más rápido porque se ahorra un salto, pero la diferencia medida es de medio milisegundo. Tampoco ahorra contexto, el texto que el modelo tiene que leer y que se cuenta en tokens. Describir las mismas herramientas ocupa casi lo mismo en los dos formatos.

La página UTCP vs MCP del proyecto trae una tabla de latencias (50 ms frente a 75, 200 frente a 250, 10 frente a 20) y otra de memoria («0 MB» frente a «50-200 MB por servidor»). No dice con qué método, hardware, código ni fecha se midió, así que no la usamos como dato.

La única medición independiente con método que hemos encontrado es de NiharDaily, del 4 de noviembre de 2026. Midió 10 herramientas en un Apple M2, todo en local, con 2.000 llamadas tras 200 de calentamiento y tres pasadas. Las medianas fueron 0,161 ms con UTCP, 0,162 ms con fetch directo y 0,632 ms con MCP sobre Streamable HTTP sin estado.

El propio autor avisa de que su servidor MCP da una cota superior (crea un objeto por petición, así que la cifra de MCP es un máximo). Tampoco probó redes reales ni clientes como Claude, y nadie lo ha replicado. Nuestra lectura es que, frente a un modelo que tarda segundos en responder, esa diferencia no decide nada.

Con los tokens pasa algo parecido. En esa misma prueba, el manual UTCP de las 10 herramientas ocupa 6.783 bytes y el tools/list de MCP, 6.052. Si te preocupa el contexto, lo que ahorra es cargar menos definiciones, por ejemplo con Code Mode.

¿Claude o ChatGPT soportan UTCP?

No hemos encontrado ningún cliente grande con soporte nativo de UTCP a 8 de noviembre de 2026. Para llegar a Claude, UTCP pasa por un puente MCP.

Unified.to, que publica sus herramientas por los dos protocolos, lo dice en su documentación de noviembre de 2026: ninguno de los grandes proveedores de LLM lo soporta de forma nativa todavía. Se usa con una librería cliente o un adaptador. Nuestra búsqueda en la documentación de OpenAI y Anthropic tampoco dio resultados, aunque no fue exhaustiva.

El proyecto está vivo. La organización de GitHub nació el 24 de junio de 2025, el SDK va por la 1.2.0 (15 y 16 de septiembre de 2026 en npm y PyPI) y hubo commits hasta el 25 de octubre.

Aun así, es pequeño. El RFC sigue en estado Draft, lo gestionan tres administradores, uno de ellos vinculado a la empresa Bevel Software, y no depende de ninguna fundación. The Register lo llamó en enero de 2026 «un protocolo de nicho».

Estos son los números a 8 de noviembre de 2026, con las descargas de los últimos 30 días:

En npm, MCP tiene unas 14.500 veces más descargas. Las descargas incluyen integración continua, espejos y dependencias, así que sirven para el orden de magnitud y no para contar usuarios. MCP, por su parte, está desde el 9 de diciembre de 2025 en la Agentic AI Foundation de la Linux Foundation, la misma fundación a la que se unió A2A, un protocolo para que agentes hablen entre sí (lo contamos en A2A frente a MCP). Hay productos que publican manuales UTCP, como Unified.to y Simplifier 11, pero ninguno publica cifras de uso.

¿Puedo usar UTCP y MCP juntos?

Sí, y el propio proyecto UTCP lo facilita en las dos direcciones. El precio es mantener dos descripciones de las mismas herramientas.

• Un cliente UTCP que usa servidores MCP. El plugin utcp-mcp registra servidores MCP, por stdio o HTTP, y llama a sus tools con un prefijo de servidor, como filesystem.read_file. Mantiene sesiones persistentes con esos servidores.
• Manuales UTCP dentro de Claude o Cursor. El puente @utcp/mcp-bridge es un servidor MCP que expone manuales UTCP como tools en Claude Desktop, Claude Code o Cursor. Tuvo 135 descargas en npm el último mes.
• Publicar en los dos. Unified.to mantiene su servidor MCP y sirve además un manual UTCP con las mismas herramientas y permisos.

Lo más usado del proyecto es otra pieza, code-mode (1.654 estrellas). Deja que el agente escriba TypeScript que llama a herramientas MCP y UTCP, así que funciona como una capa encima de los dos.

Lo que el reel y la web de UTCP no cuentan

El reel acierta en lo técnico y presenta bien el intercambio entre los dos, pero le falta contexto. La web del proyecto, en cambio, compara UTCP con el MCP de 2025.

Al reel le falta decir que ningún gran cliente soporta UTCP de forma nativa y que UTCP no tiene prompts, sampling, elicitación, Tasks ni MCP Apps. Menciona que el cliente usa credenciales configuradas, pero no explica que eso obliga a que cada cliente guarde las suyas. Cita gRPC, que solo existe en las implementaciones de Go y Rust, y llama a UTCP «más rápido» sin dar cifra.

La página UTCP vs MCP describe un MCP «Anthropic-led» y con estado. Desde el 9 de diciembre de 2025 MCP está en la Agentic AI Foundation, y la versión 2026-07-28 no tiene sesión. También dice que MCP no puede llamar directamente a WebSocket ni a una CLI. Es verdad que la especificación no los define, pero un servidor MCP puede envolver cualquiera de los dos.

Las opiniones van aparte. En el hilo de lanzamiento en Hacker News hubo escepticismo por «otra capa de abstracción». Un comentarista señaló el acoplamiento: sin servidor como interfaz, el agente queda más atado a la herramienta, y la latencia no es lo que más pesa en una consulta a un LLM. Un colaborador de UTCP le respondió que el proyecto no va de latencia, sino de seguridad y de no reconstruir infraestructura. En ese debate, sobre el acoplamiento, nos parece que el comentarista tiene razón.

Cuándo usar cada uno: el caso de Nortia Logística

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.

Así lo aplicaríamos en Nortia:

Antes de añadir cualquiera de los dos, conviene preguntarse si hace falta un protocolo. Lo tratamos en las lecciones Qué construir y cuándo no y Beneficios y desafíos, que incluye cuándo no conviene MCP. Si quieres situar UTCP entre el resto de siglas, mira el mapa de protocolos de agentes de IA.