MCP, la nube y agentes que trabajan mientras duermes

Llegaste al último módulo de Claude Code. Hasta aquí el agente trabajó en tu computador, contigo al frente: con un CLAUDE.md que le enseña tu proyecto, permisos que lo frenan, y skills, hooks y subagentes que lo extienden. Este módulo quita las dos últimas ataduras: la de tus herramientas, con MCP, y la de tu portátil, con sesiones en la nube, rutinas programadas y un agente que vigila tus pull requests.

Cinco preguntas: cómo agregar un servidor MCP a Claude Code sin regalarle acceso de más, qué servidores le sirven a un negocio, cómo correr sesiones en la nube, cómo programar trabajo que corre solo y cómo mantener seguro un agente que actúa sin ti. Todo está verificado en la documentación de Claude Code a octubre de 2026.

¿Cómo agrego un servidor MCP a Claude Code?

En el módulo 6 viste los conectores de la app de Claude. Debajo de todos está MCP, el estándar abierto para conectar un asistente a herramientas y datos, y Claude Code lo habla también. Un servidor MCP es un programa, local o remoto, que le ofrece al agente herramientas (acciones que puede ejecutar), recursos (datos que puede leer) y prompts (plantillas listas).

Agregar uno es un comando en la terminal. Para un servidor remoto, que es lo recomendado: `claude mcp add --transport http <nombre> <url>`. Para uno que corre en tu máquina: `claude mcp add <nombre> -- <comando>`. Dentro de la sesión, `/mcp` muestra el estado de cada servidor, te deja autenticarte (los remotos suelen usar OAuth) y prenderlos o apagarlos.

Lo que más importa es el alcance (scope), porque decide quién hereda el servidor:

• Local (por defecto). Solo tú, solo en este proyecto.
• Proyecto. Se escribe en un archivo `.mcp.json` en la raíz del repositorio y viaja con él: quien clone el proyecto recibe el servidor, con una aprobación la primera vez. Se activa con `--scope project` y es el alcance para equipos, porque el cambio se revisa en un pull request como cualquier otro.
• Usuario. Para ti, en todos tus proyectos.

Cada herramienta de un servidor es una herramienta más para el sistema de permisos. Las reglas usan el nombre `mcp__<servidor>__<herramienta>`: puedes permitir un servidor completo (`mcp__github`), una sola herramienta (`mcp__github__get_issue`) o un patrón (`mcp__github__get_*`, solo las que empiezan por "get"). Esa última forma es la recomendada para empezar: primero solo lectura, y las que escriben en "preguntar".

¿Qué servidores MCP le sirven a un negocio?

Tres tipos útiles, verificados a octubre de 2026:

• GitHub. La documentación de Claude Code muestra cómo agregar el servidor remoto de GitHub con un token personal: el agente lee issues, revisa pull requests y comenta sin salir de la sesión.
• Una base de datos. La misma documentación da un ejemplo para PostgreSQL con una línea que vale oro: usa un usuario de solo lectura. Un agente que consulta ventas para un reporte no necesita poder borrar una tabla.
• Un SaaS que ya pagas. Cada vez más proveedores publican su servidor MCP. PriceLabs, una herramienta de precios dinámicos para alquileres, documenta el suyo: se agrega como conector personalizado en claude.ai, y los permisos de lectura, escritura y escritura de personalizaciones se otorgan por separado.

¿Cómo corre Claude Code en la nube mientras cierro el portátil?

Una sesión en la nube corre en infraestructura de Anthropic en vez de en tu máquina. La abres en claude.ai/code, en la app móvil, en la de escritorio o desde la terminal con `claude --cloud "tarea"`. Claude clona tu repositorio de GitHub en una máquina virtual aislada, trabaja y empuja una rama para que revises. Cierras el portátil y sigue; la revisas desde el celular. A octubre de 2026 está en los planes Pro, Max y Team, consume los límites de uso de tu plan y no cobra aparte por la máquina.

Tres piezas de configuración:

1. 1GitHub. Conectas tu cuenta e instalas la Claude GitHub App. Tus credenciales quedan cifradas en los servidores de Anthropic: la máquina virtual nunca las ve, un proxy las añade a cada operación.
2. 2El entorno en la nube. Una configuración guardada con el nivel de acceso a red (None, Trusted, Full o Custom con tu lista de dominios; Trusted, el predeterminado, solo deja pasar registros de paquetes y dominios comunes), variables de entorno y un script que corre antes de que Claude arranque, por ejemplo para instalar dependencias.
3. 3Los secretos. Las claves de API no van en variables de entorno, que cualquiera que use el entorno puede leer. Van como secretos de red: las guardas una vez y el proxy de Anthropic las añade a las peticiones hacia el dominio que indiques, sin que la sesión las vea nunca.

