Servidor MCP — `/mcp-tokens`

Tokens del servidor MCP, con usuario de servicio, último uso y validez

El CMS publica un servidor MCP (Model Context Protocol): una dirección que un asistente de IA — Claude Desktop, Claude Code, o cualquier cliente que hable el protocolo — usa para leer y configurar integraciones, conversando con el sistema en vez de conversar sobre él.

En la práctica, lo que era “abre la pantalla de Aplicaciones, crea una Interfaz, después una Entrega, elige el tipo, completa los campos obligatorios de ese tipo” pasa a ser una frase: “crea una entrega HTTP POST hacia el MES en la aplicación SAP, validando el retorno”. La IA descubre lo que existe, arma el plan, lo revisa y lo aplica.

Este servidor no es un canal de mensajes. Configura y diagnostica. Enviar y recolectar mensajes sigue siendo la API pública, con API Key — o, para un agente de IA, el Servidor MCP de integraciones, que expone las Entregas y Recolecciones marcadas como tools, en una dirección por Aplicación. Son mecanismos con propósitos y riesgos diferentes.

Qué es el token, y qué no es

	API Key (`/api-tokens`)	Token MCP (`/mcp-tokens`)
Autentica	Envío y recolección de mensaje	Configuración y diagnóstico
Alcance	Aplicación + Interfaces	El Perfil de un usuario de servicio
Guardado	En texto, para volver a mostrarlo en pantalla	Solo el hash — el valor aparece una vez
En la auditoría aparece como	El token	El login del usuario de servicio

La decisión central: un token MCP no tiene permisos propios. Apunta a un usuario de servicio, y es el Perfil de ese usuario el que decide todo — qué herramientas ve la IA, qué Aplicaciones e Interfaces alcanza, qué puede modificar.

El mismo token puede además llamar a las tools del Servidor MCP de integraciones — enviar por una Entrega, ejecutar una Recolección —, pero solo si el Perfil tiene también la Herramienta /mcp/integration-tools. Configurar una Entrega y accionarla son permisos separados.

Un token MCP nunca ve más de lo que el usuario de servicio vería en pantalla. Si quieres una IA que solo lee, crea un usuario con Perfil de lectura y apunta el token hacia él — no existe un segundo lugar donde aflojar esto por error.

Crear un token

Crea el usuario de servicio

En Usuarios, un usuario dedicado al cliente MCP, con el Perfil que define el alcance. Vale tratarlo como una persona: aparece en la auditoría de todo lo que la IA haga, y es su e-mail el que recibe el token.

Abre la pantalla y haz clic en Nuevo token

Campo	Qué decide
Usuario de servicio	El Perfil que el token lleva. Tiene que estar activo
Descripción	Cómo reconoces este token en la lista. Ej.: Claude Desktop del equipo de integración
Expira el	Fecha de validez. Vacío = no expira
Permitir ver contenido de mensaje	Libera el cuerpo de los mensajes en el diagnóstico. Apagado por defecto

Copia el valor — aparece una sola vez

El CMS guarda solo el hash. El valor crudo existe fuera del cliente solo en esta pantalla: si lo pierdes, revócalo y genera otro. Junto viene la configuración lista del cliente, ya con la URL de esta instalación.

El botón Enviar a… manda el token y la configuración por e-mail — siempre a la dirección del usuario de servicio, nunca a quien apretó el botón ni a una dirección escrita. El envío, y también el fallo de envío, quedan en el Log de Auditoría.

Conecta el cliente


{
  "mcpServers": {
    "cms": {
      "type": "http",
      "url": "https://tu-cms/api/mcp",
      "headers": { "Authorization": "Bearer cms_mcp_..." }
    }
  }
}

El valor empieza con cms_mcp_ a propósito: quien encuentre la cadena en un archivo de configuración sabe de dónde es, y un barrido por cms_mcp_ encuentra un token filtrado en un repositorio.

Qué puede hacer la IA

