MCP de verificación antes de merge
MCP permite conectar agentes con herramientas reales. Eso es potente y peligroso. El patrón sano para código es separar dos roles: un agente que propone cambios y un verificador que prueba en limpio antes de merge.
Objetivos de aprendizaje
- Entender el patrón editar → verificar → aprobar.
- Separar permisos de escritura y permisos de verificación.
- Diseñar un MCP interno sin regalar llaves del repo.
En cristiano: MCP. Model Context Protocol es un estándar para que una aplicación de IA use herramientas y datos externos mediante servidores. Un servidor MCP puede exponer GitHub, archivos, bases de datos, documentación o un verificador propio.
El error típico
El agente edita código, dice “ya está” y nadie ejecuta el proyecto desde cero. Puede haber dependencias rotas, tests que no corren, variables de entorno ausentes o un build que solo funcionaba en su contexto. MCP sirve para convertir esa intuición en un proceso verificable.
Terminal
# Flujo recomendado 1. Agente editor: - crea rama - aplica cambios - abre PR con resumen y riesgos 2. Agente/verificador: - clona el repo en carpeta limpia - instala dependencias - ejecuta lint, tests y build - adjunta logs al PR 3. Humano o policy: - aprueba solo si la verificación pasa
Idea clave. El verificador no necesita poder escribir en producción. Su poder es leer, ejecutar en sandbox y devolver evidencias.
Diseño de permisos
- GitHub MCP: crear rama, commit y PR; nunca force-push a `main`.
- Verify MCP: clone fresco, install, lint, test, build y logs.
- Secrets: no pasar `.env` reales al verificador si no hacen falta.
- Red: limitar salidas externas si el proyecto no las necesita.
- Logs: guardar comando, exit code, versión de Node/Python y resumen.
Terminal
{
"tool": "verify_repo",
"input": {
"repo": "github.com/empresa/app",
"branch": "agent/fix-login",
"commands": ["npm ci", "npm run lint", "npm test", "npm run build"],
"timeout_seconds": 900
},
"output": {
"status": "failed",
"failed_command": "npm test",
"exit_code": 1,
"log_url": "https://..."
}
} Cuidado. MCP no convierte una herramienta insegura en segura. Si expones una shell sin límites, un servidor con permisos amplios o tokens con acceso total, el agente hereda ese riesgo.
Comprueba que funciona. Antes de conectar GitHub real, prueba el verificador con un repo de juguete que falla a propósito. El workflow debe devolver error claro y bloquear merge.
Guardar y reabrir el proyecto.
La regla de oro: el agente puede proponer, pero el sistema debe verificar. La confianza se gana con logs, tests y permisos mínimos.