Remote or local GitHub MCP server: which should you run?

What each one is

Both come from the same repository. GitHub's remote server documentation says the hosted version "is built using this repository as a library" and that GitHub "regularly update[s] the remote server to include the latest version of this code."

• Remote. GitHub runs it at https://api.githubcopilot.com/mcp/. Your client connects over HTTP.
• Local. You run it yourself, either as the public Docker image ghcr.io/github/github-mcp-server or by building the Go binary from cmd/github-mcp-server and running github-mcp-server stdio. Your client starts it as a local process.

Either way, the tools call the GitHub API with your credentials. The choice is about where the MCP process runs, who updates it and how you sign in, not about whether GitHub sees your requests.

Side by side

Factor	Remote	Local
Install	None	Docker, or a Go build
Client requirement	Remote MCP support (the README names VS Code 1.101 or later, Claude Desktop, Cursor and Windsurf among others)	Any client that can start a local server
Sign-in	OAuth with scope challenges, or a personal access token	OAuth login on first use, or GITHUB_PERSONAL_ACCESS_TOKEN (the token takes precedence)
GitHub Enterprise Server	Not supported	Supported with --gh-host or GITHUB_HOST
GitHub Enterprise Cloud with data residency (ghe.com)	Supported, at copilot-api.YOURSUBDOMAIN.ghe.com/mcp	Supported with GITHUB_HOST
Choose toolsets	X-MCP-Toolsets header or /x/{toolset} URL	--toolsets flag or GITHUB_TOOLSETS
Read-only mode	X-MCP-Readonly header or /readonly URL	--read-only or GITHUB_READ_ONLY
Exclude tools	X-MCP-Exclude-Tools header	--exclude-tools or GITHUB_EXCLUDE_TOOLS
Extra toolsets	copilot_spaces and github_support_docs_search are remote only	Not available
Updates	GitHub updates it	You decide when to pull or rebuild

The configuration rows come from the server configuration guide; the rest from the repository README. The README states plainly: "GitHub Enterprise Server does not support remote server hosting."

The case for remote

The remote server is the shortest path for someone who wants to try MCP against github.com. With OAuth, the scope filtering document says "when a tool needs a scope you haven't granted, you're prompted to authorize it," so you are not asked for every scope at the start. You also skip keeping a token in a config file.

Things to check first:

1. Your client must support remote servers and, for OAuth, the README notes that "Each MCP host application needs to configure a GitHub App or OAuth App." If yours has not, use a personal access token instead.
2. If you work in an organisation, the README lists "Any applicable policies enabled" as a prerequisite. An owner may need to allow it.
3. The URL form only takes one toolset (/x/issues, not /x/issues,repos). To combine toolsets, use the X-MCP-Toolsets header.

A minimal read-only setup in VS Code's mcp.json:

{
  "servers": {
    "github": {
      "type": "http",
      "url": "https://api.githubcopilot.com/mcp/",
      "headers": { "X-MCP-Toolsets": "repos,issues,pull_requests", "X-MCP-Readonly": "true" }
    }
  }
}

The case for local

Run it locally when the remote option cannot work or when you want control over the process:

• Enterprise Server. Only the local server can point at your own host. The README says the host must use https://, and that "non-HTTPS hosts are refused" except for loopback hosts during local development.
• Clients without remote support. Any client that can launch a command can run the Docker image.
• A fixed version. The remote server changes when GitHub deploys it. Locally, nothing changes until you pull a new image or rebuild.
• Isolation. The Docker image runs in a container you start and stop. Add --rm so nothing is left behind.

A local setup with a token and the same limits:

{
  "servers": {
    "github": {
      "command": "docker",
      "args": ["run", "-i", "--rm", "-e", "GITHUB_PERSONAL_ACCESS_TOKEN", "-e", "GITHUB_TOOLSETS", "-e", "GITHUB_READ_ONLY",
               "ghcr.io/github/github-mcp-server"],
      "env": {
        "GITHUB_PERSONAL_ACCESS_TOKEN": "${input:github_token}",
        "GITHUB_TOOLSETS": "repos,issues,pull_requests",
        "GITHUB_READ_ONLY": "1"
      }
    }
  }
}

The README also documents an OAuth login for the local server: the Docker install buttons publish a callback port on 127.0.0.1:8085, and the resulting token "is kept in memory only." If you use a token instead, the README's advice is to keep it in an environment variable, add .env to .gitignore, and run chmod 600 on any config file that holds it.

What does not change between them

Both versions support the same toolsets, read-only mode, excluded tools and lockdown mode. The configuration guide describes lockdown mode as "a best-effort content filter, not a security boundary," so do not treat it as protection on either side. Neither version reduces what your credential can do: the token or OAuth grant is the real limit. The thread on which token scopes the GitHub MCP server needs covers how to keep that small.

A short decision path

1. On GitHub Enterprise Server? Run local.
2. Client cannot connect to remote servers? Run local.
3. Need to pin the version for a team or a course? Run local.
4. Otherwise, start with remote in read-only mode, and add write toolsets only when a task needs them.

For a full list of tools and what each can change, see the CodeLifter GitHub MCP server page. If you also give an assistant file access on your machine, the thread on sandboxing the Filesystem MCP server covers the local side, and who is the author of a commit made through an MCP server covers what happens once writes are on.