GitHub MCPとは｜公式MCPサーバーの使い方・86ツール・リモート/ローカル版と権限設計を解説

GitHub MCPは、AIエージェントにGitHubそのものを触らせるための公式の入口です。リポジトリを読ませたい、Issueを起票させたい、失敗したCIのログを読ませて原因を推測させたい——こうした要望に対して、これまでは gh コマンドを叩かせるか、自分でAPIラッパーを書くしかありませんでした。github/github-mcp-server は、その部分をGitHub自身が公式に提供するMCPサーバーとして埋めたものです。

一言でいえば、GitHubの操作を「モデルが選べる形のツール定義」として公開し、権限の境界をトークン側で引けるようにしたサーバーです。Go製・MITライセンス、GitHubスターは31,739（2026-07-27にGitHub APIで実測）。GitHubがホストするリモート版と、自分で起動するローカル版の2形態があり、READMEには21のツールセット・86件のツール定義が列挙されています。本記事では、この2形態の使い分け、実際の接続手順、そして「どこまで権限を渡すのか」という設計の勘所を、公式リポジトリと公式ドキュメントの記述に沿って整理します。

MCPというプロトコル自体の全体像から押さえたい方は、まず MCPサーバーの作り方2026年完全ガイド：TypeScript・Python両対応チュートリアル を参照してください。本記事はその応用にあたる「公式が提供する実装をどう選び、どこまで権限を渡すか」に絞った解説です。

GitHub MCPサーバーとは——AIとGitHub APIの間に何を足しているのか

GitHub MCPサーバーは、公式READMEの冒頭で「AIツールをGitHubのプラットフォームに直接つなぐ」ものと説明されています。AIエージェント・アシスタント・チャットボットに対して、リポジトリとコードファイルの読み取り、Issueとプルリクエストの管理、コードの分析、ワークフローの自動化を、自然言語のやり取りを通じて可能にする、という位置づけです。

ここで誤解しやすいのは、MCPサーバーがGitHub APIの機能を増やしているわけではないという点です。読める情報も、書ける操作も、すべて既存のREST／GraphQL APIの範囲内にあります。MCPが足しているのは次の3つです。

・ツール定義：「このツールは何をするのか」「どんな引数を取るのか」を、モデルが選択できる形式で記述したもの。get_file_contents や create_pull_request といった単位で公開される
・認可の境界：どのトークンでどのツールが見えるか、書き込みを許すか、外部投稿者のコンテンツを見せるか、といった線引きをサーバー側で引ける
・接続の標準化：VS Code・Claude Code・Cursor・Windsurf・Zedなど、MCPに対応したホストなら同じサーバーを同じ手順で使える

つまりGitHub MCPサーバーの本質は、APIの拡張ではなく「AIに渡す用のGitHub」を公式が定義したことにあります。これまで各自が書いていたラッパーの仕様が、GitHub自身の手で標準化されたと捉えるのが正確です。

何ができるのか——READMEが挙げる5つのユースケース

公式READMEは、想定用途を5つに整理しています。実際にどのツールが対応するかを補足しながら並べると、次のようになります。

・リポジトリ管理：コードの閲覧と検索、コミットの分析、プロジェクト構造の把握。get_file_contents search_code list_commits get_repository_tree などが該当する
・IssueとPRの自動化：Issue・プルリクエストの作成、更新、管理。バグのトリアージ、コード変更のレビュー、プロジェクトボードの維持を任せられる
・CI/CDとワークフローの把握：GitHub Actionsの実行を監視し、ビルド失敗を分析し、リリースを管理する。actions_get actions_list get_job_logs actions_run_trigger の4ツールが対応
・コード分析：セキュリティの検出結果の確認、Dependabotアラートの参照。list_code_scanning_alerts list_dependabot_alerts list_secret_scanning_alerts などが該当
・チームのコラボレーション：Discussionsへのアクセス、通知の管理、チーム活動の分析

