MCP GitHub
Overview
MCP GitHub demonstrates the Skills + MCP pattern. The skill defines the procedure for PR review; the GitHub MCP server provides API access. Together they enable automated PR workflows.
When to Use
- When reviewing pull requests via GitHub
- When checking CI/build status on PRs
- When posting review comments or approvals
- When searching issues or code on GitHub
Process
Review a PR
- Use GitHub MCP to list open PRs in the repository
- Read the PR diff and description
- Check CI status — all checks must pass
- Review for:
- Correctness: does the code do what it claims?
- Tests: are new behaviors tested?
- Security: no secrets, no injection vectors
- Style: matches repo conventions
- Post review comments using GitHub MCP
- Approve if all criteria pass, request changes if not
Check CI Status
- Use GitHub MCP to get PR status checks
- List all check runs with their conclusions
- Report failures with links to logs
- Suggest next steps for fixing failures
Post a Comment
- Use GitHub MCP to create a review comment
- Reference specific lines in the diff
- Use conventional language:
[blocking],[suggestion],[nit]
Prerequisites
Configure the GitHub MCP server in opencode.json:
{
"mcp": {
"github": {
"type": "remote",
"url": "https://api.githubcopilot.com/mcp",
"headers": {
"Authorization": "Bearer {env:GITHUB_TOKEN}"
}
}
}
}
Set the token: export GITHUB_TOKEN=ghp_xxx
Red Flags
- Approving a PR without reading the full diff
- Posting comments without checking CI status first
- Using MCP tools without the skill loaded (no procedure)
- Hardcoding tokens in config (use
{env:VAR})
Rationalizations
| What you think | What MCP GitHub knows |
|---|---|
| "I'll just approve it quickly" | Quick approvals miss bugs. Follow the review checklist. |
| "MCP has access, I don't need the skill" | MCP provides access, not procedure. The skill defines what to check. |
| "I'll hardcode the token for now" | Hardcoded tokens leak in config files. Use environment variables. |
Verification
Before confirming the review is done:
- All CI checks are green
- Full diff was read (not just the title)
- Review comments are specific and actionable
- Approval is justified by the checklist, not assumed