Las herramientas se filtran por el Perfil del usuario de servicio antes de ser ofrecidas — la IA ni siquiera ve una herramienta que recibiría 403 al llamarla. Por eso el mismo servidor se comporta de formas distintas según el token.

Leer

Herramienta	Qué devuelve
`cms_list_applications` · `cms_get_application`	Aplicaciones visibles al token, con Keep Alive y estado
`cms_list_interfaces` · `cms_list_definitions` · `cms_get_definition`	Interfaces y Definiciones, con la configuración legible de cada una. En una Entrega, `cms_get_definition` trae también el Transformador de cada Aplicación productora, con su Content-Type
`cms_list_connections` · `cms_list_credentials`	Conexiones y Credenciales — sin contraseña ni token
`cms_list_transformers`	Dónde se usa cada Transformador — el uso por Aplicación productora cuenta como Entrega. El script no sale
`cms_list_business_errors`	Errores de Negocio configurados
`cms_describe_types`	Catálogo de tipos: los enums del dominio y los campos obligatorios de cada Tipo de Entrega, Recolección y Conexión

cms_describe_types es la pieza que evita la mayor parte de los errores: sin ella el modelo adivina valores de enum y nombres de campo; con ella, consulta el contrato antes de armar nada.

Diagnosticar

Herramienta	Responde
`cms_search_messages`	“¿Ese mensaje pasó?” — por Interfaz, Definición, estado y período
`cms_interface_status`	Cola acumulada, si está bloqueada y por qué, último procesamiento
`cms_application_health`	Keep Alive actual y el último período de indisponibilidad
`cms_recent_errors`	Últimos errores agrupados por Definición, para hallar el origen antes de abrir mensaje por mensaje
`cms_screen_link`	La dirección de una pantalla del CMS ya filtrada, con el conteo exacto del filtro

cms_search_messages devuelve metadatos — id, estado, fechas, intentos. El cuerpo solo sale si el token tiene el permiso de contenido encendido, y el payload cifrado nunca sale, con o sin ese permiso: descifrar exige la Herramienta propia, con justificación y reautenticación, y está fuera del alcance del MCP.

cms_screen_link no devuelve datos: devuelve adónde mirar. Es el camino barato para responder “¿pasó este mensaje?” — el conteo sale de una sola consulta, el contenido no entra en la respuesta, y la lista de pantallas alcanzables es cerrada. Cada pantalla se verifica contra el permiso del token antes de que salga la dirección. La ruta viene relativa: quien conoce la dirección pública de la instalación es quien la hospeda, no la API.

Para ventanas relativas a ahora, cms_screen_link acepta periodo (hoje, ontem, 1h, 24h, 7d…) en lugar de dataInicio/dataFim: la dirección lleva el atajo, y la pantalla resuelve las fechas en cada consulta.

Probar antes de grabar

Herramienta	Qué hace
`cms_test_connection`	Prueba una Conexión Externa ya registrada, por nombre — la misma prueba del botón de la pantalla
`cms_preview_transform`	Aplica un Transformador, guardado o suelto, a un payload de ejemplo
`cms_test_read`	Ejecuta la lectura de una Recolección sin grabar mensaje, devolviendo una muestra

cms_test_read rechaza, explicando, lo que tendría efecto colateral: Recolección con comando posterior, acción posterior a la lectura de archivo, RFC que puede escribir, y los tipos orientados a evento — que no tienen qué leer bajo demanda.

Crear y modificar

cms_create_* y cms_update_* cubren Aplicación, Interfaz, Entrega, Recolección, Error de Negocio y Conexión Externa. Crear una Aplicación cuya sigla ya existe no duplica: devuelve la existente, marcada como ya existente.

Para una integración entera de una vez, el camino es otro:

Herramienta	Papel
`cms_validate_integration`	Revisa el plan entero sin grabar: siglas en conflicto, enum inválido, campo obligatorio faltante, referencia que no existe
`cms_apply_integration`	Aplica el plan. Corre en simulación por defecto — la primera llamada devuelve lo que sería creado