この中で見落とされがちなのがCI/CDの把握とコード分析です。「CIが落ちたのでログを読んで原因を推測して」という依頼は、get_job_logs があれば人がブラウザでログを開いて貼り付ける手順を丸ごと省けます。同様に、Dependabotやシークレットスキャンのアラート一覧をAIに読ませて優先順位を付けさせる使い方も、既定では有効になっていないツールセットを足すだけで実現できます。

何を解決するのか——「コピペしてAIに読ませる」の終わり

MCPサーバーが無い状態でAIにGitHubの文脈を渡す方法は、突き詰めると3つしかありませんでした。画面をコピー＆ペーストする、リポジトリをローカルにcloneして読ませる、gh コマンドやcurlの出力を貼る——いずれも、人間が「AIに渡すための作業」を毎回やることになります。

GitHub MCPサーバーはこの中間作業を消します。ただし、消える作業と消えない作業ははっきり分かれます。人が打つCLIとしての gh、イベント駆動で回すGitHub Actions、社内システムを繋ぐ自作MCPサーバーは置き換わりません。置き換わるのは、あくまで「AIにGitHubを触らせるために自分で書いていたラッパー」と「文脈を手で運ぶ作業」です。この線引きは記事後半で改めて整理します。

なお、GitHub以外にも公式ベンダーがMCPサーバーを提供する例は増えています。デザイン側の代表例として Figma MCP使い方｜Dev ModeのデザインをClaude/Cursorにコード化させる があり、いずれも「ベンダー自身が自社データのツール定義を管理する」という同じ構図に立っています。ベンダー公式のMCPサーバーは、非公式実装と比べてツール定義の追随が速い一方、提供側の都合で仕様が変わるという性質も併せ持ちます。

GitHub MCPのリモート版とローカル版——分かれ目は認証と統制

GitHub MCPサーバーには、GitHubがホストするリモート版と、自分の環境で動かすローカル版の2つの提供形態があります。公式のポリシー文書は「どちらも同じ基盤コードベースの上に作られている」と明記しており、機能差そのものより運用と認証の差が本質です。

比較表：どちらを選ぶか

まず試すならリモート版

リモート版の利点は、単純にセットアップが要らないことです。VS Code 1.101以降ならワンクリックのインストールボタンが用意されており、それ以外のホストでも https://api.githubcopilot.com/mcp/ を type: http で登録するだけで動きます。

リモート版でしか使えないツールがある点も見逃せません。READMEの「Additional Toolsets in Remote GitHub MCP Server」には、Copilot Coding Agentにタスクを渡す create_pull_request_with_copilot、Copilot Spacesを読む get_copilot_space / list_copilot_spaces、GitHubの製品ドキュメントを検索する github_support_docs_search の4件が挙げられています。Copilotのエコシステムと組み合わせたいならリモート版が前提になります。

なお、このエンドポイントは認証必須です。実際に認証ヘッダー無しでアクセスすると HTTP 401 が返ります（2026-07-27に curl で確認）。ポリシー文書が掲げる「すべての操作で認証が必要、匿名アクセスは無し」という原則が、そのまま実装に出ている形です。

統制を効かせたいならローカル版

ローカル版を選ぶ理由は、大きく3つに整理できます。

1つ目は、GHESとデータレジデンシー環境への対応です。 リモート版はGitHub Enterprise Cloudでのみ利用でき、GitHub Enterprise Serverのリモートホスティングは現時点で提供されていません。GHESや ghe.com サブドメインに向けたい場合、--gh-host フラグ（または GITHUB_HOST 環境変数）を使えるローカル版が唯一の選択肢になります。このときGHESでは https:// スキームを明示する必要があります（省略すると http:// として扱われ、GHESが受け付けません）。

2つ目は、有効なツールを自分で決められることです。 リモート版でもツールセットの指定はできますが、ローカル版なら起動時のフラグと環境変数で、ツールセット単位・ツール単位・読み取り専用・ロックダウンの4段階を自由に組み合わせられます。