Cuando la sesión termina, abres el diff, dejas comentarios en líneas concretas (Claude los recibe con tu siguiente mensaje) y, cuando queda bien, pulsas Create PR. La sesión sigue viva: pégale la salida de un check fallido y continúa.

¿Cómo programo trabajo que corre solo?

En el módulo 8 definimos la tarea programada como la automatización más simple: como no puede preguntarte nada, el prompt tiene que decir qué es un buen resultado y qué hacer cuando no lo hay. Claude Code tiene tres formas de programar:

• `/loop` dentro de una sesión. `/loop 5m revisa si terminó el despliegue` repite un prompt mientras la sesión esté abierta. Sirve para vigilar algo hoy, no para automatizar.
• Tareas programadas de la app de escritorio. Corren en tu máquina, con acceso a tus archivos, solo mientras la app está abierta y el computador despierto.
• Rutinas. Corren en la nube, sin tu máquina. Es la opción para trabajo que debe pasar todas las noches.

Se crea en claude.ai/code/routines o desde la terminal con `/schedule`, incluso con una frase ("/schedule revisión de PRs todos los días a las 9am"). Tiene tres disparadores que se combinan: un horario (cada hora, diario, entre semana o semanal; mínimo una hora), una llamada HTTP a una URL propia de la rutina y eventos de GitHub (un pull request abierto, una release). A octubre de 2026 está en vista previa de investigación: puede cambiar.

Dos cosas antes de crear la primera. Corre de forma autónoma: ejecuta comandos y usa cualquier conector incluido sin pedir aprobación, y por defecto incluye todos tus conectores con sus herramientas de escritura; quita los que no necesite. Y un run en verde solo significa que la sesión arrancó y terminó sin error de infraestructura, no que la tarea salió bien: abre la corrida y lee la transcripción.

Por eso el diseño del módulo 8 aplica completo:

1. 1Un disparador claro, unos minutos pasada la hora en punto (la documentación sugiere 9:07 en vez de 9:00, porque en punto puede arrancar tarde).
2. 2Los datos que lee y de dónde: un conector, una API con secreto de red, archivos del repositorio.
3. 3Validaciones en código, no en el prompt: un script que revisa el resultado y se niega a escribir si algo no cuadra.
4. 4Comportamiento a prueba de fallas: si algo falla, no toca nada y deja el estado anterior.
5. 5Un registro de cada corrida y una notificación cuando falló.
6. 6Un punto de revisión humana donde importa: la rutina empuja una rama con prefijo `claude/` y abre un pull request; una persona fusiona.

¿Puede un agente cuidar mis pull requests?

Sí, con dos productos distintos. Auto-fix de pull requests es parte de las sesiones en la nube. Con la Claude GitHub App instalada, lo activas en un pull request (desde la barra de CI de la sesión o con `/autofix-pr` en la terminal) y Claude se suscribe a la actividad del PR: cuando un check falla o un revisor comenta, investiga y, si la corrección es clara, la empuja y la explica. Si el comentario es ambiguo o toca la arquitectura, te pregunta antes de actuar. Sus respuestas en GitHub salen con tu cuenta, marcadas como escritas por Claude Code.

Claude Code GitHub Actions corre en los servidores de GitHub. Con `/install-github-app` desde Claude Code se instala la app, se guarda la credencial como secreto del repositorio y se abre un PR con el workflow. Desde entonces, escribir `@claude` en un issue o un PR hace que Claude analice, implemente y empuje commits.

En los dos casos, lo que no cambia: Claude abre el pull request, responde comentarios y arregla checks; una persona revisa y fusiona. La documentación de GitHub Actions lo pone como práctica: otorga al workflow solo los permisos que necesita y revisa los cambios de Claude antes de fusionar.

¿Cómo mantengo seguro un agente que actúa solo?

Un agente en la nube o en una rutina no tiene a nadie mirando la pantalla. Es la diligencia del marco 4D llevada al extremo:

• Secretos nunca en el prompt ni en el repositorio. Claves de API como secretos de red del entorno o como secretos de GitHub, nunca en texto plano ni en un commit.
• Tokens con alcance mínimo. Un token de GitHub para un repositorio y los permisos que la tarea necesita; un usuario de base de datos de solo lectura; escritura en un servidor MCP solo cuando la tarea escribe.
• Red cerrada. Entorno en Trusted o en Custom con los dominios exactos; Full solo si sabes por qué. Con la red cerrada, una inyección de prompt tiene menos adónde mandar tus datos sensibles.
• Revisión antes de fusionar. Protección de la rama main en GitHub: el proxy de Anthropic aplica tus reglas de protección a lo que una sesión empuja, y rechaza borrar ramas o empujar etiquetas.
• Presupuestos y límites. Las rutinas consumen el uso de tu plan y tienen topes por hora; en GitHub Actions, `--max-turns` y un timeout del workflow evitan un agente que gira en círculos.
• Registro. Las operaciones en la nube quedan registradas, cada corrida de una rutina es una sesión que puedes abrir, y conviene que cada commit automático enlace la sesión que lo hizo.

