GitLab MCP Server

GitLab MCP サーバー

English | 한국어 | 简体中文 | Português (Brasil)

📖 ドキュメント → · llms.txt · llms-full.txt

デフォルト：40 個のツール（38 個のcore + discover_tools + help）。合計で 278 個のツールがあります（toolset 内に 275 個 + execute_graphql + discover_tools + help）。まずは最小構成で始め、discover_tools を呼び出して、このセッションでさらにツールを有効にしてください。

最初に npm install -g @zereight/mcp-gitlab で zereight-mcp-gitlab バイナリをインストールするか、Homebrew で brew tap zereight/gitlab-mcp https://github.com/zereight/gitlab-mcp および brew install zereight/gitlab-mcp/zereight-mcp-gitlab を実行してください。公式 MCP Registry の登録先：io.github.zereight/gitlab-mcp。ワンライナー：npx -y @zereight/mcp-gitlab@latest。

なし → あり

この MCP なし	この MCP あり
MR の URL と差分をチャットに貼り付ける	list_merge_request_changed_files → バッチ処理で get_merge_request_file_diff を呼び出す
GitLab UI でジョブログを探す	ページネーション対応の get_pipeline_job_output
毎回、プロジェクトパスを説明し直す	project_id=group%2Fproject および merge_request_iid=123

3 つのインストール方法

方法	対象	手順
ローカル IDE	手元の Cursor、Claude Code、Codex	stdio + PAT またはローカル OAuth
共有 HTTP	チームまたはホスト型 MCP	Streamable HTTP URL + リモート認証または MCP OAuth
Claude.ai	Claude のウェブコネクター	パブリック HTTPS + GITLAB_MCP_OAUTH

インストール

最初にバイナリをインストールします（npm install -g @zereight/mcp-gitlab、または Homebrew で brew tap zereight/gitlab-mcp https://github.com/zereight/gitlab-mcp を実行してから brew install zereight/gitlab-mcp/zereight-mcp-gitlab）。トークンをエコーせずに読み込みます：

read -rs GITLAB_PERSONAL_ACCESS_TOKEN && export GITLAB_PERSONAL_ACCESS_TOKEN

# Claude Code
claude mcp add gitlab --transport stdio --scope local --env GITLAB_PERSONAL_ACCESS_TOKEN="$GITLAB_PERSONAL_ACCESS_TOKEN" --env GITLAB_API_URL=https://gitlab.com/api/v4 -- zereight-mcp-gitlab

# Codex
codex mcp add gitlab --env GITLAB_PERSONAL_ACCESS_TOKEN="$GITLAB_PERSONAL_ACCESS_TOKEN" --env GITLAB_API_URL=https://gitlab.com/api/v4 -- zereight-mcp-gitlab

その他のクライアント：VS Code · GitHub Copilot · JSON クライアント · Cursor の詳細

エージェントに貼り付けるプロンプト

MCP 設定を編集できるエージェントに、以下をコピーしてください：

Install the GitLab MCP server (@zereight/mcp-gitlab) for this workspace.
Binary: zereight-mcp-gitlab (npm i -g @zereight/mcp-gitlab, or npx -y @zereight/mcp-gitlab@latest).
Auth: GITLAB_PERSONAL_ACCESS_TOKEN plus GITLAB_API_URL=https://gitlab.com/api/v4 (or GITLAB_USE_OAUTH=true).
Local: claude mcp add gitlab --transport stdio --scope local --env GITLAB_PERSONAL_ACCESS_TOKEN="$GITLAB_PERSONAL_ACCESS_TOKEN" --env GITLAB_API_URL=https://gitlab.com/api/v4 -- zereight-mcp-gitlab
Or: codex mcp add gitlab --env GITLAB_PERSONAL_ACCESS_TOKEN="$GITLAB_PERSONAL_ACCESS_TOKEN" --env GITLAB_API_URL=https://gitlab.com/api/v4 -- zereight-mcp-gitlab
Cursor: use the README deeplink or docs/clients/cursor.md.
Remote HTTP: point the client at https://mcp.example.com/mcp (Streamable HTTP). Claude.ai needs GITLAB_MCP_OAUTH on that host.
Default list: 40 tools (38 core + discover_tools + help). Call discover_tools to expand. Do not enable the api toolset unless you accept its bypass risk.
Equal non-MCP path: npx skills add zereight/gitlab-mcp --skill gitlab-mcp-skill plus the zereight-mcp-gitlab CLI.

リモート HTTP

ホスト型またはセルフホスト型サーバー向けの第一級の選択肢です。Streamable HTTP URL をクライアントに指定してください：

{
  "mcpServers": {
    "gitlab": {
      "type": "http",
      "url": "https://mcp.example.com/mcp"
    }
  }
}

• ホスト型 / Claude.ai：サーバーで GITLAB_MCP_OAUTH=true を設定します（MCP OAuth を参照）
• ユーザーごとの PAT ヘッダー：REMOTE_AUTHORIZATION=true を設定します（リモート認証 を参照）
• ローカル Docker の例は使用方法を参照してください

スキル + CLI（MCP は不要）

スキル + CLI は、フォールバックではなく、もうひとつの選択肢です。同じワークフローを、完全なペイロードでターミナルから実行でき、MCP への登録も不要です。

npx skills add zereight/gitlab-mcp --skill gitlab-mcp-skill
zereight-mcp-gitlab user whoami
zereight-mcp-gitlab mr list

CLI without MCP と skills/gitlab-mcp/ を参照してください。

MCP と人間向け CLI

MCP を使う場合	CLI を使う場合
エージェントがチャット内で構造化されたツールを必要とする場合	完全なペイロード（差分、ログ、アーティファクト）が必要な場合
jmespath またはコンパクトな結果で十分な場合	GITLAB_MCP_COMPACT_RESULTS が有効で、残りをターミナルで確認したい場合
すでにサーバーを登録している場合	PAT を持っているか、auth を実行済みで、MCP を使いたくない場合

人間向け CLI の結果は常にコンパクト化されません。破壊的なツールと GITLAB_TOOL_POLICY_APPROVE ツールには --yes が必要です。

ヒント

project_id は数値 ID または URL エンコードされたパスです。例：グループ group、プロジェクト project、マージリクエスト !123 → project_id=group%2Fproject、merge_request_iid=123。ネストされたグループでは、各セグメントの間に %2F を使用します（group%2Fsubgroup%2Fproject）。

よくある質問

認証するにはどうすればよいですか？ ローカルのデスクトップ環境では、GITLAB_PERSONAL_ACCESS_TOKEN（または GITLAB_PERSONAL_ACCESS_TOKEN_FILE）が最も簡単です。ローカル OAuth には GITLAB_USE_OAUTH=true を使用します。リモートの Claude.ai では GITLAB_MCP_OAUTH を使用します。マルチユーザー HTTP では REMOTE_AUTHORIZATION と、リクエストごとのトークンヘッダーを使用します。

ツールが約 40 個しか表示されないのはなぜですか？ デフォルトの core ツールセットは 38 個のツールに、常時有効な discover_tools と help を加えたものです。引数なしで discover_tools を呼び出してカテゴリを一覧表示し、カテゴリ（pipelines、wiki、…）を渡すと、このセッションで有効になります。GITLAB_TOOLSETS=all を設定しても、api は有効になりません。

ローカル OAuth、MCP OAuth、リモート認証の違いは何ですか？ ローカル OAuth は、サーバーと同じマシン上でブラウザーを開きます。MCP OAuth は、パブリック HTTPS サーバーと Claude.ai などのクライアント向けです。リモート認証では呼び出し元の PAT またはジョブトークンを転送するため、OAuth の認証フローはありません。

大きな応答を縮小するにはどうすればよいですか？ 任意のツール呼び出しで jmespath を渡してください。または GITLAB_MCP_COMPACT_RESULTS=true を設定すると、大きすぎる MCP 応答がプレビューと CLI コマンドに置き換えられます。完全なペイロードが必要な場合は CLI を使用してください。

api ツールセットが危険なのはなぜですか？ gitlab_api_request は、グループ／プロジェクトの許可リスト、その他のツールフィルター、ツールごとの安全チェックを回避します。プロンプトインジェクションによって、このツールが実行されるおそれがあります。GITLAB_TOOLSETS に api を指定する場合に限り、有効にしてください。all、discover_tools、GITLAB_TOOLS では有効になりません。

Cursor ルール／CLAUDE.md のスニペット

GitLab merge requests, issues, and pipelines go through this MCP (@zereight/mcp-gitlab).
Start with the default core tools. Call discover_tools to expand.
Prefer list_merge_request_changed_files, then batched get_merge_request_file_diff.
Use jmespath or compact results; use the CLI for full diffs and job logs.

@zereight/mcp-gitlab

エージェントのワークフローに最適化された GitLab MCP — stdio、SSE、Streamable HTTP を通じて、プロジェクト、マージリクエスト、イシュー、パイプライン、Wiki、リリース、タグ、マイルストーンなどを管理できます。

PAT、OAuth、読み取り専用モード、動的 API URL、VS Code、Claude、Cursor、Copilot などの MCP クライアント向けリモート認証に対応しています。

この GitLab MCP を使う理由

• 標準で40個のツール（38個のcore＋discover_tools＋help）、合計278個 — まずは少ない構成で始め、discover_toolsを呼び出して、CQRS形式のグループ分けなしでツールを追加できます
• MR の2段階レビュー — list_merge_request_changed_files → バッチ処理によるget_merge_request_file_diff
• エージェントスキルを内蔵 — ワークフローのガイダンスはskills/gitlab-mcp/にあります
• 柔軟な認証 — Personal Access Token、ローカルのOAuth2ブラウザーフロー、MCP OAuthプロキシ、リクエストごとのリモート認可に対応しています
• 複数のトランスポート — ローカルクライアント向けのstdio、レガシークライアント向けのSSE、最新のリモートデプロイ向けのStreamable HTTPに対応しています
• クライアントに優しいセットアップ — Claude Code、Codex、Antigravity、OpenCode、Copilot、Cline、Roo Code、Cursor、Kilo Code、Amp Code向けの例を用意しています
• セルフホストに対応 — カスタムGitLabインスタンス、プロキシ設定、動的なAPI URLルーティングで動作します
• JMESPathによる結果のフィルタリング — ツール呼び出しでjmespathを任意指定すると、GitLab APIへのリクエストを変更せずにJSON結果を絞り込めます（tools/listを参照）。レスポンスのマスキングが有効な場合、JMESPathはマスキング済みデータに対して実行されます。