3つ目は、トークンの取り扱いです。 v1.5.0（2026-06-27）でstdio版にOAuthログインが組み込まれ、公式ビルドならgithub.comに対してトークンもクライアントIDも渡さずに起動できるようになりました。取得したトークンはメモリ上にのみ保持され、ディスクには書かれません。「PATを設定ファイルに書きたくない」という要求に対する、公式の答えがこれです。

なお、MCPサーバーが増えてきた段階では、GitHub MCPサーバー単体の話では収まらなくなります。複数サーバーの束ね方については MCPJungle徹底解説｜散らばるMCPサーバーを1本に束ねる自己ホスト型MCPゲートウェイ が扱っている論点が、そのまま当てはまります。

GitHub MCPの導入手順——Claude Code・VS Code・Cursorへ繋ぐ

ここからは実際の接続手順です。ホストごとに設定の書き方は違いますが、渡している情報は「エンドポイントURLと認証」か「起動コマンドと環境変数」のどちらかで、構造は共通しています。

Claude Codeにリモート版を追加する

Claude Code 2.1.1以降では add-json 形式を使います。ターミナル（Claude Code CLIの中ではなくシェル）で実行します。

# .env に GITHUB_PAT=... を置いた前提（macOS / Linux）
export GITHUB_PAT="$(grep '^GITHUB_PAT=' .env | cut -d '=' -f2-)"
claude mcp add-json github '{"type":"http","url":"https://api.githubcopilot.com/mcp","headers":{"Authorization":"Bearer '"$GITHUB_PAT"'"}}'

# 登録されたか確認する
claude mcp list

--scope フラグで設定の保存先を選べます。既定の local は現在のプロジェクトで自分だけ、project は .mcp.json を通じてプロジェクトの全員と共有、user は全プロジェクト共通です。チームで共有する project を選ぶ場合、.mcp.json にトークンをそのまま書かないよう注意してください。公式ガイドも .env と .mcp.json の両方を .gitignore に入れる手順を案内しています。

Claude Codeにローカル版（OAuthログイン）を追加する

PATを作らずに済ませるなら、Dockerでローカル版を起動しOAuthログインさせる形になります。コンテナ内のコールバックを受けるため、ループバックに固定ポートを公開するのがポイントです。

# OAuthログイン版。トークンはメモリ上のみに保持され、ディスクには書かれない
claude mcp add github -e GITHUB_OAUTH_CALLBACK_PORT=8085 -- \
  docker run -i --rm -p 127.0.0.1:8085:8085 -e GITHUB_OAUTH_CALLBACK_PORT \
  ghcr.io/github/github-mcp-server

初回利用時にブラウザで認可画面が開きます。公式ドキュメントによれば、認可URLの提示には「ブラウザを自動で開く」「MCPのelicitationでクライアントが提示する（URLがモデルの文脈に入らない）」「最初のツール応答にメッセージとして返す」の3段階があり、上から順に安全な経路が選ばれます。コールバックポートを公開できないコンテナ環境などでは、デバイスコードフローにフォールバックします。

VS Code・Cursorの設定ファイル

VS CodeとCursorは、いずれもJSONの設定ファイルにサーバー定義を書きます。リモート版の記述は次のとおりです（Cursorは ~/.cursor/mcp.json、VS Codeはワークスペースの .vscode/mcp.json などに置きます）。

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

VS Code 1.101以降ではOAuthに対応しているため、headers を省いて type と url だけの記述でも動きます。CursorについてはStreamable HTTPのために v0.48.0以降が必要で、公式ガイドは「Cursorは一部のMCPサーバーでOAuthに対応しているが、GitHubサーバーは現時点でPATが必要」と注記しています。ホストごとにOAuth対応状況が違う点は、設定前に確認しておく価値があります。

検証環境と確認方法

本記事の数値と挙動は、次の方法で確認しています。事実と、確認できていないことを分けて書いておきます。

