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

Сервер MCP для API GitLab, обеспечивающий управление проектами, файловые операции и многое другое.

Функции

Автоматическое создание веток : при создании/обновлении файлов или отправке изменений автоматически создаются ветки, если они не существуют.
Комплексная обработка ошибок : понятные сообщения об ошибках для распространенных проблем
Сохранение истории Git : операции поддерживают правильную историю Git без принудительной отправки
Пакетные операции : поддержка как однофайловых, так и многофайловых операций.

Инструменты

create_or_update_file
- Создать или обновить отдельный файл в проекте
- Входные данные:
  - project_id (строка): идентификатор проекта или путь в кодировке URL
  - file_path (string): Путь, по которому необходимо создать/обновить файл.
  - content (строка): Содержимое файла
  - commit_message (строка): сообщение о фиксации
  - branch (строка): ветвь для создания/обновления файла
  - previous_path (необязательная строка): Путь к файлу для перемещения/переименования
- Возвращает: содержимое файла и сведения о фиксации
push_files
- Отправка нескольких файлов в один коммит
- Входные данные:
  - project_id (строка): идентификатор проекта или путь в кодировке URL
  - branch (строка): ветвь, в которую нужно отправить
  - files (массив): файлы для отправки, каждый с file_path и content
  - commit_message (строка): сообщение о фиксации
- Возврат: обновленная ссылка на ветку
search_repositories
- Поиск проектов GitLab
- Входные данные:
  - search (строка): Поисковый запрос
  - page (необязательное число): Номер страницы для нумерации страниц
  - per_page (необязательное число): Результаты на страницу (по умолчанию 20)
- Возвращает: Результаты поиска проектов
create_repository
- Создайте новый проект GitLab
- Входные данные:
  - name (строка): Название проекта
  - description (необязательная строка): Описание проекта
  - visibility (необязательная строка): «частная», «внутренняя» или «публичная»
  - initialize_with_readme (необязательное логическое значение): Инициализировать с помощью README
- Возвращает: Созданные детали проекта
get_file_contents
- Получить содержимое файла или каталога
- Входные данные:
  - project_id (строка): идентификатор проекта или путь в кодировке URL
  - file_path (строка): Путь к файлу/каталогу
  - ref (необязательная строка): Ветвь/тег/коммит для получения содержимого
- Возвращает: содержимое файла/каталога
create_issue
- Создать новый выпуск
- Входные данные:
  - project_id (строка): идентификатор проекта или путь в кодировке URL
  - title (строка): Название выпуска
  - description (необязательная строка): Описание проблемы
  - assignee_ids (необязательное число[]): идентификаторы пользователей для назначения
  - labels (необязательно string[]): Метки для добавления
  - milestone_id (необязательное число): идентификатор этапа
- Возвраты: Созданные детали проблемы
create_merge_request
- Создать новый запрос на слияние
- Входные данные:
  - project_id (строка): идентификатор проекта или путь в кодировке URL
  - title (строка): заголовок MR
  - description (необязательная строка): описание MR
  - source_branch (string): Ветка, содержащая изменения
  - target_branch (string): Ветка для слияния
  - draft (необязательно логическое значение): создать как черновик MR
  - allow_collaboration (необязательное логическое значение): Разрешить коммиты от вышестоящих участников
- Возвращает: Созданные детали запроса на слияние
fork_repository
- Форк проекта
- Входные данные:
  - project_id (строка): идентификатор проекта или путь в кодировке URL
  - namespace (необязательная строка): пространство имен для разветвления
- Возвращает: Подробности разветвленного проекта
create_branch
- Создать новую ветку
- Входные данные:
  - project_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
      }
    }
  }
}

НПХ

{
  "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

Для быстрой установки воспользуйтесь одной из кнопок установки в один клик ниже...

Установить с помощью NPX в VS Code Установка с NPX в VS Code Insiders

Установка с помощью Docker в VS Code

Для ручной установки добавьте следующий блок JSON в файл настроек пользователя (JSON) в VS Code. Это можно сделать, нажав Ctrl + Shift + P и введя Preferences: Open User Settings (JSON) .

При желании вы можете добавить его в файл .vscode/mcp.json в вашем рабочем пространстве. Это позволит вам поделиться конфигурацией с другими.

Обратите внимание, что ключ mcp не нужен в файле .vscode/mcp.json .

Докер

{
  "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}"
        }
      }
    }
  }
}

НПХ

{
  "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 : базовый URL для API GitLab (необязательно, по умолчанию 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

Докер

НПХ

Использование с VS Code

Докер

НПХ

Строить

Переменные среды

Лицензия

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