NewAgent Observability is live.
Back to directory
GitHub logo

GitHub MCP server: tools, toolsets, read-only

GitHub's default tools arrive before the first request, and their definitions cost context before the agent asks anything.

Connector
Official, hosted or local
Coverage
Repos, issues, pull requests, Actions, code security
Tools
85 available, 44 on by default
Biggest risk for an agent
Write tools are on by default

Last verified 1 September 2026 · from GitHub's repository, its documentation and the server's own tools/list response

This page is one of 90 in a directory of monitoring and developer tools. Each page checks what an AI coding agent can get out of the tool through its MCP server, the connector that lets the agent query the tool directly.

Summary

The GitHub MCP server is MIT licensed, has 32,631 stars, and reached v1.11.0 on 25 August 2026. The tool counts on this page were measured on v1.9.0, released 10 August 2026.

It reaches further than any other connector here into the code-review and release stages. An agent can read a pull request, run a workflow, and read the code-scanning alerts on the same branch.

44 tools arrive on a default connection and 85 when every toolset is on, and those definitions cost context before the agent asks anything. Write tools are among the defaults, so a read-only setup is a deliberate step.

What is the GitHub MCP server?

It is GitHub's server for the Model Context Protocol. You point the agent at a hosted endpoint or run a small binary, and the agent gains a set of tools: read this pull request, list those workflow runs, search that code.

There are two ways to connect, and they are not equivalent. The hosted server at api.githubcopilot.com/mcp/ needs no install and authenticates with OAuth. The local binary needs a personal access token and runs on your machine, which is the only option for GitHub Enterprise Server.

Tools are grouped into toolsets you switch on by name with GITHUB_TOOLSETS. all enables every one. The agent then picks tools on its own based on what you ask in English.

GitHub covers code review and release broadly, and reaches nothing in production observability, agent observability or cost.

Part of the workWhat GitHub has hereCan an agent reach it
Code, tests & reviewPull requests, reviews, code scanning, CopilotYes. Core strength. Reading a diff, leaving review comments, and reading code-scanning and secret-scanning alerts are all first-class tools
CI & releaseActions workflows, runs, jobs and logsYes, through the actions toolset. An agent can list workflow runs, read job logs and re-run a failed job
Production observabilityNoneNo infrastructure telemetry. GitHub knows what shipped, not how it behaves
Agent observability & evalsNoneNo traces, evaluations or prompt versioning for your own agents
AI cost managementNoneNo token or model spend data. Actions minutes are billing, not AI cost

For an agent, GitHub answers questions about the code and the pipeline that shipped it, and nothing about what happened afterwards. An agent connected here can find the pull request that introduced a regression and re-run the job that caught it. It cannot tell you the regression is happening in production. Pair this connector with an observability connector.

What can an AI agent do with GitHub?

TaskToolsWorksWatch out for
Review an open pull requestpull_request_read pull_request_review_write list_pull_requestsYesLarge diffs are truncated by the 5,000-character content window
Find why CI failedEnable actions actions_list actions_get get_job_logsYesJob logs are truncated to the content window; ask for the failed step, not the whole log
Re-run a failed jobEnable actions actions_run_triggerYesThese are writes, and they are on by default
Read security alerts on a branchlist_code_scanning_alerts list_secret_scanning_alerts list_dependabot_alertsYesNeeds the token to carry security-events scope
Search code across an organizationsearch_code search_repositoriesYesGitHub's code search indexes the default branch only
Open an issue or a pull requestissue_write create_pull_request add_issue_commentYesWrites, on by default. See the read-only setup below
Explain a production incidentNoNo telemetry of any kind. GitHub sees the commit, not the consequence

The toolset column matters more here than on most connectors. actions is not in the default set, so an agent asked about a failed build on a default connection reports nothing and does not explain why. Enable it by name before asking about CI.

85 tools registered across 21 toolsets, 44 on by default, 26 left in read-only mode

Repositories5
get_file_contentssearch_codelist_brancheslist_commitsget_commit
Issues4
issue_readlist_issuessearch_issueslist_issue_types
Issues, write3
issue_writeadd_issue_commentsub_issue_write
Pull requests3
pull_request_readlist_pull_requestssearch_pull_requests
Pull requests, write4
create_pull_requestupdate_pull_requestmerge_pull_requestpull_request_review_write
Actions, opt-in2
actions_listactions_get
Actions, write1
actions_run_trigger
Security4
list_code_scanning_alertsget_code_scanning_alertlist_secret_scanning_alertslist_dependabot_alerts
Search4
search_repositoriessearch_userssearch_orgssearch_commits

