La construcción de integraciones con Claude mediante el protocolo MCP (Model Context Protocol) presenta desafíos técnicos que van más allá del código. Un desarrollador que gestiona una plataforma de análisis de opciones financieras ha compartido su experiencia al crear un servidor MCP que permite a los usuarios consultar datos de mercado en tiempo real directamente desde Claude, revelando que la autenticación fue el componente más complejo de toda la implementación.
La solución inicial pareció simple: implementar un sistema de claves API estáticas. Los usuarios generaban una clave en su panel de configuración, la añadían como token Bearer en la configuración JSON del cliente MCP, y el servidor validaba el token contra la base de datos. Este enfoque funcionó sin problemas en Claude Desktop en apenas un día de trabajo. Sin embargo, presentaba una limitación crítica que el desarrollador no había anticipado inicialmente.
El problema surgió al intentar integrar la solución con Claude.ai, la interfaz web de Anthropic. El sistema de conectores que utiliza la plataforma web no soporta claves API estáticas, sino que requiere un flujo OAuth completo. Esta incompatibilidad significaba que la mayoría de los usuarios potenciales—aquellos que acceden a Claude desde el navegador y desean simplemente pegar una URL y conectarse—quedaban excluidos de la funcionalidad. Era necesario implementar OAuth para desbloquear acceso a la audiencia más amplia.
La implementación de OAuth resultó más compleja que la solución inicial con claves. El desarrollador aprovechó que su plataforma ya utilizaba Clerk para autenticación, buscando reutilizar las sesiones existentes en lugar de obligar a los usuarios a crear nuevas credenciales específicamente para MCP. Aunque el SDK de MCP maneja gran parte de la infraestructura de OAuth—los puntos finales para autorizar, obtener tokens, registrarse y revocar acceso—la interfaz de consentimiento debe ser implementada por el desarrollador.
El flujo resultante es elegante: Claude.ai inicia el proceso OAuth y redirige al usuario a una página de consentimiento personalizada. Si el usuario ya está autenticado en la plataforma principal, solo ve un botón "Permitir". Tras hacer clic, el código de autenticación se asocia a su cuenta y Claude intercambia este código por un token. A partir de ese momento, todas las llamadas a herramientas están autenticadas.
Una consideración importante fue la gestión de usuarios que se conectan a través de Claude.ai antes de haber visitado la plataforma web principal. El flujo de consentimiento resuelve este problema de manera elegante: crea automáticamente la cuenta del usuario durante el paso de aprobación, evitando que el usuario se encuentre con una página de error.
En la solución final de producción, ambos métodos de autenticación operan simultáneamente. El cargador de tokens verifica primero la existencia de un token OAuth y, si no lo encuentra, recurre a las claves API. Ambos métodos se resuelven al mismo usuario interno y comparten los mismos sistemas de limitación de velocidad, registro de uso y análisis. Independientemente de cómo se conecte un usuario—a través de Claude.ai con OAuth o mediante Claude Desktop con una clave API—el sistema los trata de forma idéntica.
La implementación también revela complejidades técnicas inesperadas en la capa de infraestructura. El transporte MCP de Claude utiliza Server-Sent Events (SSE), que requiere configuraciones específicas en proxies inversos como Nginx. Sin la desactivación del almacenamiento en búfer (proxy_buffering off), los flujos pueden "colgarse silenciosamente" sin generar mensajes de error útiles. Los puntos finales de descubrimiento OAuth necesitan sus propias reglas de proxy, y las barras inclinales al final de las rutas pueden romper solicitudes POST sin proporcionar retroalimentación de diagnóstico. Cada uno de estos problemas consumió aproximadamente una hora de depuración debido a la naturaleza silenciosa de los fallos.
Reflexionando sobre el proceso completo, el desarrollador concluye que habría sido más eficiente construir OAuth primero. El soporte para claves API es trivial de añadir posteriormente, ya que solo requiere una verificación de alternativa en el cargador de tokens. Sin embargo, la estrategia inicial de validar primero la utilidad de las herramientas antes de invertir en infraestructura de autenticación resultó ser correcta en términos de priorización de recursos. La solución final—soportar ambos métodos—satisface las necesidades de diferentes contextos de uso: Claude.ai requiere OAuth, Claude Desktop funciona mejor con claves API, y los usuarios no necesitan pensar en estas distinciones técnicas.
Esta experiencia ilustra un patrón común en el desarrollo de integraciones con sistemas AI: los desafíos arquitectónicos no siempre residen donde los desarrolladores esperan. La autenticación, a menudo considerada un problema resuelto, se convierte en el componente que más tiempo consume cuando se integra con múltiples plataformas que tienen requisitos distintos. La documentación sobre la integración de conectores Claude.ai con proveedores de autenticación existentes sigue siendo limitada, dejando a los desarrolladores para navegar estas complejidades mediante prueba y error.
