MCP Spotlight: GitHub MCP Server — The Official 100+ Tool Bridge With Toolsets, OAuth, Dynamic Tool Discovery & Code Security Built In

Server: github-mcp-server by GitHub Tools: 100+ (organized into dynamic toolsets) · License: MIT · Transports: Local (stdio) + Remote (HTTP, OAuth) Toolsets: repos · issues · pull_requests · actions · code_security · secret_protection · discussions · gists · notifications · projects · users · code_scanning · dependabot · labels · workflows · context (and more) First-party guide: github.blog/.../a-practical-guide-on-how-to-use-the-github-mcp-server Docs: docs.github.com/.../use-the-github-mcp-server

If you build software for a living, your agent should be able to read your code, open PRs, triage issues, and run Actions without you copy-pasting between GitHub.com and your IDE. The official GitHub MCP Server is the bridge that makes that real: maintained by GitHub itself, distributed as the github-mcp-server Docker image and as a managed remote endpoint with OAuth, organized into dynamic toolsets that ship the right tool surface for each task, and engineered with the same tool-annotation discipline as the rest of the MCP ecosystem.

This is the integration every coding agent should ship with by default. 100+ tools covering repositories, issues, pull requests, Actions, code security, secret protection, code scanning, dependabot, discussions, gists, projects, notifications, users, workflows, and labels — and the entire surface is configurable, scope-minimal, and OAuth-native.

The Architecture: Dynamic Toolsets

The single most important design choice: the GitHub MCP Server ships its 100+ tools as named toolsets that can be enabled/disabled individually. The server's tools/list response is computed dynamically based on the active configuration — you never get a flood of 100 tools when you only need to read a file.

Toolset	What It Covers	Typical User
repos (default)	Read/write files, search code, list branches, commits, releases, tags, contents	All developers
issues (default)	Create, read, update, comment, label, search issues	All developers
pull_requests (default)	Create, read, merge, review, diff, list files, request reviewers	All developers
actions	Workflow runs, logs, secrets, manual triggers, artifacts	DevOps, SRE
code_security	Code scanning alerts, secret scanning alerts, security overview	Security engineers
secret_protection	Push protection bypasses, secret scanning status	Security engineers
discussions	GraphQL discussions, categories, comments	Maintainers
gists	Create, update, list, search, fork gists	All developers
notifications	Read, mark as read, list notifications	All developers
projects	GitHub Projects v2, fields, items, views	PM, engineering leads
users	Search users, get profiles, list org members	All developers
code_scanning	Alerts, analyses, rules	Security engineers
dependabot	Alerts, configuration, dismissals	Security engineers
labels	List, create, update, delete labels	All developers
workflows	List, run, manage workflow files	DevOps

You configure the active toolsets in .github/mcp-config.json:

{
  "toolsets": ["repos", "issues", "pull_requests", "actions"]
}

The server's tools/list returns only those toolsets. The agent sees a focused surface, not a 100-tool dump. This is the right MCP design — the protocol supports dynamic tool surface composition, and GitHub uses it.

Two Deployments: Local + Remote

The server ships in two flavors:

🏠 Local stdio (Docker / NPX)

docker run -i --rm \
  -e GITHUB_PERSONAL_ACCESS_TOKEN=${credentials.GITHUB_PAT} \
  ghcr.io/github/github-mcp-server

• Runs as a child process inside your IDE / agent runtime
• Authenticated with a Personal Access Token (PAT) you generate in GitHub settings
• Full control: which toolsets, which PAT scopes, which container security policy
• No data leaves your machine except for the GitHub API calls themselves

☁️ Remote (managed endpoint, OAuth)

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

• Hosted by GitHub (no server to run)
• OAuth 2.0 flow — click "Sign in with GitHub", approve scopes
• Token refresh handled by the server
• Auto-updated with new toolsets and security patches
• Same toolset configuration as the local version

The blog post "A practical guide on how to use the GitHub MCP server" walks through both, with the explicit guidance that the remote endpoint is the recommended path for most users — automatic updates, no token rotation, OAuth-native.

The Killer Tools

A few of the tools deserve specific callouts:

Tool	What It Does
search_code	Full repo code search with qualifiers (repo:, path:, language:, extension:)
get_file_contents	Read a file at a specific ref with optional line range
create_or_update_file	Single-file write — creates or updates
create_pull_request	Create a PR with title, body, head, base, draft flag, reviewers
merge_pull_request	Merge with method (merge, squash, rebase) and commit message
add_issue_comment	Comment on an issue, optionally with PR/issue links
search_issues	GitHub search syntax for issues and PRs across repos
list_workflow_runs	List Actions runs with status, conclusion, branch, actor filters
get_workflow_run_logs	Download the logs of a specific Actions run
list_code_scanning_alerts	List code scanning alerts for a repo with severity filter
list_secret_scanning_alerts	List secret scanning alerts for a repo with state filter
create_issue	Create a new issue with assignees, labels, milestone
update_issue	Update state, assignees, labels, milestone of an issue
request_copilot_review	Trigger Copilot to review a PR

The combination of search_code + get_file_contents + create_pull_request is the bread-and-butter agent workflow: find a function, read it, fix it, open a PR. The agent does this in 4 tool calls.

