mcp-gitlab-workflow
Provides tools for issue-driven GitLab development, including workflows for requirement analysis, issue creation, branching, coding, merge request creation, and issue updates, as well as atomic GitLab API tools for custom orchestration.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@mcp-gitlab-workflow Use workflow_requirement_to_delivery to add a forum interaction feature"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
mcp-gitlab-workflow
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 callgitlab_*: 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 issueworkflow_review_mr_post_comment: review a target merge request and post a review commentworkflow_issue_to_delivery: start from an existing issue and complete branch -> code change -> MR -> issue comment -> issue logworkflow_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_labelIssues:
gitlab_create_issue,gitlab_get_issue,gitlab_get_issue_notes,gitlab_add_issue_comment,gitlab_get_issue_imagesRepository:
gitlab_create_branch,gitlab_get_file,gitlab_commit_files,gitlab_upload_project_fileMerge 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

(1) Issue creation

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

(3) Issue comment

(4) Local 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-workflowYou 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 API access token used by the server and all GitLab operations | None | Yes |
| Base URL for the GitLab API |
| No |
| Default target project ID for issue-related tools | None | No |
| Default issue project path used in templates and references | None | No |
| Default target project ID for repository, branch, commit, and MR tools | None | No |
| Default code project path used in templates, logs, and output | None | No |
| Default base branch used before creating a new delivery branch |
| No |
| Default merge request target branch |
| No |
| Default git remote used by local git workflows |
| No |
| Default issue title prefix and fallback label | None | No |
| Default assignee username for issues and merge requests | None | No |
| Path of the local issue log file |
| No |
| Whether delivery workflows update the local issue log by default |
| No |
| Default delivery mode, supports |
| No |
| Whether |
| No |
| Restrict issue operations to a fixed issue project ID | None | No |
| Restrict code and MR operations to a fixed code project ID | None | No |
Recommended configuration
GITLAB_TOKEN,GITLAB_API_BASE_URL: required to connect to GitLabWORKFLOW_ISSUE_PROJECT_ID,WORKFLOW_CODE_PROJECT_ID: define the issue project and code project, and can point to the same projectWORKFLOW_ISSUE_PROJECT_PATH,WORKFLOW_CODE_PROJECT_PATH: improve rendered references and display output, but are optionalWORKFLOW_BASE_BRANCH,WORKFLOW_TARGET_BRANCH: should follow your team branching strategyWORKFLOW_LOCAL_REMOTE_NAME: usuallyorigin
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 toolsgitlab_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
Scored across 28 tools
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.
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.
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.
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
Related MCP Connectors
A MCP server built for developers enabling Git based project management with project and personal…
Go MCP server for GitLab: 2 dynamic tools reach 1000+ REST/GraphQL actions. Free/CE, no paid tier.
MCP server for generating rough-draft project plans from natural-language prompts.
Related MCP Servers
- AlicenseCqualityDmaintenanceAn MCP server that enables communication with GitLab repositories, allowing interaction with GitLab's API to manage projects, issues, and repositories through natural language.45170,164 npm1MIT
- AlicenseNot gradedqualityDmaintenanceAn MCP server for the GitLab API that enables comprehensive project management, file operations, and issue tracking. It supports automated branch creation, batch file pushes, and interaction with merge requests and CI/CD logs.MIT
- AlicenseCqualityBmaintenanceA 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.2681,908 npm10MIT
- AlicenseNot gradedqualityDmaintenanceAn 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 npmMIT