比較

	@zereight/mcp-gitlab	GitLab MCP A（コミュニティ製のCQRS形式）	GitLab公式MCPサーバー
最適な用途	AIエージェントのワークフロー	エンタープライズ向けのマルチインスタンス／グループ化されたツール	GitLabに組み込み済み。個別のインストールは不要
ツールモデル	278個のツール：ツールセット内に275個＋execute_graphql＋discover_tools＋help	約50～60個のグループ化されたbrowse_*／manage_*ツール	HTTPヘッダーで選択するツールセット
MRレビュー	2段階のバッチ処理による差分	異なります	差分を含むget_merge_request
Node.js	>=20.0.0	多くの場合>=24	mcp-remote経由のstdioではNode.js 20以降
ライセンス	MIT	異なります	GitLabの一部

tools/list のサイズ（2026-10-24 に測定）

クライアントはセッション開始時に、tools/list の結果全体をモデルに送信します。トークン数は UTF-8 バイト数 / 4 で推定しています。

プロファイル	ツール数	JSON バイト数	推定トークン数
デフォルト（core + discover_tools + help）	40	50,682	12,671
GITLAB_TOOL_PROFILE=slim	39	49,646	12,412
GITLAB_TOOLSETS=all	276	285,677	71,420

説明またはスキーマを変更した後は、npm run test:mock（test/tools-list-budget.test.ts）で再測定してください。

GitLab は公式 MCP サーバーも提供しています。

• Free、Premium、Ultimate で利用できます。GitLab 19.2 で Premium から Free に移行しました。GitLab 19.5 で一般提供が開始されます。
• GitLab.com では、トップレベルグループの Owner が MCP サーバーへのアクセスを許可します。GitLab Self-Managed と GitLab Dedicated では、管理者がインスタンス設定を管理します。デフォルトのルールは公式ページを参照してください。
• リモートクライアントは、OAuth 2.0 の動的クライアント登録を使用して、HTTP https://<gitlab.example.com>/api/v4/mcp に接続します。
• stdio は mcp-remote を経由し、Node.js 20 以降が必要です。
• ツールセットでは X-Gitlab-Enabled-Mcp-Server-Toolsets ヘッダーを使用します。オプションの X-Gitlab-Mcp-Server-Tool-Name-Prefix ヘッダーを指定すると、ツール名のプレフィックスの先頭 32 文字が保持されます。

公式 GitLab MCP サーバーとの詳しい比較 →

クイックスタート：以下の Personal Access Token または OAuth2 の設定からいずれかを選び、@zereight/mcp-gitlab をインストールして、MCP クライアントの設定で zereight-mcp-gitlab を使用してください。

クライアント設定ガイド

• Claude Code 設定ガイド
• VS Code 設定ガイド
• GitHub Copilot 設定ガイド
• Codex 設定ガイド
• Cursor 設定ガイド
• JSON ベースの MCP クライアント設定ガイド - Factory AI Droid、OpenClaw、OpenCode 系のクライアント向け
• OAuth2 認証設定ガイド
• 環境変数リファレンス
• ステートレスモード — マルチポッド HPA
• カスタムエージェントと複数の PAT の設定

使用方法

設定の概要

認証方法

サーバーは 4 つの認証方法に対応しています。

ローカル／デスクトップでの使用向け（最も一般的）：

1. Personal Access Token（GITLAB_PERSONAL_ACCESS_TOKEN または GITLAB_PERSONAL_ACCESS_TOKEN_FILE）— 最も簡単な設定
2. OAuth2 — ローカルブラウザー（GITLAB_USE_OAUTH）— セキュリティ強化のため推奨

サーバー／リモート環境へのデプロイ向け：

3. OAuth2 — MCP プロキシ（GITLAB_MCP_OAUTH）— Claude.ai などのリモート MCP クライアント向け
4. リモート認可（REMOTE_AUTHORIZATION）— 呼び出し元ごとに独自のトークンを提供するマルチユーザーデプロイ向け

すばやく設定する方法

• Claude Code： Claude Code 設定ガイドを参照してください
• VS Code： VS Code 設定ガイドを参照してください
• GitHub Copilot： GitHub Copilot 設定ガイドを参照してください
• Codex： Codex 設定ガイドを参照してください
• Cursor： Cursor 設定ガイドを参照してください
• Factory AI Droid / OpenClaw / OpenCode スタイルのクライアント： JSON ベース MCP クライアント設定ガイドを参照してください
• OAuth ブラウザーフローの詳細： OAuth2 認証設定ガイドを参照してください
• localhost コールバックを使用しない OAuth（SSO、リモートシェル、バックグラウンドクライアント）： zereight-mcp-gitlab auth を実行してください（GitLab 17.9 以降ではデバイスフローを使用できます。17.2～17.8 では oauth2_device_grant_flow が必要です）。その後、GITLAB_USE_OAUTH=true を指定してサーバーを起動します。スタンドアロンのデバイスフローコマンドを参照してください。

最も簡単なローカル設定には、Personal Access Token を使用してください。ブラウザーベースのローカル認証には OAuth2 を使用します。リモート環境またはマルチユーザー環境へのデプロイについては、この README の後半にある MCP OAuth とリモート認可のセクションに進んでください。

サーバーを一度インストールします。

brew tap zereight/gitlab-mcp https://github.com/zereight/gitlab-mcp
brew install zereight/gitlab-mcp/zereight-mcp-gitlab

または npm を使用します。

npm install -g @zereight/mcp-gitlab

または、次の flake を自分の環境に追加して Nix を使用します。

# flake.nix
inputs.gitlab-mcp.url = "github:zereight/gitlab-mcp";

# wherever you configure your MCP client:
command = lib.getExe inputs.gitlab-mcp.packages.${system}.default;

ストアパスは lock ファイルによって固定されます。nix flake update gitlab-mcp で更新してください。

以下の例では、従来の mcp-gitlab バイナリと名前が衝突しにくいエイリアス zereight-mcp-gitlab を使用しています。MCP クライアントがこれを見つけられない場合は、which zereight-mcp-gitlab で取得した絶対パスを使用してください。

グローバルにインストールしない場合は、npx のバージョンを以前の安定版（このドキュメントで推奨するバージョン）に固定します。たとえば、npx -y @zereight/[email protected] を使用します。常に最新リリースを使用する場合は、代わりに npx -y @zereight/mcp-gitlab@latest を使用してください。次の安定版リリースより前に main にマージされた修正を試すには、プレリリースビルドの npx -y @zereight/mcp-gitlab@next を使用します。これは本番環境向けではありません。新しいバージョンが利用可能な場合、起動時にサーバーが stderr に通知を出力します（GITLAB_DISABLE_VERSION_CHECK=true で無効にできます）。

Claude Desktop のワンクリックインストール（MCP Bundle）

v2.3.1 以降のすべての GitHub リリースには、MCP Bundle の gitlab-mcp.mcpb が含まれています。最新のバンドルをダウンロードして Claude Desktop で開くか、Settings → Extensions にドラッグしてください。Claude Desktop で Personal Access Token（機密値として保存されます）を入力し、GITLAB_API_URL、GITLAB_PERMISSION_MODE、GITLAB_TOOLSETS、GITLAB_MASKING_ENABLED を設定できます。Node.js や npm を別途インストールする必要はありません。

ソースからバンドルをビルドするには、npm run pack:mcpb を実行します（gitlab-mcp.mcpb が書き出されます）。

CLI 引数の使用（環境変数に問題があるクライアント向け）

GitHub Copilot CLI など、一部の MCP クライアントでは環境変数に問題があります。代わりに CLI 引数を使用してください。

{
  "mcpServers": {
    "gitlab": {
      "command": "zereight-mcp-gitlab",
      "args": ["--token=YOUR_GITLAB_TOKEN", "--api-url=https://gitlab.com/api/v4"],
      "tools": ["*"]
    }
  }
}

使用可能な CLI 引数：

• --token - GitLab Personal Access Token（GITLAB_PERSONAL_ACCESS_TOKENを置き換えます）
• --api-url - GitLab API URL（GITLAB_API_URLを置き換えます）
• --read-only=true - 非推奨（次のメジャーバージョン（v3.0.0）で削除されます）。代わりに--permission-mode=readonlyを使用してください（GITLAB_READ_ONLY_MODEを置き換えます）
• --permission-mode - 権限レベル：readonly、modify（削除またはティアダウン用ツールは使用できません）、またはfull（GITLAB_PERMISSION_MODEを置き換えます。デフォルトはfull）
• --toolsets=all - 明示的な指定が必要なapiツールセットを除く、名前付きツールセットを有効にします（GITLAB_TOOLSETSを置き換えます。未設定の場合は軽量なcoreがデフォルトで使用されます）。gitlab_api_requestには--toolsets=apiが必要です
• --tools=list_issues - 個別のツールを追加します（GITLAB_TOOLSを置き換えます）
• --use-wiki=true - 非推奨（次のメジャーバージョン（v3.0.0）で削除されます）。代わりに--toolsets=core,wikiを使用してください（USE_GITLAB_WIKIを置き換えます）
• --use-milestone=true - 非推奨（次のメジャーバージョン（v3.0.0）で削除されます）。代わりに--toolsets=core,milestonesを使用してください（USE_MILESTONEを置き換えます）
• --use-pipeline=true - 非推奨（次のメジャーバージョン（v3.0.0）で削除されます）。代わりに--toolsets=core,pipelinesを使用し、既存の--toolsリストにvalidate_ci_lint,validate_project_ci_lintを追加してください（リストが未設定の場合は--tools=validate_ci_lint,validate_project_ci_lintを設定してください）（USE_PIPELINEを置き換えます）
• --disable-version-check=true - 起動時の新バージョン通知を無効にします（GITLAB_DISABLE_VERSION_CHECKを置き換えます）
• --masking-enabled=true - テキストレスポンスのマスキングを有効にします（GITLAB_MASKING_ENABLEDを置き換えます）
• --masking-config - マスキング設定ファイルのパス（GITLAB_MASKING_CONFIGを置き換えます）
• --masking-policy-file - 保護された管理ポリシーファイルのパス（GITLAB_MASKING_POLICY_FILEを置き換えます）
• --masking-workspace-dir - マスキングファイルの解決に使用するディレクトリ（GITLAB_MASKING_WORKSPACE_DIRを置き換えます）
• --download-dir - download_attachmentおよびdownload_job_artifactsがファイルを保存するディレクトリ（GITLAB_DOWNLOAD_DIRを置き換えます。デフォルトは.gitlab-mcp-downloads）
• --compact-results=true - サイズの大きすぎるMCPツールの応答を切り詰め、完全なペイロードを取得するためのCLIコマンドを付加します（GITLAB_MCP_COMPACT_RESULTSを置き換えます。デフォルトでは無効）
• --compact-result-chars - コンパクト化する文字数のしきい値（GITLAB_MCP_COMPACT_RESULT_CHARSを置き換えます。デフォルトは4000）
• --compact-tools - グローバルなコンパクト化を有効にせず、サイズが大きすぎる場合にコンパクト化するツール名をコンマ区切りで指定します（GITLAB_MCP_COMPACT_TOOLSを置き換えます）
• --list-summary-default=true - list_*ツールとmr_discussionsでは、summary引数が省略された場合にtrueとして扱います。summary: falseを指定すると、引き続き完全なJSONが返されます（GITLAB_MCP_LIST_SUMMARY_DEFAULTを置き換えます。デフォルトでは無効）
• --tool-profile - full（デフォルト）またはslim。slimでは、初期リストからドラフトノート、絵文字リアクション、ラベル、CIカタログツール、create_groupが除外されます。GITLAB_TOOLSETSが設定されている場合は無視されます（GITLAB_TOOL_PROFILEを置き換えます）

