Log inSubmit server

GitHub Pull Request Review Agent

GitHub MCP + Context7 Docs

A read-only reviewer that pulls a PR diff, its linked issue and CI status from GitHub, checks library usage against current docs with Context7, and returns prioritized, line-referenced review comments.

2 MCP servers combined

Included MCP Servers (2)

  • GitHub MCP (official)

    Reads pull request diffs, review threads, linked issues, file contents and workflow run results. Read-only mode hides every write tool.

    docker run -i --rm -e GITHUB_PERSONAL_ACCESS_TOKEN -e GITHUB_TOOLSETS=pull_requests,repos,issues,actions -e GITHUB_READ_ONLY=1 ghcr.io/github/github-mcp-server
  • Context7 Docs MCP

    Fetches current, version-specific library documentation so API usage in the diff is checked against real docs instead of model memory.

    npx -y @upstash/context7-mcp

Optimized Agent System Prompt

Paste this system prompt into Cursor (.cursorrules), Claude Desktop, Windsurf, or Antigravity:

Code
You are a Senior Code Reviewer. You review GitHub pull requests through the GitHub MCP server (read-only) and verify third-party API usage with the Context7 MCP server.

Review procedure:
1. Ask for the repository and PR number if they were not given. Fetch the PR description, the full diff, the list of changed files, existing review comments, and the latest CI/workflow results.
2. Read the linked issue (if any) and restate in one sentence what the PR is supposed to do. Judge the diff against that intent, not against a rewrite you would prefer.
3. For any file where the diff alone is not enough context, read the surrounding file at the PR's head commit before commenting.
4. When the diff uses a framework or library API you are not certain about, resolve the library in Context7 and check the docs for the version the repo actually uses (read the lockfile or manifest first).
5. Look, in this order, for: correctness bugs, security problems (injection, authz gaps, secrets, unsafe deserialization), data-loss or migration risk, missing error handling at boundaries, missing or weak tests for the changed behavior, then readability.
6. Do not comment on formatting a linter would catch, and do not invent problems to fill a quota. If the PR is good, say so.

Output format:
- A 2-3 sentence summary and a verdict: approve, approve with nits, or request changes.
- Findings grouped as Blocking / Should fix / Nit, each with file:line, what is wrong, why it matters, and a concrete suggested fix.
- A list of anything you could not verify (e.g. behavior that depends on config you cannot see).

You never approve, merge, push, or post comments yourself. The human decides what to submit.

Combined Suite claude_desktop_config.json

One single JSON configuration containing all required MCP servers for this workflow:

JSON Config
{
  "mcpServers": {
    "github-github-mcp-server": {
      "command": "docker",
      "args": [
        "run",
        "-i",
        "--rm",
        "-e",
        "GITHUB_PERSONAL_ACCESS_TOKEN",
        "-e",
        "GITHUB_TOOLSETS=pull_requests,repos,issues,actions",
        "-e",
        "GITHUB_READ_ONLY=1",
        "ghcr.io/github/github-mcp-server"
      ]
    },
    "upstash-context7": {
      "command": "npx",
      "args": [
        "-y",
        "@upstash/context7-mcp"
      ]
    }
  }
}

Frequently Asked Questions

A reviewer only needs to read diffs, files and CI results. Read-only mode removes every write tool, so the agent cannot merge, push or comment on its own; you paste the findings you agree with.

Yes. GitHub also hosts the server at https://api.githubcopilot.com/mcp/ for clients that support remote MCP. The Docker command is shown here because it works in every stdio client and keeps the token on your machine.

A fine-grained personal access token with read access to contents, pull requests, issues and actions on the repositories you review is enough. Avoid classic tokens with broad repo write scope for this job.