MCP Verification Before Merge

• Understand the edit → verify → approve pattern.
• Separate write permissions and verification permissions.
• Design an internal MCP without giving away repo keys.

The Typical Mistake

The agent edits code, says "it's done," and nobody runs the project from scratch. There may be broken dependencies, tests that don't run, missing environment variables, or a build that only worked in its context. MCP helps turn that intuition into a verifiable process.

# 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

Permission Design

• GitHub MCP: create branch, commit, and PR; never force-push to `main`.
• Verify MCP: fresh clone, install, lint, test, build, and logs.
• Secrets: don't pass real `.env` files to the verifier if they aren't needed.
• Network: limit external outbound connections if the project doesn't need them.
• Logs: save command, exit code, Node/Python version, and summary.

{
  "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://..."
  }
}

Official Sources

• Model Context Protocol introduction
• MCP specification