すでにGITLAB_TOOLSETSまたは--toolsetsを設定している場合は、置き換えるのではなく、そのリストにwiki、milestones、またはpipelinesを追加してください。すでにGITLAB_TOOLSまたは--toolsを設定している場合は、置き換えるのではなく、そのリストにvalidate_ci_lintとvalidate_project_ci_lintを追加してください。明示的なリストを指定すると、デフォルトのcoreツールセットは置き換えられ、統合されません。

CLI引数は環境変数より優先されます。

zereight-mcp-gitlab authはサブコマンドです（MCP サーバーのフラグではありません）。GitLabのデバイスフローを実行して終了します。CLI引数を参照してください。 同じバイナリは、gh スタイルの GitLab CLI（tool <name> または mr list などの厳選された形式）としても使用できます。MCP の登録は不要です — PAT を設定するか、auth を実行して GITLAB_USE_OAUTH=true を設定してください。詳しくは「MCP なしで CLI を使う」をご覧ください。setup --cursor / setup --claude はクライアント設定を出力し、doctor はトークン、API URL、ツールセット、バージョンを確認します。ペイロード全体をターミナルで使う場合にご利用ください。GITLAB_MCP_COMPACT_RESULTS=true（または --compact-results）を設定しない限り、MCP の応答はチャット内に表示されます。設定すると、大きすぎるツールの応答がプレビューと CLI コマンドに置き換えられます。人間向け CLI はコンパクト化されません。権限モード、ツールセット、拒否ツールの正規表現、ツールポリシーフィルターは共通です。破壊的なツールと GITLAB_TOOL_POLICY_APPROVE の対象ツールには --yes が必要です。「人間向け CLI」をご覧ください。

きめ細かなツールのフィルタリング： GITLAB_PERMISSION_MODE=modify を設定すると、作成／更新を許可しつつ、すべての削除ツールと破壊的なティアダウンツール（cancel_pipeline、 cancel_pipeline_job、stop_environment、stop_stale_environments、unprotect_branch、 unprotect_tag）をブロックできます — execute_graphql および push_files の delete／move アクションを通じた破壊的な変更（削除およびティアダウン動詞を含む）も対象です — または、読み取り専用アクセスには GITLAB_PERMISSION_MODE=readonly を設定します。さらに、 GITLAB_TOOLSETS=<group,…> でツールセットグループを有効にし、GITLAB_TOOLS=<tool,…> で個別のツールを許可リストに追加できます（例：読み取り専用グループに少数の特定の書き込みツールを追加）。また、GITLAB_DENIED_TOOLS_REGEX でパターンに基づいて拒否リストに追加できます。従来の USE_GITLAB_WIKI / USE_MILESTONE / USE_PIPELINE フラグは非推奨です（次のメジャーバージョン（v3.0.0）で削除されます）。 GITLAB_TOOLSETS=core,wiki、core,milestones、または core,pipelines を使用してください （USE_PIPELINE を使う場合は、既存の GITLAB_TOOLS リストを置き換えずに validate_ci_lint,validate_project_ci_lint を追加する必要があります）。 GITLAB_TOOLSETS をすでに設定している場合は、置き換えずに既存のリストへツールセットを追加してください。 GITLAB_TOOLS が未設定の場合は、GITLAB_TOOLS=validate_ci_lint,validate_project_ci_lint を設定してください。すでに設定されている場合は、リストを置き換えずに validate_ci_lint,validate_project_ci_lint を追加してください。 ツールリファレンスと 環境変数をご覧ください。

注意

gitlab_api_request（ツールセット api）は、GITLAB_ALLOWED_GROUPS やその他のグループ制限、プロジェクト許可リスト、ツールレベルの制限（他のツールに対する GITLAB_TOOLS、GITLAB_DENIED_TOOLS_REGEX）、個々のツールの安全性チェックを回避します。トークンの全権限スコープが公開されます。プロンプトインジェクションによって、このツールが操作される可能性があります。これらの制限に依存している運用者は、このツールを有効にしてはいけません。 有効にするには、GITLAB_TOOLSETS に api を指定してください（GITLAB_TOOLSETS=all、discover_tools、GITLAB_TOOLS、従来の USE_* フラグ、GITLAB_TOOL_PROFILE では有効になりません）。GITLAB_ALLOWED_PROJECT_IDS またはセッションのプロジェクトスコープが設定されている場合、許可されたプロジェクトの /projects/:id パスのみが受け付けられます。/search、/users、/groups/:id、/runners などのエンドポイントは拒否されます。別のプロジェクトを指定する本文およびクエリパラメーターはチェックされません。GITLAB_PROJECT_ID と OAuth グループ許可リストは適用されません。

• sse

変数名のみを渡してください。Docker クライアントは、エクスポートされた GITLAB_PERSONAL_ACCESS_TOKEN をコンテナにコピーします。

docker run -i --rm \
  -e HOST=0.0.0.0 \
  -e GITLAB_PERSONAL_ACCESS_TOKEN \
  -e GITLAB_API_URL="https://gitlab.com/api/v4" \
  -e GITLAB_PERMISSION_MODE=readonly \
  -e GITLAB_TOOLSETS=core,wiki,milestones,pipelines \
  -e SSE=true \
  -e SSE_AUTH_TOKEN=your_mcp_sse_token \
  -p 3333:3002 \
  zereight050/gitlab-mcp

{
  "mcpServers": {
    "gitlab": {
      "type": "sse",
      "url": "http://localhost:3333/sse",
      "headers": {
        "Authorization": "Bearer your_mcp_sse_token"
      }
    }
  }
}

• streamable-http

docker run -i --rm \
  -e HOST=0.0.0.0 \
  -e REMOTE_AUTHORIZATION=true \
  -e GITLAB_API_URL="https://gitlab.com/api/v4" \
  -e GITLAB_PERMISSION_MODE=readonly \
  -e GITLAB_TOOLSETS=core,wiki,milestones,pipelines \
  -e STREAMABLE_HTTP=true \
  -p 3333:3002 \
  zereight050/gitlab-mcp

{
  "mcpServers": {
    "gitlab": {
      "type": "streamable-http",
      "url": "http://localhost:3333/mcp",
      "headers": {
        "Authorization": "Bearer glpat-..."
      }
    }
  }
}

MCP OAuth Proxy の使用（GITLAB_MCP_OAUTH）

サーバー／リモート環境へのデプロイ専用です。 このモードを利用するには、MCP サーバーを、一般公開されている HTTPS URL でデプロイする必要があります。ローカル／デスクトップでの利用については、上記の GITLAB_USE_OAUTH をご覧ください。

MCP OAuth 仕様に対応するリモート MCP クライアント（例：Claude.ai）向けです。 サーバーは完全な OAuth 2.0 認可サーバーとして動作します。未認証のリクエストには 401 + WWW-Authenticate 応答が返され、クライアント側で OAuth のブラウザーフローが 自動的に開始されます。 OpenCode、MCPJam、Claude.ai などのリモート MCP クライアントは、認証時に独自のコールバック URL を送信できます。すべてのクライアントのコールバック URL を GitLab に登録できない場合は、GITLAB_OAUTH_CALLBACK_PROXY=true を有効にしてください。コールバックプロキシモードでは、GitLab に登録するリダイレクト URI は {MCP_SERVER_URL}/callback の 1 つだけで済みます。

GITLAB_OAUTH_REDIRECT_URI はローカル OAuth（GITLAB_USE_OAUTH）専用です。リモート MCP OAuth クライアントのコールバック URL を上書きするものではなく、リモートの Unregistered redirect_uri エラーを解決するために使用しないでください。

この変数があるのは、ローカル OAuth フローでは MCP サーバーと同じマシン上でブラウザーを起動し、ローカル HTTP サーバーでコールバックを待ち受けるためです。たとえば、http://127.0.0.1:8888/callback のように設定します。

リモート MCP OAuth はこれとは異なります。GITLAB_MCP_OAUTH=true モードでは、MCP クライアントが /authorize 中に独自のコールバック URL を指定します。GITLAB_OAUTH_REDIRECT_URI は、クライアントが指定した URL を置き換えません。

モード	有効化する設定	コールバック変数	GitLab のリダイレクト URI
ローカル OAuth	GITLAB_USE_OAUTH=true	GITLAB_OAUTH_REDIRECT_URI	http://127.0.0.1:8888/callback またはローカルのコールバック
リモート MCP OAuth	GITLAB_MCP_OAUTH=true	GITLAB_OAUTH_CALLBACK_PROXY=true	{MCP_SERVER_URL}/callback

