GitHub MCP Server: connecting AI hosts to GitHub through the official remote and local servers

What the GitHub MCP Server actually connects

The project is an MCP server, not a client. It sits between an AI host (VS Code, Claude Desktop, Cursor, Windsurf, Codex, OpenCode, Zed and others listed in the README's installation guides) and GitHub's platform, and translates tool calls into GitHub API operations. The README frames the use cases as repository management, issue and PR automation, CI/CD workflow intelligence, code analysis and team collaboration, which in practice means an agent can read files, search code, inspect commits, triage issues, review pull requests, look at Actions runs and read Dependabot or security findings without a human pasting URLs into a chat window.

The audience is narrow and specific: developers who already run an MCP-capable host and want GitHub context inside it. It is not a standalone CLI you type into, and it is not a GitHub client library. If you do not have an MCP host, there is nothing here to install into.

Remote endpoint versus local binary

GitHub ships two deployment shapes. The remote server is hosted by GitHub at https://api.githubcopilot.com/mcp/ and the README calls it the easiest way to get running. The local server is a Go binary you build or pull yourself, and the README points to it explicitly for hosts that do not support remote MCP servers.

The distinction matters for more than convenience. With the remote server, GitHub handles hosting and OAuth, and your host only needs to speak HTTP MCP with a bearer token or an OAuth flow. With the local server, the process runs on your machine and reaches GitHub with whatever credentials you give it. The repository layout backs this up: cmd/ holds the entrypoint, internal/ and pkg/ hold the implementation, and there is a Dockerfile plus a .goreleaser.yaml for distribution.

One structural detail worth noticing is the ui/ directory and the Dockerfile's two-stage build. The first stage runs npm ci and npm run build on the UI, and the compiled assets are copied into pkg/github/ui_dist/ before the Go build. That means the binary is not purely a headless API bridge; there is a UI component compiled into it.

Installing the remote server in VS Code

The README gives a one-click install button and a manual JSON configuration for VS Code. The manual OAuth variant is the shortest path: add the block below to your host configuration, then toggle Agent mode next to the Copilot Chat input and the server starts. The README states VS Code 1.101 or later is required for remote MCP and OAuth support.

{
  "servers": {
    "github": {
      "type": "http",
      "url": "https://api.githubcopilot.com/mcp/"
    }
  }
}

If you prefer a personal access token instead of OAuth, the README's alternative block adds an Authorization header and declares a prompted input so the token is not written into the file in plain text:

{
  "servers": {
    "github": {
      "type": "http",
      "url": "https://api.githubcopilot.com/mcp/",
      "headers": {
        "Authorization": "Bearer ${input:github_mcp_pat}"
      }
    }
  },
  "inputs": [
    {
      "type": "promptString",
      "id": "github_mcp_pat",
      "description": "GitHub Personal Access Token",
      "password": true
    }
  ]
}

After saving, the host should show the github server as connected and expose its tools. The README notes that each MCP host application needs to configure a GitHub App or OAuth App for remote access via OAuth, and that support levels vary by host, so check the host's own documentation if the OAuth flow does not complete.

Toolsets decide what the agent can touch

The README states that when no toolsets are specified, default toolsets are used, and it points to docs/remote-server.md for the full list of configuration, toolsets and headers. This is the part most teams will need to read before deployment, because the default is not the minimum. An agent connected with default toolsets gets a broad slice of GitHub surface area, and the README does not describe a per-tool permission model on top of the token you supply. The credential you hand the server is effectively the ceiling.

Two knobs are documented in the README itself. Insiders mode can be turned on either by changing the URL path to https://api.githubcopilot.com/mcp/insiders or by keeping the base URL and adding the header X-MCP-Insiders: true. The README describes insiders as early access to new features and experimental tools and links docs/insiders-features.md for the list. Treat that as a separate risk decision: experimental tools on a credential with write access is a different posture from default toolsets on a read-only token.

GitHub Enterprise and ghe.com endpoints

For GitHub Enterprise Cloud with data residency, the README shows a different hostname pattern. The example for https://octocorp.ghe.com uses https://copilot-api.octocorp.ghe.com/mcp with the same bearer token header. The note attached to it says that when using OAuth with GitHub Enterprise in VS Code and GitHub Copilot, you also need to configure VS Code settings to point at your GitHub Enterprise instance.

That is a real friction point. The public api.githubcopilot.com/mcp/ URL does not apply to ghe.com tenants, and the OAuth path has an extra configuration step that the PAT path does not. If your organisation is on a data-residency tenant, budget time for the VS Code settings change, not just the server entry.

Where the local server is the wrong tool

The local server exists for hosts without remote MCP support, but it is not a drop-in equivalent. You own the build, the credentials and the update cycle. The Dockerfile builds from golang:1.27.1-alpine and node:26-alpine and finishes on gcr.io/distroless/base-debian12, and it injects OAuth client credentials as build secrets via --mount=type=secret,id=oauth_client_id and oauth_client_secret. The Dockerfile comment states those values are public in practice but kept out of image layers. If you build your own image, you are responsible for supplying those secrets or accepting an empty value, because the build falls back to an empty string when the secret files are absent.

There is also an operational gap the README does not close. It documents installation for many hosts and points at docs/remote-server.md for remote configuration, but it does not describe rollback, downgrade, or what happens to in-flight agent sessions when the server version changes. If you pin a local build, that is on you to manage. If you use the remote server, version changes arrive on GitHub's schedule.

Finally, this is the wrong tool if your goal is unattended automation. MCP is an interactive protocol between a host and a model. For scheduled jobs that open issues or sync labels, the GitHub REST or GraphQL API called directly from a script is simpler and has no model in the loop.

How it compares to calling the GitHub API from an agent

The obvious alternative is not another MCP server; it is giving your agent a shell and letting it call gh or curl against the GitHub API. The difference is in who defines the interface. With the raw API, the model has to know endpoint shapes, pagination and authentication, and every new capability is a new prompt or a new tool you write. With the GitHub MCP Server, GitHub defines a fixed tool surface, the host discovers it, and the model calls named tools instead of constructing HTTP requests.

The trade-off runs the other way too. A fixed tool surface is a fixed tool surface: if a GitHub API capability is not exposed as a tool in your configured toolsets, the agent cannot reach it, whereas a shell-equipped agent can call anything the API allows. The go.mod shows the server is built on github.com/modelcontextprotocol/go-sdk, github.com/google/go-github/v89 and github.com/shurcooL/githubv4, so the tool surface is bounded by what those clients and the toolset definitions cover.

Licence, maintenance and what an upgrade costs

The repository is MIT licensed, which permits commercial use, modification and redistribution provided the copyright notice and permission notice are included. The repository also carries third-party-licenses.darwin.md, third-party-licenses.linux.md and third-party-licenses.windows.md, so if you redistribute a built binary you should read those files rather than assuming MIT covers everything linked in. None of this is legal advice; check with your own counsel for a redistribution decision.

Maintenance is active by the only measure available here: the last push was on 2026-08-25, and v1.11.0 was released the same day, following v1.10.1 on 2026-08-20 and v1.10.0 on 2026-08-19. Three releases in six days is a fast cadence, and that is the upgrade cost. If you self-host, you are tracking a project that ships often, and the README does not document a compatibility or deprecation policy for toolsets between minor versions. Pinning a tag and reading the release notes before each bump is the only defensible approach the README supports.

Editorial conclusion

Adopt the remote server if your host supports HTTP MCP and you want zero build steps, and adopt the local binary only when the host cannot reach a remote endpoint or when you need the server inside your own network. Skip it if you need write access scoped tighter than a PAT or OAuth grant allows, since the README does not document per-tool permission narrowing. Before rolling it out, confirm your host version (VS Code 1.101 or later for remote MCP and OAuth), check which toolsets the default configuration exposes, and verify your GitHub Enterprise or ghe.com endpoint against docs/remote-server.md rather than assuming the public URL applies.

Frequently asked questions

Official sources

1. Official README
2. Project repository
3. Release notes