Las Entregas y Recolecciones creadas por cms_apply_integration nacen desactivadas. Encenderlas es un acto humano: alguien abre la pantalla, revisa y activa. Reaplicar el mismo plan no duplica, y lo que esté marcado como personalizado solo se sobrescribe si lo autorizas explícitamente.

Documentación y guion incorporados

Además de las herramientas, el servidor publica resources — contenido que el cliente lee una vez y mantiene en el contexto:

cms://catalog/types — el mismo catálogo de cms_describe_types
cms://docs/como-criar-integracao — qué son Aplicación, Interfaz, Definición y Error de Negocio, y en qué orden crearlos
cms://docs/direcao-e-tipos — por qué quien inicia la conversación decide entre ENTREGA y RECOLECCIÓN

Y un prompt listo, configurar_integracao, que el cliente ofrece como comando: describes el objetivo en una frase y él conduce el guion hasta la validación y la vista previa.

Por qué es seguro dejar una IA aquí

La pregunta correcta no es “¿la IA es confiable?”, sino “¿qué alcanza, incluso si se sale del guion?”.

El secreto no sale. Cada respuesta se arma campo por campo, por lista de permitidos — contraseña, token y clave privada no están en esa lista. Encima de eso, un barrido final recorre la respuesta entera, incluidos los mensajes de error, y corta lo que coincida con patrón de secreto. Si esa red tiene que actuar, el incidente queda registrado.
El contenido cifrado no sale, bajo ninguna hipótesis, ni con el permiso de contenido encendido.
Nada se crea encendido. Las Entregas y Recolecciones nacen desactivadas.
Nada se expone solo. Las llaves que abren una salida de datos — Exponer como tool MCP, Devolver el contenido recogido a la IA y Devolver el resultado de la recolección en la respuesta de la API — solo las activa una persona, en la pantalla. Las herramientas de crear y modificar, y cms_apply_integration, se niegan a activarlas; desactivarlas sigue permitido.
Todo pasa por el Perfil. Las mismas verificaciones de Herramienta e Interfaces permitidas que valen en la pantalla valen aquí, en el mismo código.
Todo queda en la auditoría, con el login del usuario de servicio.

Revocar

En la lista, Revocar apaga el token al instante sin borrarlo — el historial de uso sigue legible. Eliminar quita el registro, y cualquier cliente que estuviera usando ese valor pierde el acceso de inmediato. Un token con fecha de expiración pasada deja de autenticar por sí solo.

El token también vale solo mientras vale el usuario de servicio: desactivar el usuario derriba todos sus tokens al instante, sin esperar la expiración — como ocurre con la sesión de pantalla de un usuario desactivado.

La columna Último uso es la forma rápida de encontrar un token olvidado: el que nunca se usó, o no se usa hace meses, probablemente no debería seguir existiendo.

Apagar el servidor entero

Para cerrar la puerta de una vez, sin tocar ningún token, apague el recurso Servidor MCP en Configuración → IA: a partir de ahí ningún token es aceptado.

El rechazo ocurre después de la validación del token, a propósito — quien llamara sin credencial descubriría que el servidor existe y está apagado, y la respuesta única para token ausente/inválido/expirado/revocado perdería la gracia.

Esta llave es la única del panel de IA que no tiene que ver con el costo: el servidor MCP no consume el proveedor configurado en el CMS — quien paga el modelo del otro lado es quien se conecta. Aquí es control de acceso.

Permiso de la pantalla

La Herramienta es /mcp-tokens. Quien la tiene puede crear y revocar tokens — es decir, puede conceder a una IA el acceso de cualquier usuario de servicio disponible. Trátala con el mismo cuidado que Perfiles de Acceso, y no la incluyas en perfiles operativos.

Servidor MCP — /mcp-tokens