Sistema Vivo en producción: el MCP de SCRAM con Claude, ChatGPT y lo que aprendimos en la primera semana

¿Qué es un Sistema Vivo y qué tiene que ver con MCP?

Un Sistema Vivo es un sistema con el que puedes conversar desde la inteligencia artificial que ya usas, con tus permisos y sin que nadie tenga que abrir el portal. En SCRAM lo construimos sobre el Model Context Protocol (MCP): un servidor remoto montado en nuestra propia API expone 27 herramientas de ERP, CRM y soporte, y clientes como Claude o ChatGPT las llaman. Está en producción desde el 6 de septiembre de 2026 en api.scram2k.com/mcp. Este artículo cuenta cómo está hecho y qué nos costó.

El invariante: la llave identifica, no autoriza

La decisión que definió todo: una credencial MCP no otorga permisos, identifica a una persona. La llave se resuelve a un usuario real de la plataforma y ese usuario viaja a todos los servicios de dominio, los mismos que usa el portal. Como el ERP y el CRM ya reciben al usuario autenticado en cada servicio, el acotamiento por vendedor y las puertas por rol aplicaron sin duplicar una sola regla. Un vendedor que pregunta "¿cuánto nos debe este cliente?" por Claude ve exactamente lo que vería en el portal, y nada más.

Los tres controles viven en código, nunca en el prompt:

Control	Dónde se aplica	Qué evita
Visibilidad por nivel de rol	tools/list: cada persona ve solo las herramientas de su nivel	Que el catálogo mismo revele lo que no se puede hacer
Re-verificación al llamar	tools/call: el rol se comprueba otra vez	Que un cliente MCP invoque algo que no se le listó
Confirmación en dos turnos	Toda escritura devuelve una vista previa; solo confirmar: true ejecuta	Que "crea la cotización" escriba sin que la persona vea totales y cliente

Hay 10 pruebas automatizadas sobre esos controles, dentro de una suite que al 12 de agosto sumaba 988 pruebas en verde. Los totales, IVA y descuentos los calcula el ERP con la misma función que usa el portal: el modelo nunca suma.

¿Cómo se conectan Claude y ChatGPT sin pegar llaves?

Con OAuth 2.1, y la API es también el servidor de autorización. La especificación del 28 de julio de 2026 lo permite: el MCP es el recurso protegido y el autorizador "puede vivir con él". Publicamos los metadatos de descubrimiento en las dos formas que buscan los clientes, registro dinámico de clientes, autorización y token. El estado vive en Redis; si Redis reinicia, la persona vuelve a autenticarse y ya. La pantalla de autorización reutiliza el login normal de la plataforma, con el mismo usuario y contraseña del portal.

Las cuatro trampas que costaron cuatro despliegues

Todas silenciosas. Ninguna dejó un error en el servidor.

1. La política de seguridad del formulario de login bloqueaba el envío. El navegador aplica la directiva a toda la cadena de redirección, y el formulario terminaba en claude.ai. Síntoma: error solo en la consola del navegador, cero tráfico en el servidor. Se resolvió con una política a la medida para la pantalla de acceso con el origen del redirect validado.
2. Un servicio de identidad que no era proveedor de ningún módulo. Exportarlo impedía arrancar la API. Se vio solo al levantar el contenedor.
3. El guardia global de JWT rechazaba el MCP antes de mirar la credencial. Faltaba marcar la ruta como pública para que el MCP aplicara su propia autenticación.
4. Las rutas de descubrimiento deben ir sin versión. Nuestra API versiona por URI y los clientes buscan los metadatos en la raíz del host.

De paso encontramos un defecto de autenticación que afectaba también al portal: el login buscaba el correo con coincidencia exacta, así que un correo capitalizado por el teclado del móvil daba "credenciales inválidas" con el contador de intentos en cero. Se normalizó.

¿Qué clientes hablan MCP hoy y cuáles no?

Cliente	Estado al 10 de septiembre de 2026	Nota
Claude Code	Funciona con llave	Desde 2.1.265, managedMcpServers lo entrega a toda la organización
Claude web, escritorio y móvil	Funciona con OAuth	La app cachea la lista de herramientas: con más de 10 conectores puede mostrar una sola; el remedio es re-agregar el conector y dejar 10 o menos
ChatGPT	Funciona con OAuth 2.1 y registro dinámico	Requisito estricto de OpenAI, cumplido
Microsoft Copilot Studio	Soportado por Microsoft, pendiente de probar por nosotros	Transporte streamable vía conector
Gemini (app y Workspace)	No admite MCP	Solo la Gemini CLI y la plataforma Enterprise
WhatsApp y Telegram	No hablan MCP	El asistente propio consume el mismo registro de herramientas con los mismos permisos

El último renglón es la decisión de arquitectura que más nos gusta: las herramientas viven en un registro exportado; el MCP es un cliente de ese registro, y el bot de WhatsApp es otro. Una regla de negocio se escribe una vez.

Lo que Claudeforce confirma

El 26 de agosto Salesforce y Anthropic anunciaron Claudeforce: Claude dentro de Agentforce y de Slack, y "Salesforce in Claude" con 37 habilidades de ventas. Es la misma idea a otra escala: el sistema de la empresa se vuelve conversable desde el asistente. La diferencia para una empresa mediana en México es que su ERP no es Salesforce, y nadie va a construirle el conector. Por eso el nuestro se diseñó para replicarse: el procedimiento quedó escrito como un skill con siete principios y 24 trampas verificadas, y ya lo usamos para el siguiente sistema.

Qué haríamos distinto

Probar el flujo de OAuth con un cliente real desde el primer día, no al final. Tres de las cuatro trampas se habrían visto en una hora con Claude móvil apuntando a un servidor de pruebas. Y medir desde el arranque cuántas herramientas caben en el contexto del cliente: 27 herramientas cuestan alrededor de 8,000 tokens solo en el listado, y la app de Claude ya nos enseñó que ese catálogo compite con todo lo demás.

Si quieres verlo funcionando, en una sesión de diagnóstico conectamos tu Claude o tu ChatGPT a una copia de prueba y haces las preguntas tú.