・確認日：2026-07-27（JST）
・スター数・ライセンス・リリース：GitHub REST APIで実測（スター31,739／フォーク4,652／MIT／最新リリース v1.7.0・2026-07-23公開）
・ツールセット数・ツール数：公式READMEの自動生成セクションを機械的に集計（21ツールセット・86件のツール定義。うち get_label が issues と labels の両方に載るため、ユニークなツール名は85件）
・リモートエンドポイント：curl で https://api.githubcopilot.com/mcp/ にアクセスし、認証ヘッダー無しで 401 が返ることを確認
・コンテナイメージ：ghcr.io/github/github-mcp-server が匿名トークンでタグ一覧を取得できる公開イメージであることを確認（100タグ、latest を含む）
・確認していないこと：筆者の検証環境にはDockerとGoのツールチェーンが無いため、サーバーを実際に起動しての動作確認は行っていません。フラグの挙動やツールの応答内容は、公式READMEおよび docs/ 配下の公式ドキュメントの記述に基づきます

21ツールセット・86ツール——何が呼べるのか

GitHub MCPサーバーの機能は、ツールセットという単位でまとめられています。READMEの自動生成テーブルに載っているのは21セットで、それぞれに1〜19件のツールが属します。

既定で有効なのは5セットだけ

ツールセットを何も指定しないと、default 構成が使われます。中身は context / repos / issues / pull_requests / users の5つで、ツール数は合計42件です。逆にいえば、Actions・コードスキャン・Dependabot・Projects・Discussions・通知などは既定では有効になっていません。「CIのログを読ませたい」「Dependabotアラートを一覧させたい」と思っても既定構成では呼べないので、明示的に足す必要があります。

既定に追加する場合は default を残したまま列挙します。

# 既定の5セットに actions と code_security を足す
GITHUB_TOOLSETS="default,actions,code_security" ./github-mcp-server

# 逆に、必要なものだけを明示的に並べる（default は含まれない）
github-mcp-server --toolsets repos,issues,pull_requests,actions,code_security

# 全部有効にする特殊指定
./github-mcp-server --toolsets all

環境変数 GITHUB_TOOLSETS はコマンドライン引数より優先されます。両方書いた場合に引数が無視される点は、設定を配布するときに事故りやすいので覚えておくとよいでしょう。

ツールセット一覧

21セットのうち、用途が想像しにくいものを中心に整理します。

git と code_quality が1ツールしか持たない一方、repos に19件が集中しているのが分かります。「repos だけ有効にしておけば、読み取り系の大半は賄える」というのが実務上の目安です。

ツール単位での指定と、名前の互換性

セットではなくツール単位で許可することもできます。--tools はツールセットと加算で働きます。

# repos と issues の全ツール ＋ get_gist だけを追加する
github-mcp-server --toolsets repos,issues --tools get_gist

注意点が3つあります。ひとつめは、ツール名が完全一致でなければならないこと（get_file_contents は正しく、getFileContents は不正）。不正な名前を渡すと起動時にエラーで停止します。ふたつめは、read-onlyモードが最優先で適用されるため、--tools で書き込み系を明示しても登録されないこと。みっつめは、ツール名が変更された場合に旧名がエイリアスとして残るため、既存の設定がすぐ壊れるわけではないことです。

有効ツールを絞る目的は、事故防止だけではありません。READMEも「必要なツールセットだけを有効にすることで、LLMのツール選択を助け、コンテキストサイズを削減できる」と明記しています。86件すべてのツール定義をモデルに読ませれば、その説明文だけで相応のトークンを消費します。トークン消費の観点からMCPを絞る発想は、Serena MCPの使い方｜セマンティック解析でClaude Codeのトークンを削る が扱う問題意識と同じ方向を向いています。

認証とスコープ——トークンの種類で「見えるツール」が変わる

ここが、GitHub MCPサーバーで最も理解されていない部分です。同じサーバーでも、渡すトークンの種類によって表示されるツールの数が変わります。

classic PATだけがツールを隠す

公式ドキュメント docs/scope-filtering.md によれば、classic PAT（ghp_ で始まるトークン）を使った場合、サーバーは起動時にGitHub APIへ軽量なHTTP HEADリクエストを送り、X-OAuth-Scopes ヘッダーからトークンのスコープを読み取ります。そしてスコープが足りないツールを自動的に隠します。

