Skip to main content
Glama
mcp-gitlab-workflow
by chntif

mcp-gitlab-workflow

English | 简体中文

mcp-gitlab-workflow is an MCP server for issue-driven GitLab development.

It can take a requirement or an existing GitLab issue and drive a standardized delivery flow: requirement analysis, issue creation, branching, coding, merge request creation, and issue updates. It also provides a set of atomic GitLab API tools for custom orchestration and fine-grained control.

1. Core Capabilities

  • workflow_*: higher-level tools that package common requirement-to-delivery flows into a single tool call

  • gitlab_*: atomic GitLab API tools for custom orchestration and fine-grained control

Target projects for issues and code delivery are configured with WORKFLOW_ISSUE_PROJECT_ID and WORKFLOW_CODE_PROJECT_ID. See the environment variable section below for the full configuration matrix.

Workflow Tools

  • workflow_requirement_to_issue: analyze a requirement and create a GitLab issue

  • workflow_review_mr_post_comment: review a target merge request and post a review comment

  • workflow_issue_to_delivery: start from an existing issue and complete branch -> code change -> MR -> issue comment -> issue log

  • workflow_requirement_to_delivery: run the full end-to-end flow from a requirement

Atomic GitLab Tools

Issue tools fall back to WORKFLOW_ISSUE_PROJECT_ID by default, while code and merge request tools fall back to WORKFLOW_CODE_PROJECT_ID.

  • Users and labels: gitlab_get_current_user, gitlab_list_labels, gitlab_create_label, gitlab_update_label, gitlab_delete_label

  • Issues: gitlab_create_issue, gitlab_get_issue, gitlab_get_issue_notes, gitlab_add_issue_comment, gitlab_get_issue_images

  • Repository: gitlab_create_branch, gitlab_get_file, gitlab_commit_files, gitlab_upload_project_file

  • Merge requests: gitlab_get_merge_request, gitlab_get_mr_notes, gitlab_create_merge_request, gitlab_create_mr_note, gitlab_get_mr_changes, gitlab_approve_mr, gitlab_unapprove_mr

Related MCP server: GitLab MCP Server

2. Example

Using workflow_requirement_to_delivery as an example, it is best to explicitly name the tool in your prompt or wrap it in a higher-level custom instruction / skill so the LLM can reliably choose the intended workflow.

Input

Use workflow_requirement_to_delivery to add a forum interaction feature

Result

The workflow can automatically complete the flow below:

requirement analysis -> issue creation -> branch -> code change -> MR -> issue update

image-1

(1) Issue creation

Issue creation

(2) Code changes and MR submission based on the issue

MR

(3) Issue comment

Issue comment

(4) Local issue-log.md

issue-log.md

With this workflow, a developer can hand a requirement or an assigned issue directly to an agent and let it complete the full development flow in an issue-driven way.

3. Configuration

3.1 NPX

{
  "mcpServers": {
    "gitlab-workflow": {
      "command": "npx",
      "args": ["-y", "@chntif/mcp-gitlab-workflow"],
      "env": {
        "GITLAB_TOKEN": "YOUR_TOKEN",
        "GITLAB_API_BASE_URL": "https://gitlab.com/api/v4",
        "WORKFLOW_ISSUE_PROJECT_ID": "82346102",
        "WORKFLOW_ISSUE_PROJECT_PATH": "tchen1690/test",
        "WORKFLOW_CODE_PROJECT_ID": "82346102",
        "WORKFLOW_CODE_PROJECT_PATH": "tchen1690/test",
        "WORKFLOW_BASE_BRANCH": "develop",
        "WORKFLOW_TARGET_BRANCH": "develop",
        "WORKFLOW_LOCAL_REMOTE_NAME": "origin"
      }
    }
  }
}

3.2 Codex

(1) Add from the terminal

codex mcp add gitlab-workflow \
  --env GITLAB_TOKEN=YOUR_TOKEN \
  --env GITLAB_API_BASE_URL=https://gitlab.com/api/v4 \
  --env WORKFLOW_ISSUE_PROJECT_ID=80376102 \
  --env WORKFLOW_ISSUE_PROJECT_PATH=tchen1690/test \
  --env WORKFLOW_CODE_PROJECT_ID=80376102 \
  --env WORKFLOW_CODE_PROJECT_PATH=tchen1690/test \
  --env WORKFLOW_BASE_BRANCH=develop \
  --env WORKFLOW_TARGET_BRANCH=develop \
  --env WORKFLOW_LOCAL_REMOTE_NAME=origin \
  -- npx -y @chntif/mcp-gitlab-workflow

(2) Or add it to config.toml

[mcp_servers.gitlab-workflow]
command = "npx"
args = ["-y", "@chntif/mcp-gitlab-workflow"]

