Activación del MCP remoto

Estado: código verificado localmente y revisado, preparado para PR. Sin merge ni despliegue productivo autorizados. Las pruebas usan exclusivamente demo-nexusbuilder en emuladores locales; no crean claves, modifican IAM ni escriben en el proyecto productivo.

Configuración del alojamiento

Para este repositorio, el proyecto y la base con nombre se obtienen de la configuración Firebase existente: Admin elige la misma base que el cliente. El entorno de pruebas usa la base por defecto de demo-nexusbuilder. El servidor verifica los ID tokens de Firebase y vuelve a comprobar concesión, propietario y scope en las transacciones de proyecto.

Definir estas variables tanto para el build como para las funciones. Los documentos públicos de descubrimiento se generan también como archivos reales en .well-known a partir de la misma fábrica usada por el runtime. Esto evita depender de rewrites de rutas reservadas de Vercel. Cambiar issuer/appOrigin requiere reconstruir y desplegar; comprobar que los documentos coincidan con el runtime. Su CORS público no admite credenciales; las APIs conservan validación de Origin y tokens Bearer.

La ausencia de configuración bloquea el runtime con503. Los archivos de descubrimiento de un build sin configuración contienen un error explícito, no metadatos operativos. El panel comprueba metadatos e inicialización real antes de ofrecer una URL.

El adaptador de Vercel, identificado por su variable de sistema VERCEL=1, usa la IP válida de x-vercel-forwarded-for para las cuotas públicas/OAuth. En desarrollo e ingreso directo se ignoran headers reenviados y se usa la dirección del socket. Si se cambia de proveedor o se añade otro proxy, revisar explícitamente ese límite de confianza; no activar el modo Vercel en un servidor expuesto directamente. Referencia: headers de solicitud de Vercel.

Orden de activación, después de autorización concreta

1. Revisar y desplegar las reglas de Firestore que protegen project_revisions. No exponer el MCP con las antiguas reglas recursivas que permitían falsificar ese historial desde el cliente.
2. Configurar la credencial Admin mediante secretos del alojamiento y sus permisos necesarios para Firebase Auth y la base Firestore correspondiente. No crear roles de propietario ni proporcionar credenciales al modelo.
3. Configurar los orígenes y proyecto; generar el build y desplegar las funciones Node y los archivos de descubrimiento en el mismo release.
4. Comprobar que las rutas de MCP/OAuth devuelvan protocolo/JSON y que ninguna caiga en index.html. Verificar los documentos .well-known, el challenge401, el consentimiento y el aislamiento con dos cuentas de prueba autorizadas para ese entorno.
5. Revisar el panel y la publicación manual con un proyecto de prueba. Después conectar una cuenta autorizada en cada cliente externo siguiendo client-setup.md. La prueba local del SDK no acredita una conexión real en esos productos.

Rutas: /api/mcp, /api/connections, /oauth/authorize, /oauth/token, /oauth/register, /oauth/revoke, /.well-known/oauth-authorization-server, /.well-known/oauth-protected-resource/api/mcp. Consentimiento: /connections/authorize, separado del editor.

Persistencia y conservación

Migración aditiva: no se convierten ni eliminan proyectos existentes. Se añaden registros privados mcp_clients, mcp_grants, mcp_codes, mcp_tokens, mcp_idempotency e historial en users/{uid}/project_revisions. Las comprobaciones de vencimiento son obligatorias en código y no dependen de limpieza gestionada. Fechas de seguridad en milisegundos Unix.

Los recibos de idempotencia son compactos, permanentes y apuntan al resultado inmutable de una revisión. No eliminar recibos ni revisiones referenciadas al limpiar contadores temporales. El campo transientExpiresAt no elimina el recibo: un reintento antiguo sigue devolviendo el mismo resultado. No aplicar una política TTL indiscriminada a mcp_idempotency. Los contadores de cuota son registros separados con kind=quota; su vencimiento no decide la validez de un recibo.

La rotación de refresh conserva los hashes usados hasta que termina la familia para detectar reutilización y revocarla. No borrar antes esos registros por haber sido usados. Las concesiones revocadas conservan auditoría, no tokens reutilizables.

Los clientes previamente registrados usan el mismo registro privado de clientes y las mismas redirect URIs exactas. El registro dinámico devuelve un client_id persistente reutilizable; registrar ese cliente previamente permite configurarlo de forma manual en clientes que lo admitan. No se descargan documentos de identidad desde URLs suministradas por clientes.

Retirada o rollback

Desactivar la disponibilidad del MCP retirando su configuración y reconstruyendo, o retirando sus rutas. Revocar las concesiones activas antes de retirar el servicio si se requiere cerrar conexiones. Conservar las reglas que impiden escrituras de cliente en el historial incluso al volver a un frontend anterior; no restaurar la regla recursiva antigua. Conservar borradores, publicaciones, recibos e historial. Deshabilitar MCP no requiere borrar sitios ni tocar DNS, pedidos, pagos o credenciales comerciales.

Verificación local reproducible

npm test, npm run test:mcp, npm run test:rules, npm run test:mcp:integration, npm run test:mcp:ui, npm run test:mcp:e2e, npm run lint, npm run build, npm run check:bundle.

Instalar Chromium con npx playwright install chromium; CI instala además sus dependencias. Si el entorno ya proporciona un Chromium compatible, ambos runners aceptan PLAYWRIGHT_CHROMIUM_EXECUTABLE explícito. Esa alternativa afecta solo a las pruebas, nunca al código de aplicación.

E2E inicia Vite con --mode mcp-test, proyecto demo explícito y hosts loopback de ambos emuladores. El cliente rechaza flags de emulador fuera de esa combinación, y el runtime también exige NODE_ENV=test/proyecto demo/loopback. Ningún fallo activa un fallback en memoria o accede automáticamente a producción.