たとえばトークンに repo と gist しか付いていなければ、admin:org や project、notifications を要求するツールは一覧に現れません。ツール数が減るぶんモデルのツール選択は安定し、「権限が無いのに呼んで失敗する」という無駄も減ります。

一方、この仕組みが効かないトークンもあります。

fine-grained PATはリポジトリ単位の権限モデルを使っており、X-OAuth-Scopes ヘッダー自体を返しません。そのため絞り込みはスキップされ、全ツールが表示された上で、実行時にAPI側がエラーを返すという挙動になります。「fine-grainedのほうが安全だからツールも少ないはず」という直感は、この実装では成り立ちません。安全性の観点でfine-grainedを選ぶのは妥当ですが、ツール一覧の見え方は安全性の指標にならないと理解しておく必要があります。

例外：公開リポジトリの読み取り系は常に表示される

もうひとつ、実装上の例外があります。repo または public_repo スコープしか必要としない読み取り専用ツールは、トークンにそのスコープが無くても常に表示されます。公開リポジトリなら認証なしでも読めるためです。

たとえば get_file_contents は、トークンのスコープに関わらず常に利用可能です。一方で create_or_update_file のような書き込み系は、repo スコープが無ければ隠されます。GitHub APIが public_repo を X-OAuth-Scopes ヘッダーに返さない（暗黙的な扱いになっている）という仕様に対応するための措置です。

自分のトークンのスコープを確認する

いま自分が渡しているトークンにどのスコープが付いているかは、次のコマンドで確認できます。公式ドキュメントがそのまま案内している方法です。

# 自分のトークンに付いているスコープを確認する
curl -sI -H "Authorization: Bearer $GITHUB_PERSONAL_ACCESS_TOKEN" \
  https://api.github.com/user | grep -i x-oauth-scopes

# 出力例（classic PATの場合）
# x-oauth-scopes: delete_repo, gist, read:org, repo

fine-grained PATやGitHub Appのトークンでは、このヘッダー自体が返らないことも併せて確認できます。ヘッダーが空、あるいは出力が無ければ、絞り込みは働いていないと判断してよいでしょう。

スコープには暗黙の包含関係もあります。repo は public_repo と security_events を含み、admin:org は write:org を、write:org は read:org を含みます。project は read:project を含みます。つまり repo を付けた時点で、セキュリティイベント系のツールも使えるようになります。「読み取りだけのつもりで repo を付けたら、書き込みもセキュリティアラートも通っていた」という誤解は、この包含関係を知らないことから生まれます。

もうひとつ、運用で気をつけたい挙動があります。ネットワーク不調やレート制限でスコープの取得に失敗した場合、サーバーは警告ログを出すだけで、絞り込みを行わないまま起動を継続します。「絞り込みが効いているはずだから安全」という前提でトークンのスコープを緩めておくと、この縮退時に想定より広いツールが露出します。絞り込みは利便性の機能であって、権限設計の代替ではないと考えるのが安全です。

最小スコープの目安

READMEはトークン運用のベストプラクティスとして、必要最小限のスコープだけを付けることを推奨し、具体例として次を挙げています。

・repo — リポジトリ操作
・read:packages — Dockerイメージへのアクセス
・read:org — Organizationのチーム情報へのアクセス

加えて、プロジェクトや環境ごとにトークンを分ける、定期的にローテーションする、バージョン管理に入れない、トークンを含む設定ファイルは chmod 600 で権限を絞る、といった運用が推奨されています。環境変数のサポート状況はホストによって異なり、Windsurfのように設定ファイルへの直書きを要求するものもある、という注意書きも添えられています。

出せる範囲を絞る4つのスイッチ

権限設計の実務は、「トークンのスコープ」と「サーバー側のフラグ」の二段構えです。後者には4つのスイッチがあり、それぞれ効く層が違います。

read-onlyモード——書き込みを一括で落とす

--read-only フラグ（Dockerなら GITHUB_READ_ONLY=1）を付けると、読み取り専用のツールだけが提供され、リポジトリ・Issue・プルリクエストへの変更が一切できなくなります。

