Skip to main content
Glama
deenesjakoruzh
modelcontextprotocol

GitLab MCP Server

Official
by modelcontextprotocol
OverviewSchemaRelated ServersScoreDiscussions
TypeScript
Remote

GitLab MCP 服务器

GitLab API 的 MCP 服务器，支持项目管理、文件操作等。

特征

  • 自动创建分支：创建/更新文件或推送更改时，如果分支不存在，则会自动创建分支

  • 全面的错误处理：针对常见问题的清晰错误消息

  • Git 历史记录保存：操作无需强制推送即可维护正确的 Git 历史记录

  • 批量操作：支持单文件和多文件操作

工具

  1. create_or_update_file

    • 创建或更新项目中的单个文件

    • 输入：

      • project_id （字符串）：项目 ID 或 URL 编码路径

      • file_path （字符串）：创建/更新文件的路径

      • content （字符串）：文件的内容

      • commit_message （字符串）：提交消息

      • branch （字符串）：创建/更新文件的分支

      • previous_path （可选字符串）：要移动/重命名的文件的路径

    • 返回：文件内容和提交详细信息

  2. push_files

    • 在一次提交中推送多个文件

    • 输入：

      • project_id （字符串）：项目 ID 或 URL 编码路径

      • branch （字符串）：要推送到的分支

      • files （数组）：要推送的文件，每个文件都有file_path和content

      • commit_message （字符串）：提交消息

    • 返回：更新的分支参考

  3. search_repositories

    • 搜索 GitLab 项目

    • 输入：

      • search （字符串）：搜索查询

      • page （可选数字）：分页的页码

      • per_page （可选数字）：每页结果数（默认 20）

    • 返回：项目搜索结果

  4. create_repository

    • 创建新的 GitLab 项目

    • 输入：

      • name （字符串）：项目名称

      • description （可选字符串）：项目描述

      • visibility （可选字符串）：“private”、“internal”或“public”

      • initialize_with_readme (可选布尔值): 使用 README 初始化

    • 返回：创建的项目详细信息

  5. get_file_contents

    • 获取文件或目录的内容

    • 输入：

      • project_id （字符串）：项目 ID 或 URL 编码路径

      • file_path （字符串）：文件/目录的路径

      • ref （可选字符串）：从中获取内容的分支/标签/提交

    • 返回：文件/目录内容

  6. create_issue

    • 创建新问题

    • 输入：

      • project_id （字符串）：项目 ID 或 URL 编码路径

      • title （字符串）：问题标题

      • description （可选字符串）：问题描述

      • assignee_ids （可选数字[]）：要分配的用户 ID

      • labels （可选字符串[]）：要添加的标签

      • milestone_id （可选数字）：里程碑 ID

    • 返回：创建问题详情

  7. create_merge_request

    • 创建新的合并请求

    • 输入：

      • project_id （字符串）：项目 ID 或 URL 编码路径

      • title （字符串）：MR 标题

      • description （可选字符串）：MR 描述

      • source_branch （字符串）：包含更改的分支

      • target_branch （字符串）：要合并的分支

      • draft （可选布尔值）：创建为 MR 草稿

      • allow_collaboration （可选布尔值）：允许上游成员提交

    • 返回：创建的合并请求详细信息

  8. fork_repository

    • 派生一个项目

    • 输入：

      • project_id （字符串）：项目 ID 或 URL 编码路径

      • namespace （可选字符串）：要分叉到的命名空间

    • 返回：分叉项目详细信息

  9. 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中：

Docker

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

如需手动安装，请将以下 JSON 块添加到 VS Code 中的“用户设置 (JSON)”文件中。您可以按下Ctrl + Shift + P并输入Preferences: Open User Settings (JSON)来执行此操作。

或者，您可以将其添加到工作区中名为.vscode/mcp.json的文件中。这样您就可以与其他人共享该配置。

请注意.vscode/mcp.json文件中不需要mcp键。

Docker

{
  "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
NameRequiredDescriptionDefault
refNoSource branch/commit for new branch
branchYesName for the new branch
project_idYesProject 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
NameRequiredDescriptionDefault
titleYesIssue title
labelsNoArray of label names
project_idYesProject ID or URL-encoded path
descriptionNoIssue description
assignee_idsNoArray of user IDs to assign
milestone_idNoMilestone 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
NameRequiredDescriptionDefault
draftNoCreate as draft merge request
titleYesMerge request title
project_idYesProject ID or URL-encoded path
descriptionNoMerge request description
source_branchYesBranch containing changes
target_branchYesBranch to merge into
allow_collaborationNoAllow 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
NameRequiredDescriptionDefault
branchYesBranch to create/update the file in
contentYesContent of the file
file_pathYesPath where to create/update the file
project_idYesProject ID or URL-encoded path
previous_pathNoPath of the file to move/rename
commit_messageYesCommit 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
NameRequiredDescriptionDefault
nameYesRepository name
visibilityNoRepository visibility level
descriptionNoRepository description
initialize_with_readmeNoInitialize 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
NameRequiredDescriptionDefault
namespaceNoNamespace to fork to (full path)
project_idYesProject 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
NameRequiredDescriptionDefault
refNoBranch/tag/commit to get contents from
file_pathYesPath to the file or directory
project_idYesProject 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
NameRequiredDescriptionDefault
filesYesArray of files to push
branchYesBranch to push to
project_idYesProject ID or URL-encoded path
commit_messageYesCommit 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
NameRequiredDescriptionDefault
pageNoPage number for pagination (default: 1)
searchYesSearch query
per_pageNoNumber 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.

  1. 9 tool updatesv2026.7.4
    • 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

Unclaimed servers have limited discoverability.

Looking for Admin?

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

Related MCP Connectors

Related MCP Servers

Appeared in Searches

Latest Blog Posts

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