de en es ja ko ru zh

GitLab MCP Server

Name: GitLab MCP Server
Author: modelcontextprotocol

Official

by modelcontextprotocol

Overview Schema Related Servers Score Discussions

TypeScript

Remote

GitLab MCP サーバー

GitLab API 用の MCP サーバー。プロジェクト管理、ファイル操作などが可能になります。

特徴

自動ブランチ作成: ファイルを作成/更新したり変更をプッシュしたりするときに、ブランチが存在しない場合は自動的に作成されます。
包括的なエラー処理: 一般的な問題に対する明確なエラーメッセージ
Git 履歴の保存: 強制プッシュなしで適切な Git 履歴を維持する操作
バッチ操作: 単一ファイルと複数ファイルの操作の両方をサポート

ツール

create_or_update_file
- プロジェクト内の単一のファイルを作成または更新する
- 入力:
  - project_id (文字列): プロジェクトIDまたはURLエンコードされたパス
  - file_path (文字列): ファイルを作成/更新するパス
  - content (文字列): ファイルの内容
  - commit_message (文字列): コミットメッセージ
  - branch (文字列): ファイルを作成/更新するブランチ
  - previous_path (オプションの文字列): 移動/名前変更するファイルのパス
- 戻り値: ファイルの内容とコミットの詳細
push_files
- 1回のコミットで複数のファイルをプッシュする
- 入力:
  - project_id (文字列): プロジェクトIDまたはURLエンコードされたパス
  - branch (文字列): プッシュ先のブランチ
  - files (配列): プッシュするファイル。それぞれfile_pathとcontentを持つ。
  - commit_message (文字列): コミットメッセージ
- 戻り値: 更新されたブランチ参照
search_repositories
- GitLabプロジェクトを検索
- 入力:
  - search (文字列): 検索クエリ
  - page （オプションの数値）：ページ番号
  - per_page （オプションの数値）：1ページあたりの結果数（デフォルトは20）
- 返されるもの: プロジェクト検索結果
create_repository
- 新しいGitLabプロジェクトを作成する
- 入力:
  - name (文字列): プロジェクト名
  - description （オプションの文字列）: プロジェクトの説明
  - visibility （オプションの文字列）: 'private'、'internal'、または 'public'
  - initialize_with_readme (オプションのブール値): README で初期化する
- 戻り値: 作成されたプロジェクトの詳細
get_file_contents
- ファイルまたはディレクトリの内容を取得する
- 入力:
  - project_id (文字列): プロジェクトIDまたはURLエンコードされたパス
  - file_path (文字列): ファイル/ディレクトリへのパス
  - ref (オプションの文字列): コンテンツを取得するブランチ/タグ/コミット
- 戻り値: ファイル/ディレクトリの内容
create_issue
- 新しい問題を作成する
- 入力:
  - project_id (文字列): プロジェクトIDまたはURLエンコードされたパス
  - title (文字列): 問題のタイトル
  - description （オプションの文字列）: 問題の説明
  - assignee_ids (オプションの数値[]): 割り当てるユーザーID
  - labels （オプションの文字列[]）：追加するラベル
  - milestone_id (オプションの数値): マイルストーンID
- 返品: 作成された問題の詳細
create_merge_request
- 新しいマージリクエストを作成する
- 入力:
  - project_id (文字列): プロジェクトIDまたはURLエンコードされたパス
  - title (文字列): MRタイトル
  - description （オプションの文字列）：MRの説明
  - source_branch (文字列): 変更を含むブランチ
  - target_branch (文字列): マージ先のブランチ
  - draft （オプションのブール値）：ドラフトMRとして作成
  - allow_collaboration （オプションのブール値）：上流メンバーからのコミットを許可する
- 戻り値: 作成されたマージリクエストの詳細
fork_repository
- プロジェクトをフォークする
- 入力:
  - project_id (文字列): プロジェクトIDまたはURLエンコードされたパス
  - namespace (オプションの文字列): フォークする名前空間
- 戻り値: フォークされたプロジェクトの詳細
create_branch
- 新しいブランチを作成する
- 入力:
  - project_id (文字列): プロジェクトIDまたはURLエンコードされたパス
  - branch (文字列): 新しいブランチの名前
  - ref (オプションの文字列): 新しいブランチのソースブランチ/コミット
- 戻り値: 作成されたブランチ参照

Related MCP server: GitHub MCP Server Plus

設定

個人アクセストークン

適切な権限を持つGitLab 個人アクセストークンを作成します。

