10 Things You Can Do With the GitHub MCP Server

GitHub's MCP server is organized into toolsets you enable per-install: repositories, issues, pull requests, actions, code security, discussions, notifications, projects, gists, and more. By default only a subset is active — you opt into the rest via the --toolsets flag. Everything below maps to real, documented tool names.

Real-world scenarios at a glance

• Sprint kick-off: "List all open issues assigned to me across our org repos, grouped by repo" — search_issues + list_issues.
• On-call triage: "Summarize the last 5 failed workflow runs and what jobs failed" — actions_list + get_job_logs.
• Security review: "List any open secret scanning alerts in this repo" — list_secret_scanning_alerts.
• Code archaeology: "Show me every commit that touched auth.ts in the last 90 days" — list_commits with path filter.
• Cross-repo code search: "Find all places in our org that use the deprecated createConnection API" — search_code.

1. Search code across all of GitHub

search_code runs GitHub's fast code search against any scope — a single repo, an org, or all of public GitHub. You get file paths, line matches, and repo context back directly in the conversation.

This is the single most powerful capability for developers who work across multiple repos or who want to find real-world usage of an API before writing their own integration. Combine it with get_file_contents to pull the full file once you've found the match.

2. Review pull requests end-to-end

pull_request_read fetches PR details, diff, commits, and review threads. pull_request_review_write lets the assistant leave inline comments, submit a review, and resolve threads.

The full PR review loop from the assistant:

1. Fetch the PR diff and description
2. Read the files touched using get_file_contents for full context
3. Leave inline review comments via pull_request_review_write
4. Request changes or approve — without leaving the editor

You can also use request_copilot_review to assign GitHub's own Copilot reviewer to a PR, and update_pull_request_branch to rebase it against the latest base before merging.

3. Triage and manage issues at scale

search_issues supports the full GitHub issue search syntax — filter by label, assignee, milestone, state, repo, org, and date. issue_write creates, updates, closes, and labels issues. sub_issue_write manages the parent-child sub-issue relationship GitHub added in 2025.

A practical triage prompt: "Find all open bugs labelled 'critical' in our org repos that haven't had activity in 14+ days, summarize them, and add a 'needs-triage' label to each." That's search_issues + issue_write in one thread.

4. Navigate any codebase without cloning

get_file_contents fetches any file at any ref (branch, tag, or commit SHA). get_repository_tree gives you the full directory structure recursively. list_commits shows commit history filtered by author, path, or date range, and get_commit returns the full diff for a specific SHA.

This is useful before integrating a third-party library — have the assistant explore its source to understand internals, or compare how two different OSS projects solve the same problem, without ever running git clone.

5. Trigger and debug GitHub Actions

actions_list lists workflow runs and jobs. actions_run_trigger dispatches a workflow run with custom inputs. get_job_logs fetches the raw log output — with a failed_only flag and a tail_lines cap so you're not dumping megabytes of log into context.

The classic debugging flow: list recent runs → find the failed one → fetch logs for failed jobs only → ask the assistant to explain the failure. Previously this meant three browser tabs and manual copy-paste. With MCP it's a single thread.

6. Surface security alerts before they become incidents

The code_security toolset exposes four tools: list_code_scanning_alerts and get_code_scanning_alert for static analysis findings (from CodeQL and third-party tools), plus list_secret_scanning_alerts and get_secret_scanning_alert for leaked credentials.

Both support filtering by state, severity, and ref. On top of that, list_global_security_advisories queries the GitHub Advisory Database — useful for checking whether a CVE affects packages you depend on.

Enable this toolset with --toolsets code_security — it's opt-in because it requires a token with security_events scope.

7. Push file changes directly from the conversation

create_or_update_file writes a single file with a commit message, branch, and optional SHA (for updates). push_files batches multiple files into one commit — more efficient for any change that touches more than one file.

Combine with create_branch and create_pull_request for the full automated PR workflow: branch → write files → open PR, without leaving the chat. Good for documentation updates, config changes, or scaffolded boilerplate where you want a reviewable diff rather than applying directly to main.

