El botón Connect ya conecta

Aprobar un asistente no hacía nada. La página decía que el formulario no venía de aquí, y tenía razón de una manera que era errónea: la página de aprobación pedía a los navegadores que no enviaran referrer, y Chrome deriva el origen de una página de ese mismo ajuste — así que el propio formulario de la página llegaba afirmando venir de ningún sitio, y la comprobación que impide que otro sitio apruebe cosas en tu nombre detenía a la página misma.

Nunca se había conectado nada a través de él. Las pruebas no podían verlo, porque una prueba no es un navegador y envía las cabeceras que se le indican; la base de datos sí podía, y lo decía con toda claridad: todas las peticiones mostradas, ninguna jamás aprobada.

Detrás de eso había un segundo problema. La página le dice al navegador que solo puede enviarte al asistente que lo pidió — y venía diciendo que no podía enviarte a ningún sitio salvo de vuelta a nosotros, así que aprobar funcionaba y el viaje de regreso al asistente era rechazado por la propia página. Ahora nombra esa única dirección, y nada más.

Aprobar un asistente es una página y un botón, y esto es lo que hay detrás de ellos.

Qué hace en realidad aprobar

Inicias sesión aquí con la cuenta que ya usas, lees una página que nombra al cliente y la dirección con la que va a actuar, y pulsas Connect. Lo que el cliente se lleva es un token emitido por este sitio — no tu sesión, ni una clave de API. Alcanza los documentos de la cuenta y nada más: ni la cuenta, ni el inicio de sesión, ni tus claves de API. Una conexión de solo lectura no puede guardar, compartir ni eliminar, y eso se hace cumplir sobre la credencial y no sobre las herramientas.

Para esto, TransformPipe tiene que ser su propio servidor de autorización: la especificación de MCP prohíbe que un recurso acepte un token emitido por otro, así que la sesión de inicio de sesión no se puede entregar sin más.

El orden de los eventos

  1. El asistente envía un POST a /api/mcp sin token y recibe un 401 que indica dónde mirar.
  2. Lee /.well-known/oauth-protected-resource, y luego /.well-known/oauth-authorization-server, para encontrar los endpoints.
  3. Se identifica — mediante un documento de metadatos que publica, o registrándose aquí. Ningún secreto en ningún caso: un cliente que corre en la máquina de otra persona no puede guardar uno, y para eso está PKCE.
  4. Te envía a /authorize con un desafío. code_challenge_method=S256 es obligatorio; un desafío simple se rechaza directamente.
  5. Apruebas con un POST desde la página que se te mostró, así que un enlace por sí solo no autoriza nada.
  6. Intercambia el código y su verificador en /token.

Qué hacen los tokens después

Un código vive cinco minutos y se consume al empezar su intercambio, antes de comprobar nada contra él: una copia repetida mientras la primera llamada sigue en curso no obtiene nada. Los refresh tokens rotan: entregar uno lo revoca y emite un par nuevo. Entregar uno ya rotado termina toda la concesión — el token de acceso, el refresh token y cada rotación anterior — porque presentarlo dos veces es la única señal de que se ha copiado.

Se puede retirar desde el menú de la cuenta, en Conector MCP; deja de funcionar en la siguiente llamada.

Por qué el botón no había hecho nada

Dos cabeceras en nuestra propia página. Pedía a los navegadores que no enviaran referrer, y Chrome deriva de ese mismo ajuste el Origin del POST de un formulario — así que el propio formulario llegaba afirmando venir de ningún sitio, y la comprobación que impide que otro sitio apruebe cosas en tu nombre detenía a la página misma. Detrás, el form-action nombraba solo este sitio, así que la vuelta al asistente era rechazada por la política tras acuñarse el código. Ahora nombra la única dirección a la que la petición se enviará, y nada más.

Relacionado: convertir documentos desde un asistente y si un conversor en línea es seguro.