·

GitHub MCP With Cursor

Set up GitHub MCP in Cursor so your AI agent can manage repositories, pull requests, and issues right from your editor.

Cursor's advantage over the three terminal-first clients in this module is visual: Agent Mode runs inside an editor that already renders diffs, has a Source Control panel, and shows inline comments the way a human reviewer would leave them. GitHub MCP inside Cursor is less about "can the model call the tool" — same tools, same server, same underlying REST calls — and more about how much of the review workflow actually stays visible on screen instead of scrolling past in a chat transcript.

Connecting GitHub MCP to Cursor Agent Mode

Cursor reads MCP server config from .cursor/mcp.json (project-scoped, commit it) or ~/.cursor/mcp.json (global, applies across all your projects). The schema mirrors Claude Code's .mcp.json closely enough that you can usually copy one straight over.

Remote hosted server:

{
  "mcpServers": {
    "github": {
      "url": "https://api.githubcopilot.com/mcp/"
    }
  }
}

Local server via the official binary, PAT-based auth:

{
  "mcpServers": {
    "github": {
      "command": "github-mcp-server",
      "args": ["stdio"],
      "env": {
        "GITHUB_PERSONAL_ACCESS_TOKEN": "${env:GITHUB_PAT}",
        "GITHUB_TOOLSETS": "repos,issues,pull_requests"
      }
    }
  }
}

After saving .cursor/mcp.json, open Cursor's Settings → MCP panel (or Cmd/Ctrl+Shift+P → "View: Open MCP Settings") to confirm the server shows a green status dot and lists its available tools. Cursor validates the connection at settings-load time, not only when a tool is first called, so a broken config surfaces immediately rather than mid-task.

For the OAuth-based remote server, the first tool call from Agent Mode triggers a browser-based device flow the same way it does in Claude Code — approve it once per machine.

