Conectamos Claude al Portal de Nuestros Clientes con MCP

La respuesta corta: el portal del cliente, dentro de Claude

Un cliente de Latech puede conectar su espacio del portal a Claude en menos de un minuto y, desde el chat, preguntar en qué está su proyecto, revisar tickets, leer las notas de la última reunión o reportar un error. Lo hicimos con MCP (Model Context Protocol), el estándar abierto con el que un asistente de IA usa sistemas externos mediante herramientas, y con OAuth 2.1 para que el cliente nunca vea ni copie un token.

La idea nació de algo simple: muchos de nuestros clientes ya pasan el día en Claude. Si su portal está ahí, preguntar "¿qué entregaron esta semana?" no les exige abrir otra pestaña, recordar una contraseña ni buscar el formulario. Y cada reporte que llega por este canal es uno que no se pierde en un chat de WhatsApp.

No somos los únicos que van en esa dirección. El 15 de septiembre de 2026, según TechCrunch, Meta lanzó un servidor MCP para que agentes como Claude configuren cuentas de WhatsApp Business. Los sistemas empresariales están empezando a exponerse para que la IA los use con permisos, no solo para leerlos.

Cómo se conecta el cliente: cuatro pasos y ningún token

Un cliente no va a pegar un token en una terminal, así que el flujo tenía que ser el de cualquier conector de Claude. Claude soporta conectores personalizados apuntando a un servidor MCP remoto, y la especificación de MCP define cómo autorizarlos con OAuth. Con eso, la experiencia queda así:

1. En Claude, el cliente va a Ajustes, Conectores y agrega un conector personalizado.
2. Pega la dirección del servidor MCP del portal.
3. Claude abre el portal: si no tiene sesión, entra con su contraseña o con un código; si ya la tiene, ve directamente la pantalla de permitir.
4. Elige el espacio de su empresa (si pertenece a más de uno) y, si prefiere, marca "Solo lectura".

Qué puede hacer desde Claude y qué no

Lo primero que decidimos fue no crear una segunda regla de visibilidad. Las herramientas del conector leen de las mismas consultas que usa la web del cliente, así que ve exactamente lo que ya estaba publicado para su empresa y nada más. Si mañana cambia lo que un cliente puede ver en la web, cambia también en Claude, sin riesgo de que las dos versiones se desincronicen.

El catálogo inicial tiene 14 herramientas: 11 de lectura y 3 de escritura.

Lo que dejamos fuera a propósito

Tan importante como lo que el conector hace es lo que no hace. Cada exclusión responde a una pregunta concreta: ¿qué pasa si esto sale mal dentro de un chat con un modelo de lenguaje?

• Accesos y credenciales compartidas: una clave que pasa por un chat queda en el historial de esa conversación. Las credenciales se ven solo en la web del portal, con auditoría de cada lectura.
• Aceptar o rechazar una cotización: compromete dinero y no tiene vuelta atrás. Esa decisión se toma en la web, con el documento completo delante.
• Comentarios y actividad interna del equipo de Latech: se filtran en la consulta misma, no en la respuesta del modelo, así que nunca llegan a Claude.
• Cotizaciones y facturas para cualquier miembro: solo las ven los dueños y administradores del espacio, igual que en la web.

Seguridad: OAuth 2.1, tokens cortos y permisos que se revalidan

Un conector de IA es una puerta más a tus datos, así que lo diseñamos con la misma exigencia que el login. Seguimos la especificación de autorización de MCP: OAuth 2.1 con código de autorización, PKCE obligatorio con el método S256 (RFC 7636) y registro dinámico de clientes (RFC 7591), que es lo que usa Claude para presentarse.

El detalle que más nos importó es que cada conexión queda atada a una persona, un espacio y un alcance, y que la membresía se vuelve a verificar en cada pedido. Si a alguien le quitan el acceso al espacio de su empresa o se desactiva su cuenta, su conexión deja de servir en ese mismo momento, sin esperar a que venza el token.

• Token de acceso de 1 hora y token de renovación de 60 días que rota en cada uso: el anterior deja de valer.
• En la base de datos solo se guardan hashes de los tokens, nunca el valor.
• Las direcciones de retorno solo pueden ser https o locales, y un código de autorización vale 5 minutos y se usa una sola vez.
• Desde el portal, el cliente ve sus conexiones activas y puede desconectar cualquiera; eso revoca todos sus tokens al instante.
• Lo que entra por Claude queda marcado: el equipo de Latech ve "vía Claude" en cada ticket o comentario creado desde el conector.
• El servidor MCP de clientes es distinto del que usa el equipo de Latech: otro catálogo, otra credencial y otro dominio.

Cómo lo probamos antes de abrirlo

Escribimos 16 criterios de aceptación antes de la primera línea de código, y cada uno tiene una prueba automática de punta a punta. Algunos ejemplos: sin token, el servidor responde 401 e indica dónde autorizarse; un ticket interno o de otra empresa responde "no existe", no "prohibido"; con alcance de solo lectura, las herramientas de escritura ni siquiera aparecen en el catálogo; y quitar a una persona de un espacio invalida sus conexiones a ese espacio.

Ese orden importa. En un sistema que mezcla datos de varios clientes, el error caro no es una herramienta que falla, sino una que devuelve datos de otra empresa. Por eso la prueba que más cuidamos es la de aislamiento entre espacios.

Qué sigue y qué puede aprender tu empresa de esto

La siguiente fase suma pedir cotizaciones desde Claude, adjuntar capturas a un ticket y avisar por correo cuando alguien conecta Claude a un espacio. Lo decidimos así: primero lectura y tickets para todos los clientes, después lo que mueve dinero o archivos.

Si tu empresa tiene un sistema propio (un ERP, un portal de clientes, una plataforma de pólizas o de envíos), exponerlo por MCP es una forma concreta de que tus usuarios y tu equipo lo usen desde la IA que ya tienen. La parte difícil no es el protocolo: es decidir qué herramientas exponer, con qué permisos y qué dejar fuera.