GitHub MCP Server

1What it does

GitHub's own Model Context Protocol server — the canonical way to give an agent structured access to repositories, issues, pull requests, code search, Actions workflows, Dependabot and code security alerts without shelling out to gh. The server exposes toolsets you can scope per install (repos, issues, pull_requests, code_security, actions and more), so the agent sees only the surface you intend. For Antigravity specifically it is one of the few MCP servers with a first-party install guide in GitHub's own documentation — the remote server runs hosted at api.githubcopilot.com/mcp (Streamable HTTP, OAuth or PAT), and a self-hosted stdio build exists for air-gapped or custom-permission setups. It is GitHub-maintained, MIT-licensed, and effectively the reference implementation for what a production-grade MCP server looks like.

2When to use it

Reach for it the moment the agent needs to touch GitHub state — triage an issue list, review a PR, read CI logs, search code across repos — rather than scraping git output or the web UI. The hosted remote server is the default for most setups (no binary to run, auth via OAuth/PAT); choose the local stdio build only when you need custom toolset scoping, a proxy, or a GitHub Enterprise Server endpoint. Skip it if your agent never leaves the local filesystem — it does nothing for offline work, and a server you don't use is just extra attack surface in mcp_config.json.

3How to get started

Antigravity discovers MCP servers from mcp_config.json. The documented remote install is a single block pointing at the hosted endpoint with your token in headers, or OAuth where supported — follow the step-by-step in GitHub's "Using the GitHub MCP Server with Antigravity" guide, which covers the exact JSON shape, the Personal Access Token scopes to grant, and how to verify the server appears in the agent's tool list. For the local path, go install or the released binary plus a command/args block with a PAT in env achieves the same; the repo's docs directory has the per-client JSON for both transports.

4Configuration

Two decisions matter. First, toolsets: the server starts broad — scope to the toolsets you need (e.g. repos + pull_requests for review work, skip code_security if the agent shouldn't triage alerts) via the documented flags/env so the tool surface stays tight. Second, the PAT: use a fine-grained token scoped to the repositories and permissions the work needs — a classic broad-scope PAT in mcp_config.json is the common foot-gun, and the docs cover read-only mode if the agent should observe but never write. Lock down mcp_config.json file permissions; tokens inside are plaintext to anything that can read the file.

5Things to know

• "Official" here means GitHub-official, not Google — the server is GitHub's own project; its Antigravity guide is first-party documentation, which is rare enough in this ecosystem to be worth noting.
• Remote vs local is a real fork in the road: remote needs no install but routes calls through GitHub's hosted endpoint; local stdio keeps everything on your machine at the cost of managing a binary and token yourself.
• Toolset scoping matters for agent latency too — fewer registered tools means a smaller schema the model must reason over every turn.
• Rate limits and PAT quota apply per token — an agent polling in a loop can exhaust an hourly budget quickly; prefer the agent's on-demand call pattern over scripted polling. - Enterprise boundary is a real decision point — GitHub Enterprise Server users should check the docs' GHE section before wiring, since the hosted remote endpoint does not reach self-hosted instances.
• Read-only mode deserves more use than it gets — for review-style work a scoped-down server removes the whole class of "agent opened a PR by accident" failures.

6Related on the map

References

• Repository
• Antigravity install guide (GitHub Docs)