GitLabのユーザー設定 > アクセストークンに移動します
必要なスコープを選択します。
- 完全なAPIアクセスのためのapi
- 読み取り専用アクセス用のread_api
- リポジトリ操作用のread_repositoryとwrite_repository
トークンを作成し、安全に保存する

Claude Desktopでの使用

claude_desktop_config.jsonに以下を追加します。

ドッカー

{
  "mcpServers": { 
    "gitlab": {
      "command": "docker",
      "args": [
        "run",
        "--rm",
        "-i",
        "-e",
        "GITLAB_PERSONAL_ACCESS_TOKEN",
        "-e",
        "GITLAB_API_URL",
        "mcp/gitlab"
      ],
      "env": {
        "GITLAB_PERSONAL_ACCESS_TOKEN": "<YOUR_TOKEN>",
        "GITLAB_API_URL": "https://gitlab.com/api/v4" // Optional, for self-hosted instances
      }
    }
  }
}

NPX

{
  "mcpServers": {
    "gitlab": {
      "command": "npx",
      "args": [
        "-y",
        "@modelcontextprotocol/server-gitlab"
      ],
      "env": {
        "GITLAB_PERSONAL_ACCESS_TOKEN": "<YOUR_TOKEN>",
        "GITLAB_API_URL": "https://gitlab.com/api/v4" // Optional, for self-hosted instances
      }
    }
  }
}

VS Codeでの使用

素早くインストールするには、以下のワンクリックインストールボタンのいずれかを使用します...

VS CodeでNPXを使ってインストールする VS Code Insiders で NPX を使用してインストールする

VS CodeでDockerを使ってインストールする VS Code Insiders で Docker を使用してインストールする

手動でインストールする場合は、VS Code のユーザー設定 (JSON) ファイルに次の JSON ブロックを追加します。Ctrl Ctrl + Shift + Pを押してPreferences: Open User Settings (JSON)と入力すると、このブロックを追加できます。

オプションとして、ワークスペース内の.vscode/mcp.jsonというファイルに追加することもできます。これにより、他のユーザーと設定を共有できるようになります。

.vscode/mcp.jsonファイルではmcpキーは必要ないことに注意してください。

ドッカー

{
  "mcp": {
    "inputs": [
      {
        "type": "promptString",
        "id": "gitlab_token",
        "description": "GitLab Personal Access Token",
        "password": true
      },
      {
        "type": "promptString",
        "id": "gitlab_url",
        "description": "GitLab API URL (optional)",
        "default": "https://gitlab.com/api/v4"
      }
    ],
    "servers": {
      "gitlab": {
        "command": "docker",
        "args": [
          "run",
          "--rm",
          "-i",
          "mcp/gitlab"
        ],
        "env": {
          "GITLAB_PERSONAL_ACCESS_TOKEN": "${input:gitlab_token}",
          "GITLAB_API_URL": "${input:gitlab_url}"
        }
      }
    }
  }
}

NPX

{
  "mcp": {
    "inputs": [
      {
        "type": "promptString",
        "id": "gitlab_token",
        "description": "GitLab Personal Access Token",
        "password": true
      },
      {
        "type": "promptString",
        "id": "gitlab_url",
        "description": "GitLab API URL (optional)",
        "default": "https://gitlab.com/api/v4"
      }
    ],
    "servers": {
      "gitlab": {
        "command": "npx",
        "args": [
          "-y",
          "@modelcontextprotocol/server-gitlab"
        ],
        "env": {
          "GITLAB_PERSONAL_ACCESS_TOKEN": "${input:gitlab_token}",
          "GITLAB_API_URL": "${input:gitlab_url}"
        }
      }
    }
  }
}

建てる

Dockerビルド:

docker build -t vonwig/gitlab:mcp -f src/gitlab/Dockerfile .

環境変数