To actually use GitHub MCP tools, you need Agent Mode active (not Cursor's plain Chat or Cmd-K inline edit modes) — MCP tool access is an Agent Mode feature. Select Agent from the mode dropdown in the chat panel before starting a GitHub-related prompt.

> using the github tools, list open PRs in this repo where I'm requested
  as a reviewer

Tips
- MCP tools are only available in Agent Mode — if a GitHub-related prompt gets no tool calls, check the mode dropdown first before assuming the server is misconfigured.
- .cursor/mcp.json at the project root is the version to commit for team-shared config; ~/.cursor/mcp.json is your personal cross-project default — know which one you're editing.
- Cursor validates server connectivity when settings load, so check the MCP settings panel for a green status dot right after editing the config, rather than waiting to discover a broken connection mid-task.

Browsing and Commenting on Pull Requests via Cursor and MCP

This is where Cursor's visual layer earns its keep. Ask Agent Mode to pull a PR's diff, and it renders as a readable diff block in the chat panel — not dramatically different from the terminal clients on that front — but the real advantage shows up when you have the PR's branch checked out locally: Cursor's own diff view (Source Control panel, or Cmd/Ctrl+Shift+G) shows the local file state, and you can ask the agent to reconcile what MCP reports on GitHub against what's actually in your working tree.

> get the diff for PR #214 from GitHub, and check if my local checkout of this
  branch matches it exactly, or if there are commits on GitHub not yet pulled

For posting review comments, the same create_pull_request_review / add_pull_request_review_comment tools from Topic 1 apply, and Cursor's confirmation dialog before a write shows the exact comment body and target file:line — worth reading in full before approving, since inline review comments are visible to the whole team the moment they post.

> review the diff for PR #214. For each function that changed, check if
  error handling was added or removed compared to the previous version.
  Flag anything where error handling got weaker, with file and line number.

> post those as inline review comments on PR #214, and submit the review
  as "Request changes" if you flagged 2 or more weakened error handling cases,
  otherwise "Comment"

That conditional submit-type instruction is worth calling out — asking the model to choose between "Comment," "Approve," and "Request changes" based on a rule you specify (rather than letting it decide independently) keeps the review's formal verdict consistent with an actual policy you control, instead of the model's own judgment call on severity.

For quick sanity checks against file history without opening GitHub in a browser:

> show me the last 5 commits that touched src/billing/invoice.py and give me
  a one-line summary of what each one changed

Tips
- Reconcile MCP-reported PR state against your local checkout before reviewing — a stale local branch produces a review based on outdated code, which is a worse outcome than no automated review at all.
- Give the model an explicit rule for choosing the review verdict (Approve / Comment / Request changes) rather than letting it decide freely — consistency in what triggers "Request changes" matters more for team trust than the model's raw judgment.
- Read the full comment body in Cursor's write-confirmation dialog before approving — inline PR review comments are public and persistent the instant they post, unlike a chat message you can just scroll past.

Automating Issue Triage and Labeling from Within Cursor

Issue triage in Cursor works the same as OpenCode's pattern (Topic 3) — list, evaluate, propose, checkpoint, apply — but with the advantage that you can pull relevant source files into the same Agent Mode context to ground labeling decisions in actual code, not just the issue text.

> list open issues with no labels. For each, read the body, and if it references
  a specific file or function, open that file and check if the described
  behavior actually looks like a bug versus expected behavior. Propose a label:
  bug, not-a-bug, needs-repro, or feature. Show me a table before applying anything.

This is a meaningfully different triage quality than a terminal client working from the issue body alone — the agent can call get_file_contents (or read the local checkout directly if you're in the repo) to check whether the described "bug" is actually reproducible against current code, and downgrade to needs-repro when the referenced code path doesn't match the issue's description at all, which happens more often than reporters expect on fast-moving codebases.

> apply labels for the issues marked "bug" and "feature".
  For the ones marked "needs-repro", instead add a comment asking the
  reporter for a minimal reproduction case and the app version they're on.

For a recurring weekly triage habit, Cursor's Agent Mode can be pointed at a saved prompt file to reduce repetitive typing — save the triage instructions in .cursor/prompts/triage.md and reference it:

> follow the triage process in .cursor/prompts/triage.md against issues
  opened in the last 7 days

Tips
- Use Cursor's code-reading advantage deliberately during triage — cross-checking a bug report against the actual current code catches stale or already-fixed reports that a text-only triage pass would mislabel as still-open bugs.
- Downgrade ambiguous reports to a "needs-repro" label with a specific comment (app version, repro steps) rather than guessing at severity — it's more useful to the reporter and cheaper than getting the triage wrong.
- Save a repeatable triage prompt as a markdown file in .cursor/prompts/ and reference it by path — it keeps your triage criteria consistent across sessions instead of retyping a slightly different version of the same instructions each week.

Known Limitations and Workarounds for GitHub MCP in Cursor

  • No persisted per-tool allow/deny list. Like Gemini CLI, Cursor's confirmation model doesn't currently offer a Claude Code-style settings.json with per-tool allow/ask/deny rules for MCP tools specifically — every write from a connected server prompts individually unless you toggle broader auto-run settings, which apply more coarsely than a single-tool rule. Workaround: keep GITHUB_TOOLSETS scoped tightly (Topic 1) so there are simply fewer write-capable tools available to prompt on in the first place.
  • Agent Mode context window competes with codebase context. Because Cursor's real strength is codebase-aware editing, a long GitHub-MCP-heavy session (large diffs, many issue bodies) competes for the same context budget as the code context Cursor also wants to load for accurate edits. On big PRs, ask for the diff scoped to a specific directory or file rather than the whole PR, to leave headroom for code-aware reasoning.
  • Review comment formatting doesn't always match GitHub's UI exactly. Suggested-change blocks (GitHub's ```suggestion fenced comment syntax that renders as a one-click-apply diff) aren't consistently generated by the model unless you ask for that syntax explicitly — a plain-English comment posts fine, but you'll want to explicitly request ```suggestion blocks if you want the reviewer-side one-click-apply experience.
  • Local checkout drift. As mentioned above, Cursor readily mixes "what's on GitHub via MCP" with "what's in your local working tree" — powerful when both are in sync, actively misleading when they're not. There's no automatic staleness warning; you have to ask for the reconciliation check yourself.
  • No native GitHub App auth field in .cursor/mcp.json as of current Cursor releases — same gap as OpenCode. PAT via env is the supported path for the local-server config; GitHub App usage requires a wrapper script minting short-lived tokens.
> post that comment as a GitHub suggestion block so the reviewer can
  apply it with one click

Tips
- Scope GITHUB_TOOLSETS tightly as your main lever against Cursor's lack of per-tool permission rules — fewer available write tools means fewer risky auto-run prompts to accidentally approve on autopilot.
- On large PRs, ask for diffs scoped to a specific path rather than the whole PR to preserve context budget for Cursor's codebase-aware reasoning.
- Explicitly request ```suggestion fenced blocks when you want one-click-appliable review comments — the model won't default to that format unprompted.

Tips

Tips
- Confirm Agent Mode (not Chat or Cmd-K) is selected before any GitHub MCP prompt — it's the single most common reason a GitHub-related prompt in Cursor produces zero tool calls.
- Use Cursor's local-checkout awareness deliberately: reconcile MCP-reported GitHub state against your working tree before trusting a review or triage result grounded in possibly-stale local code.
- Keep GITHUB_TOOLSETS narrow as your primary safety control, since Cursor lacks Claude Code's persisted per-tool allow/ask/deny rules for MCP servers.

Next Real World Workflow Code Review And Issue Management