Pull Request Review with MCP: A Step-by-Step Playbook (GitHub)

Pull request review is the daily job of reading someone's change, checking it against the codebase and CI results, and leaving useful comments. Reviewers usually flip between the diff, the files around it and the checks tab. With MCP (Model Context Protocol), a coding agent can read the same pull request through the official GitHub MCP Server and draft a review for a person to edit and submit.

This playbook uses tool names from GitHub's README as of October 2026. The agent prepares the review. A maintainer decides what gets posted and what gets merged.

What you need

• The GitHub MCP Server. See our GitHub MCP server profile. The README says the remote server runs at https://api.githubcopilot.com/mcp/, and that the default toolsets are context, repos, issues, pull_requests and users.
• A coding agent. Claude Code, VS Code with Copilot, Cursor and others connect to the remote server. Setup steps are in connecting Claude Code to GitHub and connecting VS Code to GitHub.
• A token or OAuth sign-in with the right scope. The README lists the repo OAuth scope for the pull request tools. Use a fine-grained token limited to the repos you review, where you can.

The workflow

1. Pick the pull requests. Ask the agent to use list_pull_requests (filter by state or base branch) or search_pull_requests with GitHub's search syntax, such as open PRs waiting on your team.
2. Read the summary. pull_request_read with the get method returns the title, description, author and branches.
3. Read the change. pull_request_read with get_diff returns the diff, and get_files lists changed files with pagination for large PRs. get_commits shows how the change was built.
4. Read the surrounding code. Use get_file_contents for files the diff touches and search_code to find other callers of a changed function. This is where an agent saves the most clicking.
5. Check CI. pull_request_read with get_check_runs returns the check runs on the head commit, and get_status returns the combined status. If a job failed and the actions toolset is on, get_job_logs pulls the log.
6. Read the existing discussion. get_reviews, get_review_comments and get_comments show what other reviewers already said, so the agent doesn't repeat them.
7. Draft the review. Once you allow writes, pull_request_review_write creates a pending review, and add_comment_to_pending_review adds comments tied to a file path and line. The README describes the latter as adding to "the requester's latest pending pull request review."
8. A human submits. The reviewer reads the draft in GitHub, edits or deletes comments, picks approve or request changes, and submits. pull_request_review_write can also submit, but this playbook leaves that click to a person.

If your org uses Copilot code review, the README's request_copilot_review tool asks Copilot to review as well.

Example prompts

• "List open pull requests in acme/web that target main and have no reviews yet."
• "Read PR 412: summarize what it changes, list the files, and flag anything that touches auth or billing."
• "For PR 412, find every caller of calculateTax outside the changed files and check whether the new signature breaks any of them."
• "Show the check runs on PR 412. If any failed, pull the job log and explain the failure in two sentences."
• "Start a pending review on PR 412 with line comments for the three issues you found. Do not submit it."

Guardrails

• Read-only first. GitHub's server configuration guide gives two ways to make the remote server read-only: the X-MCP-Readonly: true header or a URL ending in /readonly. It says read-only mode "takes priority" and disables write tools even if you request them.
• Load only the toolsets you need. Use the X-MCP-Toolsets header (for example repos,pull_requests) or a /x/{toolset} URL path. Fewer tools means fewer ways to go wrong.
• Treat PR text as untrusted. Titles, descriptions and comments on public repos can carry instructions aimed at the agent. Lockdown mode filters content from users without push access on tools such as pull_request_read:get_comments and get_review_comments. The README calls it "a best-effort content filter," not an authorization boundary. See prompt injection through MCP.
• Never let the agent merge. merge_pull_request and update_pull_request are write tools. Keep them out of the agent's toolset, and keep branch protection and required reviews on in GitHub.
• Scope tokens tightly. The agent can do whatever the token allows. Read excessive permissions in MCP and the MCP Security Center.

What to measure

• Time from "ready for review" to first review, before and after you add the agent.
• Share of agent comments kept after human edits, as a rough signal of usefulness.
• Defects found after merge in PRs the agent pre-reviewed versus those it didn't.
• CI failure explanations that were correct, judged by the PR author.
• Write tool calls the agent attempted, from your client's logs, to confirm guardrails hold.

Collect your own baseline first. There is no industry number to aim for here.

Next step

Browse more workflows in the MCP playbooks hub. If you want an AI review step set up in your repos with sensible scopes and branch rules, see our Claude Code consulting service.

Frequently asked questions