GITLAB_OAUTH_REDIRECT_URI は、MCP サーバー自体がローカルブラウザーのコールバックを処理する場合にのみ使用してください。リモート MCP クライアントがコールバック URL を処理する場合は、GITLAB_OAUTH_CALLBACK_PROXY=true を使用してください。

仕組み：この MCP サーバーを、パブリックな HTTPS URL を持つ場所にデプロイします。MCP クライアントは {MCP_SERVER_URL}/mcp に接続します。サーバーはクライアントに代わって GitLab と認証情報を交換し、OAuth 2.0 フローを処理します。

前提条件：

1. パブリックにアクセス可能な HTTPS サーバー URL（MCP_SERVER_URL） — ローカルでのテストには ngrok を使用します
2. api（または read_api）スコープを持つ、事前登録済みの GitLab OAuth アプリケーション — Admin area → Applications に移動し、Redirect URI を {MCP_SERVER_URL}/callback に設定します | 環境変数 | 必須 | 説明 | | ----------------------------- | -------- | --------------------------------------------------------------------------------------------------------------------------------------- | | GITLAB_MCP_OAUTH | ✅ | 有効にするには true に設定します | | GITLAB_API_URL | ✅ | GitLab API のベース URL です。URL に認証情報（user:pass@）を埋め込まないでください。無視されます。パスワードにカンマが含まれる場合は %2C と記述してください。 | | GITLAB_OAUTH_APP_ID | ✅ | GitLab OAuth アプリケーション ID | | MCP_SERVER_URL | ✅ | この MCP サーバーの公開 HTTPS URL | | STREAMABLE_HTTP | ✅ | true に設定する必要があります | | GITLAB_OAUTH_CALLBACK_PROXY | 任意 | MCP サーバーの固定 /callback URL を使用するには true に設定します | | GITLAB_OAUTH_ALLOWED_REDIRECT_URIS | 任意 | コールバックプロキシモードでリダイレクトするクライアントのコールバック URL（デフォルト：Claude、ChatGPT、Cursor、ループバックのコールバック。1 つ追加するには defaults,<url> を指定します） | | GITLAB_OAUTH_SCOPES | 任意 | カンマ区切りのスコープ（デフォルト：api,read_api,read_user） | | GITLAB_OAUTH_ALLOWED_GROUPS | 任意 | カンマ区切りのグループ完全パス。メンバー（およびサブグループのメンバー）のみがサーバーを使用できます（非推奨の GITLAB_ALLOWED_GROUPS を置き換えます） | | OAUTH_DISABLE_REFRESH_TOKEN | 任意 | リフレッシュトークンを発行しない場合は true に設定します。GitLab のアクセストークンが期限切れになるたび（2 時間）に、セッション TTL に関係なく、ユーザーはブラウザーで再認証します |

STREAMABLE_HTTP=true の場合、サーバー側の GitLab 認証情報（GITLAB_PERSONAL_ACCESS_TOKEN、GITLAB_JOB_TOKEN、GITLAB_AUTH_COOKIE_PATH、または GITLAB_USE_OAUTH）を使用するには、REMOTE_AUTHORIZATION=true、GITLAB_MCP_OAUTH=true、または STREAMABLE_HTTP_AUTH_TOKEN が必要です。

Unregistered redirect_uri のトラブルシューティング

ブラウザーの URL にある redirect_uri を確認してください。次のようなクライアントのコールバックを指している場合： http://127.0.0.1:xxxxx/.../callback、以下を有効にしてください：

GITLAB_OAUTH_CALLBACK_PROXY=true

GITLAB_OAUTH_REDIRECT_URI を変更してリモート MCP OAuth を修正しないでください。この 変数はローカル OAuth（GITLAB_USE_OAUTH）専用です。

docker run -i --rm \
  -e HOST=0.0.0.0 \
  -e GITLAB_MCP_OAUTH=true \
  -e GITLAB_OAUTH_CALLBACK_PROXY=true \
  -e STREAMABLE_HTTP=true \
  -e MCP_SERVER_URL=https://your-server.example.com \
  -e GITLAB_API_URL="https://gitlab.com/api/v4" \
  -e GITLAB_OAUTH_APP_ID=your_app_id \
  -p 3000:3002 \
  zereight050/gitlab-mcp

MCP クライアントの設定：

{
  "mcpServers": {
    "gitlab": {
      "type": "http",
      "url": "https://your-server.example.com/mcp"
    }
  }
}

リモート認証を使用する（REMOTE_AUTHORIZATION）

サーバー／リモート環境へのデプロイ専用です。 各 HTTP 呼び出し元が、リクエストヘッダーで自身の GitLab トークンを直接指定します。OAuth フローは使用しません。

各呼び出し元が HTTP リクエストヘッダーで自身の GitLab トークンを指定する、マルチユーザーまたはマルチテナント環境で使用します。OAuth フローはなく、MCP サーバーが呼び出し元に代わってトークンを GitLab に転送します。

ヘッダーの優先順位：Private-Token > JOB-TOKEN > Authorization: Bearer

環境変数	必須	説明
REMOTE_AUTHORIZATION	✅	有効にするには true に設定します
STREAMABLE_HTTP	✅	true に設定する必要があります
ENABLE_DYNAMIC_API_URL	任意	X-GitLab-API-URL ヘッダーによるリクエストごとの GitLab URL の指定を許可します
GITLAB_ALLOWED_HOSTS	任意	許可する X-GitLab-API-URL のホストをカンマ区切りで指定します。GITLAB_API_URL のホストは常に許可されます。リリースアセット、ジョブアーティファクト、アップロードされた添付ファイルのダウンロードリダイレクト先としても信頼されます。プライベートネットワークのホストもここに指定してください
GITLAB_ALLOW_UNAUTHENTICATED_TOOL_DISCOVERY	任意	認証なしで許可するのは initialize、notifications/initialized、tools/list、server/discover のみです（ツール呼び出しには引き続き認証が必要です）
MCP_SERVER_URL / MCP_ALLOWED_HOSTS / MCP_ALLOWED_ORIGINS	任意	DNS リバインディング対策のために許可する、公開 /mcp のホスト／オリジン値
MCP_TRUST_PROXY	任意	リバースプロキシの背後で Forwarded / X-Forwarded-* ヘッダーを信頼します（ダウンロード URL、Express の req.ip、/mcp の IP レート制限、OAuth のレート制限）

GITLAB_ALLOW_UNAUTHENTICATED_TOOL_DISCOVERY=true は、ユーザーが GitLab トークンを提供する前にツールのメタデータを確認する必要がある、MCP ゲートウェイや管理 UI 向けです。デプロイ環境でツール一覧を公開しても安全な場合を除き、無効のままにしてください。

MCP_SERVER_URL が設定されていない場合、リモートダウンロード URL はローカルサーバーのアドレスにフォールバックします。MCP_TRUST_PROXY=true に設定するのは、信頼できるリバースプロキシ経由でサーバーにアクセスでき、MCP サーバーへのクライアントからの直接アクセスがブロックされている場合に限ってください。 これにより、Streamable HTTP と SSE で Express の trust proxy が有効になり、Forwarded / X-Forwarded-Proto / X-Forwarded-Host / X-Forwarded-Prefix から公開ダウンロード URL が導出されます。また、プロキシがクライアントのポートを含む X-Forwarded-For（例：1.2.3.4:5678）を送信する場合でも、OAuth エンドポイントのレート制限が機能するようになります。 このフラグの導入後は、既存の OAuth＋プロキシ環境でも明示的に設定する必要があります。

リクエストヘッダーの例：

Private-Token: glpat-xxxxxxxxxxxxxxxxxxxx

または、Bearer トークンを使用する場合：

Authorization: Bearer glpat-xxxxxxxxxxxxxxxxxxxx

⚠️ REMOTE_AUTHORIZATION は SSE トランスポートと互換性がありません。STREAMABLE_HTTP=true が必要です。

環境変数

環境変数の一覧については、専用のリファレンスを参照してください。

• 環境変数リファレンス

ほとんどのユーザーは、以下の開始設定のいずれかだけで十分です。

• ローカル PAT：GITLAB_PERSONAL_ACCESS_TOKEN、GITLAB_API_URL
• ローカル OAuth：GITLAB_USE_OAUTH=true、GITLAB_OAUTH_CLIENT_ID、GITLAB_OAUTH_REDIRECT_URI、GITLAB_API_URL
• リモートのマルチユーザー HTTP：STREAMABLE_HTTP=true、REMOTE_AUTHORIZATION=true（または GITLAB_MCP_OAUTH=true）、MCP_TRUST_PROXY=true（リバースプロキシの背後にある場合）、MAX_REQUESTS_PER_MINUTE=300、MCP_SERVER_URL または MCP_ALLOWED_HOSTS、HOST、PORT
• 複数の並列デプロイ：インスタンスごとに異なる MCP_SERVER_NAME を設定します（例：gitlab-selfhosted-readonly）。これにより、クライアント、ログ、テレメトリで各インスタンスを識別できます
• マルチポッド HPA（ステートレス）：上記に加えて、OAUTH_STATELESS_MODE=true、OAUTH_STATELESS_SECRET（すべてのポッドで同じ値）。ステートレスモードを参照してください。

よく参照される変数：

• GITLAB_API_URL
• GITLAB_PERSONAL_ACCESS_TOKEN
• GITLAB_USE_OAUTH
• REMOTE_AUTHORIZATION
• MCP_TRUST_PROXY
• MAX_REQUESTS_PER_MINUTE
• MAX_SESSIONS
• MCP_ALLOWED_HOSTS
• MCP_ALLOWED_ORIGINS
• GITLAB_MCP_OAUTH
• GITLAB_OAUTH_CALLBACK_PROXY
• GITLAB_OAUTH_ALLOWED_REDIRECT_URIS
• OAUTH_REGISTER_RATE_LIMIT_PER_HOUR
• OAUTH_DISABLE_REFRESH_TOKEN
• OAUTH_STATELESS_MODE
• OAUTH_STATELESS_SECRET

リファレンスドキュメントでは、以下についても説明しています。