8. Manage GitHub Projects boards

The projects toolset gives you projects_list (list items, fields, and status values), projects_get (read a specific item or field), and projects_write (move items between status columns, update fields).

Useful for end-of-sprint housekeeping: "Move all issues in the 'In Review' column that have a merged PR to 'Done'." The assistant resolves issue ↔ PR linkage via search_pull_requests and then updates each project item in sequence.

9. Triage your GitHub notification inbox

list_notifications returns your GitHub notifications with filters for repo, owner, and time range. get_notification_details fetches the underlying thread. dismiss_notification marks individual items as read or done, and mark_all_notifications_read clears everything at once.

If you start the day by asking the assistant to "summarize my unread GitHub notifications and flag anything that needs a response from me", it reads each notification, fetches the thread context, and gives you a prioritized list — the GitHub equivalent of an AI email triage.

10. Generate release notes from commit history

list_commits filtered by date range or between two refs, combined with list_pull_requests merged into that range, gives the assistant everything it needs to write a structured changelog — grouped by feature, fix, and breaking change — without you maintaining a CHANGELOG.md by hand.

After the draft is ready, create_or_update_file writes the changelog to the repo and create_pull_request opens it for review. Then get_latest_release confirms what tag to base the next release off.

This is one of those workflows that takes 45+ minutes manually and under 2 minutes with the MCP server.

Why GitHub MCP is worth setting up

• Scope stays yours: the server operates under your PAT — it can only do what your token can do
• Opt-in toolsets: enable only what you need; the defaults are read-heavy and safe
• Works with any MCP client: Cursor, Claude Code, VS Code Copilot, Claude Desktop, and more
• 105+ tools: the breadth means almost any GitHub task can be expressed as a natural language prompt

Installation

You need a GitHub Personal Access Token with the scopes your intended toolsets require (at minimum: repo).

Cursor — .cursor/mcp.json

{
  "mcpServers": {
    "github": {
      "command": "docker",
      "args": ["run", "-i", "--rm",
        "-e", "GITHUB_PERSONAL_ACCESS_TOKEN",
        "ghcr.io/github/github-mcp-server"
      ],
      "env": {
        "GITHUB_PERSONAL_ACCESS_TOKEN": "<YOUR_TOKEN>"
      }
    }
  }
}

Claude Code

GITHUB_PERSONAL_ACCESS_TOKEN=<YOUR_TOKEN> claude mcp add github   -- docker run -i --rm   -e GITHUB_PERSONAL_ACCESS_TOKEN   ghcr.io/github/github-mcp-server

To enable extra toolsets, append --toolsets actions,code_security,discussions,notifications to the Docker args. Full list in the README.

FAQ

Do I need Docker or is there an npx option?

The official distribution is a Docker image (ghcr.io/github/github-mcp-server). Docker is the recommended path because it isolates the server process. There is no official npx package — community wrappers exist but the Docker image is the canonical one from GitHub.

What PAT scopes do I actually need?

For the default toolsets (repos, issues, PRs): repo scope is sufficient for private repos. Add workflow for Actions, security_events for code scanning/secret scanning, and notifications for notification tools. Use fine-grained PATs where possible and grant only the repos you need.

Can it access private repos?

Yes — the server uses your PAT, so it can access any private repo your token is authorized for. For organization-wide use, a GitHub App installation is a better fit than a personal PAT (scoped to the org, auditable, no single-person dependency).

Is this the same as GitHub Copilot?

No. GitHub Copilot is a code completion and chat product embedded in your editor. The GitHub MCP Server is a separate open-source project that exposes GitHub's platform APIs as MCP tools — so any MCP-compatible AI client can call them. You don't need a Copilot subscription to use the MCP server.

Related on MCP Playground

• Test MCP Server — connect any MCP server from the browser
• 10 Things You Can Do With Vercel MCP Server
• 10 Things You Can Do With Railway MCP Server
• What Is MCP?