Skip to main content
Hay dos servidores MCP que te vas a encontrar alrededor de UTMKit, y hacen trabajos distintos. https://docs.utmkit.co/mcp pertenece a este sitio de documentación: busca y lee estas páginas, y nada más — apunta un asistente a él para preguntar cómo funciona el producto. https://app.utmkit.co/mcp pertenece al producto: opera tu espacio de trabajo — lista, crea, edita y retira enlaces, gestiona campañas y reglas, lee el informe — y necesita un token. Mismo protocolo, misma ruta, dos hosts. Esta página es sobre el segundo.

Qué es

Un servidor MCP (Model Context Protocol), hablado sobre el transporte Streamable HTTP del protocolo, dentro del producto mismo. Cada herramienta llama a la misma operación que llaman la consola y la API, así que las reglas del espacio de trabajo aplican sin cambios: un enlace que la convención rechazaría en la consola se rechaza aquí, con la misma frase, como un resultado de herramienta que tu asistente puede leer y transmitir o reparar. Cada solicitud lleva el mismo encabezado que la API:
Emite el token en la página Tokens de la consola con los permisos que el asistente debería tener, como se describe en Autenticación y tokens. El token fija el espacio de trabajo; ninguna herramienta toma un argumento de espacio de trabajo, organización o usuario, y nada que diga un asistente puede mover una llamada a otro.

Conectar un cliente

Un comando, ejecutado en cualquier terminal:
Luego /mcp en una sesión lista el servidor y las herramientas que tu token permite. Para mantener el token fuera de la línea de comandos, ponlo en una variable de entorno y referéncialo desde .mcp.json como "Authorization": "Bearer ${UTMKIT_TOKEN}".
Cualquier otro cliente MCP que hable Streamable HTTP y pueda enviar un encabezado funciona de la misma manera.

Las herramientas

Veintiocho herramientas, cada una detrás de exactamente un permiso de token. Las lecturas solo necesitan el permiso; las escrituras también necesitan que tu rol en el espacio de trabajo las permita, verificado en vivo en cada llamada. Cada herramienta bajo rules:write también necesita un rol de administrador o propietario. Una herramienta que le falta al token se oculta, y se rechaza por nombre si se llama de todos modos. La lista de herramientas que recibe un cliente se filtra a lo que permiten los permisos del token y tu rol, y se recalcula en cada solicitud de lista. Una herramienta oculta sigue estando ahí: un asistente que llama a create_campaign con un token de solo enlaces obtiene un resultado de herramienta que dice This token does not carry campaigns:write. en vez de “herramienta desconocida”, así que puede decirte exactamente qué casilla marcar en el siguiente token. No hay herramienta de conversiones. Una conversión es un resultado que tu servidor reporta contra un enlace — una venta, un registro — y un servidor hace eso a través de la API con el permiso conversions:write, no a través de un asistente. Ver Conversiones.

Qué esperar

  • Cada escritura se atribuye a ti y al token, y aparece en el registro de actividad como un cambio hecho en la consola.
  • Los rechazos son resultados de herramienta, marcados como errores, una frase cada uno: el rechazo de la convención, un valor no aprobado, un destino que el escáner rechazó, una asignación agotada. Un error de protocolo, en cambio, significa que el cliente habló mal.
  • La puerta es la puerta de la API. Un token revocado o vencido falla la conexión con 401; una organización sin suscripción vigente con 402; aplica el límite de solicitudes por token, con Retry-After. Ninguna sesión sobrevive a su token.
  • La degradación toma efecto en la siguiente llamada. Si tu rol cambia, las herramientas de escritura desaparecen de la lista en la siguiente solicitud de lista, y una llamada hecha antes de eso se rechaza por el rol.

El otro servidor, una vez más

Si tu asistente responde una solicitud de crear un enlace con un resultado de búsqueda, está hablando con docs.utmkit.co/mcp, el servidor de la documentación. Reconéctalo a app.utmkit.co/mcp con un token.