• 認証および OAuth の変数
• MCP OAuth プロキシの変数
• プロジェクトとツールのフィルタリング変数
• discover_tools による動的なツール検出（必要に応じたツールセットの有効化）
• トランスポートとセッションの変数
• プロキシと TLS の変数

コールバックプロキシモードの詳細については、GitLab MCP OAuth コールバックプロキシを参照してください。

SSE セッションの制限

GET /sse には、Streamable HTTP と同じリモートトランスポート制御が適用されます。

• **容量：**同時に利用できる SSE セッションは最大 MAX_SESSIONS 個（デフォルトは 1000）です。それを超える接続には 503 が返されます。
• **作成レート制限：**新しい接続は、クライアント IP ごとに MAX_REQUESTS_PER_MINUTE 個までに制限されます（デフォルトは 60）。上限を超えた接続には 429 が返されます。
• アイドルタイムアウト：SESSION_TIMEOUT_SECONDS（デフォルトは 1 時間）の間 POST /messages リクエストを受け取らないセッションは閉じられるため、アイドル状態のクライアントは容量枠を占有し続けるのではなく、再接続する必要があります。Streamable HTTP とは異なり、SSE ストリームを開いたままにしてもアクティビティとしてカウントされません。
• インスタンスが容量上限に達している間、/health は status: "degraded" を含む 503 を返します。

これらの設定は、MAX_SESSIONS、MAX_REQUESTS_PER_MINUTE、SESSION_TIMEOUT_SECONDS で調整してください。

リモート認可の設定（マルチユーザーサポート）

REMOTE_AUTHORIZATION=true を使用すると、MCP サーバーは、各ユーザーが HTTP ヘッダーでそれぞれの GitLab トークンを渡すことで、複数のユーザーをサポートできます。これは、次のような場合に便利です。

• 各ユーザーが自分の GitLab アクセスを必要とする、共有 MCP サーバーインスタンス
• MCP リクエストにユーザーごとのトークンを挿入できる IDE 統合

設定例：

# Start server with remote authorization
docker run -d \
  -e HOST=0.0.0.0 \
  -e STREAMABLE_HTTP=true \
  -e REMOTE_AUTHORIZATION=true \
  -e GITLAB_API_URL="https://gitlab.com/api/v4" \
  -e GITLAB_PERMISSION_MODE=readonly \
  -e SESSION_TIMEOUT_SECONDS=3600 \
  -p 3333:3002 \
  zereight050/gitlab-mcp

クライアント設定：

IDE または MCP クライアントは、各リクエストで以下のいずれかのヘッダーを送信する必要があります。

Authorization: Bearer glpat-xxxxxxxxxxxxxxxxxxxx

または

Private-Token: glpat-xxxxxxxxxxxxxxxxxxxx

トークンはセッションごとに保存され（mcp-session-id ヘッダーで識別）、同じセッション内の後続のリクエストで再利用されます。セッションは、そのトークンの GitLab ユーザーに属します。別のユーザーのトークンを使ったリクエストには 404 Session not found が返され、トークンなしの GET / DELETE /mcp には 401 が返されます。

Cursor を使用したリモート認証クライアントの設定例

{
  "mcpServers": {
    "GitLab": {
      "url": "http(s)://<your_mcp_gitlab_server>/mcp",
      "headers": {
        "Authorization": "Bearer glpat-..."
      }
    }
  }
}

重要な注意事項：

• リモート認証は Streamable HTTP トランスポートでのみ機能します
• 各セッションは分離されています。あるセッションのトークンでは、別のセッションのデータにアクセスできません。 セッションを閉じると、トークンは自動的に削除されます
• セッションタイムアウト： 認証トークンは、SESSION_TIMEOUT_SECONDS（デフォルトは 1 時間）の間操作がないと期限切れになります。タイムアウト後、クライアントは認証ヘッダーを再度送信する必要があります。トランスポートセッションはアクティブなままです。
• リクエストを送信するたびに、そのセッションのタイムアウトタイマーがリセットされます
• レート制限： /mcp リクエストは、クライアント IP ごと、および OAuth またはリモート認証を使用する場合は MCP セッションごとに、MAX_REQUESTS_PER_MINUTE 回（デフォルトは 60）までに制限されます。environment-variables.md を参照してください。
• 容量制限： サーバーが受け入れる同時セッション数は、最大 MAX_SESSIONS（デフォルトは 1000）です

MCP OAuth の設定（Claude.ai ネイティブ OAuth）

GITLAB_MCP_OAUTH=true を設定すると、サーバーは GitLab インスタンスへの OAuth プロキシとして機能します。Claude.ai（および MCP 仕様に準拠したクライアント）がブラウザー認証フロー全体を自動的に処理するため、Personal Access Token を手動で管理する必要はありません。

前提条件：

事前登録済みの GitLab OAuth アプリケーションが必要です。GitLab では、動的に登録された（未検証の）アプリケーションのスコープが mcp に制限されており、API 呼び出しには不十分です（api または read_api が必要です）。

1. GitLab インスタンスに移動し、Admin Area > Applications（インスタンス全体）または User Settings > Applications（個人用）を開きます
2. 次の設定で新しいアプリケーションを作成します：
   • Confidential：チェックを外します
   • Scopes：api、read_api、read_user（または GITLAB_OAUTH_SCOPES を通じてリクエストする予定のスコープ）
3. 保存して Application ID をコピーします。これが GITLAB_OAUTH_APP_ID です

仕組み：

1. ユーザーが Claude.ai に MCP サーバーの URL を追加します
2. Claude.ai が /.well-known/oauth-authorization-server を通じて OAuth エンドポイントを検出します
3. Claude.ai が Dynamic Client Registration（POST /register）を通じて自身を登録します。登録は MCP サーバーがローカルで処理します（クライアントごとに仮想クライアント ID が割り当てられます）
4. Claude.ai が事前登録済みの OAuth アプリケーションを使用して、ユーザーのブラウザーを GitLab のログインページにリダイレクトします
5. ユーザーが認証すると、GitLab は https://claude.ai/api/mcp/auth_callback にリダイレクトします
6. Claude.ai はすべての MCP リクエストで Authorization: Bearer <token> を送信します
7. サーバーは GitLab でトークンを検証し、セッションごとに保存します

サーバーの設定：

docker run -d \
  -e STREAMABLE_HTTP=true \
  -e GITLAB_MCP_OAUTH=true \
  -e GITLAB_OAUTH_APP_ID="your-gitlab-oauth-app-client-id" \
  -e GITLAB_API_URL="https://gitlab.example.com/api/v4" \
  -e MCP_SERVER_URL="https://your-mcp-server.example.com" \
  -p 3002:3002 \
  zereight050/gitlab-mcp

ローカル開発の場合（HTTP が許可されます）：

MCP_DANGEROUSLY_ALLOW_INSECURE_ISSUER_URL=true \
STREAMABLE_HTTP=true \
GITLAB_MCP_OAUTH=true \
GITLAB_OAUTH_APP_ID=your-gitlab-oauth-app-client-id \
MCP_SERVER_URL=http://localhost:3002 \
GITLAB_API_URL=https://gitlab.com/api/v4 \
node build/index.js

Claude.ai の設定：

{
  "mcpServers": {
    "GitLab": {
      "url": "https://your-mcp-server.example.com/mcp"
    }
  }
}

Claude.ai が OAuth を通じてトークンを自動取得するため、headers フィールドは不要です。

環境変数：

変数	必須	説明
GITLAB_MCP_OAUTH	はい	有効にするには true に設定します
GITLAB_OAUTH_APP_ID	はい	事前登録された GitLab OAuth アプリケーションのクライアント ID
MCP_SERVER_URL	はい	MCP サーバーの公開 HTTPS URLです。/mcp の Host／Origin チェックでも許可されます
GITLAB_API_URL	はい	GitLab インスタンスの API URL（例：https://gitlab.com/api/v4）です。URL に認証情報（user:pass@）を含めないでください。含めても無視されます。パスワード内のカンマは %2C と記述してください。
STREAMABLE_HTTP	はい	true にする必要があります（SSE はサポートされていません）
GITLAB_OAUTH_SCOPES	いいえ	要求する GitLab スコープをカンマ区切りで指定します（例：api,read_user）。デフォルトは api です（有効な権限モードが readonly の場合は read_api）。事前登録されたアプリケーションには、これらのスコープを少なくとも設定しておく必要があります。
OAUTH_REGISTER_RATE_LIMIT_PER_HOUR	いいえ	Dynamic Client Registration（POST /register）の IP ごとのローリング制限です。デフォルトは 1 時間あたり 20 回、範囲は 1～1000 です。クライアント（複数の IDE ウィンドウなど）が登録のスロットリングに達する場合は、値を増やしてください。GitLab API の制限ではありません。
OAUTH_DISABLE_REFRESH_TOKEN	いいえ	/token の応答から refresh_token を除外し、リフレッシュグラントを invalid_grant で拒否するには true に設定します。これにより、GitLab アクセストークンの有効期限が切れたとき、ユーザーはブラウザーで再認証します。デフォルトは false です。コールバックプロキシモードでは、このサーバーのフローに従う MCP クライアントが GitLab のリフレッシュトークンを受け取ることはありません（パススルーでは、クライアントは GitLab から直接取得できる場合があります）。これは標準の MCP クライアント向けの再認証ポリシーであり、セキュリティ境界ではありません。有効化する前に発行されたリフレッシュトークンは、GitLab の ユーザー設定 → アプリケーション → 許可されたアプリケーション → 取り消す で取り消すまで有効です。
MCP_DANGEROUSLY_ALLOW_INSECURE_ISSUER_URL	いいえ	ローカル HTTP 開発の場合に限り true に設定します

重要な注意事項：