Groups follow the toolsets GITHUB_TOOLSETS accepts, split here into read and write rows so the write tools are visible. The values the flag takes are the ones in the setup below: repos,issues,pull_requests,actions. The counts above were taken from the server's own tools/list response on 19 August 2026, run three times: default, GITHUB_TOOLSETS=all, and --read-only.

What connecting costs before the first question

A context window is the amount of text a model can hold at once, and connecting uses some of it before the agent asks anything. Every tool the server registers sends its name, description and input schema to the model when the session starts. The tool list is charged whether or not a single tool is called.

GitHub does not publish this figure, and neither does any other vendor in this guide. Turning every toolset on roughly doubles the context cost. Name the toolsets you need instead of sending all.

Tool setToolsTokens (GPT-5.6, GPT-5.5)Tokens (GPT-4, GPT-3.5)Tokens (Claude Haiku 4.5 to Opus 5)Share of a 200,000-token window
Default toolsets4410,535 to 15,64710,236 to 15,55514,180 to 18,4065.1% to 9.2%
Every toolset enabled8519,558 to 29,14219,053 to 28,98826,206 to 34,3569.5% to 17.2%

Encodings: GPT-5.6, GPT-5.5 o200k_base; GPT-4, GPT-3.5 cl100k_base; Claude Haiku 4.5 to Opus 5 count_tokens. Counted 19 August 2026 from tools/list on the released v1.9.0 Darwin binary. It was run locally with a placeholder token.

Registration is static, so no GitHub account was involved. Figures cover name, description and input schema. The two models in column one share the o200k_base encoding, so they get one count. The spread is formatting, about 49%. Reasoning tokens are output, spent per request. This count is input, charged once at connection.

The Claude figures are measured rather than encoded. Anthropic publishes no local tokenizer. The definitions were sent to the API's count_tokens endpoint, and a no-tools baseline was subtracted. The range covers two tokenizer generations rather than two serializations. Haiku 4.5 and Opus 4.6 sit at the low end. Opus 5 and Sonnet 5 sit at the high end. The gap between them is about a third.

GitHub MCP server limits: where answers come back incomplete

Every limit below is documented by GitHub. None of them announces itself in the response, so the agent answers confidently either way.

The agent says: That is the whole diff. It is the first 5,000 characters.

The server truncates tool output at a content window of 5,000 characters by default, set with --content-window-size. A large pull request or a long job log is cut at that boundary, and the response carries no marker saying so.

Guard: Raise --content-window-size for review work, and have the agent state how many files or lines it actually read.

The agent says: There are no workflow runs. The `actions` toolset was never enabled.

Only the default toolsets are active unless GITHUB_TOOLSETS names more. actions is not among them, so the tools an agent would use to answer a CI question do not exist in that session. An agent with no tool for a job reports that it found nothing. That reads the same as a real empty result.

Guard: Set GITHUB_TOOLSETS explicitly, and have the agent list the toolsets it can see before you trust a negative answer.

The agent says: I opened a pull request. It did, because write tools are on by default.

The default connection includes issue_write, create_pull_request, add_issue_comment and actions_run_trigger, which re-runs workflows. Nothing gates them. Of the 44 default tools, 26 remain when `--read-only` is set, so 18 of them write.

Guard: Run with --read-only for investigation work. Read-only takes priority over --tools, so an explicitly requested write tool is still skipped.

How to configure GitHub MCP for agents

  1. 1

    Decide on write access first

    --read-only is a real server-side flag, and it takes priority over --tools: a write tool named explicitly is still skipped. It leaves 26 of the 44 default tools, so 18 of the defaults write.

  2. 2

    Name your toolsets

    GITHUB_TOOLSETS defaults to a subset that excludes actions, so a default connection cannot answer a CI question. GITHUB_TOOLSETS=all enables everything and roughly doubles the context cost, from about 10,535 tokens to about 19,558.

  3. 3

    Choose hosted or local

    The hosted server at api.githubcopilot.com/mcp/ needs no install and authenticates with OAuth. The local binary needs a personal access token, and is the only option for GitHub Enterprise Server.

  4. 4

    Raise the content window for review work

    Tool output is truncated at 5,000 characters by default, set with --content-window-size. A large diff or a long job log is cut at that boundary with no marker.

Paste this into your agent’s instructions

Two of GitHub's limits arrive silently: the content window truncates without saying so, and a toolset that is off produces an empty answer that reads like a real one. The block below makes the agent state both rather than answering around them.

