Conectar Claude Desktop o el plugin de ChatGPT al servidor MCP de Cabgo requiere tres pasos: obtener el token de autenticación desde el panel de operador, declarar el servidor en el archivo de configuración del cliente de agente, y hacer la primera llamada que confirma que el canal está activo. La secuencia no es larga, pero tiene tres puntos donde los operadores se detienen más de lo necesario: el formato exacto del bloque de configuración, el error que aparece cuando el token se pega con un espacio de más, y la consulta específica que distingue entre «el servidor responde» y «el servidor responde con los datos de mi operación». Este artículo cubre esos tres puntos con el detalle que no está en la documentación genérica del protocolo MCP.

Este artículo está escrito para el operador que tiene el panel de Cabgo funcionando, ha visto en el blog o en la documentación que hay un servidor MCP disponible y quiere hacer la primera conexión sin que el proceso técnico le tome más de una tarde. No asume experiencia previa con MCP ni con configuración de APIs: asume que sabes usar Claude Desktop o ChatGPT como chat y que tienes acceso al panel de operador. Al final de la guía el agente tendrá una conexión activa con el servidor y el contexto mínimo en las instrucciones del sistema para que la primera sesión de trabajo ya produzca respuestas específicas a tu operación, no respuestas genéricas que podría dar cualquier asistente sin acceso a los datos reales.

Por qué 'técnicamente conectado' y 'útil desde el primer turno' son estados distintos

El servidor MCP de Cabgo está diseñado para aceptar conexiones de cualquier cliente compatible con el protocolo. En teoría, seguir las instrucciones genéricas de configuración de Claude Desktop o el tutorial de instalación de plugins de ChatGPT es suficiente para que el canal quede activo. En la práctica, «activo» y «útil» son dos estados distintos. Un canal activo significa que el agente puede invocar las herramientas del servidor y el servidor responde. Un canal útil significa que las respuestas que el agente devuelve son específicas a la operación del operador: incluyen datos del tenant correcto, interpretan las métricas con los parámetros reales del mercado específico y usan los mismos nombres que el equipo usa internamente para zonas, conductores y configuraciones. El primer estado toma quince minutos. El segundo requiere además un mínimo de configuración en las instrucciones del sistema que convierte el acceso genérico en acceso contextualizado.

La razón por la que muchos operadores se quedan en el primer estado después de la instalación inicial es que el proceso técnico de conexión se documenta bien, pero el paso siguiente no viene en ninguna guía genérica porque varía por operación. El mínimo de instrucciones del sistema que hace útil el agente para una operación con 40 conductores en una ciudad turística es diferente al de una operación con 150 en una ciudad industrial con dos verticales. La buena noticia es que el mínimo para empezar es pequeño: cuatro elementos en menos de diez líneas, que representan menos de diez minutos de trabajo adicional después de tener el canal activo.

El token de autenticación: dónde está y qué da acceso exactamente

El token de autenticación del operador está disponible en el panel de Cabgo, en la sección de integraciones o de configuración de API — el nombre exacto de la sección depende de la versión del panel. Es un string alfanumérico de longitud fija que funciona como la identidad de la operación en cada llamada al servidor MCP. Cada vez que el agente invoca una herramienta — consultar conductores activos, revisar el historial de viajes, crear un cupón de promoción — ese token viaja en el encabezado de la petición para que el servidor sepa a qué operación corresponde la consulta y con qué tenants tiene permiso de trabajar.

Dos cosas sobre el token que conviene entender antes de configurarlo. La primera: el token autentica a la operación, no a una persona individual. Si tres miembros del equipo usan el mismo token desde sus propios clientes de agente, el servidor los identifica a todos como la misma operación, con acceso a los mismos tenants y con todas las llamadas registradas bajo el mismo historial de `cabgo_my_mcp_usage`. No hay un mecanismo automático que distinga quién hizo qué consulta a menos que cada usuario lo incluya explícitamente en sus prompts. La segunda: el token tiene permisos acotados por diseño. Permite operaciones de gestión — leer y modificar datos de la operación — pero no da acceso a la configuración de la cuenta, a la facturación ni a funciones de administración interna de la plataforma. Compartirlo con el coordinador del turno para que use el agente no implica darle acceso a configuración sensible.

Configurar Claude Desktop: el archivo de configuración y el paso que se suele saltar

Claude Desktop lee la lista de servidores MCP disponibles desde un archivo de configuración JSON almacenado localmente en la máquina. Cuando el operador agrega el bloque del servidor de Cabgo a ese archivo, Claude Desktop carga las herramientas del servidor automáticamente al siguiente inicio y aparecen disponibles durante la sesión de chat. Cabgo publica en la sección de integraciones del panel el bloque de configuración exacto listo para copiar — con el campo del token claramente marcado como placeholder. El operador no necesita escribirlo manualmente: pega el bloque en la ubicación correcta del archivo de configuración, sustituye el placeholder por el token generado en el paso anterior y reinicia Claude Desktop.

El paso que se suele saltar — y que más frecuentemente hace que Claude Desktop no cargue el servidor sin mostrar un mensaje de error claro — es verificar que el archivo de configuración quedó bien formado después de pegar el bloque. Un archivo JSON con una coma en el lugar equivocado o un par de comillas sin cerrar hace que el cliente ignore el bloque del servidor de forma silenciosa. La verificación más directa es abrir el archivo con cualquier editor de texto y confirmar que cada llave de apertura tiene su cierre correspondiente y que no hay comas sueltas antes de un corchete de cierre. Si el archivo ya tiene otro servidor MCP configurado, el bloque de Cabgo se agrega como un elemento adicional dentro del mismo objeto — no como un archivo nuevo ni reemplazando la configuración existente.