• MCP OAuth は Streamable HTTP トランスポートでのみ動作します（SSE=true とは互換性がありません）
• 各ユーザーセッションには独自の OAuth トークンが保存されます。セッションは完全に分離されています
• セッションタイムアウト、レート制限、容量制限には、REMOTE_AUTHORIZATION モードと同じ設定が適用されます（SESSION_TIMEOUT_SECONDS、MAX_REQUESTS_PER_MINUTE、MAX_SESSIONS）
• DCR のレート制限： POST /register は、クライアント IP ごとに OAUTH_REGISTER_RATE_LIMIT_PER_HOUR の上限が適用されます（デフォルトは 20 回/時）。/mcp の制限や GitLab API のクォータとは別です。詳しくは environment-variables.md をご覧ください。
• ヘッダー認証へのフォールバック： Private-Token または JOB-TOKEN リクエストヘッダーが存在する場合、OAuth の検証はスキップされ、そのセッションでは生のトークンが直接使用されます。これにより、同じサーバーインスタンスで OAuth フローと併せて PAT および CI ジョブトークンを使用できます。Authorization: Bearer は常に OAuth トークンとして扱われます。PAT によるヘッダー認証には Private-Token を使用してください。

エージェントスキルファイル

スキル + CLI は MCP と同等の選択肢です（スキル + CLI を参照）。スキル／指示の読み込みに対応した AI エージェント（Claude Code、GitHub Copilot、Cursor など）向けに、ビルド済みのスキルファイルを skills/gitlab-mcp/ で利用できます。

• SKILL.md — ツールセットの概要、主要なワークフロー、パラメーターのヒントを含む基本ガイド（約 800 トークン）
• reference/ — コードレビュー、マージリクエスト、イシュー、パイプライン、脆弱性のトリアージに関する詳細なワークフロードキュメント

skills CLI を使ってインストールします。

npx skills add zereight/gitlab-mcp --skill gitlab-mcp-skill

AI クライアントにスキルディレクトリを登録すると、完全な ListTools 応答だけに頼らず、ツールを最適に使用するためのガイダンスを得られます。

ツール 🛠️

クリックして展開