Terminal
When you answer using GitHub MCP tools, state:
- Which toolsets are enabled. If a question needs a toolset
  that is not enabled, say so rather than reporting nothing
  found.
- Whether any tool output was truncated. The content window
  is 5,000 characters by default and truncation is silent.
- The branch and repository each result came from. Code search
  indexes the default branch only.
Never state that data does not exist. State that it was not
found under the constraints above.
Write your answer in ASD-STE100 Simplified Technical
English. Use short sentences with one idea in each.

Do you need the MCP server at all?

Sometimes. A coding agent already has git and the gh CLI, and for reading a diff or checking out a branch those are faster and cost no context at all.

The MCP server earns its place on the things gh does not make easy: code scanning alerts, Dependabot, discussions, and search across an organization. It also gives the agent tool descriptions, so it can pick the right call without you naming the endpoint.

The split is simple. gh is better inside one repository you have already cloned. The server is better for questions that span repositories, or reach features with no convenient CLI shape.

If the agent already has the repository checked out, reach for gh first. Connect the server when the question spans repositories or touches security and Actions data.

GitHub MCP server setup

The hosted server needs nothing installed: point the client at https://api.githubcopilot.com/mcp/ and complete the OAuth flow. The local server needs the binary or Docker, plus a personal access token in GITHUB_PERSONAL_ACCESS_TOKEN.

GITHUB_PERSONAL_ACCESS_TOKEN takes precedence over OAuth when both are present. Grant the token only the scopes you are comfortable giving an agent; the security toolset needs security_events.

Claude Code, hosted

The hosted route is one command and no local process. No token appears in the config because the hosted server authenticates with OAuth: the client opens a browser on first connect and GitHub issues the credential.

Terminal
claude mcp add --transport http github https://api.githubcopilot.com/mcp/

Claude Code, local and read-only

Read-only takes priority over --tools, so this is the safer default for investigation work.

Terminal
claude mcp add-json "github" '{"command":"github-mcp-server",
  "args":["stdio","--read-only"],
  "env":{"GITHUB_PERSONAL_ACCESS_TOKEN":"<your-token>",
         "GITHUB_TOOLSETS":"repos,issues,pull_requests,actions"}}'

Cursor

In ~/.cursor/mcp.json for all projects, or .cursor/mcp.json in one. This points at the hosted server, so it carries no token: authentication is the OAuth flow Cursor runs on first connect.

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

Codex CLI

Codex reads TOML, so the JSON blocks above will not transfer.

Terminal
[mcp_servers.github]
command = "github-mcp-server"
args = ["stdio", "--read-only"]
env = { GITHUB_PERSONAL_ACCESS_TOKEN = "<your-token>" }

Every other client

Each block below is the configuration for one client, with the file path and the key that client expects.

Claude Desktop

macOS ~/Library/Application Support/Claude/claude_desktop_config.json. Windows %APPDATA%\Claude\claude_desktop_config.json. There is no CLI. Edit through Settings, Developer, Edit Config.

Quit and restart fully for changes to load. Paths in args must be absolute. Logs at ~/Library/Logs/Claude/mcp.log.

No credentials appear in the file. The hosted endpoint authorizes in a browser with OAuth on first connection.

Terminal
{"mcpServers":{"github":{"type":"http",
  "url":"https://api.githubcopilot.com/mcp/"}}}
Gemini CLI

~/.gemini/settings.json globally, or .gemini/settings.json per project. Key mcpServers. CLI: gemini mcp add.

No credentials appear in the file. The hosted endpoint authorizes in a browser with OAuth on first connection.

Terminal
{"mcpServers":{"github":{"type":"http",
  "url":"https://api.githubcopilot.com/mcp/"}}}
VS Code Copilot

.vscode/mcp.json per workspace, or your user profile. CLI: code --add-mcp.

No credentials appear in the file. The hosted endpoint authorizes in a browser with OAuth on first connection.

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

The key is `servers`, not `mcpServers`. VS Code is the only client that uses that name, and copying a config from anywhere else fails silently.

Windsurf

~/.codeium/windsurf/mcp_config.json, which is the path Windsurf documents. Key mcpServers, the same JSON shape as Cursor, carrying the same OAuth sign-in.

Zed

~/.config/zed/settings.json, carrying the same OAuth sign-in as the blocks above.

The key is `context_servers`. Zed does not call them MCP servers in config, so searching its settings for mcp finds nothing.

Google Antigravity