Quiero conectar el servidor MCP de [PROVEEDOR: GitHub, PostgreSQL, PriceLabs...] a este proyecto.

Datos del proveedor (sacados de su documentación):
- URL o comando: [URL DEL SERVIDOR REMOTO, O COMANDO SI ES LOCAL]
- Autenticación: [OAUTH / TOKEN EN UNA VARIABLE DE ENTORNO]
- Alcance: [LOCAL SOLO PARA MÍ / PROJECT PARA COMPARTIR CON EL EQUIPO]

Haz esto en orden y para antes de cada paso que escriba algo:
1. Muéstrame el comando claude mcp add exacto antes de ejecutarlo. No pongas ningún token en el comando ni en archivos del repositorio; si hace falta uno, dime cómo pasarlo por variable de entorno.
2. Conéctalo y lista las herramientas que expone, separadas en dos grupos: las que solo leen y las que escriben o borran.
3. Propón reglas de permisos para permitir solo las de lectura (con el patrón mcp__servidor__...) y dejar las demás en "preguntar".
4. Ejecuta una sola consulta de lectura: [CONSULTA CONCRETA, POR EJEMPLO "lista los últimos cinco issues abiertos"] y muéstrame el resultado tal cual.
5. Dime qué información del resultado podría contener instrucciones para ti (texto escrito por terceros) y cómo lo vas a tratar.

Quiero una rutina de Claude Code que haga esto cada noche: [TAREA: por ejemplo "actualizar el archivo de precios del sitio con los datos de [SISTEMA]"].

Contexto:
- Repositorio: [NOMBRE] en [LENGUAJE / FRAMEWORK]
- De dónde salen los datos: [CONECTOR MCP / API / ARCHIVOS DEL REPOSITORIO]
- Qué archivo o sistema cambia al final: [RUTA O DESTINO]
- Quién recibe la notificación: [PERSONA O CANAL]

Diseña la rutina con estas secciones, en este orden:
1. Disparador: horario propuesto (unos minutos pasada la hora en punto) y por qué esa hora.
2. Datos: qué lee, de dónde, y qué credencial necesita y dónde debe guardarse (secreto de red del entorno, nunca en el prompt ni en el repositorio).
3. Validaciones en código: lista de comprobaciones que un script debe hacer antes de escribir (rangos, fechas, cantidad mínima de registros, saltos frente al valor anterior). Escribe el script.
4. A prueba de fallas: qué pasa exactamente cuando una validación falla (no escribir nada, dejar el estado anterior, registrar el motivo).
5. Registro y notificación: qué queda escrito en cada corrida y cuándo avisa a una persona.
6. Punto de revisión humana: qué hace la rutina sola (rama claude/, pull request) y qué fusiona una persona.
7. El prompt de la rutina, listo para pegar: autónomo, explícito sobre qué es un buen resultado y qué hacer si no lo hay.

Al final, lista los conectores que la rutina NO necesita y que debo quitar.

Vigila el pull request [URL DEL PULL REQUEST] y activa Auto-fix.

Reglas:
- Si un check de CI falla, lee el log, diagnostica y empuja la corrección mínima a la misma rama. Explícame en la sesión qué cambiaste y por qué.
- Si un revisor deja un comentario claro y pequeño, atiéndelo y responde en el hilo diciendo qué hiciste.
- Si un comentario es ambiguo, toca [ÁREAS SENSIBLES: pagos, autenticación, datos de clientes...] o implica cambiar la arquitectura, no actúes: pregúntame primero.
- Nunca fusiones el pull request, nunca cierres hilos de revisión que no hayas resuelto y nunca cambies archivos de workflows o de secretos.
- Si después de dos intentos un check sigue fallando, para y resúmeme el problema.

Al terminar cada evento, deja un resumen de una línea en la sesión.

¿Qué sigue en la parte 4?

Con este módulo cierras la parte 3. La parte 4 cambia de pregunta: ya no es cómo usar un agente, sino cómo se construye uno. Qué es de verdad un agente (un modelo, unas herramientas y un ciclo), cómo especificar tareas que un agente pueda terminar y tú verificar, cuándo orquestar varios, cómo construir con la API y el Agent SDK, y cómo evaluar costos y fallas. Es la ingeniería agéntica, y empieza en el módulo 16, "Qué es un agente, de verdad".