Configure the GitHub Remote MCP Server
GitHub ships an official MCP server in two flavours — a local Docker image and a hosted remote server. Learn how to choose between them, scope authentication, and select the right toolsets so the agent can do its job without becoming a supply-chain risk.
Configure the GitHub Remote MCP Server
The fastest way to give an agent real, reviewable access to GitHub is the official GitHub MCP Server. It ships in two flavours that you must learn to pick between, plus a toolset system that decides exactly how much of the GitHub API the agent can reach.
Local vs remote — pick the right flavour
| Flavour | When to use | Auth | Trade-offs |
| --- | --- | --- | --- |
| Remote (hosted) | You want zero install, you trust GitHub to host the endpoint, and your host supports remote MCP. | OAuth or PAT | Easiest path; exposes some toolsets unavailable locally. Network-dependent. |
| Local Docker | Air-gapped or strict tenant; you need custom flags (--read-only, --toolsets); you must pin a version. | PAT (env var) | Full control of process and flags; you maintain the upgrade path. |
| Local from source | Contributors and advanced operators only. | PAT | Highest control, highest maintenance. |
Toolsets are your scope dial
The GitHub MCP Server groups tools into toolsets such as repos, issues, pull_requests, actions, code_security, discussions, users, orgs. The default toolset is intentionally narrow — context, repos, issues, pull_requests, users. Add more only when a task needs them:
github-mcp-server --toolsets repos,issues,pull_requests
# or
GITHUB_TOOLSETS="repos,issues,pull_requests" github-mcp-server
For audit-only or research workloads, combine with --read-only so the server refuses every mutating call regardless of token scope.
Remember the chain of custody: scope token → scope toolsets → scope individual tools. Each layer is a chance to revoke power; missing any one widens the blast radius.
Quick check
Quick check
A team wants their IDE-based Copilot agent to triage issues and post comments on one repository, with no ability to merge or push. Which configuration best implements least privilege?
Where this shows up on the exam
GH-600 questions about the GitHub MCP server reward you for naming the minimum configuration: the smallest toolset, the narrowest PAT scope, and the right flavour (remote vs local) for the constraint stated in the scenario. If a question mentions "auditable" or "no install", reach for remote + OAuth; if it mentions "air-gapped" or "self-hosted runners", reach for local Docker.
Key terms
- GitHub MCP Server
- The official, GitHub-maintained MCP server that exposes 20+ GitHub toolsets (repos, issues, pull_requests, actions, code_security, …) to any MCP-capable host.
- Remote MCP server
- A hosted variant of the GitHub MCP server reachable over HTTP that needs no local install and supports OAuth — generally the easiest path.
- Toolset
- A named bundle of related tools (e.g. `repos`, `issues`, `pull_requests`) that can be enabled or disabled together to keep the tool surface tight.
- PAT scope
- A permission attached to a GitHub Personal Access Token (`repo`, `read:org`, `security_events`, …) that limits which API calls succeed.
Common pitfalls
- Enabling every toolset 'just in case' — the model becomes worse at picking the right tool and the blast radius grows with no offsetting benefit.
- Using a classic `repo` scope when fine-grained tokens scoped to one repository would do — classic tokens grant broad write across every repo you can access.
- Forgetting that `--read-only` is a server-side flag: enabling it on the host config does nothing unless the GitHub MCP Server itself was started with it.