[mcp_servers.gitlab-workflow.env]
GITLAB_TOKEN = "YOUR_TOKEN"
GITLAB_API_BASE_URL = "https://gitlab.com/api/v4"
WORKFLOW_ISSUE_PROJECT_ID = "80376102"
WORKFLOW_ISSUE_PROJECT_PATH = "tchen1690/test"
WORKFLOW_CODE_PROJECT_ID = "80376102"
WORKFLOW_CODE_PROJECT_PATH = "tchen1690/test"
WORKFLOW_BASE_BRANCH = "develop"
WORKFLOW_TARGET_BRANCH = "develop"
WORKFLOW_LOCAL_REMOTE_NAME = "origin"

3.3 Claude Code

claude mcp add gitlab-workflow \
  -e GITLAB_TOKEN=YOUR_TOKEN \
  -e GITLAB_API_BASE_URL=https://gitlab.com/api/v4 \
  -e WORKFLOW_ISSUE_PROJECT_ID=80376102 \
  -e WORKFLOW_ISSUE_PROJECT_PATH=tchen1690/test \
  -e WORKFLOW_CODE_PROJECT_ID=80376102 \
  -e WORKFLOW_CODE_PROJECT_PATH=tchen1690/test \
  -e WORKFLOW_BASE_BRANCH=develop \
  -e WORKFLOW_TARGET_BRANCH=develop \
  -e WORKFLOW_LOCAL_REMOTE_NAME=origin \
  -- npx -y @chntif/mcp-gitlab-workflow

You can also directly write the configuration in 3.1 into Claude Code's configuration file.

3.4 Local startup

{
  "mcpServers": {
    "gitlab-workflow": {
      "command": "node",
      "args": ["/gitlab-workflow-server/dist/src/server.js"],
      "env": {
        "GITLAB_TOKEN": "YOUR_TOKEN",
        "GITLAB_API_BASE_URL": "https://gitlab.com/api/v4",
        "WORKFLOW_ISSUE_PROJECT_ID": "82346102",
        "WORKFLOW_ISSUE_PROJECT_PATH": "tchen1690/test",
        "WORKFLOW_CODE_PROJECT_ID": "82346102",
        "WORKFLOW_CODE_PROJECT_PATH": "tchen1690/test",
        "WORKFLOW_BASE_BRANCH": "develop",
        "WORKFLOW_TARGET_BRANCH": "develop",
        "WORKFLOW_LOCAL_REMOTE_NAME": "origin"
      }
    }
  }
}

3.5 About uv/uvx

This project is a Node.js package. npx is the recommended way to run it.

4. Environment Variables

Parameter resolution order:

tool args -> user-provided env -> built-in defaults

If the user does not explicitly pass a parameter such as project_id, the tool can use runtime configuration from environment variables. Some variables also have built-in defaults.

Environment Variable

Purpose

Default

Required

GITLAB_TOKEN

GitLab API access token used by the server and all GitLab operations

None

Yes

GITLAB_API_BASE_URL

Base URL for the GitLab API

https://gitlab.com/api/v4

No

WORKFLOW_ISSUE_PROJECT_ID

Default target project ID for issue-related tools

None

No

WORKFLOW_ISSUE_PROJECT_PATH

Default issue project path used in templates and references

None

No

WORKFLOW_CODE_PROJECT_ID

Default target project ID for repository, branch, commit, and MR tools

None

No

WORKFLOW_CODE_PROJECT_PATH

Default code project path used in templates, logs, and output

None

No

WORKFLOW_BASE_BRANCH

Default base branch used before creating a new delivery branch

develop

No

WORKFLOW_TARGET_BRANCH

Default merge request target branch

develop

No

WORKFLOW_LOCAL_REMOTE_NAME

Default git remote used by local git workflows

origin

No

WORKFLOW_LABEL

Default issue title prefix and fallback label

None

No

WORKFLOW_ASSIGNEE_USERNAME

Default assignee username for issues and merge requests

None

No

WORKFLOW_ISSUE_LOG_PATH

Path of the local issue log file

issue-log.md

No

WORKFLOW_UPDATE_ISSUE_LOG

Whether delivery workflows update the local issue log by default

true

No

WORKFLOW_DELIVERY_METHOD

Default delivery mode, supports local_git and remote_api

local_git

No

WORKFLOW_CHECKOUT_LOCAL_BRANCH

Whether remote_api delivery should sync and checkout the created branch locally

false

No

WORKFLOW_LOCK_ISSUE_PROJECT_ID

Restrict issue operations to a fixed issue project ID

None

No

WORKFLOW_LOCK_CODE_PROJECT_ID

Restrict code and MR operations to a fixed code project ID

None