Configurar el plugin de ChatGPT: las tres diferencias que afectan el uso diario

En ChatGPT, el operador agrega el servidor MCP desde la interfaz de configuración de la cuenta — no desde un archivo local. El proceso varía según el tipo de cuenta y la versión de la plataforma, pero la información requerida es la misma: la URL del servidor de Cabgo y el token de autenticación. Cabgo publica esa información en la misma sección del panel donde están los demás datos de configuración de integraciones. Una vez agregado, el plugin queda disponible en las sesiones de chat de esa cuenta.

Tres diferencias entre Claude Desktop y ChatGPT que afectan cómo el equipo trabaja con el agente una vez activo el canal. La primera es el contexto entre sesiones: Claude Desktop mantiene el historial mientras la ventana está abierta, lo que permite sesiones largas con contexto acumulado; ChatGPT resetea el contexto al iniciar una nueva conversación, de modo que cada sesión empieza sin memoria de la anterior. La segunda es la propagación de instrucciones del sistema: en Claude Desktop se configuran a nivel del cliente y se cargan automáticamente en cada sesión; en ChatGPT están vinculadas al perfil individual del usuario, lo que significa que dos personas del equipo con cuentas distintas tienen instrucciones distintas, o ninguna, si cada una no las configuró por su cuenta. La tercera es la visibilidad de las herramientas disponibles: Claude Desktop muestra explícitamente qué herramientas del servidor están cargadas; ChatGPT las integra sin listarlas de forma visible, lo que puede hacer menos obvio para el usuario qué puede pedirle al agente que haga.

La primera llamada que confirma que el canal funciona

Una vez que Claude Desktop reinició o el plugin de ChatGPT quedó activo, la verificación más directa no es explorar el menú de herramientas disponibles — es hacer una consulta real. Un prompt corto como «¿Cuántos conductores tengo activos en este momento?» hace que el agente invoque la herramienta de estado del servidor y devuelva el número actual. Si la respuesta incluye un número que corresponde a la realidad de la operación, el canal funciona y el token es válido. Si la respuesta es un error o produce datos inesperados, hay cuatro situaciones que vale revisar en ese orden.

El mínimo de instrucciones del sistema para que el agente sea útil desde la primera sesión

Una vez que la primera llamada confirma que el canal funciona, el paso que determina si el agente es útil desde el primer turno es el contexto en las instrucciones del sistema. Sin instrucciones del sistema, el agente tiene acceso a los datos del servidor pero no tiene el marco para interpretar qué significa un número en el contexto de esa operación específica. Si el servidor devuelve que la disponibilidad en la zona norte es del 45%, el agente no sabe si eso es normal a esa hora o es una señal de alerta. Si el operador pregunta por su «Zona Centro» y el servidor usa un identificador técnico distinto, el agente no conecta los dos nombres y la respuesta resulta ambigua. Esas dos fricciones desaparecen con cuatro elementos en las instrucciones del sistema.

El primer elemento es el tenantId principal de la operación: una sola línea que evita que las llamadas al servidor usen el default del token cuando el operador no lo especifica explícitamente en el prompt. El segundo son los nombres de las zonas principales — las dos o tres que el equipo menciona con más frecuencia — con su correspondencia al identificador que el servidor usa. El tercero es el rango de disponibilidad que la operación considera normal en hora pico y en hora baja: sin ese dato de referencia el agente trata cualquier variación como potencialmente relevante y el operador tiene que juzgar cada respuesta sin contexto. El cuarto es el criterio de escalación: en qué tipo de situación el agente debe sugerir ir al soporte de la plataforma en lugar de continuar el diagnóstico solo. Esos cuatro elementos, en menos de diez líneas en total, son la diferencia entre un agente conectado y uno que el equipo usa de verdad en el turno.

La conexión entre el cliente de agente y el servidor MCP de Cabgo no es el paso que determina si el agente será útil en la operación diaria — es la condición mínima para llegar a ese punto. Lo que determina si el agente produce resultados que el equipo usa de verdad es el contexto que se carga en las instrucciones del sistema en esa misma tarde de instalación. Un canal técnicamente activo sin contexto de operación es acceso a datos sin el marco que les da sentido: el agente responde, el servidor responde, pero las respuestas no se anclan a la realidad específica de esa operación, con esas zonas, esos conductores y esos parámetros de normalidad propios. Los cuatro elementos descritos — tenantId, zonas, umbrales de normalidad, criterio de escalación — son suficientes para que la primera semana de trabajo ya produzca diagnósticos específicos, no respuestas que cualquier asistente sin acceso a los datos reales podría dar sobre cualquier operación de movilidad.

Si ya tienes el panel de Cabgo funcionando, la primera conexión te va a tomar una tarde. El resultado al final de ese tiempo no es un agente que sabe todo sobre tu operación — es uno que tiene acceso real a tus datos y el marco mínimo para que sus respuestas sean específicas en lugar de genéricas. Desde ahí, las capas de contexto que hacen al agente más útil con el tiempo se construyen semana a semana: las zonas secundarias, los patrones de incidencias recurrentes, las convenciones internas del equipo. Pero el punto de partida importa: llegar bien configurado a la primera semana es la diferencia entre un equipo que adopta el agente como herramienta operativa real y uno que lo instala, lo prueba con dos consultas sin contexto y no lo vuelve a abrir.