Gitlab MCP Server
GitLab MCP Server
AIアシスタントをGitLabに接続して、マージリクエストのレビュー、パイプラインのトリアージ、イシューの管理、リリースの作成を、すべて自然言語で行えるようにしましょう。 静的バイナリ1つ(またはコンテナ)で、1000以上のGitLabツールをREST + GraphQL API全体にわたって提供し、Claude、Cursor、VS Code、およびあらゆるMCPクライアントで動作します。
あなたがAIアシスタントに話しかけるだけで、GitLabの作業はAIアシスタントが行います。プロジェクトID、APIエンドポイント、JSONを覚える必要はありません。
「マージリクエスト !15 をレビューして — マージしても安全?」 · 「最後のパイプラインはなぜ失敗した?」 · 「自分に割り当てられたオープンなイシューを一覧して」 · 「v1.0 から v2.0 のリリースノートを作成して」
🤖 AIアシスタントを利用中ですか? このリポジトリURLを渡して、お使いのクライアントにサーバーをインストールするよう依頼してください。モデルがヘッドレスで実行するために必要なものすべて(クライアントごとの宣言的設定、
claude mcp addのワンライナー、デフォルト値)はllms.txtにあります(対話型ウィザードは不要です)。
60秒でインストール
いずれか1つを選んでください。どの方法でも、最後にあなたがアシスタントへプロンプトを入力するところまで進みます。
ワンクリックインストール
各ボタンはDockerベースのサーバーを登録します(初回実行時にイメージを自動プルします。インストールにはDockerが必要です)。Claude Desktopの行は、代わりにネイティブの.mcpbデスクトップ拡張機能をダウンロードします(macOSユニバーサル + Windows、Docker不要)。Claude Desktopで開いて設定を入力してください。トークンが必要ですか? api スコープで個人アクセストークンを作成してください。セルフマネージドGitLabの場合? インストール後、お使いのクライアントのMCP設定にGITLAB_URL環境変数を追加してください。
Claude Code(claude mcp add)
Docker(インストール不要 — 初回実行時にイメージをプルします):
claude mcp add gitlab --env GITLAB_TOKEN=glpat-xxxx --transport stdio \
-- docker run -i --rm -e GITLAB_TOKEN ghcr.io/jmrplens/gitlab-mcp-server:latest --http=falseまたは、ネイティブバイナリを先にインストールしてから登録します:
# macOS/Linux (Homebrew)
brew install jmrplens/tap/gitlab-mcp-server
# Linux/macOS (script)
curl -fsSL https://raw.githubusercontent.com/jmrplens/gitlab-mcp-server/main/scripts/install.sh | sh
# Windows (winget)
winget install --id jmrplens.gitlab-mcp-server -e
# Windows (PowerShell)
irm https://raw.githubusercontent.com/jmrplens/gitlab-mcp-server/main/scripts/install.ps1 | iex
claude mcp add gitlab --env GITLAB_TOKEN=glpat-xxxx -- gitlab-mcp-serverセルフマネージドGitLabの場合? --env GITLAB_URL=https://gitlab.example.com を追加してください(自己署名証明書の場合は --env GITLAB_SKIP_TLS_VERIFY=true も追加)。
ガイド付きセットアップ(どのクライアントでも、フラグを覚える必要なし)
バイナリにはセットアップウィザードが同梱されており、GitLabトークンを収集してMCPクライアントを設定してくれます。JSONを編集したくない場合に最適です:
gitlab-mcp-server --setupVS Code、Claude Desktop、Claude Code、Cursor、Windsurfを自動検出して、正しい設定を書き込みます。Windowsでは、.exe をダブルクリックして起動します。
手動JSON(Claude Desktop、Cursor、VS Codeなど)
ネイティブバイナリ(Claude Desktopの mcpServers、Cursorなど):
{
"mcpServers": {
"gitlab": {
"command": "/path/to/gitlab-mcp-server",
"env": { "GITLAB_TOKEN": "glpat-xxxxxxxxxxxxxxxxxxxx" }
}
}
}VS Code(.vscode/mcp.json、servers + type に注意):
{
"servers": {
"gitlab": {
"type": "stdio",
"command": "/path/to/gitlab-mcp-server",
"env": { "GITLAB_TOKEN": "glpat-xxxxxxxxxxxxxxxxxxxx" }
}
}
}Docker版 — "command"/"args" を次に置き換えます:
"command": "docker",
"args": ["run", "-i", "--rm", "-e", "GITLAB_TOKEN", "ghcr.io/jmrplens/gitlab-mcp-server:latest", "--http=false"]Cline(VS Code)— Clineサイドバー → MCPサーバーアイコン → グローバルMCPを編集 を開くか、設定ファイルを直接編集します:
macOS:
~/Library/Application Support/Code/User/globalStorage/saoudrizwan.claude-dev/settings/cline_mcp_settings.jsonLinux:
~/.config/Code/User/globalStorage/saoudrizwan.claude-dev/settings/cline_mcp_settings.jsonWindows:
%APPDATA%\Code\User\globalStorage\saoudrizwan.claude-dev\settings\cline_mcp_settings.json
Clineは上記のネイティブバイナリ用の mcpServers 形式を使用します。
ユーザーごとのstdioではなく、共有の常時稼働HTTPデプロイメントについては、HTTPサーバーモードを参照してください。
何もインストールせずに試す(ホスト型エンドポイント)
公開インスタンスが https://mcp.jmrp.io/gitlab で稼働しています。インストール不要、必要なのは自分のGitLabトークンだけです。HTTP対応のMCPクライアントからこのURLに向けるだけです:
{
"mcpServers": {
"gitlab": {
"type": "http",
"url": "https://mcp.jmrp.io/gitlab",
"headers": { "PRIVATE-TOKEN": "glpat-xxxxxxxxxxxx" }
}
}
}PRIVATE-TOKEN は必須で、リクエストごとに送信されます。サーバーに保存されることはありません。GITLAB-URL はオプションで、デフォルトは https://gitlab.com です。別のインスタンスに接続するにはこれを設定してください(そのインスタンスはパブリックインターネットから到達可能である必要があります)。
これはサーバーを試す最も速い方法ですが、使い続けるための正しい方法は依然としてローカル(上記のいずれかのオプション)です。これは免責事項ではなく、具体的な理由があります:あなたのトークンとすべてのリクエストは、他人のマシンを経由します。 ローカルで実行すれば、認証情報とGitLabトラフィックが自分のコンピュータから出ることはありません。そのため、プライベートなセルフマネージドインスタンスでは唯一の合理的な選択肢でもあります。
このエンドポイントは、デフォルトの dynamic サーフェス上で動作するステートレスなストリーミングHTTPです。POST がトランスポートで、GET は設計上 405 を返します。また https://mcp.jmrp.io/gitlab/health は 200 と {"status":"ok",…} を返します。セルフホストのHTTPデプロイメントでは、--auth-mode=oauth --gitlab-url=https://gitlab.com --public-url=https://mcp.example.com を指定して実行することもできます(両方とも必須です。OAuthには固定インスタンスと、RFC 9728がリソースを識別するための外部から到達可能なオリジンが必要です)。その場合、クライアントはそのメタデータを介してGitLabを認可サーバーとして検出し、トークンをコピーする代わりにブラウザで認可します — OAuthアプリのセットアップ を参照してください。これは私が保守しているMCPサーバーのディレクトリである mcp.jmrp.io に掲載されているサーバーの1つで、それぞれが独自のエンドポイントでアクセスできます。https://mcp.jmrp.io/servers.json は、自動化クライアント向けの同じリストです。
あとは聞くだけ: AIクライアントを開いて 「自分のGitLabプロジェクトを一覧表示して」 と試してみてください。クライアント別の詳細はスタートガイドを、その他のプロンプト例はこちらを参照してください。
Related MCP server: GitLab MCP Server
なぜこのサーバーなのか
平易な言葉で使えるGitLab。 AI が「MR !15 はマージしても安全ですか?」を適切な API 呼び出しに変換します。エンドポイント、ID、JSON に触れる必要はありません。
プラットフォーム全体 — 1000以上のツール。 GitLab REST v4 + GraphQL を広範にカバー: プロジェクト、ブランチ、タグ、リリース、マージリクエスト、イシュー、パイプライン、ジョブ、グループ、ユーザー、Wiki、環境、デプロイ、パッケージ、コンテナレジストリ、ランナー、フィーチャーフラグ、CI/CD 変数、セキュリティ、管理、トークンなど。
デフォルトで低トークン。 デフォルトのダイナミックサーフェスは、全カタログに到達しつつ、ツールを2つだけ(
find+execute)公開します — そのため、どのクライアントのコンテキストウィンドウにも収まります。(トークンフットプリント →)実モデルで実証済み。 自動評価器が Anthropic、Google、OpenAI、Qwen を実際の GitLab インスタンスに対して実行します。数千のオペレーションにわたり総合成功率 99.5%。(結果 →)
設計による安全性。 読み取り専用モード、セーフモード(すべてのミューテーションをドライランでプレビュー)、セルフホスト型 GitLab 向けの TLS オプション、そして継続的な SonarCloud 品質/セキュリティゲート。
どこでも実行可能。 単一の静的バイナリまたはコンテナ。Windows、Linux & macOS。amd64 & arm64。stdio(デスクトップ)と HTTP(リモート)。
45のMCPリソース(読み取り専用データ: プロジェクト、イシュー、パイプライン、MR、ブランチ、メンバー、サーフェス対応の
gitlab://toolsマニフェスト、ワークフローのベストプラクティスガイド)。26種類の単一オブジェクトもサブスクライブ可能です。37のMCPプロンプト(コードレビュー、パイプラインステータス、リスク評価、リリースノート、スタンドアップ、アナリティクス、監査など)。
4つのエリシテーションウィザード(対話型のイシュー/MR/リリース/プロジェクト作成)。
4つのMCPキャパビリティ(コンプリーション、プログレス、エリシテーション、リソースサブスクリプション — ライブの
resources/updated通知(ポーリングで対応))と、MCPクライアントで視覚的に識別するための51のツールアイコン(50のドメインアイコンとプロジェクトマーク)。ページネーション — すべてのリストエンドポイントで、完全なメタデータ付き。
ツールサーフェス
サーバーは、TOOL_SURFACE によって制御される3つの形態で GitLab を提示できます。デフォルトでは設定は不要です。
サーフェス | 表示されるツール | 最適な用途 |
ダイナミック(デフォルト) | 2( | 最小のトークンコスト。find/execute で全カタログに到達。 |
メタツール( | 32 base / 49 Ultimate / 50 GitLab.com Ultimate |
|
個別( | ~847 Free/CE · ~999 Premium · 1065–1071 Ultimate | GitLab の操作ごとに1つのMCPツール。大きなコンテキストウィンドウが必要。 |
ツール数は GitLab エディション(GITLAB_TIER)に応じて拡大します。上位ティアほど多くのアクションが公開されます。ランキングモデル、安全ガード、完全なカタログについては、ダイナミックツールセットとメタツールリファレンスを参照してください。リソースがコンテキストの大部分を占めるダイナミック実行では、CAPABILITY_SURFACE=minimal を設定してください。
トークンフットプリント
現在のカタログに対して、go run ./cmd/audit_tokens/ -footprint で測定しました。合計値は、MCP クライアントから見える起動時コンテキスト、つまり表示されるツールスキーマと共有リソース・プロンプトを、cl100k_base トークナイザー(GPT-4/GPT-3.5 エンコーディング)を使用して推定したものです。完全なマトリクス(メタサーフェスと個別サーフェス、すべての META_PARAM_SCHEMA モード)については、トークンフットプリントリファレンスを参照してください。
デフォルト設定: TOOL_SURFACE が未設定または TOOL_SURFACE=dynamic、CAPABILITY_SURFACE=full、META_TOOLS 未設定、META_PARAM_SCHEMA=opaque、GITLAB_TIER 未設定(自動検出、フォールバックは free)の場合、サーバーは**ダイナミック find/execute サーフェス
ドキュメント
完全なドキュメントは jmrp.io/docs/gitlab-mcp-server にあります。特定の領域に関する信頼できるリファレンスとして、このマップを使用してください:
ドキュメント | 説明 |
ダウンロード、セットアップウィザード、クライアント別設定 | |
クライアント別のstdio、HTTPレガシー、HTTP OAuthの例 | |
環境変数、トランスポートモード、TLS | |
デフォルト値と例を含む環境変数の完全な表 | |
すべてのコマンドラインフラグ、終了コード、実行例 | |
共有HTTPデプロイ、認証、サーバープールの分離 | |
GitLab OAuthアプリケーション、スコープ、リダイレクトURI、フローを完了できるクライアント | |
GitLab CIおよびGitHub Actionsパイプライン内でのサーバー実行 | |
すべてのツールが従うレスポンス契約: コンテンツブロック、ページネーション、次のステップ | |
エラーの分類、GitLabメッセージの抽出、ツールが返すヒント | |
GitLab.com限定のOrbitを含む、入出力スキーマを持つすべての個別ツール | |
アクションディスパッチを備えた32/49/50ドメインメタツール | |
正規アクションカタログ、安全性モデル、例を備えた2ツール低トークンモード | |
URIテンプレート付きの全45リソース | |
引数と出力形式を持つ全37プロンプト | |
自己更新メカニズム、モード、リリース形式 | |
ユニット、E2E、スキーマモデル評価、Dockerモデル評価、厳選されたモデル結果 | |
セキュリティモデル、トークンのスコープ、入力検証 | |
システムアーキテクチャ、コンポーネント設計、データフロー | |
ビルド、テスト、CI/CD、コントリビューション | |
よくある起動、トークン、TLS、トランスポート、ツール検出の問題 |
FAQ
はい。GITLAB_URL にインスタンスのURLを設定してください。GITLAB_URL を省略した場合、stdioモードは https://gitlab.com を使用します。自己署名TLS証明書は GITLAB_SKIP_TLS_VERIFY=true でサポートされています。
自分で実行する場合 — ローカルでstdio経由、または自社インフラでHTTP経由 — すべてのAPI呼び出しはGitLabインスタンスに直接送信されます。他のどこかに送信される唯一のリクエストは、GitHub Releasesに対する更新チェックです。これはデフォルトで有効になっており、AUTO_UPDATE=false で無効にできます。
例外はホスト型エンドポイントです: https://mcp.jmrp.io/gitlab を使用すると、トークンとすべてのリクエストがそのマシンを経由します。そこには何も保存されませんが、他人のサーバーであるため、ホスト型セクションではローカルで使い続けるよう記載されています。
更新チェックが送信する正確な内容についてはPRIVACY.mdを、セキュリティモデルについてはSECURITY.mdを参照してください。
はい。GITLAB_READ_ONLY=true を設定すると、すべての変更系ツール(作成、更新、削除)が無効になります。読み取り操作のみが利用可能になります。
または、GITLAB_SAFE_MODE=true を設定するとドライランモードになります: 変更系ツールは表示されたままですが、実行せずに構造化されたJSONプレビューを返します。監査、トレーニング、AIアシスタントが行う操作のレビューに役立ちます。
Community Edition (CE) と Enterprise Edition (EE) の両方に対応しています。stdioモードで GITLAB_TIER=premium または GITLAB_TIER=ultimate を設定すると、Premium/Ultimate機能(DORAメトリクス、脆弱性、コンプライアンスなど)向けの追加ツールが有効になります。未設定の場合は、インスタンスのライセンスからティアを検出します(フォールバックは free)。HTTPモードでは、--tier でティアを強制できます。それ以外の場合は、ライセンスからトークン+URLプールのエントリごとに検出されます。
サーバーには、GitLab APIのレート制限に対するバックオフ付きリトライロジックが含まれています。エラーは一時的(再試行可能)または永続的に分類され、エラーメッセージには実行可能なヒントが含まれます。
MCP互換のクライアントであればすべて対応しています: VS Code + GitHub Copilot、Claude Desktop、Cursor、Claude Code、Windsurf、JetBrains IDEs、Zed、Kiro、その他。内蔵のセットアップウィザードは、ほとんどのクライアントを自動設定できます。
ソースからのビルド
git clone https://github.com/jmrplens/gitlab-mcp-server.git
cd gitlab-mcp-server
make build公開されているコンテナイメージは ghcr.io/jmrplens/gitlab-mcp-server:latest です。クロスコンパイル、Docker Compose、コントリビューションガイドラインについては、開発ガイドを参照してください。
コンポーネント | テクノロジー |
言語 | Go 1.27+ |
MCP SDK |
|
GitLabクライアント |
|
トランスポート | stdio(デフォルト)、HTTP(Streamable HTTP) |
プライバシーポリシー
サーバーは完全にあなたのマシン上で動作し、テレメトリ、アナリティクス、独自のバックエンドは一切ありません。データは、設定したMCPクライアントとGitLabインスタンスの間でのみ流れます(さらに、GitHub Releasesに対するオプションの署名付きバイナリ更新チェックがあります)。トークンはGitLabリクエストの認証にのみ使用され、ログに記録されることはありません。詳細: PRIVACY.md。
コントリビューションとセキュリティ
コントリビューション: 開発ガイドライン、ブランチ命名規則、コミット規約、PRプロセスについては CONTRIBUTING.md を参照してください。
セキュリティ: セキュリティポリシーと脆弱性の報告については SECURITY.md を参照してください。
行動規範: CODE_OF_CONDUCT.md (Contributor Covenant v2.1) を参照してください。
リポジトリミラー: GitHubが正規のリポジトリです。見つけやすくするため、読み取り専用ミラーが GitLab.com にあります。コントリビューションはGitHubで行ってください。
ファイル数
カテゴリ | ファイル | 行数 |
ソース( | 992 | 202,107 |
ユニットテスト( | 553 | 314,659 |
エンドツーエンドテスト | 182 | 47,508 |
合計 | 1,727 | 564,274 |
関数
カテゴリ | 件数 |
ソース関数 | 7,693 |
— エクスポート済み(公開) | 2,675 |
— 未エクスポート(非公開) | 5,018 |
ユニットテスト関数( | 11,985 |
サブテスト( | 2,986 |
エンドツーエンドテスト関数 | 439 |
注目すべき比率
観察事項 | 値 |
テスト行数とソース行数 | テストがコードより1.56倍多い |
ソースファイルの平均行数 | ~203行 |
テストファイルの平均行数 | ~569行 |
ソース内のコメント行 | 23,569(ソースの~11.7%) |
ソース関数あたりのテスト関数数 | 1.6倍 |
コードパターン
パターン | 件数 |
| 6,715 |
| 934 |
定義された | 2,743 |
| 263 |
| 2 |
プロジェクト
メトリック | 値 |
Goパッケージ | 237 |
直接依存関係( | 17 |
間接依存関係 | 47 |
殿堂入り
記録 | ファイル |
最長のソースファイル |
|
最長のテストファイル |
|
だって、いいじゃないか
事実 | 値 |
ソースコードを55行/ページで印刷した場合 | A4で約3,674ページ |
| 12,629(避けるのは不可能) |
ソース内で最長の関数名 |
|
最長のテスト関数名 |
|
José M. Requena Plens によってメンテナンスされています · プロジェクトページ · ホスト型インスタンス: mcp.jmrp.io/gitlab
Available Tools
2 toolsgitlab_execute_actionGitLab Execute ActionADestructiveInspect
Execute one GitLab catalog action by canonical ID or alias. Always pass params as an object. Destructive actions require top-level confirm=true. Use find first only when action or params are unclear.
| Name | Required | Description | Default |
|---|---|---|---|
| action | Yes | Canonical action ID returned by gitlab_find_action, or a supported compatibility alias, such as project.list, issue.update, or issue.close. | |
| params | Yes | Required action-specific parameters object validated by the selected action schema. Use an empty object for actions with no parameters. | |
| confirm | No | Set top-level confirm=true to explicitly approve destructive actions. Do not put confirm inside params for gitlab_execute_action. |
Output Schema
| Name | Required | Description |
|---|---|---|
| next_steps | No | Optional. Suggested follow-up actions or tool calls for the LLM, contextual to the result. |
| pagination | No | Present on list actions. Use `has_more` and `next_page` to paginate through results. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=true and readOnlyHint=false, but the description adds an important behavioral requirement: destructive actions require top-level confirm=true. It also signals that the tool is general-purpose by saying 'one GitLab catalog action,' which helps set expectations versus a specialized tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences: the first states the core function, the second gives a required parameter convention, and the third gives the key safety and routing rule. Every sentence contributes new, actionable information with no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a generic action-executor with an open-world catalog, the description provides full operational context: how to identify actions, how to pass parameters, how to handle destructive actions, and when to fall back to the sibling discovery tool. The output schema covers return-value expectations, so nothing critical is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents action, params, and confirm with clear descriptions. The description mostly restates these constraints ('Always pass params as an object', confirm requirement) rather than adding new parameter semantics, but it does reinforce the canonical-vs-alias action concept.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Execute one GitLab catalog action by canonical ID or alias.' It also names the sibling relationship indirectly by saying to use find first when actions are unclear, which distinguishes this execution tool from gitlab_find_action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit usage rules: pass params as an object, set top-level confirm=true for destructive actions, and use find first only when action or params are unclear. This gives an agent clear decision criteria for when to call this tool versus gitlab_find_action.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
gitlab_find_actionGitLab Find ActionARead-onlyIdempotentInspect
Search the local GitLab action catalog. Read-only and no GitLab API call. Use when the action ID or params are unclear. Returns schemas, hints, destructive flags, and execute examples.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of matches to return. Defaults to 20 and is capped at 50. | |
| query | Yes | Search terms combining a GitLab domain or resource with a verb, filter, or object name, such as project create, merge request approve, pipeline retry, issue delete, or ci variable. At most 256 characters: a longer query is refused, not truncated. | |
| explain | No | When true, include deterministic scoring reasons for each returned action. Defaults to false to keep responses compact. |
Output Schema
| Name | Required | Description |
|---|---|---|
| count | Yes | Number of returned matches. |
| query | Yes | Original search query. |
| results | Yes | Matching GitLab catalog actions with schemas and execute examples. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint, but the description adds valuable behavioral detail beyond that: it states 'no GitLab API call' (a specific limitation not in the annotations) and describes what the tool returns ('schemas, hints, destructive flags, and execute examples'). This gives the agent a concrete understanding of the tool's behavior and output without contradicting any annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact—three sentences, each serving a distinct purpose: the first states the core function and read-only nature, the second gives the use case trigger, and the third lists return content. It is front-loaded with the most important information and contains no filler or redundant details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (read-only, no API call, no side effects) and the presence of an output schema that covers return structure, the description fully equips an agent: it knows what the tool does, when to invoke it, and what to expect back. Nothing essential is missing for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and each parameter is already well-documented in the input schema, including examples for query. The description does not add any additional meaning beyond the schema; it just restates the query pattern. Per the rubric, baseline 3 is appropriate when the schema carries the full parameter documentation burden.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action (search) and resource (local GitLab action catalog), and explicitly notes it is read-only and makes no API call. It distinguishes itself from the sibling gitlab_execute_action by implying this tool is for lookup when the action ID or params are unclear, so an agent can easily tell them apart.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives an explicit trigger: 'Use when the action ID or params are unclear.' This clearly indicates when to use the tool, and implicitly that if you have the action ID you would use the execute sibling instead. It stops short of naming the sibling or giving an explicit 'when not to use' rule, but the guidance is clear enough for most cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
2 tool updates
v3.0.0- Changed
gitlab_execute_action1 field changed- changed
Input schema / properties / confirm / descriptionPrevious value: -"Set top-level confirm=true to explicitly approve destructive actions; do not put confirm inside params for gitlab_execute_action."New value: +"Set top-level confirm=true to explicitly approve destructive actions. Do not put confirm inside params for gitlab_execute_action."
- Changed
gitlab_find_action2 fields changed- changed
Input schema / properties / query / descriptionPrevious value: -"Search terms combining a GitLab domain or resource with a verb, filter, or object name, such as project create, merge request approve, pipeline retry, issue delete, or ci variable."New value: +"Search terms combining a GitLab domain or resource with a verb, filter, or object name, such as project create, merge request approve, pipeline retry, issue delete, or ci variable. At most 256 characters: a longer query is refused, not truncated." - added
Input schema / properties / query / maxLengthAdded value: +256
1 tool update
v2.7.5- Changed
gitlab_execute_action1 field changed- changed
Input schema / properties / action / x-mcp-headerPrevious value: -"Mcp-Param-Action"New value: +"Action"
1 tool update
v2.6.0- Added
gitlab_execute_action
1 tool update
v2.5.2- Removed
gitlab_execute_action
3 tool updates
v2.1.3- Added
gitlab_execute_action - Removed
gitlab_execute_tool - Changed
gitlab_find_action4 fields changed- changed
Output schema / properties / results / items / properties / example / descriptionPrevious value: -"Example gitlab_execute_tool call."New value: +"Example gitlab_execute_action call." - changed
Output schema / properties / results / items / properties / example / properties / arguments / descriptionPrevious value: -"Example arguments for gitlab_execute_tool."New value: +"Example arguments for gitlab_execute_action." - changed
Output schema / properties / results / items / properties / id / descriptionPrevious value: -"Canonical action ID to pass to gitlab_execute_tool."New value: +"Canonical action ID to pass to gitlab_execute_action." - changed
Output schema / properties / results / items / properties / required_params / descriptionPrevious value: -"Required parameter names captured from the input schema."New value: +"Required action-specific parameter names to place inside gitlab_execute_action params."
2 tool updates
v2.0.2- Changed
gitlab_execute_tool3 fields changed- changed
Input schema / properties / action / descriptionPrevious value: -"Canonical action ID returned by gitlab_find_action, such as project.list."New value: +"Canonical action ID returned by gitlab_find_action, or a supported compatibility alias, such as project.list, issue.update, or issue.close." - changed
Input schema / properties / confirm / descriptionPrevious value: -"Set true to explicitly confirm destructive actions."New value: +"Set top-level confirm=true to explicitly approve destructive actions; do not put confirm inside params for gitlab_execute_tool." - changed
Output schema / (root)Previous value: -nullNew value: +{ + "additionalProperties": true, + "description": "Result envelope. Top-level shape varies per action and matches the chosen action's typed output. Includes optional cross-cutting fields documented below.", + "properties": { + "next_steps": { + "description": "Optional. Suggested follow-up actions or tool calls for the LLM, contextual to the result.", + "items": { + "type": "string" + }, + "type": "array" + }, + "pagination": { + "additionalProperties": true, + "description": "Present on list actions. Use `has_more` and `next_page` to paginate through results.", + "properties": { + "has_more": { + "description": "True when more pages are available after the current one.", + "type": "boolean" + }, + "next_page": { + "description": "Next page index when `has_more` is true.", + "type": "integer" + }, + "page": { + "description": "Current 1-based page index.", + "type": "integer" + }, + "per_page": { + "description": "Items per page.", + "type": "integer" + }, + "prev_page": { + "description": "Previous page index when applicable.", + "type": "integer" + }, + "total": { + "description": "Total item count when known (some endpoints omit it for performance).", + "type": "integer" + }, + "total_pages": { + "description": "Total page count when known.", + "type": "integer" + } + }, + "type": "object" + } + }, + "type": "object" +}
- Changed
gitlab_find_action1 field changed- changed
Input schema / properties / query / descriptionPrevious value: -"Search terms for GitLab actions, such as project create, merge request approve, pipeline retry, or ci variable."New value: +"Search terms combining a GitLab domain or resource with a verb, filter, or object name, such as project create, merge request approve, pipeline retry, issue delete, or ci variable."
TDQS
Scored across 2 tools
gitlab_execute_action and gitlab_find_action have clearly distinct roles: one executes catalog actions, the other searches the local catalog without making API calls. There is no meaningful overlap or ambiguity between them.
Both tools follow the same gitlab_<verb>_action pattern, creating a predictable and consistent naming convention. The verb prefixes accurately indicate the operation type.
Two tools is a minimal surface and feels thin for a GitLab server, even though the find/execute split is functional. The generic executor and catalog search reduce the impact, but the count is still borderline.
The two tools form a complete discovery-and-execution loop: find_action provides schemas, hints, and examples, while execute_action runs the selected action. Assuming the underlying catalog covers the needed GitLab operations, there are no obvious dead ends.
Maintenance
Related MCP Connectors
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
GitLab MCP — wraps the GitLab REST API v4 (BYO API key)
AI-native git hosting — repos, PRs, issues, CI gates, and AI code review over MCP (60 tools).
Model Context Protocol server for the Apideck Unified API. Connect any MCP-compatible agent framework to 100+ accounting systems, HRIS platforms, file storage providers, and more through one integration. More information https://www.apideck.com/mcp-server
Related MCP Servers
- AlicenseBqualityAmaintenanceFirst gitlab mcp for you, building together11870,206 npm1,987MIT
- -licenseNot gradedqualityNot gradedmaintenanceA Model Context Protocol server that enables AI assistants to interact with GitLab repositories, allowing tasks like managing merge requests, searching projects, and creating comments through RESTful API integration.5 npm2-
- AlicenseBqualityCmaintenanceA Model Context Protocol (MCP) server for GitLab and Jira integration. This server allows AI agents like gemini-cli to interact with your GitLab and Jira instances.326 npm11MIT
- AlicenseNot gradedqualityAmaintenanceFull-coverage GitLab MCP server with 44 tools across 18 resource types. Agent-optimized CQRS design — one tool call handles complete multi-step operations. Supports OAuth 2.1, read-only mode, stdio/SSE/StreamableHTTP transports, and GraphQL-native work items with full hierarchy (epics,issues,etc)1,922 npm6Apache 2.0