Claude Code ha corregido los fallos de inicio de sesión OAuth con servidores MCP en clientes preregistrados, con Slack como caso más visible. El origen del problema estaba en discrepancias en la redirect URI: la dirección a la que el proveedor devuelve al usuario después de autenticarse no coincidía con la que esperaba el cliente, y el flujo moría justo ahí. Es una corrección sin brillo, del tipo que no aparece en ningún resumen de novedades, pero desbloquea integraciones que llevaban tiempo sin poder completarse.
Una dirección que no cuadra tumba el flujo entero
La redirect URI es una de esas piezas que solo se miran cuando fallan. En un flujo OAuth, el usuario sale de la aplicación hacia el proveedor, se autentica allí, y el proveedor lo devuelve a una dirección registrada de antemano junto con el código que permite completar el intercambio. Ese registro previo no es burocracia: es lo que impide que alguien intercepte el proceso y reciba el código en un destino que no le corresponde.
Por eso la comprobación es deliberadamente estricta. La dirección debe coincidir exactamente con la registrada, y cualquier diferencia —un puerto distinto, una barra final de más, un esquema que no encaja— provoca un rechazo. Y aquí está la parte que vuelve loco a cualquiera que lo haya sufrido: el error que se ve casi nunca describe el problema real. El usuario recibe un mensaje genérico de sesión fallida, no un aviso de que faltaba una barra.
El fallo se veía como un login que no funciona. La causa era una dirección que difería en un detalle que nadie mira.
Por qué los clientes preregistrados son un caso aparte
El matiz de los clientes preregistrados explica por qué el fallo afectaba a unos casos y no a otros. En el escenario flexible, la aplicación se da de alta contra el proveedor sobre la marcha y negocia sus parámetros, redirect URI incluida, de modo que ambas partes acaban de acuerdo por construcción. En el escenario preregistrado, la relación se establece de antemano y con valores fijos: el proveedor ya sabe qué cliente es y a qué dirección tiene permitido devolver.
Esa rigidez es exactamente lo que buscan las plataformas corporativas, y por eso Slack aparece como el ejemplo destacado. Cuando una herramienta va a operar dentro del espacio de trabajo de una organización, nadie quiere que el cliente se registre solo con los parámetros que le apetezcan. La contrapartida es que no hay margen de negociación: si lo que envía el cliente difiere en un carácter de lo registrado, no hay conexión.
Esto sitúa el fallo en un lugar incómodo del mapa. No afectaba a quien probaba MCP en local con un servidor de juguete, sino precisamente a quien intentaba conectar con las plataformas más serias, que son las que exigen preregistro. Es decir, golpeaba justo en el caso de uso profesional.
Lo que este tipo de fallo cuesta en la práctica
Un error de autenticación mal explicado no cuesta el tiempo de arreglarlo: cuesta el tiempo de descartar todo lo demás. Ante un login que no completa, la secuencia habitual es revisar las credenciales, regenerarlas, comprobar permisos y ámbitos, mirar si el token caducó, probar en otro navegador, revisar la configuración del servidor MCP y, después de todo eso, empezar a sospechar de la dirección de retorno. Se van tardes enteras en llegar a una causa que, una vez conocida, se resume en una línea.
El coste real, sin embargo, no es ese. Es el abandono silencioso. Quien intentó conectar su servidor MCP con una plataforma corporativa, no lo consiguió y no encontró explicación, probablemente no volvió a intentarlo: apuntó mentalmente que «eso no funciona bien» y montó la integración por otro camino más manual. Ese juicio se queda instalado mucho después de que el fallo se haya corregido, y ningún changelog llega a desmentirlo.
🔁 Si abandonaste una integración por esto
Actualiza y vuelve a intentar la conexión que diste por imposible, sobre todo si el síntoma era un inicio de sesión que se quedaba a medias sin decir por qué. Antes de dar por buena la prueba, comprueba que la redirect URI registrada en el proveedor coincide carácter a carácter con la que usa tu cliente: esquema, host, puerto y barra final incluidos.
MCP se juega su adopción en este tipo de detalles
Conviene poner la corrección en su contexto. MCP se ha convertido en la vía estándar para que un agente hable con servicios externos, y su valor depende por completo de que conectar sea trivial. Un protocolo de integración no se juzga por lo elegante que es su especificación, sino por cuántas veces conecta a la primera. Cada fallo de autenticación sin explicar resta más adopción que la que suma cualquier funcionalidad nueva, porque llega antes: ocurre en el minuto cero, cuando el usuario todavía está decidiendo si esto le sirve.
Para quien mantiene servidores MCP propios dentro de su flujo de trabajo, la lectura práctica es doble. La primera, inmediata: si tienes conexiones a plataformas corporativas que fallaban, este es el momento de recuperarlas. La segunda, más de fondo: merece la pena documentar en el propio proyecto qué redirect URI está registrada y dónde, porque es el dato que nadie recuerda y el primero que hay que comprobar la próxima vez que un inicio de sesión se quede a medio camino.