docker run -i --rm \
  -e GITHUB_PERSONAL_ACCESS_TOKEN=<your-token> \
  -e GITHUB_TOOLSETS="repos,issues,pull_requests,actions,code_security" \
  -e GITHUB_READ_ONLY=1 \
  ghcr.io/github/github-mcp-server

前述のとおり、read-onlyは --tools による明示指定よりも優先されます。「読み取り専用にしたつもりが、ツール単位の指定で書き込みが復活していた」という事故は構造的に起きません。AIにコードベースを調査させるだけの用途なら、まずこれを付けるのが出発点です。

lockdownモード——公開リポジトリの「外から来た文章」を絞る

--lockdown-mode（環境変数 GITHUB_LOCKDOWN_MODE=1）は、他の3つとは性質が異なります。ツールの数を減らすのではなく、公開リポジトリから引き出せるコンテンツの範囲を制限します。

有効にすると、サーバーは各アイテムの投稿者がそのリポジトリへのpush権限を持つかどうかを確認します。プライベートリポジトリは影響を受けず、コラボレーターは自分のコンテンツに完全にアクセスできます。呼び出したツールによって挙動が2種類に分かれます。

投稿者にpush権限が無い場合にエラーを返すツール

・issue_read:get
・pull_request_read:get

push権限が無い投稿者のコンテンツをフィルタして除外するツール

・issue_read:get_comments
・issue_read:get_sub_issues
・pull_request_read:get_comments
・pull_request_read:get_review_comments
・pull_request_read:get_reviews

対象がIssue本文とコメント、PRの本文とレビューコメントに集中している点に注目してください。これらはいずれも、リポジトリ外の第三者が自由に文字列を書き込める場所です。そこに書かれた文章をAIエージェントがそのまま読み、指示として解釈してしまうリスクは、OSSリポジトリを扱う場面で現実的な懸念になります。lockdownモードは、その入力面を「push権限を持つ人が書いたものだけ」に狭める仕組みだと理解すると腑に落ちます。

v1.7.0のリリースノートにも「Lockdown mode improvements」が挙げられており、Centralise lockdown author checks（PR #2881）で権限確認のロジックが集約されています。実装が継続的に手当てされている領域です。

4つのスイッチの使い分け

--toolsets all は手軽ですが、86件のツール定義をすべてモデルの文脈に載せることになります。「なぜか関係ないツールを呼びに行く」「文脈が重い」と感じたら、まずここを疑うのが定石です。

何を代替し、何を代替しないのか——そして組織で使う前に

最後に、実務でいちばん問われる「で、これは何を置き換えるのか」に答えます。

置き換わらないもの

gh CLIは置き換わりません。 人が意図を持って打つコマンド、シェルスクリプトで確実に回す処理、CI内での実行——これらはMCPの対象外です。MCPはモデルがツールを「選ぶ」ことを前提にしており、決定論的な実行が必要な場面には向きません。

GitHub Actionsも置き換わりません。 MCPサーバーはAIホストからの呼び出しに応答する受け身の存在で、イベント駆動で自動的に走るものではありません。「PRが来たら必ず走る」といった処理はActionsの領分です。

自作MCPサーバーも置き換わりません。 社内のチケットシステム、独自のデプロイ基盤、業務データベースとの接続は、当然ながらGitHub公式サーバーの守備範囲外です。この意味で、GitHub MCPサーバーの存在は自作MCPサーバーの需要を減らすというより、「公式が用意している部分は公式に任せ、自分は差分だけ作る」という切り分けを可能にします。

ブラウザでの最終確認も置き換わりません。 差分を目で見て承認する工程は、権限設計上も残しておくべき部分です。

置き換わるもの

置き換わるのは、AIとGitHubの間を人力で埋めていた作業です。GitHub APIを叩く自作ラッパー、PATを渡してcurlさせる運用、画面をコピー＆ペーストしてAIに読ませる手順、リポジトリを毎回cloneしてから読ませる段取り——このあたりは、公式のツール定義に置き換わります。

