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

Servidor MCP de GitLab

Servidor MCP para la API de GitLab, que permite la gestión de proyectos, operaciones de archivos y más.

Características

Creación automática de ramas : al crear o actualizar archivos o enviar cambios, las ramas se crean automáticamente si no existen.
Manejo integral de errores : mensajes de error claros para problemas comunes
Preservación del historial de Git : las operaciones mantienen el historial de Git adecuado sin forzar el envío.
Operaciones por lotes : compatibilidad con operaciones de un solo archivo y de varios archivos

Herramientas

create_or_update_file
- Crear o actualizar un solo archivo en un proyecto
- Entradas:
  - project_id (cadena): ID del proyecto o ruta codificada en URL
  - file_path (cadena): Ruta donde crear/actualizar el archivo
  - content (cadena): Contenido del archivo
  - commit_message (cadena): Mensaje de confirmación
  - branch (cadena): Rama para crear/actualizar el archivo en
  - previous_path (cadena opcional): Ruta del archivo a mover/renombrar
- Devuelve: Contenido del archivo y detalles de confirmación
push_files
- Insertar varios archivos en una sola confirmación
- Entradas:
  - project_id (cadena): ID del proyecto o ruta codificada en URL
  - branch (cadena): Rama a la que enviar
  - files (matriz): archivos para enviar, cada uno con file_path y content
  - commit_message (cadena): Mensaje de confirmación
- Devoluciones: Referencia de rama actualizada
search_repositories
- Buscar proyectos de GitLab
- Entradas:
  - search (cadena): consulta de búsqueda
  - page (número opcional): Número de página para paginación
  - per_page (número opcional): Resultados por página (predeterminado 20)
- Devoluciones: Resultados de la búsqueda del proyecto
create_repository
- Crear un nuevo proyecto de GitLab
- Entradas:
  - name (cadena): nombre del proyecto
  - description (cadena opcional): Descripción del proyecto
  - visibility (cadena opcional): 'privada', 'interna' o 'pública'
  - initialize_with_readme (booleano opcional): Inicializar con README
- Devoluciones: Detalles del proyecto creado
get_file_contents
- Obtener el contenido de un archivo o directorio
- Entradas:
  - project_id (cadena): ID del proyecto o ruta codificada en URL
  - file_path (cadena): Ruta al archivo/directorio
  - ref (cadena opcional): rama/etiqueta/confirmación de la que obtener el contenido
- Devuelve: Contenido del archivo/directorio
create_issue
- Crear un nuevo problema
- Entradas:
  - project_id (cadena): ID del proyecto o ruta codificada en URL
  - title (cadena): Título del problema
  - description (cadena opcional): Descripción del problema
  - assignee_ids (número opcional[]): ID de usuario para asignar
  - labels (cadena opcional[]): etiquetas para agregar
  - milestone_id (número opcional): ID del hito
- Devoluciones: Detalles del problema creado
create_merge_request
- Crear una nueva solicitud de fusión
- Entradas:
  - project_id (cadena): ID del proyecto o ruta codificada en URL
  - title (cadena): título de MR
  - description (cadena opcional): descripción de MR
  - source_branch (cadena): rama que contiene los cambios
  - target_branch (cadena): rama en la que fusionarse
  - draft (booleano opcional): Crear como borrador MR
  - allow_collaboration (booleano opcional): Permitir confirmaciones de miembros ascendentes
- Devoluciones: Detalles de la solicitud de fusión creada
fork_repository
- Bifurcar un proyecto
- Entradas:
  - project_id (cadena): ID del proyecto o ruta codificada en URL
  - namespace (cadena opcional): espacio de nombres al que bifurcar
- Devoluciones: Detalles del proyecto bifurcado
create_branch
- Crear una nueva rama
- Entradas:
  - project_id (cadena): ID del proyecto o ruta codificada en URL
  - branch (cadena): Nombre de la nueva rama
  - ref (cadena opcional): rama de origen/confirmación para la nueva rama
- Devuelve: Referencia de rama creada

Related MCP server: GitHub MCP Server Plus

Configuración

Token de acceso personal

Cree un token de acceso personal de GitLab con los permisos adecuados:

Vaya a Configuración de usuario > Tokens de acceso en GitLab
Seleccione los ámbitos requeridos:
- api para acceso completo a la API
- read_api para acceso de solo lectura
- read_repository y write_repository para operaciones de repositorio
Crea el token y guárdalo de forma segura

Uso con Claude Desktop

Agregue lo siguiente a su claude_desktop_config.json :

Estibador

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

Uso con VS Code

Para una instalación rápida, utilice uno de los botones de instalación de un solo clic que aparecen a continuación...

Instalar con NPX en VS Code Instalar con NPX en VS Code Insiders

Instalar con Docker en VS Code

Para la instalación manual, agregue el siguiente bloque JSON a su archivo de configuración de usuario (JSON) en VS Code. Para ello, presione Ctrl + Shift + P y escriba Preferences: Open User Settings (JSON) .

Opcionalmente, puede agregarlo a un archivo llamado .vscode/mcp.json en su espacio de trabajo. Esto le permitirá compartir la configuración con otros.

Tenga en cuenta que la clave mcp no es necesaria en el archivo .vscode/mcp.json .

Estibador

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

Construir

Compilación de Docker:

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

Variables de entorno

GITLAB_PERSONAL_ACCESS_TOKEN : Su token de acceso personal de GitLab (obligatorio)
GITLAB_API_URL : URL base para la API de GitLab (opcional, el valor predeterminado es https://gitlab.com/api/v4 )

Licencia

Este servidor MCP cuenta con la licencia MIT. Esto significa que puede usar, modificar y distribuir el software libremente, sujeto a los términos y condiciones de la licencia MIT. Para más detalles, consulte el archivo de LICENCIA en el repositorio del proyecto.

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

Servidor MCP de GitLab

Características

Herramientas

Configuración

Token de acceso personal

Uso con Claude Desktop

Estibador

NPX

Uso con VS Code

Estibador

NPX

Construir

Variables de entorno

Licencia

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