~/.gemini/config/mcp_config.json globally, or .agents/mcp_config.json per project. Key mcpServers. There is no CLI. Use the /mcp overlay in the editor. Supports stdio, streamable HTTP, SSE and websocket.

No credentials appear in the file. The hosted endpoint authorizes in a browser with OAuth on first connection.

Terminal
{"mcpServers":{"github":{"type":"http",
  "url":"https://api.githubcopilot.com/mcp/"}}}
Amp (Sourcegraph)

~/.config/amp/settings.json or .amp/settings.json, carrying the same OAuth sign-in. The amp mcp CLI covers approve, doctor and oauth.

The key is `amp.mcpServers`, namespaced. A bare mcpServers block is ignored.

Cline

~/.cline/mcp.json per the docs. The source also reads ~/.cline/data/settings/cline_mcp_settings.json. Key mcpServers, standard JSON shape, carrying the same OAuth sign-in. Supports stdio, streamable HTTP and SSE.

Goose (Block)

~/.config/goose/config.yaml, carrying the same OAuth sign-in.

YAML, and servers are called `extensions`. Goose does not use the MCP vocabulary in config at all. Add one interactively with goose configure, or per session with goose session --with-extension.

Kiro (AWS)

.kiro/settings/mcp.json per workspace, or ~/.kiro/settings/mcp.json globally. Key mcpServers, standard JSON shape, carrying the same OAuth sign-in.

Warp

~/.warp/.mcp.json or .warp/.mcp.json. Key mcpServers, standard shape, carrying the same OAuth sign-in. Also addable through the /agent-add-mcp skill.

JetBrains Junie

.junie/mcp/mcp.json per project, or ~/.junie/mcp/mcp.json. Key mcpServers, carrying the same OAuth sign-in. Use /mcp in the CLI to manage.

Roo Code

.roo/mcp.json per project. The global file is mcp_settings.json, opened from the Roo Code MCP settings view with Edit Global MCP. Key mcpServers, carrying the same OAuth sign-in.

Continue

