GitHub MCP server: how to set it up, and what it can actually answer

Setting up the official GitHub MCP server takes three minutes: point your agent at https://api.githubcopilot.com/mcp/, authenticate with a GitHub account, and it gains around twenty families of tools over your repositories — files, commits, pull requests, issues, Actions, security alerts. Its limit is not access. It is that a diff is read one commit at a time, on explicit request, and that this is not the default setting.

This guide does both halves: the real setup in Claude, Cursor and VS Code, then a record of what it answers well and the call log of a question it answers badly. Everything below was re-read in the github/github-mcp-server repository on 10 September 2026.

Setting up the GitHub MCP server, step by step

Two ways to run it. The remote one is hosted by GitHub, with nothing to install:

{
  "mcpServers": {
    "github": {
      "url": "https://api.githubcopilot.com/mcp/",
      "headers": { "Authorization": "Bearer YOUR_GITHUB_PAT" }
    }
  }
}

• Cursor: that block goes in ~/.cursor/mcp.json, then restart. The docs ask for Cursor v0.48.0 or newer, for streamable HTTP transport.
• VS Code: same URL, servers key instead of mcpServers, version 1.101 minimum. With no Authorization header, VS Code runs a browser OAuth flow instead.
• Claude Code: one line, claude mcp add github with the URL; the local variant passes the Docker image.

The local way runs the server on your machine, from the public image ghcr.io/github/github-mcp-server. It is mandatory for GitHub Enterprise Server, which the hosted version does not serve. Two ways to authenticate: a personal access token in GITHUB_PERSONAL_ACCESS_TOKEN, or a browser OAuth login whose token is kept in memory only. The personal token wins when both are present.

One last setting, useful from day one: the server exposes around twenty toolsets — repos, issues, pull_requests, actions, code_security, git, orgs and more. You do not want twenty. Set an allow-list with GITHUB_TOOLSETS="repos,pull_requests" locally, or point at a toolset URL on the remote side: https://api.githubcopilot.com/mcp/x/repos.

What it answers well, and that deserves saying

On a repository your token can reach, the agent becomes genuinely capable. A few questions it handles without trouble:

• "Where is VAT calculated?" — code search, then file reads.
• "What does PR 412 do, and who reviewed it?" — the pull request, its comments, its commits.
• "Is the main build green?" — Actions workflow status, logs of failing jobs.
• "List this week's commits on main." — a date-filtered list, up to a hundred results per page.
• "Any open Dependabot alerts?" — straight answer.

For a tooled developer, that is a clear win. A repository's knowledge stops being something you read and becomes something you query. If that is your need, stop reading here and install it.

"What changed in the product this week?"

That one it answers badly. Not because it is forbidden — because it is expensive. The clearest way to see it is to walk through the calls the agent has to make. The numbers below are illustrative; swap in your own and the shape holds.

1. The agent calls list_commits with since set to Monday. It gets 40 commits: SHA, author, date, message.
2. It reads the messages. Twelve say something ("add CSV separator option"); twenty-eight say "fix", "wip", "review comments".
3. To learn what those twenty-eight did, it needs the diff. So it calls get_commit, one commit at a time.
4. By default, get_commit returns the stats level: file names, lines added and removed. No content.
5. Diff content requires an explicit parameter, detail: "full_patch". The documentation itself warns that the response "can be very large".
6. Times forty commits, the full patches do not fit in the context window. The agent truncates, gives up, or answers from the twelve readable messages.

What comes back looks like an answer. It lists what the commit messages already said. The other twenty-eight changes went through untouched.

The limit is not access, it is the per-commit cost

This is the nuance most guides miss, including friendly ones. You often read that the GitHub MCP server "only sees metadata". That is wrong, and correcting it beats repeating it: it does see diffs, it serves them whole on request, and the parameter is documented.

What it does not do is aggregate. Each diff is a call, each call costs context, and nothing turns forty of them into a list of behaviour changes. Aggregation is analysis work; the API supplies raw material, not the finished product.

The practical consequence shows up at scale. On one commit, "why did this behaviour change" is handled beautifully by the official tool. On a whole release, it is not handled at all. The wall is not a locked door, it is an addition.

The second wall: one credential per asker