The security tools (list_code_scanning_alerts, list_secret_scanning_alerts) are the differentiator — most "code AI" integrations can read your code, but the GitHub MCP server can also surface the security findings GitHub has already produced. The agent can reason: "this function is XSS-prone and there's a code-scanning alert for it; let me fix both."

Facio Integration

{
  "mcpServers": {
    "github": {
      "url": "https://api.githubcopilot.com/mcp/",
      "auth": "oauth",
      "toolsets": ["repos", "issues", "pull_requests", "actions", "code_security"]
    }
  }
}

Facio's audit trail captures every GitHub MCP call with the user identity, the toolset, the tool, the parameters, the diff, and the result. For an agent that opens a PR, Facio captures the file diff, the PR description, the reviewers, the branch — enough to reproduce the action deterministically.

For HITL workflows, the tool annotations map cleanly to gate requirements:

Operation	Severity	Suggested Gate
get_file_contents, search_code, list_*	Read	None — autonomous
create_issue, add_issue_comment	Write, idempotent	None for known patterns (e.g., standup updates)
create_or_update_file on a feature branch	Write, idempotent	Soft confirm (review the diff)
create_pull_request to main	Write, destructive in effect	Hard confirm (visible to the team)
merge_pull_request to main	Write, destructive	Hard confirm (CI may not have run yet)
delete_file, delete_branch	Write, destructive	Hard confirm (irreversible on origin)
push_protection_bypass	Write, destructive	Hard confirm + reason required

The OAuth scope of the PAT (or the OAuth token) controls the ceiling. The HITL confirmation controls the per-call gating. Both layers enforce: the agent never pushes to main without a human saying so.

Quickstart

# 1. Local stdio (Docker)
docker run -i --rm \
  -e GITHUB_PERSONAL_ACCESS_TOKEN=${credentials.GITHUB_PAT} \
  ghcr.io/github/github-mcp-server

# 2. Local stdio (NPX)
npx -y @modelcontextprotocol/server-github

# 3. Remote (managed endpoint, recommended)
#    Add to MCP client config:
{
  "mcpServers": {
    "github": {
      "url": "https://api.githubcopilot.com/mcp/",
      "auth": "oauth",
      "toolsets": ["repos", "issues", "pull_requests", "actions"]
    }
  }
}

# 4. First prompts
# "Find every TODO in src/ older than 6 months and open a tracking issue for each"
# "Open a PR that adds retry logic to the Stripe webhook handler with exponential backoff"
# "List all open code-scanning alerts in this repo, sorted by severity, and draft a fix PR for the top 3"
# "Who reviewed the most PRs on this team in the last 30 days?"
# "Find the issue that introduced this regression and link it to the commit that fixed it"

Use Cases

PR review automation: "Find all open PRs in the 'API' org assigned to no one, summarize each, and assign the right reviewer based on codeowners." Agent scans PRs, parses diffs, matches against CODEOWNERS, makes assignments — human approves each one.

Issue triage: "List all open issues labeled 'needs-triage' across our repos, classify them (bug, feature, question, doc), suggest labels and assignees, and add a triage comment." Mass triage workflow that normally takes a maintainer a weekend.

Security audit: "Pull all code-scanning alerts and all secret-scanning alerts in this org, group by severity and repo, and draft a remediation plan." The agent produces a structured audit report from the security toolsets.

Refactor planning: "Find all usages of the deprecated request.get() API across the codebase, count them by file, and open a tracking epic for the migration." Cross-repo query with epic creation.

Release notes generation: "Compare the last 20 PRs merged to main, group by area (frontend, backend, infra), and draft release notes for the team meeting." The agent reads merged PRs, classifies them, and writes the summary.

Dependabot supervision: "List all Dependabot alerts older than 7 days, identify the ones that block deployment, and open PRs to bump them." The agent uses dependabot + repos + pull_requests toolsets in a coordinated workflow.

Onboarding for new contributors: "Find the 10 most-asked questions in our Discussions, link them to the relevant docs pages in our repo, and draft a CONTRIBUTING.md update." Cross-product synthesis (Discussions + repos + search) that humans rarely do well.

Code archaeology: "When was this regex introduced, by whom, and in which PR? Has it been touched since?" Agent traces a string across the git history using search_code + commit history.

Bottom Line

The GitHub MCP Server is the official, first-party integration that every coding agent should ship with by default. 100+ tools, organized into 15+ dynamic toolsets, two deployment paths (local stdio + remote OAuth), full tool annotations, configurable per-toolset scope, and maintained by GitHub itself.

For developers, this is the missing layer that turns "agent helps me with code" into a real workflow. The agent can search code, read files, open PRs, merge after CI, triage issues, run Actions, surface security alerts — all from the same conversational surface, with proper audit, proper permissions, proper HITL gating on the destructive calls.

For the broader MCP ecosystem, the dynamic-toolset pattern is the template every large-surface-area server should copy. Don't ship 100 tools in the default tools/list. Organize them into named, enable-able toolsets, and let the user (or the agent runtime) pick the active set per session.

docker run ghcr.io/github/github-mcp-server or sign in to https://api.githubcopilot.com/mcp/. Your agent has GitHub.

---

MCP Spotlight is a series covering servers that give AI agents real capabilities. Every server is evaluated for architecture, vendor commitment, and integration fit with Facio's HITL-first agent runtime.