1. `merge_merge_request` - マージリクエストをマージ 2. `approve_merge_request` - マージリクエストを承認 3. `unapprove_merge_request` - マージリクエストの承認を取り消す 4. `get_merge_request_approval_state` - 承認者を含むマージリクエストの承認詳細を取得 5. `get_merge_request_conflicts` - マージリクエストの競合を取得 6. `list_merge_request_pipelines` - ページネーション付きでマージリクエストのパイプラインを一覧表示 7. `execute_graphql` - GitLab GraphQL クエリを実行 8. `create_or_update_file` - GitLab プロジェクト内のファイルを作成または更新 9. `search_repositories` - GitLab プロジェクトを検索 10. `create_repository` - 新しい GitLab プロジェクトを作成 11. `create_group` - 新しいグループまたはサブグループを作成 12. `get_file_contents` - GitLab プロジェクト内のファイルまたはディレクトリの内容を取得 13. `push_files` - 複数のファイルを単一のコミットでプッシュ 14. `create_issue` - 新しいイシューを作成 15. `create_merge_request` - 新しいマージリクエストを作成 16. `fork_repository` - プロジェクトを自分のアカウントまたは指定した名前空間にフォーク 17. `create_branch` - 新しいブランチを作成 18. `get_branch` - ブランチの詳細（コミット、保護状態）を取得 19. `list_branches` - 検索フィルターを使ってプロジェクト内のブランチを一覧表示 20. `delete_branch` - プロジェクトからブランチを削除 21. `list_protected_branches` - 検索フィルターに対応し、プロジェクト内の保護ブランチを一覧表示 22. `get_protected_branch` - 単一の保護ブランチの詳細（アクセスレベル、強制プッシュ設定）を取得 23. `protect_branch` - リポジトリのブランチを保護（プッシュ／マージ／保護解除のアクセスレベルを設定） 24. `update_protected_branch` - 既存の保護ブランチルール（アクセスレベル、強制プッシュ、コードオーナーの承認）をその場で更新 25. `unprotect_branch` - 以前に保護したブランチの保護を解除 26. `update_default_branch` - プロジェクトのデフォルトブランチを変更 27. `get_merge_request` - マージリクエストの詳細を取得（merge_request_iid または source_branch が必要）。デプロイ／コミット／承認の概要を含めるには、include_summaries=true を設定 28. `get_merge_request_diffs` - マージリクエストの変更／差分を取得（merge_request_iid または source_branch が必要） 29. `list_merge_request_changed_files` - 差分内容を含めずに、マージリクエストで変更されたファイルパスを一覧表示（merge_request_iid または source_branch が必要） 30. `list_merge_request_diffs` - ページネーション付きでマージリクエストの差分を一覧表示（merge_request_iid または source_branch が必要） 31. `get_merge_request_file_diff` - マージリクエストから指定したファイルの差分を取得（merge_request_iid または source_branch が必要） 32. `list_merge_request_versions` - マージリクエストの全バージョンを一覧表示 33. `get_merge_request_version` - マージリクエストの特定のバージョンを取得 34. `get_branch_diffs` - 2つのブランチまたはコミット間の差分を取得 35. `update_merge_request` - マージリクエストを更新（merge_request_iid または source_branch が必要） 36. `create_note` - イシューまたはマージリクエストに新しいノート（コメント）を作成 37. `create_merge_request_thread` - マージリクエストに新しいスレッドを作成 38. `resolve_merge_request_thread` - マージリクエストのスレッドを解決済みにする 39. `mr_discussions` - マージリクエストのディスカッション項目を一覧表示 40. `get_merge_request_discussion` - マージリクエストの単一のディスカッション項目を取得 41. `delete_merge_request_discussion_note` - マージリクエストのディスカッションノートを削除 42. `update_merge_request_discussion_note` - マージリクエストのディスカッションノートを更新 43. `create_merge_request_discussion_note` - 既存のマージリクエストスレッドに新しいディスカッションノートを追加 44. `create_merge_request_note` - マージリクエストに新しいノートを追加 45. `delete_merge_request_note` - 既存のマージリクエストノートを削除 46. `get_merge_request_note` - マージリクエストの特定のノートを取得 47. `get_merge_request_notes` - マージリクエストのノートを一覧表示 48. `update_merge_request_note` - 既存のマージリクエストノートを変更 49. `get_draft_note` - マージリクエストの単一の下書きノートを取得 50. `list_draft_notes` - マージリクエストの下書きノートを一覧表示 51. `create_draft_note` - マージリクエストの下書きノートを作成 52. `update_draft_note` - 既存の下書きノートを更新 53. `delete_draft_note` - 下書きノートを削除 54. `publish_draft_note` - 単一の下書きノートを公開 55. `bulk_publish_draft_notes` - マージリクエストのすべての下書きノートを公開します。オプションで reviewer_state を設定し、概要ノートを投稿します（GitLab 19.2+）。下書きがなくても reviewer_state を設定できます。 56. `list_merge_request_emoji_reactions` - マージリクエストのすべての絵文字リアクションを一覧表示 57. `list_merge_request_note_emoji_reactions` - マージリクエストのノートに対するすべての絵文字リアクションを一覧表示。ディスカッションスレッドへの返信では discussion_id を渡します。 58. `create_merge_request_emoji_reaction` - マージリクエストに絵文字リアクションを追加（例：thumbsup、rocket、eyes） 59. `delete_merge_request_emoji_reaction` - マージリクエストから絵文字リアクションを削除 60. `create_merge_request_note_emoji_reaction` - マージリクエストのノートに絵文字リアクションを追加。ディスカッションスレッドへの返信では discussion_id を渡します。 61. `delete_merge_request_note_emoji_reaction` - マージリクエストのノートから絵文字リアクションを削除。ディスカッションスレッドへの返信では discussion_id を渡します。 62. `update_issue_note` - 既存のイシューのスレッドノートを変更 63. `create_issue_note` - イシューにノートを追加。オプションでディスカッションスレッドへの返信が可能 64. `list_issue_emoji_reactions` - イシューのすべての絵文字リアクションを一覧表示 65. `list_issue_note_emoji_reactions` - イシューのノートに対するすべての絵文字リアクションを一覧表示。ディスカッションスレッドへの返信では discussion_id を渡します。 66. `create_issue_emoji_reaction` - イシューに絵文字リアクションを追加（例：thumbsup、rocket、eyes） 67. `delete_issue_emoji_reaction` - イシューから絵文字リアクションを削除 68. `create_issue_note_emoji_reaction` - イシューのノートに絵文字リアクションを追加。ディスカッションスレッドへの返信では discussion_id を渡します。 69. `delete_issue_note_emoji_reaction` - イシューのノートから絵文字リアクションを削除。ディスカッションスレッドへの返信では discussion_id を渡します。 70. `list_issues` - イシューを一覧表示（デフォルト：現在のユーザーが作成したイシュー。すべて表示するには scope='all' を使用） 71. `my_issues` - 認証済みユーザーに割り当てられたイシューを一覧表示 72. `get_issue` - 特定のイシューの詳細を取得。デフォルトでは、簡易版のマイルストーンをネストしたイシューを返します。完全なマイルストーンオブジェクトを取得するには full_response=true を設定 73. `update_issue` - イシューを更新。デフォルトでは簡易版の確認情報を返します。更新後のイシューオブジェクト全体を取得するには full_response=true を設定 74. `update_issue_description_patch` - イシューの説明にパッチ（検索／置換または unified diff）を適用。説明全体を送信せずに小さな変更を行えるため、トークン使用量を削減します。変更をプレビューする dry_run と、更新概要を記録する create_note に対応しています。 75. `delete_issue` - イシューを削除 76. `list_todos` - 現在のユーザーの GitLab To-Do 項目を一覧表示 77. `mark_todo_done` - GitLab To-Do 項目を完了としてマーク 78. `mark_all_todos_done` - 現在のユーザーの保留中の GitLab To-Do 項目をすべて完了としてマーク 79. `list_issue_links` - 特定のイシューのすべてのイシューリンクを一覧表示 80. `list_issue_discussions` - イシューのディスカッションを一覧表示 81. `get_issue_link` - 特定のイシューリンクを取得 82. `create_issue_link` - 2つのイシュー間にイシューリンクを作成 83. `delete_issue_link` - イシューリンクを削除 84. `list_namespaces` - 現在のユーザーが利用できるすべての名前空間（ユーザーとグループ）を一覧表示。グループのみを対象にするには kind='group' で絞り込みます。 85. `get_namespace` - ID またはパスを指定して名前空間（ユーザーまたはグループ）の詳細を取得。kind='group' の名前空間はグループです。 86. `verify_namespace` - 名前空間のパスが存在するか確認。特定の親名前空間に範囲を限定するには parent_id を使用します。同じパスが異なる親の下に存在する可能性があるネストされた名前空間では必須です。 87. `get_project` - 特定のプロジェクトの詳細を取得 88. `list_projects` - 現在のユーザーがアクセスできるプロジェクトを一覧表示 89. `update_project` - 説明、可視性、デフォルトブランチ、機能のアクセスレベルなどのプロジェクト設定を更新 90. `list_project_members` - GitLab プロジェクトのメンバーを一覧表示 91. `list_group_members` - オプションの名前またはユーザー名検索を指定して、GitLab グループのメンバーを一覧表示 92. `list_labels` - プロジェクトのラベルを一覧表示 93. `get_label` - プロジェクトから単一のラベルを取得 94. `create_label` - プロジェクトに新しいラベルを作成 95. `update_label` - プロジェクトの既存のラベルを更新 96. `delete_label` - プロジェクトからラベルを削除 97. `list_group_projects` - グループ内のプロジェクトを一覧表示 98. `list_wiki_pages` - プロジェクトの Wiki ページを一覧表示 99. `get_wiki_page` - 特定の Wiki ページの詳細を取得 100. `create_wiki_page` - プロジェクトに Wiki ページを作成 101. `update_wiki_page` - プロジェクトの Wiki ページを更新 102. `delete_wiki_page` - プロジェクトから Wiki ページを削除 103. `list_group_wiki_pages` - グループの Wiki ページを一覧表示 104. `get_group_wiki_page` - 特定のグループ Wiki ページの詳細を取得 105. `create_group_wiki_page` - グループに Wiki ページを作成 106. `update_group_wiki_page` - グループの Wiki ページを更新 107. `delete_group_wiki_page` - グループから Wiki ページを削除 108. `get_repository_tree` - リポジトリ内のファイルとディレクトリを一覧表示 109. `list_pipelines` - フィルターオプションを使ってパイプラインを一覧表示 110. `get_pipeline` - 特定のパイプラインの詳細を取得 111. `get_pipeline_variables` - パイプラインに設定された変数を取得 112. `get_pipeline_test_report` - パイプラインのテストレポートを取得 113. `get_pipeline_test_report_summary` - パイプラインのテストレポートの概要を取得 114. `delete_pipeline` - パイプラインを削除。プロジェクトの Owner ロールが必要です。取り消しはできず、子パイプラインは自動的に削除されません。 115. `update_pipeline_metadata` - パイプラインのメタデータを更新 116. `list_deployments` - フィルターオプションを使ってデプロイを一覧表示 117. `get_deployment` - GitLab から提供される場合、approval_summary、approvals、pending_approval_count を含むデプロイの詳細を取得 118. `create_deployment` - デプロイを作成 119. `update_deployment` - デプロイのステータスを更新 120. `delete_deployment` - デプロイを削除 121. `list_deployment_merge_requests` - デプロイに含まれるマージリクエストを一覧表示 122. `approve_deployment` - 保護環境へのデプロイを承認または却下 123. `list_environments` - プロジェクトの環境を一覧表示 124. `get_environment` - 特定の環境の詳細を取得 125. `update_environment` - 環境を更新 126. `delete_environment` - 停止した環境を削除 127. `stop_environment` - 環境を停止 128. `stop_stale_environments` - 停止対象となる古い環境を停止。保護環境は対象外で、環境は削除されず停止されます。 129. `delete_review_app_environments` - 停止したレビューアプリ環境の削除を1週間後にスケジュール。dry_run のデフォルトは true で、実際にスケジュールするには dry_run=false が必要です。 130. `list_pipeline_triggers` - プロジェクトのパイプライントリガートークンを一覧表示 131. `get_pipeline_trigger` - プロジェクトのパイプライントリガーを取得 132. `create_pipeline_trigger` - プロジェクトのパイプライントリガーを作成 133. `update_pipeline_trigger` - プロジェクトのパイプライントリガーを更新 134. `delete_pipeline_trigger` - プロジェクトのパイプライントリガーを削除 135. `trigger_pipeline` - パイプライントリガートークンを使ってパイプラインをトリガー 136. `list_pipeline_jobs` - 特定のパイプライン内のすべてのジョブを一覧表示 137. `list_pipeline_trigger_jobs` - パイプライン内のトリガージョブ（ブリッジ）を一覧表示 138. `get_pipeline_job` - GitLab パイプラインのジョブ番号の詳細を取得 139. `get_pipeline_job_output` - 終端からのページネーション、または全ログの部分文字列／正規表現検索を使って、パイプラインジョブのトレースを取得 140. `validate_ci_lint` - 指定された GitLab CI/CD YAML コンテンツをプロジェクト向けに検証 141. `validate_project_ci_lint` - プロジェクトの既存の .gitlab-ci.yml 設定を検証 142. `list_ci_catalog_resources` - ユーザーに表示される GitLab CI/CD Catalog のリソース／コンポーネントを一覧表示 143. `get_ci_catalog_resource` - バージョンとコンポーネントを含む、GitLab CI/CD Catalog リソースの詳細を取得 144. `create_pipeline` - ブランチまたはタグ用の新しいパイプラインを作成 145. `retry_pipeline` - 失敗またはキャンセルされたパイプラインを再試行 146. `cancel_pipeline` - 実行中のパイプラインをキャンセル 147. `list_pipeline_schedules` - プロジェクトのパイプラインスケジュールを一覧表示。オプションで有効または無効に絞り込み可能 148. `get_pipeline_schedule` - 変数と最後のパイプラインを含む、特定のパイプラインスケジュールの詳細を取得 149. `list_pipeline_schedule_pipelines` - パイプラインスケジュールがトリガーしたパイプラインを一覧表示 150. `create_pipeline_schedule` - ブランチまたはタグ用の新しいパイプラインスケジュールを作成 151. `update_pipeline_schedule` - 既存のパイプラインスケジュールを更新 152. `delete_pipeline_schedule` - パイプラインスケジュールを削除 153. `play_pipeline_schedule` - パイプラインスケジュールをすぐに実行 154. `take_ownership_pipeline_schedule` - パイプラインスケジュールの所有権を取得 155. `get_pipeline_schedule_variable` - パイプラインスケジュールの単一の変数を取得 156. `create_pipeline_schedule_variable` - パイプラインスケジュールの変数を作成 157. `update_pipeline_schedule_variable` - パイプラインスケジュールの変数を更新 158. `delete_pipeline_schedule_variable` - パイプラインスケジュールから変数を削除 159. `play_pipeline_job` - 手動パイプラインジョブを実行 160. `play_pipeline_jobs` - 複数の手動パイプラインジョブを順番に実行 161. `retry_pipeline_job` - 失敗またはキャンセルされたパイプラインジョブを再試行 162. `cancel_pipeline_job` - 実行中のパイプラインジョブをキャンセル 163. `erase_pipeline_job` - パイプラインジョブのログとアーティファクトを消去 164. `wait_for_pipeline` - パイプラインが終了ステータスに到達するまで待機 165. `wait_for_job` - ジョブが終了ステータスに到達するまで待機 166. `list_job_artifacts` - ジョブのアーカイブ内のアーティファクトファイルを一覧表示 167. `download_job_artifacts` - ジョブのアーティファクトアーカイブ（zip）をダウンロードし、ダウンロードディレクトリに保存 168. `get_job_artifact_file` - ジョブのアーティファクトから単一ファイルの内容を取得 169. `list_merge_requests` - マージリクエストを一覧表示（project_id なし：ユーザーの MR、project_id あり：プロジェクトの MR） 170. `list_group_merge_requests` - グループとそのサブグループに属するすべてのプロジェクトのマージリクエストを一覧表示 171. `list_milestones` - フィルターオプションを使ってマイルストーンを一覧表示 172. `get_milestone` - 特定のマイルストーンの詳細を取得 173. `create_milestone` - 新しいマイルストーンを作成 174. `edit_milestone` - 既存のマイルストーンを編集 175. `delete_milestone` - マイルストーンを削除 176. `get_milestone_issue` - 特定のマイルストーンに関連付けられたイシューを取得 177. `get_milestone_merge_requests` - 特定のマイルストーンに関連付けられたマージリクエストを取得 178. `promote_milestone` - マイルストーンを次の段階に進める 179. `get_milestone_burndown_events` - 特定のマイルストーンのバーンダウンイベントを取得 180. `list_group_milestones` - フィルターオプションを使ってグループのマイルストーンを一覧表示 181. `get_group_milestone` - 特定のグループマイルストーンの詳細を取得 182. `create_group_milestone` - 新しいグループマイルストーンを作成 183. `edit_group_milestone` - 既存のグループマイルストーンを編集 184. `delete_group_milestone` - グループマイルストーンを削除 185. `get_group_milestone_issue` - 特定のグループマイルストーンに関連付けられたイシューを取得 186. `get_group_milestone_merge_requests` - 特定のグループマイルストーンに関連付けられたマージリクエストを取得 187. `get_group_milestone_burndown_events` - 特定のグループマイルストーンのバーンダウンイベントを取得 188. `get_users` - ユーザー名から GitLab ユーザーの詳細を取得 189. `get_user` - ID からユーザーの詳細を取得 190. `whoami` - 現在の認証済みユーザーの詳細を取得 191. `list_commits` - フィルターオプションを使ってリポジトリのコミットを一覧表示 192. `get_commit` - 特定のコミットの詳細を取得 193. `get_commit_diff` - 特定のコミットの変更／差分を取得 194. `get_file_blame` - 指定した ref におけるファイルの git blame を取得します。各エントリーは、連続するソース行の範囲を、その行を最後に変更したコミット（id、author、authored_date、message）に対応付けます。特定の行に限定するには range_start/range_end を使用します。 195. `list_commit_statuses` - コミットのステータスを一覧表示 196. `create_commit_status` - コミットのステータスを作成または更新 197. `list_group_iterations` - フィルターオプションを使ってグループのイテレーションを一覧表示 198. `upload_markdown` - Markdown コンテンツで使用するファイルをアップロード 199. `download_attachment` - プロジェクトからアップロード済みファイルをダウンロード（画像は base64 で返されます。その他のファイル、または local_path を指定した画像は、ダウンロードディレクトリに新しいファイルとして保存されます） 200. `health_check` - サーバーの状態と認証を確認。MCP サーバーのバージョン（mcp_server_version）は常に報告されます。認証済みの場合は、GET /api/v4/version から GitLab インスタンスのバージョン（version、revision、enterprise）も報告されます。バージョン取得に失敗してもヘルスチェックは失敗せず、該当フィールドは省略されます。 201. `list_events` - 認証済みユーザーのイベントを一覧表示（before/after：YYYY-MM-DD） 202. `get_project_events` - プロジェクトのイベントを一覧表示（before/after：YYYY-MM-DD） 203. `list_releases` - プロジェクトのすべてのリリースを一覧表示 204. `get_release` - タグ名からリリースを取得 205. `create_release` - 新しいリリースを作成 206. `update_release` - 既存のリリースを更新 207. `delete_release` - リリースを削除（タグは削除されません） 208. `create_release_evidence` - リリースのエビデンスを作成（Premium/Ultimate） 209. `download_release_asset` - アセットの直接パスを指定してリリースアセットファイルをダウンロード 210. `list_tags` - プロジェクトのリポジトリタグを一覧表示 211. `get_tag` - 名前からリポジトリタグを取得 212. `create_tag` - 新しいリポジトリタグを作成 213. `delete_tag` - リポジトリタグを削除 214. `get_tag_signature` - 署名付きタグの X.509 署名を取得（未署名の場合は 404） 215. `list_protected_tags` - プロジェクトの保護タグを一覧表示 216. `get_protected_tag` - 単一の保護タグまたはワイルドカードの詳細を取得（作成アクセスレベル） 217. `protect_tag` - リポジトリタグまたはワイルドカードを保護（作成可能なユーザーを設定） 218. `unprotect_tag` - 以前に保護したタグまたはワイルドカードの保護を解除 219. `get_work_item` - ステータス、階層、タイプ、ウィジェットを含む詳細を取得して作業項目を取得 220. `list_work_items` - フィルター（タイプ、状態、検索、担当者、ラベル）を使って作業項目を一覧表示 221. `create_work_item` - すべてのフィールドに対応して作業項目（イシュー、タスク、インシデント、エピックなど）を作成 222. `update_work_item` - 作業項目（タイトル、説明、ラベル、担当者、状態、親、カスタムフィールドなど）を更新 223. `convert_work_item_type` - 作業項目を別のタイプに変換 224. `list_work_item_statuses` - 作業項目タイプで利用可能なステータスを一覧表示（Premium/Ultimate） 225. `list_custom_field_definitions` - 作業項目タイプのカスタムフィールド定義を一覧表示 226. `move_work_item` - 作業項目を別のプロジェクトに移動 227. `list_work_item_notes` - 作業項目のノートとディスカッションを一覧表示 228. `create_work_item_note` - 作業項目にノートを追加（Markdown、内部ノート、スレッドに対応） 229. `list_work_item_emoji_reactions` - 作業項目のすべての絵文字リアクションを一覧表示 230. `list_work_item_note_emoji_reactions` - 作業項目のノート（コメント、スレッド、スレッドへの返信）に対するすべての絵文字リアクションを一覧表示 231. `create_work_item_emoji_reaction` - 作業項目に絵文字リアクションを追加（例：thumbsup、rocket、eyes） 232. `delete_work_item_emoji_reaction` - 作業項目から絵文字リアクションを削除 233. `create_work_item_note_emoji_reaction` - 作業項目のノート（コメント、スレッド、スレッドへの返信）に絵文字リアクションを追加 234. `delete_work_item_note_emoji_reaction` - 作業項目のノート（コメント、スレッド、スレッドへの返信）から絵文字リアクションを削除 235. `get_timeline_events` - インシデントのタイムラインイベントを一覧表示 236. `create_timeline_event` - インシデントにタイムラインイベントを作成 237. `list_webhooks` - プロジェクトまたはグループの Webhook を一覧表示 238. `create_webhook` - プロジェクトまたはグループに Webhook を作成 239. `update_webhook` - 既存のプロジェクトまたはグループの Webhook を更新 240. `delete_webhook` - プロジェクトまたはグループの Webhook を削除 241. `list_webhook_events` - 最近の Webhook イベント（過去7日間）を一覧表示 242. `get_webhook_event` - 特定の Webhook イベントの詳細を取得 243. `search_code` - すべてのプロジェクトのコードを検索（高度な検索または Zoekt が必要） 244. `search_project_code` - 特定のプロジェクト内のコードを検索（高度な検索または Zoekt が必要） 245. `search_group_code` - 特定のグループ内のコードを検索（高度な検索または Zoekt が必要） 246. `list_project_variables` - プロジェクトの CI/CD 変数を一覧表示 247. `get_project_variable` - プロジェクトから単一の CI/CD 変数を取得 248. `create_project_variable` - プロジェクト用の CI/CD 変数を作成 249. `update_project_variable` - プロジェクトの既存の CI/CD 変数を更新 250. `delete_project_variable` - プロジェクトから CI/CD 変数を削除 251. `list_group_variables` - グループの CI/CD 変数を一覧表示 252. `get_group_variable` - グループから単一の CI/CD 変数を取得 253. `create_group_variable` - グループ用の CI/CD 変数を作成 254. `update_group_variable` - グループの既存の CI/CD 変数を更新 255. `delete_group_variable` - グループから CI/CD 変数を削除 256. `get_dependency_proxy_settings` - グループの依存関係プロキシ設定を取得 257. `update_dependency_proxy_settings` - グループの依存関係プロキシ設定を更新（有効化／無効化、認証が必要な Docker Hub プル用の認証情報） 258. `list_dependency_proxy_blobs` - グループのキャッシュ済み依存関係プロキシ Blob を一覧表示 259. `purge_dependency_proxy_cache` - グループのキャッシュ済み依存関係プロキシ Blob をすべて削除する処理をスケジュール 260. `list_project_vulnerabilities` - オプションの状態、重大度、レポートタイプのフィルターを使ってプロジェクトの脆弱性を一覧表示（GraphQL ベース、カーソルページネーション） 261. `get_vulnerability` - 特定の脆弱性の詳細をすべて取得 262. `dismiss_vulnerability` - 理由（acceptable_risk、false_positive、used_in_tests、mitigating_control、not_applicable）とオプションのコメントを指定して脆弱性を却下 263. `confirm_vulnerability` - 修正が必要な実際の検出結果として脆弱性を確認 264. `orbit_query` - インデックス化された SDLC ナレッジグラフに対して GitLab Orbit グラフクエリを実行 265. `orbit_get_schema` - 現在の GitLab Orbit グラフスキーマ（ノードとエッジのタイプ）を取得 266. `orbit_get_status` - 有効なスコープの GitLab Orbit インデックス作成状況を確認 267. `orbit_list_tools` - GitLab Orbit が公開する MCP ツール定義を一覧表示 268. `list_snippets` - スニペットを一覧表示 — project_id が指定されている場合はプロジェクトスニペット、それ以外は個人用スニペット 269. `get_snippet` - スニペットのメタデータを取得。生のファイルコンテンツも取得するには include_content=true を設定します。 270. `create_snippet` - スニペットを作成 — project_id が指定されている場合はプロジェクトスコープ、それ以外は個人用スニペット。title に加え、file_name + content（単一ファイル）または files[]（複数ファイル）のいずれかが必要です。2つの形式は混在できません。 271. `update_snippet` - 既存のスニペットを更新（変更するフィールドを1つ以上指定）。複数ファイルの編集（名前変更、削除、追加）では、action（create/update/delete/move）と previous_path を含む files[] を渡します。単一ファイルのコンテンツ置換には file_name + content の簡易形式も引き続き使用できます。 272. `delete_snippet` - スニペットを削除 273. `list_project_runners` - プロジェクトで利用できる Runner を一覧表示（type、status、paused、tag_list）。登録トークンと認証トークンは省略されます。 274. `get_runner` - Runner の tag_list、run_untagged、locked、access_level を取得。プロジェクトの許可リストが有効な場合、Runner は許可されたプロジェクトで利用可能である必要があります。登録トークンと認証トークンは省略されます。 275. `rebase_merge_request` - マージリクエストのソースブランチをターゲットブランチにリベース 276. `gitlab_api_request` - /api/v4 配下で GitLab REST 呼び出しを1回実行。GITLAB_TOOLSETS に api が含まれる場合のみ有効です。Readonly では GET が許可され、modify では DELETE が拒否されます。 277. `discover_tools` - このセッションで追加のツールカテゴリを検出して有効化。利用可能なカテゴリ：core、merge_requests、issues、repositories、branches、projects、labels、ci、groups、pipelines、milestones、wiki、releases、tags、snippets、users、workitems、webhooks、search、variables、dependency_proxy、vulnerabilities、orbit。有効化済みのカテゴリは応答に表示されます。 278. `help` - GitLab ワークフローの簡潔なガイドを返す。概要とトピック一覧を表示するには topic を省略します。