No

  • GITLAB_TOKEN, GITLAB_API_BASE_URL: required to connect to GitLab

  • WORKFLOW_ISSUE_PROJECT_ID, WORKFLOW_CODE_PROJECT_ID: define the issue project and code project, and can point to the same project

  • WORKFLOW_ISSUE_PROJECT_PATH, WORKFLOW_CODE_PROJECT_PATH: improve rendered references and display output, but are optional

  • WORKFLOW_BASE_BRANCH, WORKFLOW_TARGET_BRANCH: should follow your team branching strategy

  • WORKFLOW_LOCAL_REMOTE_NAME: usually origin

If a specific operation should target values different from your default environment configuration, passing explicit tool arguments will override the configured values.

5. License

MIT

Available Tools

28 tools
gitlab_add_issue_commentA

Create issue note/comment. Supports direct body or auto-generation from MR changed files (by MR IID or source branch).

Inputs: project_id, issue_iid, body, auto_generate_from_mr_changes, +7 more. Returns: ok, tool, data, error_type, +1 more

gitlab_approve_mrB

Approve merge request by GitLab approval API.

Inputs: project_id, mr_iid, sha. Returns: ok, tool, data, error_type, +1 more

gitlab_commit_filesB

Create one commit with multiple file actions via GitLab commits API.

Inputs: project_id, branch, commit_message, start_branch, +1 more. Returns: ok, tool, data, error_type, +1 more

gitlab_create_branchB

Create repository branch by GitLab REST API.

Inputs: project_id, branch, ref. Returns: ok, tool, data, error_type, +1 more

gitlab_create_issueB

Create an issue with GitLab REST API /projects/:id/issues.

Inputs: project_id, title, description, labels, +7 more. Returns: ok, tool, data, error_type, +1 more

gitlab_create_labelB

Create a project label (/projects/:id/labels).

Inputs: project_id, name, color, description, +1 more. Returns: ok, tool, data, error_type, +1 more

gitlab_create_merge_requestB

Create merge request by GitLab REST API /projects/:id/merge_requests.

Inputs: project_id, source_branch, target_branch, title, +10 more. Returns: ok, tool, data, error_type, +1 more

gitlab_create_mr_noteC

Create merge-request note/comment.

Inputs: project_id, mr_iid, body. Returns: ok, tool, data, error_type, +1 more

gitlab_delete_labelB

Delete a project label (/projects/:id/labels/:label_id).

Inputs: project_id, label_name. Returns: ok, tool, data, error_type, +1 more

gitlab_get_current_userA

Get current authenticated GitLab user (/user).

Inputs: no named parameters. Returns: ok, tool, data, error_type, +1 more

gitlab_get_fileB

Get repository file by GitLab REST API /repository/files/:file_path.

Inputs: project_id, file_path, ref. Returns: ok, tool, data, error_type, +1 more

gitlab_get_issueB

Get one issue by project_id + issue_iid.

Inputs: project_id, issue_iid. Returns: ok, tool, data, error_type, +1 more

gitlab_get_issue_imagesA

Extract image references from issue description/notes. When include_base64=true, download each image, return base64 metadata, and attach MCP image content blocks so the model can inspect the image itself.

Inputs: project_id, issue_iid, include_notes, include_base64, +1 more. Returns: ok, tool, data, error_type, +1 more

gitlab_get_issue_notesB

Get issue notes/comments by project_id + issue_iid.

Inputs: project_id, issue_iid, sort, order_by. Returns: ok, tool, data, error_type, +1 more

gitlab_get_merge_requestB

Get merge request detail (/projects/:id/merge_requests/:mr_iid).

Inputs: project_id, mr_iid. Returns: ok, tool, data, error_type, +1 more

gitlab_get_mr_changesB

Get merge request changes/diff metadata.

Inputs: project_id, mr_iid. Returns: ok, tool, data, error_type, +1 more

gitlab_get_mr_notesC

Get merge request notes/comments (/projects/:id/merge_requests/:mr_iid/notes).

Inputs: project_id, mr_iid, sort, order_by. Returns: ok, tool, data, error_type, +1 more

gitlab_list_labelsB

List labels of a GitLab project (/projects/:id/labels).

Inputs: project_id, search, page, per_page, +2 more. Returns: ok, tool, data, error_type, +1 more

gitlab_unapprove_mrB

Remove approval from merge request.

Inputs: project_id, mr_iid. Returns: ok, tool, data, error_type, +1 more

gitlab_update_labelB

Update a project label (/projects/:id/labels).

Inputs: project_id, name, new_name, color, +2 more. Returns: ok, tool, data, error_type, +1 more

gitlab_upload_project_fileB

Upload binary file to project markdown uploads and return markdown/url metadata.

Inputs: project_id, filename, content_base64, content_type. Returns: ok, tool, data, error_type, +1 more

workflow_issue_log_appendA