GITLAB_PERSONAL_ACCESS_TOKEN : GitLab個人アクセストークン（必須）
GITLAB_API_URL : GitLab API のベース URL (オプション、デフォルトはhttps://gitlab.com/api/v4 )

ライセンス

このMCPサーバーはMITライセンスに基づいてライセンスされています。つまり、MITライセンスの条件に従って、ソフトウェアを自由に使用、改変、配布することができます。詳細については、プロジェクトリポジトリのLICENSEファイルをご覧ください。

Available Tools

9 tools

create_branchB

Create a new branch in a GitLab project

ParametersJSON Schema

Name	Required	Description
`ref`	No	Source branch/commit for new branch
`branch`	Yes	Name for the new branch
`project_id`	Yes	Project ID or URL-encoded path

TDQS

B3.1/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, and description omits behavioral details like error handling on duplicate branch, permission requirements, or whether ref is optional.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Single sentence is concise and front-loaded with key info, but lacks structure for complex details.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema and no annotations, description is too brief. Does not mention important context like branch naming rules or default behavior.

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 covers 100% of parameters with descriptions. Description adds no extra meaning beyond what schema provides.

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?

Description clearly states action (Create), resource (branch), and context (GitLab project). It effectively distinguishes from sibling tools as no other tool creates branches.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool vs alternatives, no prerequisites or exclusions provided.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

create_issueB

Create a new issue in a GitLab project

ParametersJSON Schema

Name	Required	Description
`title`	Yes	Issue title
`labels`	No	Array of label names
`project_id`	Yes	Project ID or URL-encoded path
`description`	No	Issue description
`assignee_ids`	No	Array of user IDs to assign
`milestone_id`	No	Milestone ID to assign

TDQS

B3.1/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description bears full responsibility for disclosing behavioral traits. It only states the basic action, omitting side effects (e.g., audit trail, notifications), authorization needs, rate limits, or what occurs on success/failure. This is insufficient for an agent to use the tool safely.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, concise sentence with no fluff. It conveys the core purpose efficiently. However, it could be slightly expanded to include key usage hints without losing conciseness.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has 6 parameters (2 required) and no output schema, the description fails to provide enough context for complete understanding. It does not explain the relationship between parameters or common usage patterns, leaving the agent to infer from the schema alone.

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?

The input schema covers all 6 parameters with descriptions, achieving 100% schema coverage. The description adds no new meaning beyond the schema, so a baseline score of 3 is appropriate. No parameter information is missing from the structured data.

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 action ('create') and the resource ('a new issue in a GitLab project'). It effectively distinguishes from sibling tools like create_branch or create_merge_request, leaving no ambiguity about what this tool does.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives (e.g., create_merge_request). It does not mention any prerequisites, such as required permissions or project existence, and offers no example scenarios.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

create_merge_requestB

Create a new merge request in a GitLab project

ParametersJSON Schema

Name	Required	Description
`draft`	No	Create as draft merge request
`title`	Yes	Merge request title
`project_id`	Yes	Project ID or URL-encoded path
`description`	No	Merge request description
`source_branch`	Yes	Branch containing changes
`target_branch`	Yes	Branch to merge into
`allow_collaboration`	No	Allow commits from upstream members

TDQS

B3.1/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Description is minimal and does not disclose any behavioral traits beyond the basic creation. No mention of permissions, side effects, or what happens on success/failure. With no annotations, description carries full burden but fails to provide insights.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Single sentence with no unnecessary words. However, it could be considered under-specified but that is more about completeness than conciseness.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given 7 parameters and no output schema, the description is insufficient. It does not explain return values, error conditions, or any additional context needed for proper use.

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 has 100% description coverage, so the schema already documents all 7 parameters. The description adds no extra meaning beyond the schema, meeting the baseline expectation.

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?

Description clearly states the action 'Create' and resource 'merge request' in a specific context 'GitLab project'. It distinguishes from siblings like create_branch and create_issue.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool vs alternatives like create_branch or create_issue. No context about prerequisites or when not to use it.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

create_or_update_fileC

Create or update a single file in a GitLab project

ParametersJSON Schema

Name	Required	Description
`branch`	Yes	Branch to create/update the file in
`content`	Yes	Content of the file
`file_path`	Yes	Path where to create/update the file
`project_id`	Yes	Project ID or URL-encoded path
`previous_path`	No	Path of the file to move/rename
`commit_message`	Yes	Commit message

TDQS

C2.9/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations exist, so the description alone must disclose behavioral traits. It only states the action ('create or update') but does not mention side effects, required permissions, idempotency, or what happens if the file already exists or not. This is insufficient for a mutation tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single concise sentence that immediately conveys the purpose. It is front-loaded and efficient, though it could benefit from slight expansion.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With 6 parameters, no output schema, and no annotations, the description is too brief. It omits details about rename behavior via 'previous_path', error conditions, size limits, and typical usage flows. Incomplete for a complex mutation tool.

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%, meaning all parameters have descriptions in the schema. The description adds no extra meaning beyond what the schema already provides, so baseline score of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states the verb ('Create or update') and resource ('a single file in a GitLab project'). It is specific enough to distinguish from most siblings, though not explicitly from 'push_files' which may have overlapping functionality.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use this tool versus alternatives like 'push_files' or 'get_file_contents'. No when-not-to-use or prerequisite information is included.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

create_repositoryC

Create a new GitLab project

ParametersJSON Schema

Name	Required	Description
`name`	Yes	Repository name
`visibility`	No	Repository visibility level
`description`	No	Repository description
`initialize_with_readme`	No	Initialize with README.md

TDQS

C2.8/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries full burden. It only says what the tool does, but does not disclose side effects, authentication needs, or output behavior. For a creation tool, more detail is expected.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence of 5 words. It is concise but too minimal; it could benefit from a bit more context without losing efficiency.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema or annotations, the description should explain return values or what happens after creation. It does not, leaving agents without critical context.

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?

Input schema has 100% coverage with descriptions for all 4 parameters. The description adds no extra meaning beyond the schema, meeting the baseline of 3.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description 'Create a new GitLab project' clearly states the verb (create) and resource (repository/project). It distinguishes from siblings like create_branch or create_issue, but does not explicitly differentiate.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool versus alternatives. Does not mention prerequisites, use cases, or exclusions, leaving agents to infer.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

fork_repositoryB

Fork a GitLab project to your account or specified namespace

ParametersJSON Schema

Name	Required	Description	Default
`namespace`	No	Namespace to fork to (full path)
`project_id`	Yes	Project ID or URL-encoded path

TDQS

B3.1/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description is the sole source for behavioral traits. It only describes the basic action without disclosing potential side effects, permissions, visibility settings, or confirmation of success.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

A single sentence that is concise and direct. However, it could be restructured to front-load more crucial information or be slightly expanded without losing conciseness.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Despite a simple tool with 2 parameters and no output schema, the description lacks details about what happens after forking (e.g., new repository creation, visibility), leaving the agent underinformed.

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 covers both parameters with descriptions (100% coverage), so the description adds no extra meaning. Baseline score of 3 applies as the schema is self-sufficient.

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 action (Fork) and resource (GitLab project) with explicit destination options (your account or specified namespace). It is distinct from siblings like create_repository or create_branch.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool versus alternatives. There is no mention of prerequisites, exclusions, or comparison to sibling tools like create_repository.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_file_contentsB

Get the contents of a file or directory from a GitLab project

ParametersJSON Schema

Name	Required	Description
`ref`	No	Branch/tag/commit to get contents from
`file_path`	Yes	Path to the file or directory
`project_id`	Yes	Project ID or URL-encoded path

TDQS

B3.1/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden for behavioral disclosure, but it only states 'Get', implying a read operation without confirming safety, authentication needs, or potential side effects. Minimal transparency.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Single sentence, 11 words, no waste. Efficiently conveys the core purpose, though could be slightly more informative without losing conciseness.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

No output schema exists, so the description should explain return value format or behavior (e.g., raw text, JSON, pagination). It only says 'get contents', leaving the agent uninformed about what to expect.

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%, so baseline is 3. The description adds no additional meaning to the parameters beyond what the schema already provides.

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 gets 'contents of a file or directory from a GitLab project', using a specific verb and resource. It distinguishes from sibling tools which are all about creating or searching, not retrieving contents.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool versus alternatives, no prerequisites or exclusions provided. The description lacks any contextual cues for appropriate usage.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

push_filesC

Push multiple files to a GitLab project in a single commit

ParametersJSON Schema

Name	Required	Description
`files`	Yes	Array of files to push
`branch`	Yes	Branch to push to
`project_id`	Yes	Project ID or URL-encoded path
`commit_message`	Yes	Commit message

TDQS

C2.9/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the burden of behavioral disclosure. It only mentions that the push is in a single commit, but lacks details on whether files can be created or updated, what happens on merge conflicts, permission requirements, or rollback behavior. This is insufficient for a mutation 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?

The description is a single sentence with no wasteful words. It is front-loaded with the core action and context.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema and no annotations, the description should provide more context about prerequisites, success conditions, and failure modes. It lacks completeness for a tool that modifies project files.

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%, with all 4 parameters described in the schema. The tool description adds no extra semantic meaning beyond 'push multiple files' and 'single commit'. Baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/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: pushing multiple files to a GitLab project in a single commit. It uses a specific verb ('push') and resource ('GitLab project'), and implicitly distinguishes from sibling tools like create_or_update_file which handle single files.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool versus alternatives such as create_or_update_file or create_branch. The description does not mention prerequisites like branch existence or file path constraints.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

search_repositoriesB

Search for GitLab projects

ParametersJSON Schema

Name	Required	Description
`page`	No	Page number for pagination (default: 1)
`search`	Yes	Search query
`per_page`	No	Number of results per page (default: 20)

TDQS

B3.2/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, and the description does not disclose behavioral traits such as read-only nature, rate limits, or response format. It only states the basic action.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Single sentence is concise, but it lacks structure or front-loading of key information. It serves its purpose without excess.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple search tool with three parameters and no output schema, the description is minimally adequate. It does not explain return values or search behavior beyond the basic verb.

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% with descriptions for all parameters. The description adds no additional meaning beyond the schema, so baseline 3 is appropriate.

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?

Description says 'Search for GitLab projects' which is a specific verb and resource. It clearly distinguishes from sibling tools which are about creation, branching, and file operations.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool versus alternatives. The description provides no context for when searching is appropriate compared to other actions.

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. Dates show when Glama detected each change.

9 tool updatesv2026.7.4Jul 5, 2026
- First observedcreate_branch
- First observedcreate_issue
- First observedcreate_merge_request
- First observedcreate_or_update_file
- First observedcreate_repository
- First observedfork_repository
- First observedget_file_contents
- First observedpush_files
- First observedsearch_repositories

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.5/5.0

Disambiguation5/5

Each tool targets a distinct resource or action (branch, issue, merge request, file, repository, fork, search) with no overlapping purposes.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern (e.g., create_branch, get_file_contents), with only 'create_or_update_file' being slightly longer but still consistent.

Tool Count5/5

9 tools is well-scoped for a GitLab server, covering core operations without being excessive or insufficient.

Completeness4/5

Covers essential create/read operations but lacks explicit update/delete for issues, merge requests, and branches, which agents may need to work around.

Maintenance

ActivityActive

ResponsivenessSlow

Resources

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

mcpOAuth
com.gitlab
Official GitLab MCP Server
Version Control CI/CD & DevOps Developer Tools
2
neverinfamous-memory-journal-mcp
ai.smithery
A MCP server built for developers enabling Git based project management with project and personal…
Version Control Developer Tools Project Management
320
Gitlab A
io.github.pipeworx-io
GitLab MCP — wraps the GitLab REST API v4 (BYO API key)
Version Control CI/CD & DevOps Developer Tools
362
server B
io.cycloid.mcp
An MCP server that let you interact with Cycloid.io Internal Development Portal and Platform
Developer Tools CI/CD & DevOps Cloud Platforms
62

Related MCP Servers

GitHub MCP Serverofficial
Version Control Developer Tools File Systems
modelcontextprotocol
-
license
Not graded
quality
A
maintenance
MCP Server for the GitHub API, enabling file operations, repository management, search functionality, and more.
Updated 3 days ago (2026-09-03 01:42 UTC)
117,296
90,042
MIT
GitHub MCP Server Plus
Version Control Developer Tools
PhialsBasement
A
license
B
quality
D
maintenance
MCP Server for the GitHub API, providing features for file operations, repository management, and advanced search, with automatic branch creation and comprehensive error handling.
Updated a year ago (2025-05-05 10:31 UTC)
18
13
8
MIT
gitlab-mcp-server
Version Control Developer Tools CI/CD & DevOps
yoda-digital
A
license
C
quality
B
maintenance
GitLab MCP Server (with activity tracking and group projects listing features) This server is based on the original GitLab MCP server with Group Projects Listing and Activity Tracking enhancements
Updated 24 days ago (2026-08-12 20:15 UTC)
86
372
64
MIT
GitLab MCP Server
Version Control Developer Tools
harshmaur
A
license
C
quality
D
maintenance
An MCP server that enables communication with GitLab repositories, allowing interaction with GitLab's API to manage projects, issues, and repositories through natural language.
Updated a year ago (2025-06-05 11:51 UTC)
45
123,899
1
MIT

Appeared in Searches

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/modelcontextprotocol/gitlab'

If you have feedback or need assistance with the MCP directory API, please join our Discord server

GitLab MCP サーバー

特徴

ツール

設定

個人アクセストークン

Claude Desktopでの使用

ドッカー

NPX

VS Codeでの使用

ドッカー

NPX

建てる

環境変数

ライセンス

Available Tools

Tool Schema Changelog

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

GitHub MCP Serverofficial

Appeared in Searches

Latest Blog Posts

MCP directory API