Wikiページのタイトルとスラッグ

GitLabは、ページタイトルからWikiページのスラッグ（URLの/-/wikis/<slug>）を生成します。そのため、update_wiki_page / update_group_wiki_pageにtitleを渡すと、ページの名前が変更され、URLも変わります。ネストされたページの場合は、別のパスに移動することもあり、既存のリンクが機能しなくなります。

URLを維持したまま表示タイトルだけを変更するには、titleを渡さないでください。代わりに、ページコンテンツのYAMLフロントマターに表示タイトルを保存し、コンテンツを更新します。

---
title: My Custom Display Title
---

Page body…

GitLabはスラッグ／URLを変更せず、フロントマターのタイトルをUIに表示します。render_html: trueを指定してget_wiki_pageで読み込むと、front_matterフィールドに値が設定されます。プレーンなtitleフィールドには、常にスラッグから生成された値が設定されます。

テスト 🧪

このプロジェクトには、リモート認可を含む包括的なテストが用意されています。

# Run all tests (API validation + remote auth)
npm test

# Run only remote authorization tests
npm run test:remote-auth

# Run all tests including readonly MCP tests
npm run test:all

# Run only API validation
npm run test:integration

リモート認可テストでは、すべてモックGitLabサーバーを使用するため、実際のGitLab認証情報は必要ありません。