Use when only local issue log markdown should be appended. This tool does not create MR or commit.

Inputs: issue_title (required), issue_iid (required), issue_web_url (required), branch_name (required), +8 more. Returns: ok, tool, data, error_type, +1 more

workflow_issue_to_deliveryA

Use when an existing issue_iid should be delivered end-to-end: branch, commit, MR, issue comment, local sync, and issue log. Before composing commit_actions, first call workflow_prepare_delivery_workspace and use its preparation_key here. Then inspect the issue text and any screenshots. If the issue may contain image references, call gitlab_get_issue_images(project_id, issue_iid, include_base64=true) first and review the returned image blocks. Do not call this twice for the same issue or same user request. If the issue and MR may already exist, inspect GitLab first before retrying.

Inputs: preparation_key (required), issue_iid (required), change_summary (required), test_plan (required), +22 more. Returns: ok, tool, data, error_type, +1 more

workflow_prepare_delivery_workspaceA

Use before delivery workflows. Pass the explicit local repo_path for the target project. This tool verifies a clean local repo, refreshes the latest base branch, and returns a preparation_key that workflow_issue_to_delivery/workflow_requirement_to_delivery must provide. When delivery_method=local_git, it also creates and checks out the local working branch where code changes should be made.

Inputs: repo_path (required), delivery_method, remote_name, base_branch, +5 more. Returns: ok, tool, data, error_type, +1 more

workflow_requirement_to_deliveryA

Use when requirement text should run the full chain once: create issue, then continue in the same workflow through branch, commit, MR, issue comment, local sync, and issue log. Before composing commit_actions, first call workflow_prepare_delivery_workspace and use its preparation_key here. Do not combine this with workflow_requirement_to_issue or workflow_issue_to_delivery for the same user request.

Inputs: requirement_text (required), preparation_key (required), change_summary (required), test_plan (required), +28 more. Returns: ok, tool, data, error_type, +1 more

workflow_requirement_to_issueA

Use when requirement text should only create a GitLab issue and stop there. Do not combine this with workflow_requirement_to_delivery for the same user request. If the issue is already created, continue with workflow_issue_to_delivery instead of calling this tool again.

Inputs: requirement_text (required), source_text, issue_template, template_variables, +13 more. Returns: ok, tool, data, error_type, +1 more

workflow_review_mr_post_commentA

Two-step MR review workflow. Step 1: call with prepare_review_context=true to fetch review_prompt + diffs for LLM review. Step 2: let the LLM inspect that context, then call again with review_comment_body to post the final review comment (optional approval).

Inputs: mr_iid (required), code_project_id, review_comment_body, prepare_review_context, +7 more. Returns: ok, tool, data, error_type, +1 more

workflow_sync_local_branchA

Use when local repository should fetch/pull and switch to a target branch. Local git operations only.

Inputs: branch_name (required), repo_path (required), remote_name, base_branch. Returns: ok, tool, data, error_type, +1 more

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

Loading tool schema changelog…

    TDQS

    B3.3/5.0

    Scored across 28 tools

    Disambiguation4/5

    Most tools have distinct purposes targeting specific GitLab resources (issues, MRs, labels, files). A few potential overlaps exist (e.g., gitlab_add_issue_comment vs gitlab_create_mr_note) but they apply to different resources, and descriptions clarify the difference.

    Naming Consistency3/5

    Tools use two prefixes ('gitlab_' and 'workflow_'), creating a split. Within each prefix, naming follows verb_noun pattern, but verbs are inconsistent (e.g., 'add' vs 'create', 'get' vs 'list'). Overall pattern is present but not uniform.

    Tool Count4/5

    28 tools cover both low-level GitLab API actions and high-level workflow orchestrations, which is appropriate for a full-featured workflow server. While on the higher side, each tool serves a distinct role.

    Completeness3/5

    Core operations for issues, MRs, labels, and files are covered, but notable gaps exist: no tool to list issues, no update issue tool, and no delete for issues/MRs. The high-level workflows partially compensate but leave some CRUD incomplete.

    Maintenance

    ActivityInactive
    ResponsivenessNo recent community issues

    Related MCP Connectors

    Related MCP Servers

    • 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.
      45
      170,164 npm
      1
      MIT
    • A
      license
      C
      quality
      B
      maintenance
      A production-ready MCP server for GitLab enabling AI assistants to read and manage GitLab projects, merge requests, issues, pipelines, wikis, releases, and more through a unified interface.
      268
      1,908 npm
      10
      MIT
    • A
      license
      Not graded
      quality
      D
      maintenance
      An MCP server that enables AI agents to perform automated code reviews on GitLab merge requests, including fetching details, reading diffs, posting inline comments, managing labels, and approving or unapproving MRs.
      1,908 npm
      MIT