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.

# Recommended flow
1. Editor agent:
   - create branch
   - apply changes
   - open PR with summary and risks

2. Agent/verifier:
   - clone repo in clean folder
   - install dependencies
   - run lint, tests, and build
   - attach logs to PR

3. Human or policy:
   - approve only if verification passes

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/company/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