The first wall is technical and patience gets you around it. The second one does not move.

The GitHub MCP server acts under your token. Every person and every agent that wants to ask a question therefore needs repository access of their own. For you, a developer, that is one more token in a config file. For everyone else, it is a wall.

Who is everyone else? A support agent like Intercom Fin or HubSpot Breeze, answering your customers all day. An agency's client, whose contract forbids exposing the code. An external integrator wondering whether your API moved. None of them will hold a token on your repository, and that is as it should be.

Narrowing the surface: read-only mode

If you install the official tool, install it tight. Three settings, all documented, all free:

• --read-only: the server exposes read tools only. The flag takes priority — a write tool requested by name is still skipped.
• Read-only URLs on the remote side: every toolset has its variant, such as https://api.githubcopilot.com/mcp/x/issues/readonly.
• The toolset allow-list above, or even a named list of individual tools via GITHUB_TOOLS.

An agent that answers questions needs no write access at all. That should be the default; it is not yet. Set it yourself.

When a per-project product expert becomes the right answer

Between them, the two walls describe what is missing: something that has already read the diffs, and that answers without the asker holding any access. That is DeployIt's job. DeployIt reads your actual code (resynced on every push), your git history (commits and diffs) and your customer data through its own MCP servers, and checks the code before it asserts anything. One MCP server per project acts as the expert on your product: the weekly question comes back as a list of behaviour changes sourced from diffs, even when twenty-eight commits out of forty are called "fix".

The shift fits in one sentence: the people you work with get access to the answers, not access to the code. The support agent queries the expert. So does the agency's client. Nobody opens an account on the repository.

The two tools also live together comfortably. Keep the GitHub MCP server in your IDE, where it shines — one repository, one developer, real credentials. The product expert covers the surfaces where credentials do not exist, and the questions that span a whole release.

"We just need better commit messages"

True, and it is the strongest argument against us. A team that enforces conventional commits and one PR per change will get correct "what changed" answers out of the official tool. Discipline replaces analysis, and it works.

Two caveats, one factual and one about reach. Factual: that discipline rarely survives past the core team, and it does nothing for the three years of history already written. Reach: a commit message says what its author believed they were doing, not what the code does now. A fix typo that changes a default value stays a fix typo in the list, and a behaviour change in the product.

The diff has no such blind spot. That is the only reason we start from it.

"So DeployIt reads my repository too?"

It does, and asking is healthy — we just spent an article explaining that the material lives in the diffs, so they have to be read. The terms are bounded. GitHub connection in read-only mode. One server per project: the one for your mobile app has no idea your billing service exists. Answers sourced from commits and diffs, never a dump of raw source. Access revocable at any time from GitHub.

To place it on the map: Context7 and DeepWiki cover public libraries and repositories, Mintlify generates an MCP server from written documentation. DeployIt covers your private product, derived from the code itself, fresh on every deployment. The DeployIt MCP server is in early access, through a design partner program.

Mini-FAQ

Is the GitHub MCP server free? The server itself is open source and the Docker image is public. What matters is the reach of the token you hand it: it acts with your rights on your repositories, no more and no less.

Remote or local? Remote by default — nothing to maintain. Local on GitHub Enterprise Server, or for tight control over which tools are exposed.

Can it read diffs or not? It can, through get_commit with detail: "full_patch". The default level stops at per-file statistics, and the docs flag that a full patch can be very large. It is one call per commit.

Can my support agent use it? Technically yes, if it holds a repository token. In practice, granting code access to a third-party support platform is a decision few teams make — and support agents that don't know your product are better solved with an answers endpoint.

How is this different from Claude's native GitHub connector? The connector syncs files with no history; the MCP server gives tooled access to the API. Both routes are compared in our guide to what Claude connected to GitHub cannot see.

What to take away

Install the GitHub MCP server. It is good, it is free, it makes your IDE markedly more useful, and read-only mode is one line away.

Just know where it stops: one diff per call, one token per asker. Questions that span a whole release, and askers with no credentials, fall on the far side of that border — and those are the ones that keep a support desk, a help centre and a changelog derived from git history alive.

DeployIt is free during early access; paid plans are announced for January 2027. To shape the product expert with us, the design partner program is taking applications.