組織で使う前に確認すること

個人利用ならここまでで足りますが、組織で導入するなら統制の話が避けられません。公式の docs/policies-and-governance.md は、既存のGitHub側の制御機構がどう効くかを整理しています。要点は次のとおりです。

・「MCP servers in Copilot」ポリシー：Enterprise/Organization → Policies → Copilot にある設定。無効化すると、対象のCopilotエディタからのGitHub MCPサーバー接続がリモート・ローカル・認証方式を問わず完全にブロックされる。現時点の対象はVS CodeとCopilot Coding Agentで、他のCopilotエディタも順次移行予定
・このポリシーが及ばない範囲：パブリックプレビュー段階のCopilotエディタ（Visual Studio・JetBrains・Xcode・Eclipse）、Claude・Cursor・Windsurfなどサードパーティのホスト、GitHubの公開APIを使うコミュニティ製MCPサーバー
・PATポリシー：ローカル版はPAT（またはGitHub Appインストールトークン）で動くため、Organizationのpersonal access tokenポリシーで制御できる
・OAuth Appアクセスポリシー／GitHub Appのインストール：リモート版でOAuthを使う場合、ホストアプリごとに登録されたGitHub App（またはOAuth App）の認可が必要になる。Enterpriseでは組織単位に細かくインストールするか、Enterprise単位で一括管理するかを選べる（Enterprise単位のインストールはGitHub Appのみ対応）
・SSO強制：SSOが有効な組織・Enterpriseでは、OAuth App・GitHub App・PATのいずれでも有効なSSOセッションが必要になる
・監査ログ：MCP経由の操作も、その裏で走るAPI呼び出しとしてGitHubの監査ログに記録される（記録可能な場合）

ここで実務上いちばん重要なのは、Copilotポリシーだけではサードパーティホストを止められないという点です。「Copilot側で無効化したから社内では使われていないはず」という理解は誤りで、Claude CodeやCursorから個人PATで繋がる経路は別途PATポリシーで塞ぐ必要があります。

そして、権限の原則そのものは明快です。公式ドキュメントは「アクセスはGitHubのネイティブな権限モデルで強制される。ユーザーやアプリが、通常のAPI経由でアクセスできる以上のリソースにMCPサーバー経由でアクセスすることはできない」と述べています。MCPは権限を増やす仕組みではありません。 逆にいえば、広いスコープのトークンを渡した時点で、その範囲はそのままAIから触れる範囲になります。統制の主戦場はサーバー側のフラグではなく、渡すトークンそのものにある——これが本記事を通じて最も強調したい点です。

判断材料としてのリポジトリの状態

最後に、採用判断のための素の情報を並べておきます。いずれも2026-07-27時点の実測値です。

リリース間隔は v1.4.0（6/18）→ v1.5.0（6/27）→ v1.6.0（7/15）→ v1.7.0（7/23）と、おおむね1〜3週間ごとです。オープンIssueが340件ある点は規模相応ですが、開発が活発であることの裏返しでもあります。なお、READMEには「このモジュールのエクスポートされたGo APIは現時点で不安定と考えるべきで、破壊的変更があり得る」との注記があります。ライブラリとしてGoコードから使う場合は、この不安定性を前提に置いてください。 MCPサーバーとして使うぶんには関係ありません。

参照ソース

・github/github-mcp-server（公式リポジトリ・README） — ツールセット一覧、ツール定義、read-onlyモード、lockdownモード、トークン運用のベストプラクティス
・docs/scope-filtering.md（PAT Scope Filtering） — classic PAT／fine-grained PAT／GitHub Appでのスコープ絞り込みの挙動
・docs/policies-and-governance.md（Policies & Governance） — リモート版とローカル版の定義、Copilotポリシー、SSO、監査ログ
・docs/oauth-login.md（Local Server OAuth Login） — stdio版のOAuthログイン、PKCE、デバイスコードフォールバック
・docs/installation-guides/install-claude.md — Claude Code CLIへの追加手順
・Release v1.7.0 — server-to-server認証の追加、lockdownモード改善