.continue/mcpServers/*.yaml, one file per server, carrying the same OAuth sign-in.

YAML, and `mcpServers` is a list, not an object. Every JSON client keys servers by name. Continue takes an array, so a converted config will not parse.

Trae

.trae/mcp.json per project, or paste into the UI under Raw Config (JSON). Key mcpServers, standard shape, carrying the same OAuth sign-in.

Devin

Devin has no config file to edit. Servers are added through a web form in the settings UI, and Devin's documentation states you do not need to write or paste JSON. The block below is the shape those fields describe, shown for reference. Either route uses the same OAuth sign-in.

Docker

Useful when you would rather not put the binary on your PATH.

Terminal
docker run -i --rm -e GITHUB_PERSONAL_ACCESS_TOKEN \
  ghcr.io/github/github-mcp-server stdio --read-only
GitHub Enterprise Server

Enterprise Server does not support the hosted server. Run the binary and set GITHUB_HOST to your instance.

Terminal
GITHUB_HOST=https://ghe.example.com \
GITHUB_PERSONAL_ACCESS_TOKEN=<your-token> github-mcp-server stdio

Read-only access, permissions and security

  • Read-only is a real flag

    --read-only is enforced by the server, not by the client, and it takes priority over --tools. It leaves 26 of the 44 default tools.

  • Scope the token

    The personal access token's permissions are the agent's permissions. GitHub's own guidance is to grant only the scopes you are comfortable giving an AI tool, and to restrict file permissions on any config holding one.

  • Write tools ship in the defaults

    issue_write, create_pull_request, add_issue_comment and actions_run_trigger are all in the default set. actions_run_trigger re-runs workflows, which can redeploy.

  • The server declares which tools are safe

    Of the 85 tools, 54 carry a readOnlyHint of true and 31 do not. That hint is an annotation the server attaches to each tool, saying whether the tool only reads. A client that respects annotations can gate on the server's own declaration.

Troubleshooting

The agent says there are no workflow runs
The actions toolset is not in the default set. Set GITHUB_TOOLSETS to include it, then ask again.
A diff or log is cut off partway
The content window truncates tool output at 5,000 characters by default. Raise it with --content-window-size, or ask for the specific file or failed step rather than the whole thing.
403 on a security tool
Code scanning, secret scanning and Dependabot need the token to carry security_events. A token without it reaches the rest of the server normally.
A write happened that you did not intend
Write tools are in the default set. Restart with --read-only, which the server enforces even when --tools names a write tool explicitly.
The hosted server will not connect from Enterprise Server
GitHub Enterprise Server does not support remote server hosting. Run the local binary with GITHUB_HOST pointed at your instance.

GitHub MCP server: Reference

ItemValue
Statusv1.11.0 on 25 August 2026 · repository pushed 31 August 2026
Adoption32,631 stars · MIT license
Endpointapi.githubcopilot.com/mcp/ hosted, or a local binary and Docker image
TransportStreamable HTTP for hosted, stdio for local
AuthOAuth on hosted, GITHUB_PERSONAL_ACCESS_TOKEN on local, token taking precedence
Tools85 registered · 44 on by default · 26 in read-only mode
Read-only--read-only, server-enforced, taking priority over --tools
Toolsets21, selected with GITHUB_TOOLSETS; all enables every one
Output limit5,000 characters, set with --content-window-size

What engineers report

GitHub's server is the most widely used in this guide, and the discussion reflects that: 32,631 stars and a steady release cadence. The recurring themes are tool count and permission scope rather than whether it works.

What was checkedWhat it shows
Stars32,631
Release measuredv1.9.0, 10 August 2026
LicenseMIT
Tools85 across all toolsets, 44 on by default, 26 in read-only mode

“PATs are long lived credentials that are discouraged, and sometimes entirely restricted in many organizations. This limits the organizations from taking advantage of this MCP server.”

aSapien, GitHub issue, 6 April 2025 · The most-discussed issue on the repository, with 49 comments, on authentication methods.

“Currently, GitHub MCP Server lacks the ability to access private repositories that belong to organizations where a user is a member. This is a significant limitation for professional developers who primarily work with company repositories.”

adamklepacz, GitHub issue, 7 April 2025 · Access scope for organization repositories, with 33 comments.

Counts retrieved from the GitHub API on 1 September 2026. Tool counts come from the server's own tools/list response on the released v1.9.0 binary, not from the README.

Should you connect an agent to GitHub?

Yes. Best for any team already on GitHub, connected with named toolsets and --read-only unless a write is the point of the session.

Strongest fit
Teams that want an agent working across code review and CI in one conversation, especially where code scanning and Dependabot are part of the review.
Main advantage
Breadth and maintenance. It reaches more of the code-and-release stages than any other connector here, and it is actively released.
Main weakness
Size. 44 tools arrive before you ask for anything, and enabling every toolset roughly doubles the context cost.
Operational risk
Write tools ship in the default set, including workflow re-runs. Read-only is a flag you have to set.

From Oodle

One platform for agent traces and infrastructure

Agent traces usually sit in a different product from the rest of your telemetry, so when a slow database makes an agent slow the symptom is in one tool and the cause is in another. Oodle keeps both in one query surface, from $10 per million spans.

See agent observability

Frequently asked questions

How many tools does the GitHub MCP server have?

85 across all toolsets, and 44 on a default connection. Read-only mode leaves 26 of those 44. Counted from the server's own tools/list response on v1.9.0, 19 August 2026.

How do I make it read-only?

Run the binary with --read-only. Write tools are then skipped even if --tools names them explicitly. The hosted server has a server-side equivalent: append /readonly to any toolset URL, so https://api.githubcopilot.com/mcp/readonly for the full set, or https://api.githubcopilot.com/mcp/issues/readonly for one toolset. GitHub documents a header form as well. Prefer either over a client-side permission rule, because the server enforces it.

Do I need to install anything?

No, if you use the hosted server at api.githubcopilot.com/mcp/, which authenticates with OAuth. The local binary is required for GitHub Enterprise Server.

Can an agent see my CI failures?

Yes, after enabling the actions toolset by name. It is not in the default set, so a default connection returns nothing for CI questions and does not explain why.

Does it cover production monitoring?

No. GitHub has no infrastructure telemetry. Pair it with an observability connector such as Grafana or Datadog.

Changelog

  • 20 August 2026. github/github-mcp-server v1.10.1 released. v1.11.0 followed on 25 August 2026.
  • 16 April 2026. v1.0.0 released, the first stable version.
  • 3 April 2025. First release, v0.1.0-rc.1.
  • 4 March 2025. github/github-mcp-server created on GitHub.

Sources

Every number on this page traces to one of these

  1. Repository facts from the GitHub API · github/github-mcp-server, retrieved 1 September 2026
  2. Tool counts from the server's own tools/list response on the released v1.9.0 Darwin binary
  3. Toolsets, read-only mode and the content window from the repository README
  4. Remote server endpoint and client setup from the repository's remote-server documentation

GitHub’s own MCP documentation

Also code review and release:

For what happens after the deploy: