MCP o GUI: cómo elegir la interfaz para una operación corporativa

Conversar con un agente sirve para localizar un ticket por significado y preparar un cambio. Antes de escribir, suele ser mejor un formulario que muestre el valor anterior y el nuevo. MCP conecta una aplicación con herramientas; decidir quién puede modificar un ticket sigue siendo responsabilidad de tu sistema.

Este escenario didáctico de service desk interno no describe una integración terminada de un producto concreto. Un empleado lee un ticket, propone cambiar al responsable y envía el cambio a confirmación. Los nombres de herramientas y campos son de diseño: hay que implementarlos y probarlos en el sistema elegido.

Separa lectura, propuesta y escritura

En la arquitectura de MCP, la aplicación host trabaja con servidores mediante clientes y los servidores exponen herramientas y otras capacidades. Una tool con un nombre apropiado no concede por sí misma permisos de negocio.

Acción	Interfaz inicial útil	Condición de admisión
Buscar un ticket accesible al usuario	MCP y conversación	El servidor limita los resultados por permisos del usuario
Proponer otro responsable	MCP para el borrador; formulario para comparar	La propuesta no modifica el registro
Confirmar el cambio	GUI o formulario MCP Apps probado	Se ven los campos exactos; el servidor vuelve a comprobar permisos y vigencia

Es una recomendación de diseño para este caso. Una GUI normal también puede ocultar valores importantes o usar un backend mal protegido. Evalúa la ruta real de escritura y la evidencia de que funciona.

Supón que el ticket de prueba REQ-204 tiene responsable team-a y el usuario quiere team-b. La conversación ayuda a encontrar el objeto, pero antes de guardar muestra ID, valor anterior, valor nuevo y consecuencias: notificación, cambio de acceso o acción externa. Coincidir en el título no basta para elegir un objeto.

La confirmación debe referirse al cambio exacto

Un objeto interno de confirmación podría ser:

{
  "ticket_id": "REQ-204",
  "expected_revision": "r17",
  "changes": {
    "assignee": {"from": "team-a", "to": "team-b"}
  },
  "mode": "proposal"
}

Es un esquema de aplicación, no un estándar MCP. Al guardar, el servidor debe comparar revisión y permisos. Si el ticket cambió, vuelve a mostrar la propuesta; el botón Confirmar no debe aplicar silenciosamente otro diff.

La sección Tools de la especificación MCP contempla llamadas visibles, la posibilidad de que una persona rechace una acción y validación del servidor para entradas y acceso. El protocolo no impone una interfaz de confirmación; acceder a un servidor MCP no autoriza todas las operaciones corporativas.

Define de antemano el comportamiento del backend tras un timeout. Si se pierde la respuesta, consulta primero el resultado por el identificador conservado. Reintentar a ciegas puede duplicar una notificación o un efecto externo. Restituir al responsable anterior no vuelve reversibles todas las consecuencias.

Cuándo encaja MCP Apps

MCP Apps permite que una herramienta del servidor ofrezca UI interactiva dentro de un cliente compatible. El host la renderiza en un iframe sandboxed. Sirve para comparar campos dentro de la conversación si las versiones de cliente y servidor admiten la extensión.

El formulario puede mostrar ticket, diff propuesto y botones explícitos Aplicar y Cancelar. Siguen siendo necesarios autorización del servidor, validación de revisión y registro del resultado. El iframe sandboxed no sustituye permisos del service desk ni convierte un servidor arbitrario en confiable.

Conserva una GUI separada si el cliente actual no puede mostrar el diff con fiabilidad, completar la confirmación corporativa o ofrecer la accesibilidad necesaria. Si el modelo no está disponible, una persona debe poder abrir el ticket por ID y ver su estado real; el fallo del modelo no debe dejar dudas sobre si se guardó el cambio.

Piloto: modelo mediante BetterToken, tickets mediante MCP

Para el piloto usa Claude Desktop como cliente y conecta un modelo Claude mediante BetterToken con la guía de configuración de API. Usa tu propia API Key con acceso al proveedor Claude y Gateway Base URL https://bettertoken.ai; comprueba en la guía los campos y condiciones exactos de tu versión. Primero obtén respuesta a un mensaje corto normal para verificar por separado la conexión del modelo.

Después conecta un servidor MCP de service desk de prueba con el cliente elegido y comprueba acceso a un ticket no secreto. BetterToken proporciona la capa API del modelo; credenciales del service desk, permisos y confirmación de escritura se configuran por separado. La conexión del modelo no demuestra que MCP Apps funcione en ese modo de cliente: pruébalo antes de elegir el formulario integrado. Si no está disponible, confirma en la GUI.

Conecta el modelo mediante BetterToken para el escenario de prueba y realiza las comprobaciones siguientes. Usa datos ficticios: una respuesta MCP enviada al modelo puede entrar en una solicitud API. La autorización para datos corporativos reales debe seguir las reglas de tu organización.

Prueba la decisión ante fallos

Ejecuta el ejercicio en pruebas con dos roles y tickets no secretos. Un rol puede cambiar responsable y el otro solo lee los registros permitidos. Guarda el resultado real de cada prueba; la tabla contiene criterios esperados, no un informe.

Comprobación	Resultado esperado
Se solicita un ticket ajeno no accesible	El servidor rechaza sin revelar contenido
Un rol de solo lectura confirma el cambio	El servidor rechaza la escritura
Se cancela el diff propuesto	El ticket no cambia
La revisión cambia después de verlo	Se detiene el guardado; hace falta una nueva vista
Se pierde la respuesta tras guardar	Se conoce el estado antes de reintentar
El modelo no está disponible	La GUI permite leer el estado real
Se usa teclado y lector de pantalla	Se entiende, confirma o cancela el cambio

Si falla una prueba, deja ese tipo de escritura en la interfaz existente y probada hasta resolver la causa. La lectura por MCP puede evaluarse por separado y también necesita permisos y límites de resultados.

Deja una pista de auditoría

Registra usuario, ID del ticket, diff acordado, revisión fuente, hora, ID de operación y resultado backend. No guardes tokens ni el contenido completo de tickets restringidos sin necesidad. La retención y el acceso al registro deben seguir las políticas de tu organización.

Al terminar el piloto, registra una decisión por acción: lectura en conversación, preparación como borrador y escritura en el formulario probado elegido. Adjunta resultados de fallos y responsable de los problemas restantes. Amplía MCP solo para operaciones cuyos permisos, confirmación y recuperación tras fallos ya se entiendan.