Skip to main content
Glama

GitLab MCP Server

GitHub Release License: MIT Platform

CI Quality Gate Coverage Go Reference

Glama MCP Score

MCP Badge MCP Toplist Cursor Directory Hosted endpoint

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 --setup

VS 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.jsonservers + 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.json

  • Linux: ~/.config/Code/User/globalStorage/saoudrizwan.claude-dev/settings/cline_mcp_settings.json

  • Windows: %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/health200{"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(gitlab_find_action, gitlab_execute_action

最小のトークンコスト。find/execute で全カタログに到達。

メタツールmeta

32 base / 49 Ultimate / 50 GitLab.com Ultimate

action パラメータを持つドメイン別ディスパッチャ。

個別individual

~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=dynamicCAPABILITY_SURFACE=fullMETA_TOOLS 未設定、META_PARAM_SCHEMA=opaqueGITLAB_TIER 未設定(自動検出、フォールバックは free)の場合、サーバーは**ダイナミック find/execute サーフェス

ドキュメント

完全なドキュメントは jmrp.io/docs/gitlab-mcp-server にあります。特定の領域に関する信頼できるリファレンスとして、このマップを使用してください:

ドキュメント

説明

はじめに

ダウンロード、セットアップウィザード、クライアント別設定

IDE設定

クライアント別のstdio、HTTPレガシー、HTTP OAuthの例

設定

環境変数、トランスポートモード、TLS

環境変数

デフォルト値と例を含む環境変数の完全な表

CLIリファレンス

すべてのコマンドラインフラグ、終了コード、実行例

HTTPサーバーモード

共有HTTPデプロイ、認証、サーバープールの分離

OAuthアプリのセットアップ

GitLab OAuthアプリケーション、スコープ、リダイレクトURI、フローを完了できるクライアント

CI/CD

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

github.com/modelcontextprotocol/go-sdk v1.7.0

GitLabクライアント

gitlab.com/gitlab-org/api/client-go/v2 v2.59.0

トランスポート

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で行ってください。

ファイル数

カテゴリ

ファイル

行数

ソース(.go、テスト以外)

992

202,107

ユニットテスト(_test.go)

553

314,659

エンドツーエンドテスト

182

47,508

合計

1,727

564,274

関数

カテゴリ

件数

ソース関数

7,693

— エクスポート済み(公開)

2,675

— 未エクスポート(非公開)

5,018

ユニットテスト関数(TestXxx)

11,985

サブテスト(t.Run(...))

2,986

エンドツーエンドテスト関数

439

注目すべき比率

観察事項

テスト行数とソース行数

テストがコードより1.56倍多い

ソースファイルの平均行数

~203行

テストファイルの平均行数

~569行

ソース内のコメント行

23,569(ソースの~11.7%)

ソース関数あたりのテスト関数数

1.6倍

コードパターン

パターン

件数

if err != nil チェック

6,715

defer ステートメント

934

定義された struct

2,743

//nolint 抑制

263

TODO / FIXME / HACK コメント

2

プロジェクト

メトリック

Goパッケージ

237

直接依存関係(go.mod)

17

間接依存関係

47

殿堂入り

記録

ファイル

最長のソースファイル

internal/tools/projects/projects.go — 3,846行

最長のテストファイル

internal/tools/projects/projects_test.go — 8,183行

だって、いいじゃないか

事実

ソースコードを55行/ページで印刷した場合

A4で約3,674ページ

"gitlab" を含むソース行

12,629(避けるのは不可能)

ソース内で最長の関数名

assertDynamicCompatibilityPolicyOwnedByActionCompat (51文字)

最長のテスト関数名

TestRequiredMissingAndUnknownParamNames_SchemaValidation_ReturnsSortedMissingAndUnknown (87文字)


José M. Requena Plens によってメンテナンスされています · プロジェクトページ · ホスト型インスタンス: mcp.jmrp.io/gitlab

Available Tools

2 tools
gitlab_execute_actionGitLab Execute ActionA
Destructive
Inspect

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.

ParametersJSON Schema
NameRequiredDescriptionDefault
actionYesCanonical action ID returned by gitlab_find_action, or a supported compatibility alias, such as project.list, issue.update, or issue.close.
paramsYesRequired action-specific parameters object validated by the selected action schema. Use an empty object for actions with no parameters.
confirmNoSet top-level confirm=true to explicitly approve destructive actions. Do not put confirm inside params for gitlab_execute_action.

Output Schema

ParametersJSON Schema
NameRequiredDescription
next_stepsNoOptional. Suggested follow-up actions or tool calls for the LLM, contextual to the result.
paginationNoPresent on list actions. Use `has_more` and `next_page` to paginate through results.

TDQS

A4.5/5.0
Behavior4/5

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.

Conciseness5/5

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.

Completeness5/5

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.

Parameters3/5

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.

Purpose5/5

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.

Usage Guidelines5/5

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 ActionA
Read-onlyIdempotent
Inspect

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.

ParametersJSON Schema
NameRequiredDescriptionDefault
limitNoMaximum number of matches to return. Defaults to 20 and is capped at 50.
queryYesSearch 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.
explainNoWhen true, include deterministic scoring reasons for each returned action. Defaults to false to keep responses compact.

Output Schema

ParametersJSON Schema
NameRequiredDescription
countYesNumber of returned matches.
queryYesOriginal search query.
resultsYesMatching GitLab catalog actions with schemas and execute examples.

TDQS

A4.5/5.0
Behavior5/5

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.

Conciseness5/5

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.

Completeness5/5

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.

Parameters3/5

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.

Purpose5/5

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.

Usage Guidelines4/5

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.

  1. 2 tool updatesv3.0.0
    • Changedgitlab_execute_action1 field changed
      • changedInput schema / properties / confirm / description
        Previous 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."
    • Changedgitlab_find_action2 fields changed
      • changedInput schema / properties / query / description
        Previous 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."
      • addedInput schema / properties / query / maxLength
        Added value: +256
  2. 1 tool updatev2.7.5
    • Changedgitlab_execute_action1 field changed
      • changedInput schema / properties / action / x-mcp-header
        Previous value: -"Mcp-Param-Action"New value: +"Action"
  3. 1 tool updatev2.6.0
    • Addedgitlab_execute_action
  4. 1 tool updatev2.5.2
    • Removedgitlab_execute_action
  5. 3 tool updatesv2.1.3
    • Addedgitlab_execute_action
    • Removedgitlab_execute_tool
    • Changedgitlab_find_action4 fields changed
      • changedOutput schema / properties / results / items / properties / example / description
        Previous value: -"Example gitlab_execute_tool call."New value: +"Example gitlab_execute_action call."
      • changedOutput schema / properties / results / items / properties / example / properties / arguments / description
        Previous value: -"Example arguments for gitlab_execute_tool."New value: +"Example arguments for gitlab_execute_action."
      • changedOutput schema / properties / results / items / properties / id / description
        Previous value: -"Canonical action ID to pass to gitlab_execute_tool."New value: +"Canonical action ID to pass to gitlab_execute_action."
      • changedOutput schema / properties / results / items / properties / required_params / description
        Previous value: -"Required parameter names captured from the input schema."New value: +"Required action-specific parameter names to place inside gitlab_execute_action params."
  6. 2 tool updatesv2.0.2
    • Changedgitlab_execute_tool3 fields changed
      • changedInput schema / properties / action / description
        Previous 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."
      • changedInput schema / properties / confirm / description
        Previous 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."
      • changedOutput 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"
        +}
    • Changedgitlab_find_action1 field changed
      • changedInput schema / properties / query / description
        Previous 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

A4.5/5.0

Scored across 2 tools

Disambiguation5/5

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.

Naming Consistency5/5

Both tools follow the same gitlab_<verb>_action pattern, creating a predictable and consistent naming convention. The verb prefixes accurately indicate the operation type.

Tool Count3/5

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.

Completeness5/5

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

ActivityActive
ResponsivenessResponsive

Related MCP Connectors

Related MCP Servers

  • -
    license
    Not graded
    quality
    Not graded
    maintenance
    A 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 npm
    2
    -
  • A
    license
    B
    quality
    C
    maintenance
    A 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.
    32
    6 npm
    11
    MIT
  • A
    license
    Not graded
    quality
    A
    maintenance
    Full-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 npm
    6
    Apache 2.0